If you ask anyone who knows me what my thoughts are on javascript, you will get a unanimous “he hates it”. Typescript helps, but it doesn’t fix the problems. I don’t believe the problems I have with it are actually solvable without some radical changes in the ecosystem. Why do I care so much? Because I freaking want to build websites that stick around for a while goddamnit! Sites built with the “right decisions” today feel like they fall over from a strong breeze. I hate to admit it, but in 2024, the right way to build a website is probably a Typescript and React app. I have pushed hard against these choices, but the network effects are just too strong. There is just too much mindshare, packages, integrations, documentation that exists to justify using other technology for the frontend. When I first learned about htmx I grew optimistic. Their book talks about what was theorized from early days on the Internet and the lost art of hypermedia driven design. If you are building a discrete system (ex. contracting, small company, etc.), htmx is the correct choice. It is just so dead simple to use. There might be a bit of a learning curve, but more and more people are using it within existing web frameworks, like django, documentation on how to solve problems will exist. Unfortunately, htmx does not pass the test of a technology that scales with the size of your team/company. There is little that binds the htmx API endpoints you put in the html to the backend which implements the logic. Maybe this could be solved in time with tooling, but there is also the problem with managing more complicated state, the DOM is just a difficult place for it. And then there was elm.
Elm is my mistress, its beauty intoxicating. The type system is reminiscent of Haskell, meaning runtime errors are almost non-existent. The architecture is meant to directly support building components and managing the state as your codebase increases in size. I was surprised to see just how many packages people have built. Then again, when a language is written well, it is easy to build packages. The most important part of Elm, imo, is that it compiles to javascript and has strong support for interop between it with ports. It is not a naive project that is trying to force you into its language, you can incrementally add it to your app. This talk on elm was enlightening.
Why not go full elm? It is not at a major version release. There were some breaking changes from 0.18 to 0.19 that while well documented is indicative of the state of the project. The language is taking its time to be written well, which I do not fault, but makes it hard to justify using it. I could incrementally adopt it, but then that would be another language someone using my project would have to learn. I am using connect rpc which compiles grpc to js, I would need to write some elm ports to hook those up or port the transport to elm. Not impossible, just work.
When do you take a risk on a language? When you are dealing with such low stakes with coding, as is often the case with a personal project, why wouldn’t you take these risks? I have rewritten many projects in my pursuit of finding a stack that “feels right”. Is elm a part of it?