Elm. No, really, elm. It goes away with all the js fatigue, your code is clean, readable and reliable, and does not produce runtime errors. You don't need npm (though it's probably a good idea for development, since you get hot-reload for free). Linter, testing and ci is a must, regardless of which kind of development we are talking about. Of course, linting with elm is a no-brainer with elm-format, and testing is much easier when you don't have side-effects. Plus you get fuzz testing "by default".

I was just as pessimistic as you wrt frontend development, I had dropped it off altogether. Elm made frontend dev enjoyable again. Can't recommend it enough.

If someone wants to talk about elm and how it is to develop with it, feel free to drop me a line. Email is on profile.

Thanks, this is interesting.

I think what this person is talking about is simplicity in the actual UI pattern, and thinking about them. The problems you mention are JavaScript problems, not UI problems.

Have you ever tried to build a UI with Qt or JUCE?

Isn't JUCE music-app only (or, mostly)? Also, I am having a hard time figuring out whether you are mentioning Qt and JUCE in a positive light, or a negative one...

JUCE is mostly for music, but otherwise fully flexible UI-wise and with tons of helper stuff for all kinds of things.

And the parent is obviously implying QT/JUCE are much harder to create a GUI than js/html/css/etc.

Many of these are particular implementations of FRP, not FRP itself. That's like saying MVC is complex because there are 50,000 implementations. It's a non sequitur.

The life on native client side development is more peaceful.

I'm waiting for cycle.js to become the framework du jour.