That is one topic I would like you (cljs developers) to expand on. I really want to see advantages of figwheel over react + webpack hot reloading or even vue + webpack hot reloading. I don’t know if you are aware of it, but it is pretty impressive how good does it work. Maybe figwheel was way better and much more advanced 3 years ago, but I want to know the advantages that it has right now. I really feel that there is a gap between javascript developers like me getting into ClojureScript and ClojureScript developers that long ago left javascript behind. The first time I saw about figwheel a year ago or so I thought “this is just hot reloading, good to have it on ClojureScript but it is not so revolutionary as this guy is saying”. I’m pretty sure that any ClojureScript developer thought exactly the same when he saw the opposite on javascript after years of working with figwheel. I think it is a matter of when and in which order do you discover things. Your reaction could vary from total mind-blow to just a “meh”
Thanks all. Actually I was trying to render another page of ClojureScript for beginners, using the domain http://clojure-script.org/ .
In this page I listed some code snippets at the first screen. It’s randomly chosen from https://github.com/clojure-china/clojure-script.org/blob/master/src/app/comp/showcase.cljs#L14 . They are mostly from the top links from Google. Thanks for the inspirations, maybe we can add more snippets there.
Small trick: click on ClojureScript logo on the left top to try a random snippet 
I think you are touching a good point here. I believe most people will claim that getting a Figwheel code reloading setup is much more easier/simpler due to more robust fundamentals of the language. Webpack claims hot code reloading but the fundamentals are shaky due to the nature of JS and the ecosystem, that getting it to work might require jumping through hoops or even eventually giving up. If this is not the case, please do share because it could be that JS has caught up.
One other point that is attractive to me is that CLJS and the surrounding ecosystem feels much more stable. The language is mature, tools are relatively stable, it’s not a moving target. Whereas JS seems to be changing all the time with new syntax and features, which actually rely on tooling that also changes constantly (e.g webpack is already at a new version). JS fatigue is real.
Hi Daniel, I think you have touched on a good point.
Webpack hot code reloading does work, and in practice I use figwheel the same way as I would use webpack hot code reloading. This is definitely the main feature of figwheel, but today - I can see why javascript developers would shrug and not be impressed.
However figwheel/CLJS hve two additional enhancements that improve my dev workflow:
Access to the figwheel browser repl. This allows me to test small snippets of logic code before the page refreshes.
Figwheel can also serve a ring handler which allows for complete hot code reloading between CLJ/CLJS. In my experience this is harder to setup with Javascript - although I am limited in experience in that area.
Going forward as javascript tooling improves I think the main selling point of Clojurescript will have to be that it is simply a superior language to javascript (which is admittedly subjective)
Hello @briangorman and @orestis, thank you for your positive feedback.
Having a webpack making hot-reloading of the frontend and nodemon making hot reloading on the backend is quite simple and like in clojure, you’ll be working on the same language on both sides.
I think that figwheel is superior on that matter, you don’t have a REPL on the server side. However despite the lack of a REPL I feel that debugging javascript tools are a bit superior to clojure ones. I am not even sure if you can debug step by step on clojure code, something which is extremely helpful.
That is, from my point of view, a common misconception, but I can understand why. Seeing the language from the barrier could make you think that it is a moving target and that you will lose your mind if you try to keep things up. This is due to dozends of blog-posts about the new hotness on JS ecosystem and new developers getting excited about trying every new feature/library that appears. However, one of the weak points of JS is one of it’s strengths too: it is retro-compatible almost to the beginning of times. The language is evolving, sure, new libraries are appearing, that’s true too, but you can stick with your libraries of choice, use the same framework and style of programming for decades and it will continue to work. Then once a year you can pick a new feature (the one you find more useful) and a new library and merge them into your base knowledge, and slowly evolve with the language. Trust me, I have been working with JS for years and I don’t have any fatigue.
Sorry, I think I hijack the thread a second time
@danielo515 I have to say +1 on this. I like Clojure, but every year or so when I try ClojureScript again, it’s a painfully frustrating experience and I go back to JavaScript.
If you know the good parts of JavaScript, its actually quite a nice little language. It supports a lot of the paradigms of ClojureScript.
I think we’re facing a new challenge recently, we’ve got JS devs coming to ClojureScript as an alternative to JavaScript. This was not the intended audience at first. The idea of ClojureScript was to allow a single stack from Clojure to the browser for existing Clojure devs to be able to stick to Clojure all the way down. Devs who want a JVM backend.
But in the world of ClojureScript only, without Clojure, or lets call it ClojureScript all the way up, where it is used with a Node backend, the value proposition isn’t as strong, and also hasn’t been as strongly advertised.
I think immutable first datastructures and design is one advantage. The google closure ecosystem being first class is another. The Lisp advantage, aka macros, homoiconicity and paredit. Its proper module system. Its nicer object model based on protocols and records. And the amazing set of core functional functions. Maybe its reactive support also.
Its a good list, but hard to showcase. And its also a smaller list then what Clojure proper brings.
Well this tweet demonstrates why clojurescript has an edge over JS :
I would instead say that ClojureScript’s power is allowing Clojure to run in places where the JVM either can’t go or isn’t a good choice. This includes the browser (obviously), mobile (React Native, &c), quick-starting scripts and various platforms (included embedded ones) that have embraced the JS runtime because of its ubiquity.
Thinking that CLJS is about web apps requires one to forget that there are many kinds of interesting programs that are not web apps.
You’re still describing an advantage that only applies if you’re already a Clojure developer, and would want your skillset in Clojure to transfer to other domains to which Clojure is weak at, like scripting, mobile, and web frontend. Which is why I say originally, ClojureScript was trying to sell itself to Clojure devs, or people interested in a singular language across the full stack.
My point is that if I know JavaScript, that argument isn’t convincing. Like someone telling me Go has a counterpart that can now be used to write mobile apps. Sure, but why would I not just continue to use JavaScript to write mobile apps?
So now it becomes much more about JavaScript, TypeScript, PureScript, Reason, Scala.js, Nim, etc. Versus ClojureScript.
Those comparison haven’t been explored as much I think. Or at least, I don’t have full knowledge of the different trade offs and when you would still prefer to go with ClojureScript.
Why not Haskell? There are plenty of Haskell-like languages that compile to javascript
Haskell’s JavaScript story is just not as far along as Scala / Scala.js or Clojure / ClojureScript. I’ve asked around members of the Haskell community about this and we’re really way further along. PureScript, Elm etc. are not Haskell.
(Sorry last post got discarded due to UI confusion, repeating what was said)
I was a JavaScript programmer and I was convinced. Why not use an arguably better programming language that scales from clients to multithreaded server programs? The only real mature competition in this space is Scala / Scala.js.
Actually i partially hate the fact that the standard library isnt completely supported so we have to always dip into the host api’s. A basic standard api should exist which is common everywhere and behaves exactly the same. The moment i have to think of CLJS and CLJ as two different entities there is a fork in my head. Both have different nuances, when they should be as consistent as possible.
An important aspect of Clojure/Script is immutability as a first class feature, which makes cljs use disciplined patterns for mutation. All mutation in clj/cljs is restricted to the atom defined in the app. React uses the same pattern but emulates it by means of defining interface functions to restrict modifying the state.
The comedy of the situation is that most JS devs dont realize that they are jumping hoops to achieve features which should be native to the language.
There are other features like homoiconicity for instance, Gives the power to describe the view code like html markup in the same language constructs as the logic code. Clojurescript with Reagent is an excellent example of this while react does the same through use of special JSX syntax. React with JSX looks alien not native. A similar effect to cljs is achieved in elm or Purescript. But programming with types is a different beast altogether.
Infact i think Clojurescript with Reagent is arguably the best UI library ever written.
Very good point, I came to the same conclusion.
The time I started programming in cljs I realized that I was only able to do it because I already knew javascript. That lead me to believe that if I want to code in Clojure I need to learn Java first. In my opinion that is very unappealing for both Clojure and ClojureScript. The first thing I thought when I evaluated Clojure what that I can learn a language a compile it to the two mainstream VM of nowadays, now I think it is the opposite, I have to learn 3 languages if I want to program on Clojure/clojurescript effectively.
Indeed! Some time ago I tried PHP Laravel (+ Vue.js, +JavaScript, etc…) but quickly got fed up with the idiosyncrasies of all the languages and frameworks involved. And what if a framework goes out of fashion? You’ll have to learn a new one (probably totally different). The one language --Clojure(Script)-- to rule them all (in a functional manner) approach is much more to my liking.
Oh, don’t have to convince me either, but the truth is, not everyone needs to scale up to a JVM back-end. Also like others said, to do so asks people to learn two standard libs, since Clojure/Script’s one is incomplete.
So its back to my point, if the idea of having a single fullstack language from frontend to backend, with a JVM backend appeals to you, then you are the target audience for ClojureScript and Clojure.
But if you just want to write Node scripts. Or client only mobile apps. Or want to have a Node back-end and that’s good enough for you. Then I think ClojureScript is still a great choice, but it has a smaller differentiator against the competition in those cases. Also, it isn’t as fully mature for those use cases.
So I ask myself, how do I convince someone who doesn’t care to scale up to a JVM backend and have a common language accross the stack? How do I convince a python scripter of the benefits of switching to ClojureScript? How do I convince a JavaScript Node backend dev to switch to ClojureScript? Etc. How can you demonstrate the differentiating value effectively and quickly for people looking into those other usage scenarios which don’t involve JVM Clojure?
I think you nailed it. IMO that should be the main topic of this thread