11 ms·

Why ClojureScript Matters

198 points by jonpither 11y ago

bobajeff 11y ago
By the time JavaScript is being compiled down to WebAssembly you'll probably also be able to have the full Clojure, Scala, Java and other JVM based languages (also .Net languages) compiled down there as well.
- aardvark179 11y ago
  That's going to be long time coming. To be a suitable target for higher level languages wasm is going to have to gain GC, method dispatch instructions (preferably with the sort of machinery invokeDynamic on the JVM provides, because method dispatch isn't identical across languages), dynamic code loading, threads, and probably a bunch of other stuff. Wasm is definitely a good start, but it is only a start right now. It's a good target for AOT languages, but really not suitable for interpreted or JITed ones right now.
  - eropple 11y ago
    I'm not sure why you say that a traditionally JITed language won't benefit from this. We've had AOT compilers for the JVM and for .NET for years. The perf may be slightly worse, but we've had good-enough perf forever.
- mikerichards 11y ago
  Then we go full circle and go back to Web Forms?
maleghast 11y ago
Really enjoyed reading this, Jon, thanks for sharing it :-) If nothing else it has added another unit of weight to the idea that I need to adopt CljS quickly before I am left completely behind. Now all I need is a project and more free time than I currently have... ;-)
jwr 11y ago
As a data point, I've just written a significant ClojureScript application, using React (Rum for bindings, Datascript for client-side db). It's amazing how quickly one can create complex apps with impressive performance out of the box. If you haven't used ClojureScript, it is definitely worth looking at.
- javajosh 11y ago
  How did you select your components? I've never heard of Rum or Datascript, for example.
  - deleted 11y ago
    [deleted]
  - straws 11y ago
    Nikita Prokopov has presented a pretty cohesive vision for front-end programming in the cljs community. Even if you don't agree with all of his opinions, he's one of the only people assembling a big picture about how to write apps in this way. It's worth reading his blog: http://tonsky.me/ http://tonsky.me/ An emphasis on low-level tooling and not enough discussion around high-level architecture/examples has hurt the react+cljs combo adoption from my point of view. It's the nature of Lisp to come up with your own abstractions around application architecture, but the community would be wise to talk more about solving common web patterns and how to cleanly break away from those patterns when necessary.
    - KurtMueller 11y ago
      Thanks for pointing me to his blog. He's a great read. Got anything else by him I should read/watch/listen?
  - jwr 11y ago
    It's true that it isn't that easy to discover new libraries, especially as there seem to be lots of them popping up. You generally hear about these things from the community (which is great, btw!), or public talks. Nikita Prokopov is a brand by now, so I tend to watch his work closely.
Frozenlock 11y ago
If Om hurts your brain, I can't recommend Reagent enough: http://reagent-project.github.io/ http://reagent-project.github.io/
- bostonOU 11y ago
  Can you explain why Om hurts your brain? I've heard other people say similar things, but I've never quite understood why. Is it cursors? Local component state?
  - okal 11y ago
    I use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it. The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source. So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆 EDIT: More details.
    - bostonOU 11y ago
      While not a specific answer, "feels" is a valid response IMO. Like mentioned elsewhere, using reify seems to throw people off, which falls in to the "feels" category I think.
  - Frozenlock 11y ago
    It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.
    - jeremiep 11y ago
      reify is usually a low-level construct in Clojure. A lot of libraries use it under the hood, I wouldn't be surprised if you use a few of them :)
