4 ms·

Full-stack Clojure with Clojurescript front-end is about the fastest workflow I’ve ever used. The front-end part in particular with Reagent (a Clojurescript Rea

Full-stack Clojure with Clojurescript front-end is about the fastest workflow I’ve ever used. The front-end part in particular with Reagent (a Clojurescript React library) is a very quick workflow compared to all front-end alternatives. There are perhaps more valid options for server, but even still, having the same language in both browser and server is very convenient both for reduction in cognitive dissonance and automatic transfer of language-specific data structures back and forth. Highly recommend. I should add that on both server and in browser your code base will usually be a lot smaller than most other languages, which greatly speeds workflow as well. As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines. Using Heroku to just git push the project works well too. Deploys in seconds. If your project becomes more, it all scales well. Clojure is quite fast compared to Ruby or Python, and Heroku scales with the click of a button. You won’t have to port to a more performant language or host if you suddenly get popular.

oreganoz 8y ago
Does Clojurescript support stuff like hot code reloading? And does Clojure have any good framework for an actor system implementation? Because I've been interesting to get an excuse and try Clojure out and what you're saying is really interesting.
- asragab 8y ago
  It does support hot-code reloading, the preeminent build tool for Clojurescript: https://github.com/bhauman/lein-figwheel https://github.com/bhauman/lein-figwheel has that out of the box. As for an actor model implementation, there is pulsar: http://docs.paralleluniverse.co/pulsar/ http://docs.paralleluniverse.co/pulsar/ Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.
  - oreganoz 8y ago
    Hmm, I guess I better look deeper into Clojure. Finally I get to play with a Lisp. My main interest with actors is that these can be made to support hot code reloading on the server side. They also tend to be easily composable. Also also, they can be optimized by locality (eg. same-node, same-cluster, different-cluster) I'm biased though, having not worked with CSP or other models.
    - hellofunk 8y ago
      I think you will find that as far as composability and hot code reloading, the combination of proper functional programming with a true REPL make this a powerful combination in Clojure that will at least match what you would get in a language built around actors.
- hellofunk 8y ago
  Clojure has its own very effective strategy for multi-threading, and it is not the actor model. The language is built for concurrency and much careful language design was tailor-made for the challenges on modern threaded applications. Rich Hickey investigated the actor model considerably, and decided on a different model. In the core language, you have the choice of using its normal futures/threads with highly efficient and lock-free data structures, or using core.async, which is a model like Go channels. The latter is particularly popular in the community and generally the recommended approach. Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it. Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.
  - oreganoz 8y ago
    Yeah, that's nice for multi-threading but it does not seem as good for distributed systems. This is why I still don't know if I should invest in Clojure or Elixir. Can the REPL on the server be used to update production systems with no downtime?
    - hellofunk 8y ago
      Yes you can easily REPL into a live remote server and work with it while it is running. But more typically, the REPL-driven development happens on your own machine while you build, and then you just deploy the whole app. But it can be useful for remote debugging when necessary. For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure: http://www.onyxplatform.org/index.html http://www.onyxplatform.org/index.html I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.
pgorczak 8y ago
I've had the same experience. On the front-end, reagent is a joy to use. Haven't found a framework that feels more elegant/smooth than what reagent does with components and hiccup (maybe adding re-frame for state management). There are some great choices for the server side too. Plus libraries for pretty much every DB. When something is missing, there's definitely a fallback option in Java. Plus you get hot-reloading on both sides (e.g. boot-reload and ring-reload). And the ability to bundle everything into one neat jar file so the only dependency for deployment is Java. Here's a getting started project that I found helpful: https://github.com/oakes/full-stack-boot-example https://github.com/oakes/full-stack-boot-example
dustingetz 8y ago
For interactive Clojure/Script prototyping with Datomic, check out http://www.hyperfiddle.net/ http://www.hyperfiddle.net/
dorian-graph 8y ago
> As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines. I'm curious to hear more about this. I'm someone who's used Elm at work, and on the side is interested in Lisp.
- hellofunk 8y ago
  I think it is much easier to get real-world nontrivial work done in Clojurescript compared to Elm.
  - dorian-graph 8y ago
    Can you go into any more specifics? I'm genuinely interested! Do you think it'll stay true as Elm matures?
    - hellofunk 8y ago
      Personally I think Elm is dying. It relies on a single language designer who works very very slowly. Since Elm came on the scene, vibrant languages with static typing for the front end have sprouted up and are better alternatives, like ReasonML if you want a language with static guarantees and workflow. Elm could have been something, but I don’t expect it gain any mindshare, and the boat has sailed. Clojurescript is a dynamic language, with easy JS interop and nearly zero boilerplate, so I still think it is the fastest route to a production app.
cutler 8y ago
Although Clojure is my favourite language I find web development difficult with it due to auth for which Buddy is the standard. Buddy's integration with Luminus is opaque at best and the Buddy docs themselves I found unhelpful. You're left with the impression that Clojure web development is for experts who already understand how it all works. Total contrast with Rails where there are great resources for average developers and newcomers. I think this stems from the Clojure community's reluctance to embrace web frameworks.

oreganoz 8y ago

Does Clojurescript support stuff like hot code reloading? And does Clojure have any good framework for an actor system implementation? Because I've been interesting to get an excuse and try Clojure out and what you're saying is really interesting.

asragab 8y ago
It does support hot-code reloading, the preeminent build tool for Clojurescript: https://github.com/bhauman/lein-figwheel https://github.com/bhauman/lein-figwheel has that out of the box. As for an actor model implementation, there is pulsar: http://docs.paralleluniverse.co/pulsar/ http://docs.paralleluniverse.co/pulsar/ Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.
- oreganoz 8y ago
  Hmm, I guess I better look deeper into Clojure. Finally I get to play with a Lisp. My main interest with actors is that these can be made to support hot code reloading on the server side. They also tend to be easily composable. Also also, they can be optimized by locality (eg. same-node, same-cluster, different-cluster) I'm biased though, having not worked with CSP or other models.
  - hellofunk 8y ago
    I think you will find that as far as composability and hot code reloading, the combination of proper functional programming with a true REPL make this a powerful combination in Clojure that will at least match what you would get in a language built around actors.
hellofunk 8y ago
Clojure has its own very effective strategy for multi-threading, and it is not the actor model. The language is built for concurrency and much careful language design was tailor-made for the challenges on modern threaded applications. Rich Hickey investigated the actor model considerably, and decided on a different model. In the core language, you have the choice of using its normal futures/threads with highly efficient and lock-free data structures, or using core.async, which is a model like Go channels. The latter is particularly popular in the community and generally the recommended approach. Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it. Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.
- oreganoz 8y ago
  Yeah, that's nice for multi-threading but it does not seem as good for distributed systems. This is why I still don't know if I should invest in Clojure or Elixir. Can the REPL on the server be used to update production systems with no downtime?
  - hellofunk 8y ago
    Yes you can easily REPL into a live remote server and work with it while it is running. But more typically, the REPL-driven development happens on your own machine while you build, and then you just deploy the whole app. But it can be useful for remote debugging when necessary. For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure: http://www.onyxplatform.org/index.html http://www.onyxplatform.org/index.html I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.

pgorczak 8y ago

I've had the same experience. On the front-end, reagent is a joy to use. Haven't found a framework that feels more elegant/smooth than what reagent does with components and hiccup (maybe adding re-frame for state management). There are some great choices for the server side too. Plus libraries for pretty much every DB. When something is missing, there's definitely a fallback option in Java. Plus you get hot-reloading on both sides (e.g. boot-reload and ring-reload). And the ability to bundle everything into one neat jar file so the only dependency for deployment is Java. Here's a getting started project that I found helpful: https://github.com/oakes/full-stack-boot-example https://github.com/oakes/full-stack-boot-example

dustingetz 8y ago

For interactive Clojure/Script prototyping with Datomic, check out http://www.hyperfiddle.net/ http://www.hyperfiddle.net/

dorian-graph 8y ago

> As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines. I'm curious to hear more about this. I'm someone who's used Elm at work, and on the side is interested in Lisp.

hellofunk 8y ago
I think it is much easier to get real-world nontrivial work done in Clojurescript compared to Elm.
- dorian-graph 8y ago
  Can you go into any more specifics? I'm genuinely interested! Do you think it'll stay true as Elm matures?
  - hellofunk 8y ago
    Personally I think Elm is dying. It relies on a single language designer who works very very slowly. Since Elm came on the scene, vibrant languages with static typing for the front end have sprouted up and are better alternatives, like ReasonML if you want a language with static guarantees and workflow. Elm could have been something, but I don’t expect it gain any mindshare, and the boat has sailed. Clojurescript is a dynamic language, with easy JS interop and nearly zero boilerplate, so I still think it is the fastest route to a production app.

cutler 8y ago

Although Clojure is my favourite language I find web development difficult with it due to auth for which Buddy is the standard. Buddy's integration with Luminus is opaque at best and the Buddy docs themselves I found unhelpful. You're left with the impression that Clojure web development is for experts who already understand how it all works. Total contrast with Rails where there are great resources for average developers and newcomers. I think this stems from the Clojure community's reluctance to embrace web frameworks.