Fork me on GitHub
#clojurescript
<
2016-05-03
>
ctford08:05:55

Would it be a silly idea to make cljs.js cross-platform, using Nashorn on JVM?

ctford08:05:08

At the moment there's a .clj version, but it's only for macros.

ctford08:05:04

The specific use-case I'm looking at is pre-compiling Clojurescript to save redundant computation in the browser.

borkdude08:05:23

@ctford: do you want it for pre-rendering?

ctford08:05:11

In my case, I want it to prime a compiler state.

ctford08:05:36

I'm compiling cljs in the browser, and want to precompile the namespaces I require.

ctford08:05:48

But it could also be useful for progressive enhancement.

ctford08:05:58

Thinking about it, it's more work than I'd considered, because you'd need to make the namespaces that cljs.js depends on .cljc as well.

thheller09:05:02

@ctford compiling cljs in the browser is a terrible idea as the compiler is quite huge to download

thheller09:05:35

if you are going to talk to the server anyways .. do all the compilation there

darwin09:05:51

in the year 2100 compiling cljs in the browser does not sound like a terrible idea, pretty much everyone does that

thheller10:05:03

by then the browser will understand cljs without a compiler 😉

ctford10:05:58

@thheller: I have quite a particular use case, with user supplied code. http://ctford.github.io/klangmeister/

ctford10:05:54

@thheller: It makes my app.js ~900kb, which is large.

thheller10:05:14

ah I guess I misunderstood, you are not talking to the server

ctford10:05:10

@thheller: My concept was, precompile a CLJS compiler state during the original compilation.

thheller10:05:24

you can't really do that

thheller10:05:32

as the compiler state is much much much larger than that

ctford10:05:33

@thheller: That way, the browser's "start-up" compilation is much faster.

thheller10:05:43

we are talking 30mb+

ctford10:05:08

@thheller: Oh, I hadn't realised. So even if it saved me compute time on the browser, it would blow out the download size.

thheller10:05:23

yes as the compiler state keeps a lot of "meta" information

thheller10:05:56

the :cljs.analyzer/namespaces thingy .. remembers all vars and stuff

risto10:05:45

What about making java optional for ClojureScript? since it can now compile itself, and since everything that is compiled is JavaScript, it's seems possible to do this

risto10:05:59

Basically treating it like any other transpiler that you would add to a Node project

ctford10:05:10

@risto: It's technically feasible, but not presently a goal.

thheller10:05:23

@risto not a goal of clojurescript since one of the biggest selling points (at least for me) is the closure compiler

ctford10:05:43

@risto: Clojurescript relies on the Google Closure Compiler to eliminate dead code, as @thheller says.

risto10:05:48

Why wouldn't it still be able to use the closure compiler?

risto10:05:04

the closure compiler?

thheller10:05:23

well technically you could do all cljs compilation without the closure compiler

thheller10:05:36

BUT cljs on clj is still quite a lot faster than cljs on cljs

risto10:05:46

Ah , I see...

thheller11:05:28

@ctford as for the compilation state .. the compiler needs to analyze cljs.core and others

thheller11:05:35

this builds up quite a lot of state

thheller11:05:47

you could serialize that

thheller11:05:50

but it is huge

thheller11:05:25

cljs.core alone is 3.6mb as transit json

acron11:05:20

Is it true to believe that atoms in Clojurescript don't have/require concurrency safety mechanisms because current JS implementations are all single-threaded?

acron11:05:08

So what do atoms give you that volatile! doesn't? Just watches?

acron11:05:26

Cool, that was easy. Thanks thheller

thheller11:05:20

np. I've been using volatile! a lot myself in places I don't want watches

bojan.matic12:05:01

where can i find documentation on how to do ajax requests?

bojan.matic12:05:31

for example, in that answer the function GET is mentioned, but where does that function come from? is it a library? built-in? what about other types of requests?

kingoftheknoll12:05:42

Depends on the interface you want, some are callback based and some promise based. I used Httpurr which is promise based. Cljs-Ajax is used callback and I think it's the one references in the SO answer.

bojan.matic12:05:59

which would you recommend?

kingoftheknoll12:05:26

I've found being able to pass around a promise value helps me have better code separation.

kingoftheknoll12:05:15

In my daily JS work I was bit in the ass by taking a callback approach on an interface before lol don't know it feels cleaner

kingoftheknoll12:05:10

Httpurr has been nice for that reason.

