4 ms·

Have you tried out React + ES6 ? whats your opinion on clojurescript versus that. Especially when you bring in concepts like generators [1] (as a replacement

Have you tried out React + ES6 ? whats your opinion on clojurescript versus that. Especially when you bring in concepts like generators [1] (as a replacement for clojurescript's async), destructuring,etc. [1] https://babeljs.io/docs/learn-es2015/ https://babeljs.io/docs/learn-es2015/

Skinney 11y ago
I'm working on a React+ES6 project professionally, and use Clojurescript+Reagent for all my hobby projects. I would gladly use cljs+reagent for everything if I could. First off, cljs allows you to type less. Second, functionality provided by Immutable.JS is built into the language. Third, I can use paredit. I love paredit. Fourth, google closure has amazing code minification, dead code removal and a good standard library. Fifth, I've found figwheel to be better to react-hot-loader, the latter cannot always reload my application. Sixth, devcards. Seventh, incremental compile speed is faster. Eight, macros can greatly simplify code you're writing and allow new syntax to be exposed by libraries (core.async).
- sandGorgon 11y ago
  thank you for writing such a detailed reply. But it seems that 4 out of your 8 points are covered by external libraries that are pretty good - Immutable is great... lodash is great... and google closure compiler is usable (https://github.com/mihaip/react-closure-compiler https://github.com/mihaip/react-closure-compiler). I use systemjs/jspm as well as its hot reloader and it works great (unless a particular component is legacy JS.. which will be a problem anywhere). Not really refuting your point, but ES6/ES7 (and from what I'm hearing.. Typescript) with all these libraries have sort of taken over the mindshare that clojurescript used to have. IMHO the only reason for me would be the package manager. I mean Systemjs/jspm is okay.. but the whole AMD/global/cjs/webpack/requirejs/browserify crap is way too much. Nothing works anywhere in the javascript world .
  - Skinney 11y ago
    Google Closure is usable, but only if you write your app in a way that is google closure compatible, the same goes for any dependencies you pull in. In clojurescript, all code you write, and any pure cljs library, is google closure compatible. Immutable.js is great, but your libraries probably doesn't use it, and you have to make sure you use it everywhere as well. This can lead to subtle bugs that boils down to using .value instead of .get('value'), a problem you'll rarely encounter in cljs where everything is immutable by default. I haven't used systemjs/jspm, so I can't say anything about that. I can only say that I have yet to encounter a case where figwheel doesn't successfully reload my code, whereas I encounter this in webpack/react-hot-loader all the time. ES6/ES7/Typescript are great improvements over ES5. But you have to pair it with Immutable.js for it to be comparable to the offering that cljs provides. Even then, when you have a setup that gives many of the same benefits as cljs, you'll have written way more code, and you need to be a bit paranoid to make sure you're using the correct API at the correct place, and that you don't have any libraries that are incompatible with your setup. In short. While you can have a setup that gives you all the advantages of cljs+om/reagent, it's just a lot easier to do it in clojurescript.
    - sandGorgon 11y ago
      You are completely true. In fact I spent the last couple of days fixing some incompatibility issues with Handsontable - a very popular spreadsheet component. But that's precisely my point. Is there value in a pure language when you will need to leverage tons of third party libraries...most of which are incompatible? To get anything meaningful done, you would need to write EVERYTHING in cljs...or you could use a component which will be in old js. So where's the tru value of cljs in a real life project. Let's take Handsontable - to cover all the corner cases that a spreadsheet needs, it would take me an inordinate time. But it does not even play well with npm..forget cljs
      - freshhawk 11y ago
        I've done a fair bit of integration with handsontable from clojurescript. It has been excellent so far. Clojurescript isn't really a pure language, it just makes some types of purity the default. If you need to get dirty and mutable then that's simple, still simpler than plain js in my opinion. Clojurescript and Clojure have very good interop with their host language, integrating 3rd party libs is very simple. To be fair, you will have to write the glue code more often than when working in js since there is a smaller user base.
  - Flow 11y ago
    I was about to write a comment like Skinneys below, but he/she put it so well. I found this joke on r/ProgrammerHumor and it strikes me that I've been falling into this trap for the majority of my career. > You know what we need? Another mostly imperative garbage collected language, that's what. If we just tweak the syntax and feature set just right, it will change everything!" As Skinney writes, the mix of libs and tools that you base your webapp on might not be what the libs you want to use the next months agree with. Use of immutable collections are nearly pointless if only parts of your app use it, and you have to carefully maintain barriers that translate to/from them. Clojure(Script) makes their use succinct and natural, something I doubt yet another lib can make ES2015/TypeScript do.
yogthos 11y ago
I find ClojureScript to be far preferable. The language is much better designed in my opinion. It's simple and consistent, while being very flexible and expressive. from what I can tell it does everything ES6 does and more right now. The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png https://i.imgur.com/AjSTP20.png). I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving. I also find tooling for ClojureScript is better in many areas. Instead of having to juggle things like npm, gulp, grunt, and so on. You can use a single build tool like Leiningen that handles all those things. You have a live coding environment with Figwheel, and you get an editor integrated REPL where you can inspect things easily at runtime. I've been using ClojureScript in prod for about a year now without any issues. I simply wouldn't go back to using Js at this point.

Skinney 11y ago

I'm working on a React+ES6 project professionally, and use Clojurescript+Reagent for all my hobby projects. I would gladly use cljs+reagent for everything if I could. First off, cljs allows you to type less. Second, functionality provided by Immutable.JS is built into the language. Third, I can use paredit. I love paredit. Fourth, google closure has amazing code minification, dead code removal and a good standard library. Fifth, I've found figwheel to be better to react-hot-loader, the latter cannot always reload my application. Sixth, devcards. Seventh, incremental compile speed is faster. Eight, macros can greatly simplify code you're writing and allow new syntax to be exposed by libraries (core.async).

sandGorgon 11y ago
thank you for writing such a detailed reply. But it seems that 4 out of your 8 points are covered by external libraries that are pretty good - Immutable is great... lodash is great... and google closure compiler is usable (https://github.com/mihaip/react-closure-compiler https://github.com/mihaip/react-closure-compiler). I use systemjs/jspm as well as its hot reloader and it works great (unless a particular component is legacy JS.. which will be a problem anywhere). Not really refuting your point, but ES6/ES7 (and from what I'm hearing.. Typescript) with all these libraries have sort of taken over the mindshare that clojurescript used to have. IMHO the only reason for me would be the package manager. I mean Systemjs/jspm is okay.. but the whole AMD/global/cjs/webpack/requirejs/browserify crap is way too much. Nothing works anywhere in the javascript world .
- Skinney 11y ago
  Google Closure is usable, but only if you write your app in a way that is google closure compatible, the same goes for any dependencies you pull in. In clojurescript, all code you write, and any pure cljs library, is google closure compatible. Immutable.js is great, but your libraries probably doesn't use it, and you have to make sure you use it everywhere as well. This can lead to subtle bugs that boils down to using .value instead of .get('value'), a problem you'll rarely encounter in cljs where everything is immutable by default. I haven't used systemjs/jspm, so I can't say anything about that. I can only say that I have yet to encounter a case where figwheel doesn't successfully reload my code, whereas I encounter this in webpack/react-hot-loader all the time. ES6/ES7/Typescript are great improvements over ES5. But you have to pair it with Immutable.js for it to be comparable to the offering that cljs provides. Even then, when you have a setup that gives many of the same benefits as cljs, you'll have written way more code, and you need to be a bit paranoid to make sure you're using the correct API at the correct place, and that you don't have any libraries that are incompatible with your setup. In short. While you can have a setup that gives you all the advantages of cljs+om/reagent, it's just a lot easier to do it in clojurescript.
  - sandGorgon 11y ago
    You are completely true. In fact I spent the last couple of days fixing some incompatibility issues with Handsontable - a very popular spreadsheet component. But that's precisely my point. Is there value in a pure language when you will need to leverage tons of third party libraries...most of which are incompatible? To get anything meaningful done, you would need to write EVERYTHING in cljs...or you could use a component which will be in old js. So where's the tru value of cljs in a real life project. Let's take Handsontable - to cover all the corner cases that a spreadsheet needs, it would take me an inordinate time. But it does not even play well with npm..forget cljs
    - freshhawk 11y ago
      I've done a fair bit of integration with handsontable from clojurescript. It has been excellent so far. Clojurescript isn't really a pure language, it just makes some types of purity the default. If you need to get dirty and mutable then that's simple, still simpler than plain js in my opinion. Clojurescript and Clojure have very good interop with their host language, integrating 3rd party libs is very simple. To be fair, you will have to write the glue code more often than when working in js since there is a smaller user base.
- Flow 11y ago
  I was about to write a comment like Skinneys below, but he/she put it so well. I found this joke on r/ProgrammerHumor and it strikes me that I've been falling into this trap for the majority of my career. > You know what we need? Another mostly imperative garbage collected language, that's what. If we just tweak the syntax and feature set just right, it will change everything!" As Skinney writes, the mix of libs and tools that you base your webapp on might not be what the libs you want to use the next months agree with. Use of immutable collections are nearly pointless if only parts of your app use it, and you have to carefully maintain barriers that translate to/from them. Clojure(Script) makes their use succinct and natural, something I doubt yet another lib can make ES2015/TypeScript do.

yogthos 11y ago

I find ClojureScript to be far preferable. The language is much better designed in my opinion. It's simple and consistent, while being very flexible and expressive. from what I can tell it does everything ES6 does and more right now. The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png https://i.imgur.com/AjSTP20.png). I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving. I also find tooling for ClojureScript is better in many areas. Instead of having to juggle things like npm, gulp, grunt, and so on. You can use a single build tool like Leiningen that handles all those things. You have a live coding environment with Figwheel, and you get an editor integrated REPL where you can inspect things easily at runtime. I've been using ClojureScript in prod for about a year now without any issues. I simply wouldn't go back to using Js at this point.