7 ms·

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just g

by modarts 11y ago

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure? - You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,) - Don't need to bring a functional utility lib (lodash/ramda/etc) - The build ecosystem revolves around a really solid piece of software in Leiningen (that has a ridiculously high level of adoption) - Hot reloading (mainly through Figwheel) is simply magical (it's stable and "just works".) The amount of work to get a hot reloading environment setup and maintained with Webpack and various loaders is way too much, and often involves actual changes to application code to support it, which is unacceptable. - The language itself is designed from the ground up to be functional This is just what I can think of off the top of my head after a few glasses of wine, but there's a ton of reasons why we as JS developers should start taking a hard look at Clojurescript again.

AlwaysBCoding 11y ago
Also you don't really need to use a flux library or Redux if you're using Reagent, it's pretty much all set up for you. I've been using ClojureScript/Reagent for about a year now and all this JS tooling talk goes way over my head, I haven't needed to use any tooling other than lein cljsbuild for a while now, and it's glorious. If the Clojure community / ClojureScript was more approachable to beginners I think ClojureScript would be taking over right now.
- yogthos 11y ago
  Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that: Install OpenJDK: http://www.azul.com/downloads/zulu/ http://www.azul.com/downloads/zulu/ Install Leiningen: http://leiningen.org/ http://leiningen.org/ Create a new project and run it: lein new reagent myapp cd myapp lein figwheel Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React. I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.
lsdafjklsd 11y ago
I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super difficult
- moeamaya 11y ago
  Any write ups why your team moved from Ember to React? Seems like the recent tenets of Ember coincide with Reacts's componentized architecture and one-way data. Also if you were able to convince the team to go from Ember to React, appears as though the opportunity to switch to clojurescript was there (although react is the hotness right now so convincing was probably easier).
- sotojuan 11y ago
  Question (from a newbie): Why didn't you stay with Ember, now that it has a similar engine as React yet comes with a CLI tool and strong community conventions that get rid of any build tool frustrations?
  - Skinney 11y ago
    I'll assume the main keywords are "one and a half year ago". Me personally, I like the fact that React is a library wheras Ember is a framework. React doesn't dictate how you code your program, while Ember does.
tlrobinson 11y ago
Isn't Om Next built on ideas pioneered in Relay and Falcor, not the other way around?
- modarts 11y ago
  To be fair, there's been quite a bit of cross-pollination, but the original surge in popularity for React came about because of the pioneering work by David Nolen to show how to fully unlock the promise of React's approach when coupled with immutable data structures and a functional mindset (Basically everything presented in the original version of Om.)
ilostmykeys 11y ago
<Rant> I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now. What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. Everyone pointed me to core.async (later on someone mentioned the cats library which uses monads etc) It didn't feel right to use core.async's syntactically and conceptually complicated CSP pattern to solve a truly simple problem that can be solved far more elegantly with a much simpler and more general pattern using ES7's async/await. And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types. </Rant>
- Skinney 11y ago
  > What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. What? Async/await in CLJS is: (defn async-fn [] (go true)) (go (<! (async-fn))) How is that syntactically and conceptually complicated compared to async/await?
  - ilostmykeys 11y ago
    Why don't you go further and try/catch that to make it usable in a real app? How do you handle async errors?
    - Skinney 11y ago
      Install an exception handler on the channel or return exceptions on the channel. The latter is more common. I've written my own macros to make the latter case pleasant (<10 loc), but I believe the go-catching and <? macros from glossop provide the same functionality. (defmacro go-catching [& body] `(go (try ~@body (catch js/Error e# e#)))) (defmacro <? [chan] `(let [res# (<! chan)] (if (instance? js/Error res#) (throw res#) res#))) Used like this: (go-catching (<? (async-fn)))