bojan.matic12:05:24

yeah ofc, in js promises > callbacks

dnolen12:05:36

@bojan.matic: I recommend looking at how XhrIo in Google Closure works first, then decide which library you want to use.

dnolen12:05:54

most things are just thinnish wrappers around XhrIo

dnolen12:05:05

also while promises are certainly valid way to deal with asynchrony - I would imagine core.async is probably more popular here if you don’t want callback code.

dnolen12:05:38

@risto it’s already been done by the wider community - there are stand alone things on the web, for OS X / iOS, and there is a nascent Node.js thing.

dnolen13:05:21

@ctford to your earlier point - I don’t see any reason why that shouldn’t work - but haven’t done signficant testing under Nashorn - mostly because warmup takes an unreasonable amount of time.

sivakumargsk13:05:01

How to write this expression in clojurescript. chart.defaultColors = [ new dimple.color("orange") ];

jheadapohl13:05:38

maybe… (set! (.-defaultColors js/chart) (array (js/dimple.color. “orange”)))

bojan.matic14:05:00

@dnolen: thanks, will take a look into XhrIo

bojan.matic14:05:08

@dnolen: would you say that Cljs-Ajax is a better choice if one wants to use core.async?

dnolen14:05:30

@bojan.matic: no idea since I do not use cljs-ajax

roberto14:05:01

i don’t think cljs-ajax plays well with core.async. I’ve found cljs-http a better fit.

roberto14:05:30

mostly because when I tried to use cljs-ajax, you had to provide a ‘success handler’

jrychter19:05:06

Hmm. My ClojureScript app is 1.4MB. I think it's time to think about modularity and loading things on demand.

blissdev19:05:35

advanced compile + gzip?

jrychter19:05:34

That's with advanced compilation, uncompressed .js. Unfortunately a large part of that is semantic-ui's JavaScript, which can't go through advanced compilation. And the silly jquery dependency (260kB right there) 😕

blissdev19:05:47

ah yeah, that doesn’t help

richiardiandrea19:05:10

I was actually considering SemanticUI for my next app, why can't it go through :advanced compilation?

jrychter19:05:28

I do recommend using SemanticUI. It's a fantastic toolkit for complex apps, and fits very well with ClojureScript+Rum+React. But its JavaScript isn't prepared for advanced compilation.

jrychter19:05:46

I'm not even using that much JavaScript from Semantic UI — it's mostly CSS that I'm happy with. I think I'm using dropdown and popup only. I plan to replace that JavaScript, but so far this didn't make much sense.

richiardiandrea19:05:19

Yes that is what I mean, from what I heard you usually use CSS of it, but still you pay the cost of the JS?

jrychter19:05:31

No, you can use CSS only. But certain things need JavaScript to function. Like dropdown or popup. If I got rid of that JavaScript, I could use just the CSS. BTW, that JavaScript isn't that helpful in a React app anyway.

richiardiandrea19:05:28

Yes because you have to wrap it right? I once tried out soda-ash, which is very cool but supports CSS-only components

richiardiandrea19:05:50

the rest needs wrapping and form-3 reagent management

richiardiandrea19:05:13

(aka mixins in Rum)

Nicolas Boskovic19:05:26

I think SemanticUI is pretty handy for its page structuring

jrychter19:05:51

Well, it doesn't expect being included in a React component. And some of it (popup) expects to be able to freely modify the DOM, which simply won't work. Fortunately there is an option to manage the DOM modifications yourself (include popup content in the DOM yourself). You end up writing lots of mixins, and it's difficult to generalize/modularize this code.

jrychter19:05:55

Still, it gets the job done, and it's the most complete toolkit I found. See https://partsbox.io/ for an app that uses it extensively.

richiardiandrea19:05:43

how do you manage the string concatenation of class? soda-ash does this very well

jrychter19:05:49

I'm not sure I see the problem?

jrychter19:05:44

If you mean dynamically managing the list of classes, sablono deals with this very well, apart from the [:div.class1.class2] you can also pass a {:class ["more" "classes" "vector"]}, which can be dynamically built.

Nicolas Boskovic19:05:42

Yes, that's how I'm handling classes

Nicolas Boskovic19:05:16

You can also use reagent atoms to read those classes, as well

richiardiandrea19:05:41

@jrychter: yes I was exactly thinking about that

richiardiandrea19:05:57

@nnbosko: can you paste an example of that, just for curiosity 😉

