Maybe this is usual for small languages like Elm, but as I enter my third year of doing side projects exclusively in Elm I feel heartened by certain projects in the community such as Elm Radio (Elm Lamdera is another one). Elm the language/community is not catching fire and growing in popularity like I had once dreamed it would, but as long as its core userbase continues to use and love it I am fully satisfied. It's a language/framework built to last, and built to a high standard. I love that it doesn't receive updates any longer and seems to be regarded as "done" by its creator (despite lacking a "1.0" status). It's served me faithfully for years, and as long as javascript itself doesn't change radically (seems unlikely) can continue to do so for perhaps my whole life.
Always a chance it still takes off, just need the right tool/library. Ruby was around a good while before Rails made it blast into the stratosphere for example.
True! I'm still hoping Lamdera can be Elm's Rails. I've done some side projects using Lamdera and received a lot of help personally from its creator Mario. He's awesome, always available to debug stuff, and also organizes a lot of events in the community.
What drew me into Elm was their focus on demonstrating how using elm would let you build web interfaces a different way. PureScript seems technically interesting but I don't feel like their current website "pitches" me on how I might want to use it.
Is PureScript stable/matured yet? I got burned trying to make a side-project with it when the API was still in flux and making major changes and tons of my dependencies no longer worked when I came back to it and wanted to update.
The primary barrier will always be the learning Curve. Elm was always more accessible than PureScript which seemed like a first learn Haskell before you sue it type of thing.
I couldn't get past its build systems. I ended up looking at pulp, npm, bower, yarn, webpack and parcel but couldn't figure it out. Someone said 'use spago' (hooray! another package manager!) but no luck either.
The Elm Architecture is the main reason I choose it over PureScript. I know there are PS implementations, but it just works that way at a fundamental level in Elm.
I wrote a blog post https://blog.poleprediction.com/clr-purescript-elm about this kind of thing. The main sentence of relevance is "All libraries written for Elm, assume that the consumer is writing their application using TEA."
It is semi-regularly noted in the Elm community that Purescript is a good counter-factual for Elm. Many requests for greater flexibility, such as access to kernel code for non-annointed libraries, have the pretty decent answer "well if you want that, go try Purescript".
Purescript, though, is just a sort of closest-cousin here. I'd say most languages have a philosophy closer to "we're all adults here, anything goes, the more we let innovators innovate, the more productive we'll ultimately be". That's not to say the Elm approach is 'better' in any sense, but it does mean that it's a worthwhile experiment. It's different from most other languages in that it's way more restrictive.
Those that ask for changes in Elm's approach, obviously have some other reason for wishing to use Elm, otherwise they wouldn't wish for Elm to change, they would just use something else. But those must acknowledge that whatever it is about Elm that is attracting them, may be as a result of Elm's unusual approach.
Robin Heggelund Hansen (one of the elm/core contributors) launched a fork of Elm this May with the help of 13 other contributors. It's called "Gren" (/gre:n/), which is Norwegian for "branch": https://gren-lang.org/
The introductory blog post promises a new release every six months. There are some differences from Elm (Git based package manager, immutable array as default sequential data structure), but the introductory blog post promises "If you already know Elm, then you also know Gren.": https://gren-lang.org/news/220530_first_release
Not to hijack the thread, but does anyone know what's going on with Elm right now? There hasn't been a release since Oct 2019 or any real communication from Evan (that I can see in public) for quite a while.
It's funny, I don't believe Elm itself needs much (if any) modification- the language is in a great spot, as are the core libs. I
f you care about it winning the "language wars", it needs more PR, examples, success stories, and tutorials. Here, I'm happy to have contributed in some way(s).
I have to disagree. Elm especially needs to be updated. That’s because Elm limits your interactions with browser. You can’t use browser APIs in Elm. (We can nitpick that ports and web components are some form of an escape hatch)
Internationalization API is a great example. We should leverage the platform but we can’t.
From my brief experience of trying to move onto 0.19, it broke the few project I had running on elm and the path forward wasn't very straightforward. JS interop and dealing with json are both still tedious and awful. I really want to want to use elm, but I'm not sure I can justify putting in the time.
JS interop via webcomponents is "the way" (vs ports). Re JSON decoding, agreed, and we cover in the episode: it's a solved/solvable problem that isn't popularized via a nice package...yet. But I think you've zero'd in on the pragmatic pain points; webcomponents is the revelation that was missing in the communication on the migration from 18 to 19, unfortunately.
I use web components as a workaround for elm being anti-component. It's infuriating. It makes me write JS instead of elm and obviously that causes lots of problems. The elm testing framework makes testing web components impossible too.
Elm has tons of low hanging fruit still. Evan just chooses to ignore them and look down his nose at any use case that doesn't work in elm currently.
Evan no longer works at the company NoRedInk that had been sponsoring his work on Elm, but has resurfaced to let folks know he's doing fine, doesn't need financial support, and still has no news to share on his plans for Elm.
With all due respect, the core language still has open issues the look valid and are unaddressed and no real code has been added for over a year, and in the case of elm/html 3 years.
Who among us is still using Elm (other than this company)? I thought most would have stopped after the creator's holier-than-thou attitude [0], publicly shaming critics [1], only allowing certain people (read: core contributors) to use language features without monkey patching, and generally acting like only they know how to make a good language so everyone else should just sit down and shut up [2].
We are silent legion. We have no runtime errors, we don't cry, we don't collect github stars, nor fancy logos for packages.
There has been nothing even close to Elm for building stable and maintainable projects! I am using it for 5+ years now, and since 0.19.1 came out my life became so much easier and straight forward. It works as advertised, its fast, its clean.
I'd always been curious about it but never really took the plunge. How well does it scale? Have you built any significantly complex applications with it?
I work on the app mentioned in the podcast. It is roughly 600k lines of Elm. I have previously worked at bigger, more well known companies, on apps 1/3 the size if not smaller. I've seen more frequent, and more reliable refactors in this Elm code than any I've worked in before. I'd easily take 1M lines of Elm over 100k lines of any JS framework, and I've worked with most of them.
I use it at my current job (they've used it for a few years now) and for my personal projects (mostly game jams).
Tbh, idgaf what Evan thinks of me or anyone else. The more you nemesize him, the more people will messianize him. It's best to divorce creators from their products.
I will admit I vehemently disagree with his apparent categorical dismissal of CSS features like custom properties, but discordant opinions are not going to stop me from using my preferred front end development platform.
You spammed this exact same comment 5 days ago on another thread. [0]
>Who is still using Elm? I thought most would have stopped after the creator's holier-than-thou attitude [0], publicly shaming critics [1], only allowing certain people (read: core contributors) to use language features without monkey patching, and generally acting like only they know how to make a good language so everyone else should just sit down and shut up [2].
The politics itself affects how I use Elm. If the creator who is the BDFL doesn't want to provide features that other frameworks do, and moreover shames people for suggesting them, that does not inspire much confidence in me that I should use it in production, so I don't. I thought something might have changed, but it appears it has not, so I will continue not using it.
I wasn't aware of any of that. And most of it is irrelevant to my question, but what keeps a fork project from being made of Elm to sidestep disagreements like this?
Nothing. And the reason no one has done it is because these links being brought up each time elm is discussed is irrelevant for us actually using elm. Things work fine.
Saw this post title and immediately my mind went to Elm, the text based email client from years ago. Such fond memories of getting a shell account and using it and Pine in the 90s in HS.
