3 ms·

They do seem to be doing really nice things. And from time to time I try to keep up, watching videos on new tools and things. But I guess I always get hung up

They do seem to be doing really nice things. And from time to time I try to keep up, watching videos on new tools and things. But I guess I always get hung up on the idea that you should just write in the language that you're targeting, and I wonder about the cost of the (admittedly pretty nice) developer experience of cljs. When you have a bug in production you're stuck debugging the generated JS. This was also my problem with CoffeeScript.

yogthos 11y ago
I've been using ClojureScript in production for about a year now. The runtime is very fast, and in some cases it actually outperforms native Js. For example, both Om and Reagent are actually faster than React.js itself (http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s). Debugging story is very good. You pretty much never have to see the generated JavaScript. ClojureScript uses source maps, so any errors in the compiled Js will map back to the original ClojureScript source that caused them. Chrome dev tools even do syntax highlighting for ClojureScript now. Having a live dev environment with Figwheel and a REPL goes a long way here as well. You can inspect a lot of things at runtime very easily. Using immutable data structures by default avoids a lot of the debugging pain as well. You practically never have to trace through a bunch of function calls to find the problem. In most cases the problem is exactly on the line where the error occurred.
- draw_down 11y ago
  What if your thing crashes in IE?
  - yogthos 11y ago
    IE 11 supports source maps, so that's helpful. The other nice thing is that you rarely end up dealing with browser specific quirks since all popular ClojureScript libraries piggie back on React.js and the Google Closure library. These do a great job of handling the platform specific quirks for you. The first app I developed with Reagent actually had to run on IE8, and to my shock and surprised worked without any issues after I added the standard IE shims. So, overall my experience is that you're better off dealing with IE than with most Js frameworks.
freshhawk 11y ago
I used to agree with you about writing in the language you are targeting, really strongly agreed. Coffeescript, for example, was something I never took seriously. Clojurescript, and core.async in particular, changed my mind. It has converted me completely. The debugging issue is much less of an issue than I expected, since other methods of problem solving make more sense in a clojure context than breakpoint style line by line debugging. Of course sometimes you do need to drop to that level, and it is a bit of a learning curve to debug the generated js, even with the great source maps, but it's not that bad. Overall I am still more productive by a big margin, and it's more enjoyable.

yogthos 11y ago

I've been using ClojureScript in production for about a year now. The runtime is very fast, and in some cases it actually outperforms native Js. For example, both Om and Reagent are actually faster than React.js itself (http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s). Debugging story is very good. You pretty much never have to see the generated JavaScript. ClojureScript uses source maps, so any errors in the compiled Js will map back to the original ClojureScript source that caused them. Chrome dev tools even do syntax highlighting for ClojureScript now. Having a live dev environment with Figwheel and a REPL goes a long way here as well. You can inspect a lot of things at runtime very easily. Using immutable data structures by default avoids a lot of the debugging pain as well. You practically never have to trace through a bunch of function calls to find the problem. In most cases the problem is exactly on the line where the error occurred.

draw_down 11y ago
What if your thing crashes in IE?
- yogthos 11y ago
  IE 11 supports source maps, so that's helpful. The other nice thing is that you rarely end up dealing with browser specific quirks since all popular ClojureScript libraries piggie back on React.js and the Google Closure library. These do a great job of handling the platform specific quirks for you. The first app I developed with Reagent actually had to run on IE8, and to my shock and surprised worked without any issues after I added the standard IE shims. So, overall my experience is that you're better off dealing with IE than with most Js frameworks.

freshhawk 11y ago

I used to agree with you about writing in the language you are targeting, really strongly agreed. Coffeescript, for example, was something I never took seriously. Clojurescript, and core.async in particular, changed my mind. It has converted me completely. The debugging issue is much less of an issue than I expected, since other methods of problem solving make more sense in a clojure context than breakpoint style line by line debugging. Of course sometimes you do need to drop to that level, and it is a bit of a learning curve to debug the generated js, even with the great source maps, but it's not that bad. Overall I am still more productive by a big margin, and it's more enjoyable.