Cshelton 11y ago
While clojureScript is awesome and gets you to think differently when writing javascript, I think a more interesting thing people should check out it es6 (or ecmascript 6, or es 2015, w/e it's called now.). It brings many new things to javascript that people from other languages will be used to...likes the "class" syntax. Right now you can write near 100% es6 standard with a pre-compiler. Most use babel. Soon it will run on all the latest browsers without though, making it far better to write then a language that compiles to JS. JS is nice now, I know I know, just give it a try =p Also, another thing to look at is eithe Facebook's flow or Typescript. It adds some type checking, really great. Especially if you are writing server side in Node.
- warfangle 11y ago
  'class' is one of the most commonly mentioned but least useful constructs available in ES6. Things that win out over it? Destructured assignment, sane module syntax, arrow functions, true block scope variable declaration, and constants.
  - Cshelton 11y ago
    Yes, but people coming from java or c# or something will like it. Despite it being just syntactical sugar. I wasn't about to list out all the benefits of es6, that would take several entire blog posts.
    - jeremiep 11y ago
      I would rather see ES6 with no class support whatsoever and having people learn to code without them instead of adding features to satisfy the lowest common denominator. I've used classes in CoffeeScript and regretted it every single time. Once your web project starts to grow in scale classes quickly become your first pain point. Especially given how functional JS libraries have become nowadays.
      - warfangle 11y ago
        Composition over inheritance wins, so hard. (edit: downvote for a typically well-thought-of idiom, especially with regard to a language like js? .. if you disagree, why not talk about it?)
manishsharan 11y ago
I think that the main argument presented in this blog -- "avoiding splitting" is wrong :Splitting the development into frontend and backend is essential for developing maintainable code for large projects. Having a well defined communication api between backed and frontend defines responsibility for front end and backend developers and also enable better (j)unit test cases. The communication overhead and associated documentation is beneficial in the long run as the code that is produced will be better understood by all , not just the lone developer; it also makes code reviews easier and allows new developers to take over existing code base when necessary. It is immature to think developers will only feel pride in their when they own the entire codebase, the ui-to-db stack; The idea that "Lovingly crafted aesthetics in a codebase is key" is silly; code needs to be testable, well documented and highly optimized and re-usable.The "jostling of positions" are design discussions and they are important part of the software development cycle. I like Clojure and I am interested in learning ClojureScript but this blog post makes a poor case for it.
- rubiquity 11y ago
  Agreed. The client-server abstraction is one of the very best in the history of computing. I don't know why so many people are trying to do away with it.
  - jeremiep 11y ago
    The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.
    - rubiquity 11y ago
      I think trying to write your apps in this way hides the underlying client-server architecture.
      - reitzensteinm 11y ago
        I've written a clj/cljs app with source sharing, and there are many downsides. Tooling, lack of progressive enhancement, debugging, download sizes. I feel the benefits are worth it for my use case, but it's not all roses. But hiding the client server architecture is just a bizarre criticism to me, because it's not at all what writing one of these projects is like, and I'm not sure how you're even getting that impression. The degree to which you share code depends on how much functionality you are replicating, and is code that you would literally be cut paste porting if you were using another toolset. Or just avoiding writing altogether, like speculative updates. Just because you can theoretically attempt an antipattern doesn't make a tool bad; you can write shit in any language. And many do.
bryanlarsen 11y ago
Much more relevant than WASM in 2015 is that modern Javascript development is also moving towards compilation. There's little fundamental difference between compiling ES7 via babel.js vs compiling clojurescript.
- serve_yay 11y ago
  I had a similar thought, though for me that's a reason to keep using Babel and ES.next rather than ClojureScript. I find lispy syntax difficult to read.
pbowyer 11y ago
I disagree with some of the statements about developer pride. I was reading https://speakerdeck.com/garann/code-is-a-job https://speakerdeck.com/garann/code-is-a-job this morning and it's a position I have a lot of sympathy with. Not having the backend developer/fronted developer split is good; while each will have its own specialities, they shouldn't be siloed into separate teams.
- qzcx 11y ago
  Thanks for sharing. Good read.
Touche 11y ago
One thing Clojure/ClojureScript desperately needs is an answer for progressive-enhancement.
- emidln 11y ago
  No it doesn't. You can literally do the same thing you did with PHP in 2007 if you want to (have a controller that outputs xml to be transformed into jquery commands if an ajax call or renders html if not ajax). You could also do something less silly like share your templates (maybe via hiccup and its many cljs implementations or via enlive/enforce/kioo (or via Soy, or anything else really)). If you want to get really fancy, you can actually just render your js server side via nashhorn and then rebind whatever modern rendering library you choose (React, Ember, etc) onto the rendered html at runtime. This is all ignoring the fact that nothing prevents you from serving html from server-side templates and keeping your cljs codebase completely separately ala most web apps (then progressively enhancing with whatever you normally would).
  - Touche 11y ago
    It really does. Isomorphic is the new standard. Doing it in a very manual way is not good enough. Every new JS framework is expected to do this out of the box and the older frameworks are scurrying to gain support.
    - emidln 11y ago
      React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it. This is identical to what you'd be doing on react+node. With a macro or two, it's easier than anything node provides. As an aside, isomorphic isn't a new anything. We were rendering pages on the server, rendering updates on the server with the same templates, sticking them in xml representing jquery dom manipulation, and pipelining those in a single request since at least 2007 (when I first encountered the technique and shipped with it, I believe we used a javascript library called Taconite, maybe since 2005 from looking at the sourceforge account). Progressive enhancements were rendered off the same templates and inserted asynchronously, automatically, based on whether the controller on the server detected it was an ajax request or a bare GET. This incidentally made things very cacheable.
chowes 11y ago
I've come to appreciate some of the new ES6 features (anonymous functions, lets) much more after using their equivalents in ClojureScript. Also, The interactive REPL based workflow that a lot of the LISP languages utilize is extremely appealing. I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more. For those curious, here are some blogs that convinced me to finally give Clojure a spin: - http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html http://rigsomelight.com/2014/05/01/interactive-programming-f... (seems like this is the stereotypical "you should try ClojureScript because... " post) - http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... (a bit code-heavy, but an admirable workflow) - http://swannodette.github.io/2013/11/07/clojurescript-101/ http://swannodette.github.io/2013/11/07/clojurescript-101/ (dealing with asynchronous code) I'm curious HN, anyone out there making strides in interactive JS development, akin to the 2nd blog post I referenced above?
- smrtinsert 11y ago
  Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes. I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't seem to be helping much. It's pushed me back to simple gulp based es6 dev using ramda, rxjs, immutablejs, etc - basically the parts of clojurescript I like. The only thing I sort of miss from Clojure are macros and homoiconicity - it sure is nice to look so uniform, but the tooling just drives me away.
  - mordocai 11y ago
    I can agree with that with clojurescript, but I disagree that clojure itself has this problem. Clojurescript -should- be calming down soon. It is in a stage of changing constantly ATM but that should calm down once some of the underlying tech is stabilized (like clojurescript bootstrapped from clojurescript).
serve_yay 11y ago
I notice the author employing a bit of jiu-jitsu I see sometimes -- basically, that you shouldn't worry about designers not understanding ClojureScript (or whatever), because that is insulting to the designers. But how about designers have 18,000 other things to deal with and maybe they aren't interested in learning (in their estimation) the latest wacky-ass way web developers invented to generate HTML. The point isn't that they couldn't understand it if they tried, the point is that they would have to try, perhaps to the exclusion of something they would consider more useful.
- Skinney 11y ago
  I agree with this. The author should've mentioned enlive (you got a similar library that supports om) which allows html to be html, which should make designers happy.
saosebastiao 11y ago
So I tried Clojurescript and I liked it as a language. In terms of fit for a compile-to-Javascript language, it is probably the best implementation out there, partially due to Javascript's dynamic lispy origin. But it has a a major problem: It's not Clojure. It might be a Clojure-like language, but its not Clojure. So you still end up "splitting", but when you split you have to squint harder at the details. As far as fidelity to the native language, I've found Scala.js to be much better. I can't wait for WebAssembly though... it will be a game changer for people that prefer strong static typing for managing logical complexity.
- malcolmjuxt 11y ago
  I haven't used Scala.js, but I find Clojure and ClojureScript to be so damn close to identical I'm surprised at this comment. When I'm doing ClojureScript, everything I use from syntax, sequences, persistent data structures, core.async, protocols and records (the list seems endless) is the same as Clojure. The only thing that trips me up is regular expressions. In fact, I find there's a great deal more difference in the Scala written by any given two Scala developers than between Clojure and ClojureScript.
mikerichards 11y ago
Taking the 'splitting' argument head on, I don't believe that having a planned split between 'front end' and 'back end' developers is a good idea at all. I don't like that he seems to have to concoct that argument to sell ClojureScript. The argument seems artificial. There's lots of reasons to decouple the front-end development from backend development. In fact, once you start using a client framework and use the backend as a service layer you can really decouple your layers. Doing web stuff, I primarily work in ASP.NET MVC and I'm trying to get rid of razor completely. In fact, If I had my way, I'd have css/photoshop jockeyes (with a little angular/whatever knowledge) in charge of the client, a javascript/Typescript guy doing the client MVC, and a data guy doing Web API. Agile tends to frown on these distinctions. I don't buy it , just like I don't buy a lot of the Agile dogma. Oh well.
rymndhng 11y ago
I'm still waiting for stable tooling support. With Clojure 1.7, the introduction of Reader Conditionals via `.cljc` is a step in the right direction. The tooling still isn't quite ready yet. I've tried porting some `.cljx` code over, but it's not quite working for me yet with leiningen.

198 points by jonpither 11y ago

By the time JavaScript is being compiled down to WebAssembly you'll probably also be able to have the full Clojure, Scala, Java and other JVM based languages (also .Net languages) compiled down there as well.

aardvark179 11y ago
That's going to be long time coming. To be a suitable target for higher level languages wasm is going to have to gain GC, method dispatch instructions (preferably with the sort of machinery invokeDynamic on the JVM provides, because method dispatch isn't identical across languages), dynamic code loading, threads, and probably a bunch of other stuff. Wasm is definitely a good start, but it is only a start right now. It's a good target for AOT languages, but really not suitable for interpreted or JITed ones right now.
- eropple 11y ago
  I'm not sure why you say that a traditionally JITed language won't benefit from this. We've had AOT compilers for the JVM and for .NET for years. The perf may be slightly worse, but we've had good-enough perf forever.