cageface 11y ago
Lisp is just a non-starter for a lot of people. Maybe it's an irrational bias but it's also widely prevalent. I think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages. Clojurescript is a case in point. Statistically its userbase is zero but it's been the source of several useful techniques.
- yogthos 11y ago
  The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it. The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment. In fact, the demand appears to outpace supply resulting in benefits such as accommodation for remote work (https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for_remote_clojure_clojurescript/ https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for...). Thanks to the irrational bias against Lisp you're also competing against a smaller pool of developers when you look for Clojure jobs. Seems like a win to me.
  - cageface 11y ago
    I've been hearing this argument since I was heavily into Common Lisp in the early 2000s. Personally I like lisps so I hope Clojurescript does establish a viable niche. But it's not the case that number of users is irrelevant. If I commit to Clojurescript (or Haskell, or any other niche language), I'm cutting my prospective job market down by 95%+. This means fewer companies I can work with, fewer places I can live, and fewer gigs available overall. Some might consider the tradeoff worth it but I don't.
    - yogthos 11y ago
      I didn't say that the number of users is irrelevant. There needs to be a minimum user base to make a language viable, however beyond that it's just tradeoffs. While you might be cutting down the job market, you're also focusing on companies that are forward thinking, get to work with great technology, and get perks such as remote work. The most exciting part for me is that you get to shape the future of the ecosystem. Being on the ground floor of a new technology means that you get a lot of say in how it will evolve. For me the tradeoff was absolutely worth it, but I can understand how it's not for everyone.
