Thanks for replying... You can parse JSON safely using the excellent bs-json library. I Googled bs-json and it looks like Go code of parsing/stringifying JSON. Uncertain yet. Will try. You can easily keep global state in the root component though. Components in our app are nested heavily. By putting data in root, accessing and manipulating would require passing methods along the tree. Won't be very easy as project group, I think. But you will quickly find yourself taking advantage of more and more features because they are so elegant and they express so much. At least brought me a little more confidence. :D Your existing build pipeline doesn't even need to care about Reason, because the JavaScript outputs will be co-located with your original JavaScript sources. I read some examples before. It appears Reason projects does not use Webpack like we normally do in CoffeeScript/Babel/TypeScript? Any good example out there I can use? Or has Reason community agreed to the way of how to use Webpack?

No need to be sorry, the problem came from the fact that ClojureScript is intrinsically complicated. And shadow-cljs actually brought me confidence on ClojureScript. I see shadow-cljs as a great help. It's more like a confused period of my life that I need to choose what job and what a life in the future. I feel beaten by the fact ClojureScript is not as good as I expected. I bet on ClojureScript before, somehow I lost.

Yes you can always get better experience with Figwheel or boot-reload, and shadow-cljs itself provides better tooling too. The reason I use Webpack is I was from JavaScript side and have features and toolchains I liked in Webpack. Need to mention that, by using Webpack, we no longer have correct SourceMaps, cljs REPL, head-up compilation error messages. It's an insufficient solution to senior cljs developers.

I voted Clojure, because I chose ClojureScript at last after a lot of considerations. I'm convinced that Haskell is the best language if someone is really trying to learn every concept from FP correctly. But Haskell comes with lots of confusions and costs of time. So I voted Clojure for a sane choice of a normal programmer. JavaScript is totally an Assembly language before WebAssembly is spread.

My opinion might be kind of unstable. For my projects in the company I would choose write CSS alone or something like SASS or LESS. But for my personal projects I use inline styles with ClojureScript merge functions as well as inlined <style> elements to handle media queries and pseudo classes. The problem inline styles does not fix is like handling media queries and pseudo classes. I see JSS showed a really interesting way to solve the problem and I would say: awesome! Nowadays people treat the browser APIs like a virtual machine. Everything is compiled and we just need better compilers. Before JSS we use inline styles to write properties to Element.style directly. The drawback is it's only values. If we have 100 elements sharing the same styles, we have to write the styles for 100 times in all elements. Because we don't have variables like in JavaScript. However with the help of JSS, now we have basic support for variables. It's really interesting now JavaScript is compiled to JavaScript plus CSS! I guess we can have more things like that in the future by treating the browser like a VM.

Mostly local machine. Sometimes I use a remote one. No VM. A front-end developer in ClojureScript.

One of my friends said Angular is trivial thing to learn for Java developers. As a non-Java programmer, I always consider Angular a nightmare.

If a single programming language is and will be enough for your work and communications, then knowing more languages may be useless. But it does and is very useful if you need to. Languages today are evolving all time. Take JavaScript for example, it's learning features from all kinds of programming languages and in the early days, due to the lack of guides, reading guides on other languages can be helpful. Even in some cases, you need to do it by your own to learn skills in another language and do it in JavaScript. That's really touch story since you need to learn concepts and terminologies in various kinds of languages, just to get it right. In short, more languages will help you know the precent of the discoveries in the history, and help you foresee the future of a single language.

For the "What" part, I'd like to suggest this posts since immutable.js is almost same as persistent data structure in Clojure, which is well described: https://en.wikipedia.org/wiki/Persistent_data_structure http://hypirion.com/musings/understanding-persistent-vector-pt-1 Why should use? Well it's not necessary to use immutable.js . It's useful to build a uni-directional data-flow and make React components diffing faster. In JavaScript, a language designed with mutation at heart, using persistent data structure is not a perfect choice. If you are just learning, I would suggest ClojureScript. But if you are building large apps with React, immutable.js is a nice-to-have.

I guess one reason may be caused by the fact that web browsers are not provided by only one company so no one is allowed to use a closed language for his own only profits.