Nice to see Elm is back

[John Walker]

I've always admired Elm from a distance and was sad to see it's demise. Happily I was mistaken!
https://elm-lang.org/news/faster-builds
John

[Michael Webb]

I wish that were true.

We've used Elm as our primary front-end stack since 19.1 was released. This is the first update in 7 years.

Elm works great. IMHO it's still the best front end framework you can possibly use, bar none. It is the _perfect_ introduction to functional programming, and a great on-ramp to Haskell. 

But... it has become too difficult (pretty much impossible) to hire for, and I can't imagine this new release convincing anyone to adopt it once they take a look at Elm's history. It's such a shame - if Evan had nominated others to nurture the language while he did other things I don't think it would have turned out this way. Maybe better, maybe worse, who knows.

All I know is that for these reasons, sadly, we're moving off of Elm in favour of a mix of Astro and Typescript.

[Ben Hutchison]

With the proviso that the definition of "best frontend framework" is of course, highly context-dependent, I want to make the case for why Scala.js has a strong claim here (although it's a platform, not a framework).

Scala offers something not unique, but very rare: a language and library ecosystem that genuinely works across the back- (JVM) and front- (JS) end environments. Scala.js is really solid and well supported, has wide support from open source Scala libraries (which cross-build artifacts to both platforms), and gets genuine industrial usage.

Scala.js release versioning is very low-key, emphasizing the stability of the platform, but for example, in v1.22.0, WebAssembly became a new supported target platform! You can also pretty easily extend Scala.js to desktop app development via Electron.

Of course, Typescript over NodeJS offers the same shared platform for front and back. But unlike clunky, verbose Typescript, Scala gives you a truly powerful and expressive, statically typed functional language, with typeclasses, rich types, effects, and polished immutable data structures. Almost any concept expressible in Haskell can be expressed in Scala in much the same form.

Once you taste the benefits of sharing code seamlessly between your front and backend environments, having to fully switch languages and libraries merely to run in a browser starts to feel like an unwelcome imposition.

-Ben

--
You received this message because you are subscribed to the Google Groups "Melbourne Compose Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to melbourne-compose...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/melbourne-compose-group/7605dc30-75a6-4eff-bbb0-3741d13544fan%40googlegroups.com.

[Michael Webb]

> With the proviso that the definition of "best frontend framework" is of course, highly context-dependent

Of course! Relevant context for Bellroy is that we nominally have front-end and back-end developers, and Elm was just approachable enough as a truly pure functional language/framework that our front-end developers could do great work in it without ever having to really have to work with monads and side effects, and that let us draft particular types of folks (as in, technical but much more design-focused) into those roles without having to compromise on our desire to have a fully functional stack.

In my opinion, Scala.js and PureScript don't have those properties - as good as those languages/platforms/frameworks are - so they were non-starters for us.

[John Walker]

I recant!
Seven years is a long time, so maybe "Back" is somewhat of an overstatement. 
Perhaps green shoots would be a better description.
When Michael is inundated with job applications from FE devs demanding to use Elm 1.0 and Ben has rewritten all his Scala.js in the same, Elm will be truly back. 
Could be a while off though!

[Ben Hutchison]

While we're on this topic, some of those at pizza last week may recall me talking about the state of front-end "reactive" web UI frameworks in 2026 and the various design choices they make. 

One month earlier in the year, maybe April, I talked about UI programming is actually an instance of Incremental Computation. This is a broad class of often hard or under-solved problems in comp sci where a system typically gets small changes in its inputs and produces small changes in its output. In many cases, Incremental Computation seeks to find more optimal solutions than recomputing the output in full. 

To make the relevance to web UI programming clear, the use of Virtual DOMs (VDOMs) is an incremental computation technique. Updating DOM trees are expensive, so many frameworks, including Elm, compute their next state in a lightweight VDOM and then diff this against the current DOM to produce a much smaller update.

It's an interesting question to ask "For those frameworks that *don't* use a VDOM, how do they solve the incremental computation problem?"

For solve it they must. If one has a complex form on screen with many fields, and a header and a footer and a user profile avatar up in the corner, and the needed change is to toggle on a <span>First name is required</span>, it's too inefficient to rerender the whole DOM.

The Scala.js-based framework Laminar has been one vocal advocate for a non VDOM approach (Im not personally endorsing the "hack" claim in the article title, although I think it's a worthy, thought-provoking piece).

In some month late in the year, I aspire to do a talk on this VDOM-or-not-VDOM topic.

-Ben

To view this discussion, visit https://groups.google.com/d/msgid/melbourne-compose-group/255143fe-7cc5-4cfb-8838-43afe0191868n%40googlegroups.com.