Lazare 11y ago
I was hired to write JS code on a team of people who know JS, by a company that is comfortable writing significant chunks of code in JS. If I try and check in some Clojure into our repo, I'll fail code review. If I suggest adopting Clojure on a new project, it'll be shot down. And for good reason; nobody here knows Clojure, we're not a Clojure shop, we don't even know the right questions to be asking about risks and issues of adopting Clojure, much less the answers. If we were going to adopt a new language, I think I could make a solid case for Typescript that might get accepted. I could see making a case for Elm or Purescript, but I don't think either will fly. But Clojure is a lot further out there in terms of adding it to an existing team of PHP/JS/HTML/CSS devs. In addition, while you note that the JS ecosystem is basically just playing catchup with Clojure, it is (slowly!) catching up. More to the point, ES6 is the future of browsers; we're using Babel and polyfills as a stopgap, but the code we're writing is code which is increasingly capable of running on the browsers on our dev machines. Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. JS, as a language, is getting better, JS build tools are getting better, and the JS ecosystem is getting better. It may have a long way to go, and it may be slow, but it's getting there. From where I stand, the gap between JS and Clojure is just going to get narrower (it's always easier to copy than innovate after all). Why shouldn't I just wait and get the benefits for free? (Disclaimer: I love the idea of Clojure, and I actively looked for Clojure/Clojurescript jobs the last time I was on the market. But what I found was a job writing ES6/React/Redux, which is almost as good as the hypothetical Clojure job, and has the advantage of existing.)
- hellofunk 11y ago
  >Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support. But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm not sure what exactly you are referring to.
  - Tankenstein 11y ago

by modarts 11y ago

AlwaysBCoding 11y ago

Also you don't really need to use a flux library or Redux if you're using Reagent, it's pretty much all set up for you. I've been using ClojureScript/Reagent for about a year now and all this JS tooling talk goes way over my head, I haven't needed to use any tooling other than lein cljsbuild for a while now, and it's glorious. If the Clojure community / ClojureScript was more approachable to beginners I think ClojureScript would be taking over right now.

yogthos 11y ago
Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that: Install OpenJDK: http://www.azul.com/downloads/zulu/ http://www.azul.com/downloads/zulu/ Install Leiningen: http://leiningen.org/ http://leiningen.org/ Create a new project and run it: lein new reagent myapp cd myapp lein figwheel Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React. I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.

lsdafjklsd 11y ago

I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super difficult

moeamaya 11y ago
Any write ups why your team moved from Ember to React? Seems like the recent tenets of Ember coincide with Reacts's componentized architecture and one-way data. Also if you were able to convince the team to go from Ember to React, appears as though the opportunity to switch to clojurescript was there (although react is the hotness right now so convincing was probably easier).
sotojuan 11y ago
Question (from a newbie): Why didn't you stay with Ember, now that it has a similar engine as React yet comes with a CLI tool and strong community conventions that get rid of any build tool frustrations?
- Skinney 11y ago
  I'll assume the main keywords are "one and a half year ago". Me personally, I like the fact that React is a library wheras Ember is a framework. React doesn't dictate how you code your program, while Ember does.

tlrobinson 11y ago

Isn't Om Next built on ideas pioneered in Relay and Falcor, not the other way around?

modarts 11y ago
To be fair, there's been quite a bit of cross-pollination, but the original surge in popularity for React came about because of the pioneering work by David Nolen to show how to fully unlock the promise of React's approach when coupled with immutable data structures and a functional mindset (Basically everything presented in the original version of Om.)

ilostmykeys 11y ago

<Rant> I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now. What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. Everyone pointed me to core.async (later on someone mentioned the cats library which uses monads etc) It didn't feel right to use core.async's syntactically and conceptually complicated CSP pattern to solve a truly simple problem that can be solved far more elegantly with a much simpler and more general pattern using ES7's async/await. And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types. </Rant>

Skinney 11y ago
> What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. What? Async/await in CLJS is: (defn async-fn [] (go true)) (go (<! (async-fn))) How is that syntactically and conceptually complicated compared to async/await?
- ilostmykeys 11y ago
  Why don't you go further and try/catch that to make it usable in a real app? How do you handle async errors?
  - Skinney 11y ago
    Install an exception handler on the channel or return exceptions on the channel. The latter is more common. I've written my own macros to make the latter case pleasant (<10 loc), but I believe the go-catching and <? macros from glossop provide the same functionality. (defmacro go-catching [& body] `(go (try ~@body (catch js/Error e# e#)))) (defmacro <? [chan] `(let [res# (<! chan)] (if (instance? js/Error res#) (throw res#) res#))) Used like this: (go-catching (<? (async-fn)))

cageface 11y ago

Lisp is just a non-starter for a lot of people. Maybe it's an irrational bias but it's also widely prevalent. I think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages. Clojurescript is a case in point. Statistically its userbase is zero but it's been the source of several useful techniques.

yogthos 11y ago
The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it. The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment. In fact, the demand appears to outpace supply resulting in benefits such as accommodation for remote work (https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for_remote_clojure_clojurescript/ https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for...). Thanks to the irrational bias against Lisp you're also competing against a smaller pool of developers when you look for Clojure jobs. Seems like a win to me.
- cageface 11y ago
  I've been hearing this argument since I was heavily into Common Lisp in the early 2000s. Personally I like lisps so I hope Clojurescript does establish a viable niche. But it's not the case that number of users is irrelevant. If I commit to Clojurescript (or Haskell, or any other niche language), I'm cutting my prospective job market down by 95%+. This means fewer companies I can work with, fewer places I can live, and fewer gigs available overall. Some might consider the tradeoff worth it but I don't.
  - yogthos 11y ago
    I didn't say that the number of users is irrelevant. There needs to be a minimum user base to make a language viable, however beyond that it's just tradeoffs. While you might be cutting down the job market, you're also focusing on companies that are forward thinking, get to work with great technology, and get perks such as remote work. The most exciting part for me is that you get to shape the future of the ecosystem. Being on the ground floor of a new technology means that you get a lot of say in how it will evolve. For me the tradeoff was absolutely worth it, but I can understand how it's not for everyone.

Lazare 11y ago

I was hired to write JS code on a team of people who know JS, by a company that is comfortable writing significant chunks of code in JS. If I try and check in some Clojure into our repo, I'll fail code review. If I suggest adopting Clojure on a new project, it'll be shot down. And for good reason; nobody here knows Clojure, we're not a Clojure shop, we don't even know the right questions to be asking about risks and issues of adopting Clojure, much less the answers. If we were going to adopt a new language, I think I could make a solid case for Typescript that might get accepted. I could see making a case for Elm or Purescript, but I don't think either will fly. But Clojure is a lot further out there in terms of adding it to an existing team of PHP/JS/HTML/CSS devs. In addition, while you note that the JS ecosystem is basically just playing catchup with Clojure, it is (slowly!) catching up. More to the point, ES6 is the future of browsers; we're using Babel and polyfills as a stopgap, but the code we're writing is code which is increasingly capable of running on the browsers on our dev machines. Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. JS, as a language, is getting better, JS build tools are getting better, and the JS ecosystem is getting better. It may have a long way to go, and it may be slow, but it's getting there. From where I stand, the gap between JS and Clojure is just going to get narrower (it's always easier to copy than innovate after all). Why shouldn't I just wait and get the benefits for free? (Disclaimer: I love the idea of Clojure, and I actively looked for Clojure/Clojurescript jobs the last time I was on the market. But what I found was a job writing ES6/React/Redux, which is almost as good as the hypothetical Clojure job, and has the advantage of existing.)

hellofunk 11y ago
>Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support. But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm not sure what exactly you are referring to.
- Tankenstein 11y ago