mikerichards 11y ago
Then we go full circle and go back to Web Forms?

maleghast 11y ago

Really enjoyed reading this, Jon, thanks for sharing it :-) If nothing else it has added another unit of weight to the idea that I need to adopt CljS quickly before I am left completely behind. Now all I need is a project and more free time than I currently have... ;-)

jwr 11y ago

As a data point, I've just written a significant ClojureScript application, using React (Rum for bindings, Datascript for client-side db). It's amazing how quickly one can create complex apps with impressive performance out of the box. If you haven't used ClojureScript, it is definitely worth looking at.

javajosh 11y ago
How did you select your components? I've never heard of Rum or Datascript, for example.
- deleted 11y ago
  [deleted]
- straws 11y ago
  Nikita Prokopov has presented a pretty cohesive vision for front-end programming in the cljs community. Even if you don't agree with all of his opinions, he's one of the only people assembling a big picture about how to write apps in this way. It's worth reading his blog: http://tonsky.me/ http://tonsky.me/ An emphasis on low-level tooling and not enough discussion around high-level architecture/examples has hurt the react+cljs combo adoption from my point of view. It's the nature of Lisp to come up with your own abstractions around application architecture, but the community would be wise to talk more about solving common web patterns and how to cleanly break away from those patterns when necessary.
  - KurtMueller 11y ago
    Thanks for pointing me to his blog. He's a great read. Got anything else by him I should read/watch/listen?
