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.
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.
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.
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
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.
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.
(Sorry last post got discarded due to UI confusion, repeating what was said)
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
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.
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.
I think you nailed it. IMO that should be the main topic of this thread