Nicolas Boskovic20:05:22

that's not particularly dynamic since you're defining it from fixed data, but

Nicolas Boskovic20:05:31

i could have it be reacting to events and changing an atom

Nicolas Boskovic20:05:53

let's see if I can find a more concrete example

richiardiandrea20:05:16

yes I was going to say that, but if you have to add a class you would have to deref the atom and recreating the class vector/string right?

richiardiandrea20:05:32

that is what soda-ash avoids from what I understood

Nicolas Boskovic20:05:09

you don't have to recreate it

Nicolas Boskovic20:05:14

but you do deref the atom

richiardiandrea20:05:43

ok so you keep the vector of classes directly in the atom then right?

Nicolas Boskovic20:05:40

I juse use a string

richiardiandrea20:05:06

yes, thanks @nnbosko, have a look at soda-ash if you haven't already, it is very cool the way it handles this

Nicolas Boskovic20:05:51

It looks interesting, but since I'm mostly dealing with the dynamic side of Semantic UI, I'm just using its JS functionality through CLJS

Nicolas Boskovic20:05:27

I understand soda-ash is more for the visual side

pataprogramming21:05:31

This is probably a frequent question, but I'm looking for a pointer to the best current starting point for setting up a CLJS dev environment, to whomp together a web UI for some real-time visualizations. I'm looking for something that can slot into my existing CIDER workflow.

pataprogramming21:05:36

There's a lot of stuff out there, but some of it looks a bit dated, so I'm hoping to get this working without too much bogging down fussing with tooling. It looks like Reagent may be the lowest-friction starting point? I messed with Om about 18 months ago, but never did anything substantial with it.

richiardiandrea21:05:21

@pataprogramming: I think reagent is a better fit for what you want to achieve, Om shines when you have a lot of data sync/network calls to perform

pataprogramming21:05:32

Thanks. Any recommendations for a tutorial?

pataprogramming21:05:00

And is figwheel definitely the way to go? I had a few issues with getting it working when I tried it, but, again, that was quite a while ago.

puhrez21:05:07

is incredible

richiardiandrea21:05:12

A lot of info is on the readme, and yes ^

richiardiandrea21:05:36

one thing, figwheel with cider is tricky

pataprogramming21:05:45

...and it's mentioning Bret Victor in tutorial 2...that looks promising.

puhrez21:05:54

the second edition uses boot, but regardless it really elucidates a lot of rather ambiguous best practices and what not

puhrez21:05:10

moreover the boot approach is very cider friendly

richiardiandrea21:05:12

So probably the fastest root is boot and boot-cljs-repl nowadays, but

richiardiandrea21:05:38

figwheel in my tests performs a bit better in the reloading

pataprogramming21:05:16

Hm. I've wanted to try boot, but have put it off because I haven't wanted to deal with porting my lein dev profile.

richiardiandrea21:05:49

oh well, if you don't have the requirement of cider integration you should be fine

pataprogramming21:05:41

Well, I'd rather not break the CIDER workflow too badly...I'm working on a project with another person who's pretty CLJS-dubious due to some previous bogging down in tools. We're both CIDER users.

richiardiandrea21:05:46

I spent some amount of time for cider+figwheel but finally I got it right in here: https://github.com/Lambda-X/replumb/blob/master/project.clj

richiardiandrea21:05:30

the {:profiles {:dev part is crucial

richiardiandrea21:05:03

and with cider > 0.11.0 you don't need to inject middlewares by yourself anymore

richiardiandrea21:05:19

so I would just jack-in and see what happens

pataprogramming21:05:55

I know! That's great. No more spending half my train commute trying to get my cider nrepl refactor version to agree they all like each other.

pataprogramming22:05:10

Sweet. I really appreciate the advice.

pataprogramming22:05:06

Have to drop offline for a bit. Thanks again.

fasiha23:05:47

@pataprogramming: I can recommend (1) the Figwheel getting started guide https://github.com/bhauman/lein-figwheel/wiki/Quick-Start for a no-magic here's-the-files-you-need-to-create approach that'll give you a taste of raw React.js from ClojureScript without the many layers of cljs wrapper code obscuring its simplicity. Then (2) I recommend reading the re-frame tutorial: https://github.com/Day8/re-frame it's a lib built on reagent which the Brave Clojure author recommends and uses (trying that as a justification 😄). Both are lein-oriented (but I don't know anything about cider)