- jwr 11y ago
  It's true that it isn't that easy to discover new libraries, especially as there seem to be lots of them popping up. You generally hear about these things from the community (which is great, btw!), or public talks. Nikita Prokopov is a brand by now, so I tend to watch his work closely.

Frozenlock 11y ago

If Om hurts your brain, I can't recommend Reagent enough: http://reagent-project.github.io/ http://reagent-project.github.io/

bostonOU 11y ago
Can you explain why Om hurts your brain? I've heard other people say similar things, but I've never quite understood why. Is it cursors? Local component state?
- okal 11y ago
  I use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it. The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source. So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆 EDIT: More details.
  - bostonOU 11y ago
    While not a specific answer, "feels" is a valid response IMO. Like mentioned elsewhere, using reify seems to throw people off, which falls in to the "feels" category I think.
- Frozenlock 11y ago
  It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.
  - jeremiep 11y ago
    reify is usually a low-level construct in Clojure. A lot of libraries use it under the hood, I wouldn't be surprised if you use a few of them :)

Cshelton 11y ago

While clojureScript is awesome and gets you to think differently when writing javascript, I think a more interesting thing people should check out it es6 (or ecmascript 6, or es 2015, w/e it's called now.). It brings many new things to javascript that people from other languages will be used to...likes the "class" syntax. Right now you can write near 100% es6 standard with a pre-compiler. Most use babel. Soon it will run on all the latest browsers without though, making it far better to write then a language that compiles to JS. JS is nice now, I know I know, just give it a try =p Also, another thing to look at is eithe Facebook's flow or Typescript. It adds some type checking, really great. Especially if you are writing server side in Node.

warfangle 11y ago
'class' is one of the most commonly mentioned but least useful constructs available in ES6. Things that win out over it? Destructured assignment, sane module syntax, arrow functions, true block scope variable declaration, and constants.
- Cshelton 11y ago
  Yes, but people coming from java or c# or something will like it. Despite it being just syntactical sugar. I wasn't about to list out all the benefits of es6, that would take several entire blog posts.
  - jeremiep 11y ago
    I would rather see ES6 with no class support whatsoever and having people learn to code without them instead of adding features to satisfy the lowest common denominator. I've used classes in CoffeeScript and regretted it every single time. Once your web project starts to grow in scale classes quickly become your first pain point. Especially given how functional JS libraries have become nowadays.
    - warfangle 11y ago
      Composition over inheritance wins, so hard. (edit: downvote for a typically well-thought-of idiom, especially with regard to a language like js? .. if you disagree, why not talk about it?)

manishsharan 11y ago

I think that the main argument presented in this blog -- "avoiding splitting" is wrong :Splitting the development into frontend and backend is essential for developing maintainable code for large projects. Having a well defined communication api between backed and frontend defines responsibility for front end and backend developers and also enable better (j)unit test cases. The communication overhead and associated documentation is beneficial in the long run as the code that is produced will be better understood by all , not just the lone developer; it also makes code reviews easier and allows new developers to take over existing code base when necessary. It is immature to think developers will only feel pride in their when they own the entire codebase, the ui-to-db stack; The idea that "Lovingly crafted aesthetics in a codebase is key" is silly; code needs to be testable, well documented and highly optimized and re-usable.The "jostling of positions" are design discussions and they are important part of the software development cycle. I like Clojure and I am interested in learning ClojureScript but this blog post makes a poor case for it.

rubiquity 11y ago
Agreed. The client-server abstraction is one of the very best in the history of computing. I don't know why so many people are trying to do away with it.
- jeremiep 11y ago
  The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.
  - rubiquity 11y ago
    I think trying to write your apps in this way hides the underlying client-server architecture.
    - reitzensteinm 11y ago
      I've written a clj/cljs app with source sharing, and there are many downsides. Tooling, lack of progressive enhancement, debugging, download sizes. I feel the benefits are worth it for my use case, but it's not all roses. But hiding the client server architecture is just a bizarre criticism to me, because it's not at all what writing one of these projects is like, and I'm not sure how you're even getting that impression. The degree to which you share code depends on how much functionality you are replicating, and is code that you would literally be cut paste porting if you were using another toolset. Or just avoiding writing altogether, like speculative updates. Just because you can theoretically attempt an antipattern doesn't make a tool bad; you can write shit in any language. And many do.

bryanlarsen 11y ago

Much more relevant than WASM in 2015 is that modern Javascript development is also moving towards compilation. There's little fundamental difference between compiling ES7 via babel.js vs compiling clojurescript.

serve_yay 11y ago
I had a similar thought, though for me that's a reason to keep using Babel and ES.next rather than ClojureScript. I find lispy syntax difficult to read.

pbowyer 11y ago

I disagree with some of the statements about developer pride. I was reading https://speakerdeck.com/garann/code-is-a-job https://speakerdeck.com/garann/code-is-a-job this morning and it's a position I have a lot of sympathy with. Not having the backend developer/fronted developer split is good; while each will have its own specialities, they shouldn't be siloed into separate teams.

qzcx 11y ago
Thanks for sharing. Good read.

Touche 11y ago

One thing Clojure/ClojureScript desperately needs is an answer for progressive-enhancement.

emidln 11y ago
No it doesn't. You can literally do the same thing you did with PHP in 2007 if you want to (have a controller that outputs xml to be transformed into jquery commands if an ajax call or renders html if not ajax). You could also do something less silly like share your templates (maybe via hiccup and its many cljs implementations or via enlive/enforce/kioo (or via Soy, or anything else really)). If you want to get really fancy, you can actually just render your js server side via nashhorn and then rebind whatever modern rendering library you choose (React, Ember, etc) onto the rendered html at runtime. This is all ignoring the fact that nothing prevents you from serving html from server-side templates and keeping your cljs codebase completely separately ala most web apps (then progressively enhancing with whatever you normally would).
- Touche 11y ago
  It really does. Isomorphic is the new standard. Doing it in a very manual way is not good enough. Every new JS framework is expected to do this out of the box and the older frameworks are scurrying to gain support.
  - emidln 11y ago
    React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it. This is identical to what you'd be doing on react+node. With a macro or two, it's easier than anything node provides. As an aside, isomorphic isn't a new anything. We were rendering pages on the server, rendering updates on the server with the same templates, sticking them in xml representing jquery dom manipulation, and pipelining those in a single request since at least 2007 (when I first encountered the technique and shipped with it, I believe we used a javascript library called Taconite, maybe since 2005 from looking at the sourceforge account). Progressive enhancements were rendered off the same templates and inserted asynchronously, automatically, based on whether the controller on the server detected it was an ajax request or a bare GET. This incidentally made things very cacheable.

chowes 11y ago

I've come to appreciate some of the new ES6 features (anonymous functions, lets) much more after using their equivalents in ClojureScript. Also, The interactive REPL based workflow that a lot of the LISP languages utilize is extremely appealing. I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more. For those curious, here are some blogs that convinced me to finally give Clojure a spin: - http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html http://rigsomelight.com/2014/05/01/interactive-programming-f... (seems like this is the stereotypical "you should try ClojureScript because... " post) - http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... (a bit code-heavy, but an admirable workflow) - http://swannodette.github.io/2013/11/07/clojurescript-101/ http://swannodette.github.io/2013/11/07/clojurescript-101/ (dealing with asynchronous code) I'm curious HN, anyone out there making strides in interactive JS development, akin to the 2nd blog post I referenced above?

smrtinsert 11y ago
Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes. I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't seem to be helping much. It's pushed me back to simple gulp based es6 dev using ramda, rxjs, immutablejs, etc - basically the parts of clojurescript I like. The only thing I sort of miss from Clojure are macros and homoiconicity - it sure is nice to look so uniform, but the tooling just drives me away.
- mordocai 11y ago
  I can agree with that with clojurescript, but I disagree that clojure itself has this problem. Clojurescript -should- be calming down soon. It is in a stage of changing constantly ATM but that should calm down once some of the underlying tech is stabilized (like clojurescript bootstrapped from clojurescript).

serve_yay 11y ago

I notice the author employing a bit of jiu-jitsu I see sometimes -- basically, that you shouldn't worry about designers not understanding ClojureScript (or whatever), because that is insulting to the designers. But how about designers have 18,000 other things to deal with and maybe they aren't interested in learning (in their estimation) the latest wacky-ass way web developers invented to generate HTML. The point isn't that they couldn't understand it if they tried, the point is that they would have to try, perhaps to the exclusion of something they would consider more useful.

Skinney 11y ago
I agree with this. The author should've mentioned enlive (you got a similar library that supports om) which allows html to be html, which should make designers happy.

saosebastiao 11y ago

So I tried Clojurescript and I liked it as a language. In terms of fit for a compile-to-Javascript language, it is probably the best implementation out there, partially due to Javascript's dynamic lispy origin. But it has a a major problem: It's not Clojure. It might be a Clojure-like language, but its not Clojure. So you still end up "splitting", but when you split you have to squint harder at the details. As far as fidelity to the native language, I've found Scala.js to be much better. I can't wait for WebAssembly though... it will be a game changer for people that prefer strong static typing for managing logical complexity.

malcolmjuxt 11y ago
I haven't used Scala.js, but I find Clojure and ClojureScript to be so damn close to identical I'm surprised at this comment. When I'm doing ClojureScript, everything I use from syntax, sequences, persistent data structures, core.async, protocols and records (the list seems endless) is the same as Clojure. The only thing that trips me up is regular expressions. In fact, I find there's a great deal more difference in the Scala written by any given two Scala developers than between Clojure and ClojureScript.

mikerichards 11y ago

Taking the 'splitting' argument head on, I don't believe that having a planned split between 'front end' and 'back end' developers is a good idea at all. I don't like that he seems to have to concoct that argument to sell ClojureScript. The argument seems artificial. There's lots of reasons to decouple the front-end development from backend development. In fact, once you start using a client framework and use the backend as a service layer you can really decouple your layers. Doing web stuff, I primarily work in ASP.NET MVC and I'm trying to get rid of razor completely. In fact, If I had my way, I'd have css/photoshop jockeyes (with a little angular/whatever knowledge) in charge of the client, a javascript/Typescript guy doing the client MVC, and a data guy doing Web API. Agile tends to frown on these distinctions. I don't buy it , just like I don't buy a lot of the Agile dogma. Oh well.

rymndhng 11y ago

I'm still waiting for stable tooling support. With Clojure 1.7, the introduction of Reader Conditionals via `.cljc` is a step in the right direction. The tooling still isn't quite ready yet. I've tried porting some `.cljx` code over, but it's not quite working for me yet with leiningen.