4 ms·

Neat! Now look at: https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript And try it: http://himera.herokuapp.com/index.html http:/

Neat! Now look at: https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript And try it: http://himera.herokuapp.com/index.html http://himera.herokuapp.com/index.html

zupatol 11y ago
Clojurescript has to be compiled by the google closure compiler on the server side. The closure compiler doesn't work out of the box with other libraries, you need some kind of bridge. Lispyscript has the very nice advantage of being able to run directly in the browser. Since it's translated directly to javascript, I expect it won't have problems using other javascript libraries.
- swannodette 11y ago
  Some inaccuracies here. ClojureScript does not have to be compiled by Google Closure. That pass is an optional one for production builds. There is no "bridging" when using the Closure Compiler with non-Closure compatible code. The issue is that in production mode the Closure Compiler will make aggressive assumptions about what it can rename. So it's not about bridging it's about preventing renaming - again this is only relevant for advanced production builds. That said for non-Web applications or applications where advanced compilation isn't that useful providing a bootstrapped ClojureScript is desirable. We've been working on that slowly for a long time now. In the coming months you'll see changes such that the ClojureScript compiler can itself be compiled into JavaScript.
  - didyoucheckthe 11y ago
    > "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
    - moron4hire 11y ago
      This needs to be stressed. Performance in mobile web is already bad enough. If a tool has an optional, manual "improve performance" step, that is bad, it needs to be the default case and it needs to be a good citizen within the environment.
    - swannodette 11y ago
      Not really. Advanced optimizations doesn't matter for server-side JS whether Node.js or Nashorn.
    - moonchrome 11y ago
      Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts. You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics. But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.
      - minikomi 11y ago
        Things are progressing and I encourage you to have another look. $ lein new figwheel myproject $ cd myproject $ rlwrap lein figwheel Browse to http://localhost:3449 If you return to the terminal, you should have a connected REPL now running. Along with live code reloading on save of your cljs files.
        girvo 11y ago
        Oh wow, that's a lot nicer than the last time I played with Clojure/ClojureScript. This plus Om makes me really want to play with it now.
  - zupatol 11y ago
    It seems I got many things wrong about ClojureScript. If I don't use the closure compiler, can I use any requirejs javascript library without problem? Once you have the JavaScript version of the ClojureScript compiler, will it be reasonable to use it for compiling in the browser? That would be great.
    - swannodette 11y ago
      There's very little in the JavaScript world that can't be made to work with ClojureScript. That said it could be made easier and official support for CommonJS and RequireJS is underway thanks to Maria Neise's Google Summer of Code work.
- lewisl9029 11y ago
  Yes there are additional steps involved for working with the Closure compiler, but in return, you get extremely robust dead-code elimination for your own code and third party code alike. This turns out to be invaluable in production because most projects only realistically use a handful of functions from utility libraries that tend to be 10s of KBs in size.

Neat! Now look at: https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript And try it: http://himera.herokuapp.com/index.html http://himera.herokuapp.com/index.html

zupatol 11y ago

Clojurescript has to be compiled by the google closure compiler on the server side. The closure compiler doesn't work out of the box with other libraries, you need some kind of bridge. Lispyscript has the very nice advantage of being able to run directly in the browser. Since it's translated directly to javascript, I expect it won't have problems using other javascript libraries.

swannodette 11y ago
Some inaccuracies here. ClojureScript does not have to be compiled by Google Closure. That pass is an optional one for production builds. There is no "bridging" when using the Closure Compiler with non-Closure compatible code. The issue is that in production mode the Closure Compiler will make aggressive assumptions about what it can rename. So it's not about bridging it's about preventing renaming - again this is only relevant for advanced production builds. That said for non-Web applications or applications where advanced compilation isn't that useful providing a bootstrapped ClojureScript is desirable. We've been working on that slowly for a long time now. In the coming months you'll see changes such that the ClojureScript compiler can itself be compiled into JavaScript.
- didyoucheckthe 11y ago
  > "again this is only relevant for advanced production builds" So, all real-life builds that anyone would care about.
  - moron4hire 11y ago
    This needs to be stressed. Performance in mobile web is already bad enough. If a tool has an optional, manual "improve performance" step, that is bad, it needs to be the default case and it needs to be a good citizen within the environment.
  - swannodette 11y ago
    Not really. Advanced optimizations doesn't matter for server-side JS whether Node.js or Nashorn.
  - moonchrome 11y ago
    Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts. You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics. But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.
    - minikomi 11y ago
      Things are progressing and I encourage you to have another look. $ lein new figwheel myproject $ cd myproject $ rlwrap lein figwheel Browse to http://localhost:3449 If you return to the terminal, you should have a connected REPL now running. Along with live code reloading on save of your cljs files.
      - girvo 11y ago
        Oh wow, that's a lot nicer than the last time I played with Clojure/ClojureScript. This plus Om makes me really want to play with it now.
- zupatol 11y ago
  It seems I got many things wrong about ClojureScript. If I don't use the closure compiler, can I use any requirejs javascript library without problem? Once you have the JavaScript version of the ClojureScript compiler, will it be reasonable to use it for compiling in the browser? That would be great.
  - swannodette 11y ago
    There's very little in the JavaScript world that can't be made to work with ClojureScript. That said it could be made easier and official support for CommonJS and RequireJS is underway thanks to Maria Neise's Google Summer of Code work.
lewisl9029 11y ago
Yes there are additional steps involved for working with the Closure compiler, but in return, you get extremely robust dead-code elimination for your own code and third party code alike. This turns out to be invaluable in production because most projects only realistically use a handful of functions from utility libraries that tend to be 10s of KBs in size.