Elm Blog

One alternative is the Model-View-Update framework developed in the Elm language [1]. A few years ago, it influenced Redux [2], but JS doesn't have good ergonomics to support it, so people complained it was too verbose. Anyway, I brought Elm to the company I worked at two jobs ago, and it worked very well, since it is conceptually very simple. The experienced developers loved its explicitness, which made it possible to build a very intricate app from just a few dependencies, which in turn allowed the company to have a very fine-grained control of the UI, and the customers loved the result.

On the other hand, other less experienced developers didn't like Elm so much because React allows you to write your app with fewer lines of code. The article from this discussion explains well that React (especially with hooks) hides complexity, which bites people later. At that time, it is perhaps too late to switch to something else.

Needless to say, I haven't been able to convince any other employer to use Elm, and then I see issues popping out all the time that would never happen with it. Such a waste, just because people like shiny toys and just follow what others around them are doing without thinking too much.

[1] https://elm-lang.org/
[2] https://redux.js.org/understanding/history-and-design/prior-art

There's a common pattern I've seen over and over. When people learn a new thing they tend to go through a creative phase with it. The first time I noticed it was in a programming class I took in school. We were learning in Pascal. (It was cute!) When we got to the lesson on changing output colors, for the next week it was like some unicorn barfed rainbows all over our screens.

People like to play. (Remember blink tag? Scrolling marquee?)

What you're seeing in the JS Frontend space is (in my considered opinion) a combination of the effect of:

1) Lots of people learning to program by messing around with JS, and

2) Folks willing to pay people to mess around with JS.

So you have a volcano of creativity combined with a tidal wave of money...

The results were inevitable.

> Follow up question : Is that complexity necessary or artificially inflated?

No, and yes. It's not necessary (for the vast majority of sites) so it's definitely (IMO) artificially inflated.

The good news is that you can end-run all the introduced complexity by using e.g. Elm lang ( https://elm-lang.org/ ), or just sticking to simple "plain vanilla" JS systems. The only reason to use something other than Elm is if you enjoy some other particular system (I hear good things about "htmx" https://htmx.org/ )

> The first question I usually get ... is “Why not Haskell?”.

> The answer is JavaScript.

My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2].

Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why:

It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds.

[1]: http://elm-lang.org/

[2]: http://elm-lang.org/learn/FAQ.elm

EDIT:

Also, Elm fixed Haskell's awful syntax record name collision problem, and awesomely too!

There are several paths:

1. JS as an assembly language. This is what emscripten[0], a LLVM bytecode-to-JS does, by following the asm.js specification[1]. This is for CPU-intensive tasks, not DOM manipulation. You can use any language that has a LLVM frontend.

2. JS as a target language, from a specific, new language. Those include cleaner variants that keep the same semantics (CoffeeScript, TypeScript, maybe Dart, ...) or more innovative ones, such as Elm[2], which is written in Haskell too. I'd say that a big innovation that makes the life easier is FRP (which is at the heart of Elm or React.js).

I fail yet to see what advantages PureScript brings compared to Elm.

0: https://github.com/kripken/emscripten
1: http://asmjs.org
2: http://elm-lang.org/

For direction of learning, I'd recommend finding challenging projects with them which they have a strong interest in, and can feel a sense of ownership over, then let their curiosity and creativity drive the teaching. The teaching should reward them by solving problems they are perceptive of and value.

I think for a language, Javascript is a great choice. It's convenient because it can be used in the browser, or CLI / server with Node. It has powerful and user-friendly tools for debugging and profiling. NPM has a wealth of libraries for graphics, robotics, machine learning, and pretty much anything else you might want.

For functional programming, with interoperability with Javascript, there's Elm: https://elm-lang.org/

How about http://elm-lang.org/ ? It is very similar to haskell but a bit less daunting and all its libraries are focussed on building inbrowser games. Sounds like something kids would love.

Now that i am brainstorming anyway. Something like http://scratch.mit.edu would be so much nicer if it were a functional language! Instead of confusing blocks that maintain state every block is just a standalone welldefined function and combining blocks is just functional composition and application! I think it would be reaallt easy for a kid to digest mentally: blocks have inputs and outputs, thats it.

Does anybody know if there are projects tjat accomplish this?