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

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

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

Here's the primary bit you'd need to work on - https://github.com/clojure/clojurescript/blob/396a62dd360dee917ff6063608eb25ef62ff094a/src/main/cljs/cljs/js.cljs#L104

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

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

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

But it could also be useful for progressive enhancement.

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.

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

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

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

by then the browser will understand cljs without a compiler 😉

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

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

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

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

you can't really do that

as the compiler state is much much much larger than that

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

we are talking 30mb+

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

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

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

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

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

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

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

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

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

it is java

the closure compiler?

yep

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

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

Ah , I see...

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

this builds up quite a lot of state

@thheller: Good point.

you could serialize that

but it is huge

cljs.core alone is 3.6mb as transit json

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

yes

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

yes

Cool, that was easy. Thanks thheller

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

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

http://stackoverflow.com/questions/30060533/ajax-get-with-reagent

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?

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.

https://github.com/JulianBirch/cljs-ajax/blob/master/README.md

https://funcool.github.io/httpurr/latest/

nice, thanks

which would you recommend?

httpurr?

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

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

Httpurr has been nice for that reason.

yeah ofc, in js promises > callbacks

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

most things are just thinnish wrappers around XhrIo

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.

@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.

@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.

@dnolen: Thanks.

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

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

@jheadapohl: thanks its working

no problem

@dnolen: thanks, will take a look into XhrIo

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

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

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

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

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

advanced compile + gzip?

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) 😕

ah yeah, that doesn’t help

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

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.

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.

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?

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.

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

the rest needs wrapping and form-3 reagent management

(aka mixins in Rum)

I think SemanticUI is pretty handy for its page structuring

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.

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.

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

I'm not sure I see the problem?

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.

Yes, that's how I'm handling classes

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

@jrychter: yes I was exactly thinking about that

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

sure

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

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

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

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?

that is what soda-ash avoids from what I understood

you don't have to recreate it

but you do deref the atom

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

I juse use a string

just*

pretty basic

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

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

I understand soda-ash is more for the visual side

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.

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.

@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

Thanks. Any recommendations for a tutorial?

oh oh

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.

this

https://github.com/magomimmo/modern-cljs

is incredible

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

one thing, figwheel with cider is tricky

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

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

moreover the boot approach is very cider friendly

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

figwheel in my tests performs a bit better in the reloading

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.

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

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.

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

Oh, cool.

the {:profiles {:dev part is crucial

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

so I would just jack-in and see what happens

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.

Sweet. I really appreciate the advice.

Have to drop offline for a bit. Thanks again.

no problem 😉

@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)