5 ms·

It's nice to see the Clojure/ClojureScript community growing. But the fact remains that these tools still don't enjoy the maturity of their more mainstream coun

It's nice to see the Clojure/ClojureScript community growing. But the fact remains that these tools still don't enjoy the maturity of their more mainstream counterparts. So if you use any ClojureScript libraries in production, expect to run into strange issues and submit bug reports that are not responded to for months on end. Nothing against their authors, it's just the nature of writing niche tools.

swannodette 12y ago
This is not my experience. Doing JavaScript for years I mostly leaned on jQuery & Underscore.js and more recently React. ClojureScript has all the functionality of Underscore.js and a whole lot more, Google Closure I honestly find just as usable as jQuery for the cross browser bits, and finally there are several React bindings like Om. And I do a pretty darn good job of maintaining Om :)
- sgrove 12y ago
  There are still some huge hurdles to overcome for working on large projects & medium-size teams with designers. Nothing insurmountable, but a lot of polish that still needs to be put into (re-)usable infrastructure, tooling, and polish. All that said, once devs are up to speed, and designers have a modicum of tooling, it's the best system I've used so far.
- Touche 12y ago
  Google Closure's documentation is terrific though.
mcav 12y ago
I've used Om for several projects and have never run into a bug in the framework.
- BrianEatWorld 12y ago
  I think OP is talking about CLJS development at large, not Om specifically. Personally, I ran into an issue with the Chas Emerick's testing framework and lost about a day of dev time trying to track down the issue. I never did figure out what was wrong and ended up just scrapping and starting over. In the end, it would have been nice to have some alternatives, but there really weren't any mature ones at the time. Contrasting the situation with a language like Python where, should I run into an issue with Py.Test, I can always switch to Nose or numerous other frameworks. Searching for documentation for CLJS is also a bit rough. I ended up relying on ClojureDocs for the most part, but because CLJS transpiles to JS and not JVM code, there are some undocumented idiosyncrasies. This also complicates troubleshooting because the errors are thrown by something like line 6400 of the transpiled code, not line 20 of the code you have been writing. I still love the language. I am even taking part in a CLJ/CLJS specific hackathon next weekend. However, I have trouble recommending it to others without caveats. Most of which are due to the language's relative immaturity.
  - prabhasp 12y ago
    RE: line 6400 vs. line 20, check out Source Maps: https://github.com/clojure/clojurescript/wiki/Source-maps https://github.com/clojure/clojurescript/wiki/Source-maps Once you have these working, errors are linked to line 20 of hte code you are writing.
dj-wonk 12y ago
Can you show some examples (e.g. filed bugs)? If you point out your top bugs, I (for one) will take a look.

swannodette 12y ago

This is not my experience. Doing JavaScript for years I mostly leaned on jQuery & Underscore.js and more recently React. ClojureScript has all the functionality of Underscore.js and a whole lot more, Google Closure I honestly find just as usable as jQuery for the cross browser bits, and finally there are several React bindings like Om. And I do a pretty darn good job of maintaining Om :)

sgrove 12y ago
There are still some huge hurdles to overcome for working on large projects & medium-size teams with designers. Nothing insurmountable, but a lot of polish that still needs to be put into (re-)usable infrastructure, tooling, and polish. All that said, once devs are up to speed, and designers have a modicum of tooling, it's the best system I've used so far.
Touche 12y ago
Google Closure's documentation is terrific though.

mcav 12y ago

I've used Om for several projects and have never run into a bug in the framework.

BrianEatWorld 12y ago
I think OP is talking about CLJS development at large, not Om specifically. Personally, I ran into an issue with the Chas Emerick's testing framework and lost about a day of dev time trying to track down the issue. I never did figure out what was wrong and ended up just scrapping and starting over. In the end, it would have been nice to have some alternatives, but there really weren't any mature ones at the time. Contrasting the situation with a language like Python where, should I run into an issue with Py.Test, I can always switch to Nose or numerous other frameworks. Searching for documentation for CLJS is also a bit rough. I ended up relying on ClojureDocs for the most part, but because CLJS transpiles to JS and not JVM code, there are some undocumented idiosyncrasies. This also complicates troubleshooting because the errors are thrown by something like line 6400 of the transpiled code, not line 20 of the code you have been writing. I still love the language. I am even taking part in a CLJ/CLJS specific hackathon next weekend. However, I have trouble recommending it to others without caveats. Most of which are due to the language's relative immaturity.
- prabhasp 12y ago
  RE: line 6400 vs. line 20, check out Source Maps: https://github.com/clojure/clojurescript/wiki/Source-maps https://github.com/clojure/clojurescript/wiki/Source-maps Once you have these working, errors are linked to line 20 of hte code you are writing.

dj-wonk 12y ago

Can you show some examples (e.g. filed bugs)? If you point out your top bugs, I (for one) will take a look.