Hi, I discovered Elm quite recently and was curious if the stdlib packages like Html are abandoned, seeing how there are already a number of exclusively positive additions (fixed typos, recently™ added elements, and so on), that are not even reacted to. So, maybe I’m missing something here, but is there a lack of maintainers? It doesn’t seem to be a lack of community or contributors.
Pull Requests for Html: Pull requests · elm/html · GitHub
Hello!
Right now, the original author of the Elm programming language is the sole contributor and maintainer of the tools and standard library. He is currently focused on other Elm-related objectives (something that has to do with back end development, but there are no additional details), so no work is being done on anything else.
The libraries being abandoware depends on your definition of the term: the last commit is in 2019, which is not a good look, but the libraries still work and there are no outstanding or unsurmountable bugs.
In general, the policy for updating and maintaining the language is a controversial issue within the Elm community. The short version is “nobody is actively maintaining it, but it still works”.
There is a community driven effort to apply those small patches and pull requests to the core libraries: GitHub - elm-janitor/manifesto: Meta repository for elm-janitor organization documentation.
I have never used it so I can’t say how successful/convenient/hackish it is.
I did some analysis on the open bugs which mostly focussed on the ones that have pull requests submitted for them. You can find the results of this analysis here:
Some of these bugs have been patched, and you can install the patches using the scripts here:
The situation is certainly not ideal! Maybe calling them “abandonware” is too strong a term but not completely unjustified.
My view is that the quality of these packages is already high, and the outstanding bugs are usually minor and can be worked around. On the other hand fixes are not being evaluated and applied and we have to work around the whole thing in a more awkward way with a patching script! My hope is that now that we can share and evaluate the fixes using the patching script we can demonstrate their value and get some of them back into the core packages - Eventually!
I thoroughly agree, but I might argue that elm would – as a language – greatly benefit from (lacking a better phrase) go with the times. Technology is an ever-changing field, and web development is an extreme case even in that category. While I have not encountered any terrible bugs (or any, really), I can’t help but feel that no updates for what’s quickly approaching half-a-decade might be somewhat of an issue. I agree though, that “being somewhat old” does not make any piece of software good or bad.
I may be guilty of clickbait there, true 
Things like the missing dialog element and open property were easy enough to work around, but I still think “updating” the core libraries (read applying patches), would be necessary. This way everyone could have bugs fixed and features added ootb without becoming a micro-maintainer themselves. I have only recently touched elm for the first time, and there not being any updates is a huge red flag to me.
The janitor project seems like a great way to put a bandage on it and is admirable, but hardly an approach that scales, even with the limited size of the stdlib.
In any way, thank you for clearing this up a bit!
I think the janitor project can scale. If people use it in the wild for a while, some of those bug fixes would eventually get accepted upstream.
One thing to understand about Elm versus typical javascript frameworks is that software engineering principles have been applied to it as a system. What I mean by this is that there is a clear division of functionality between the compiler, the core packages, the contributed packages and then the applications you write. That is in order working out from the center which is the most stable. With enforced semantic versioning, things can safely evolve at their own appropriate pace. The core does not need to be updated frequently - but of course that does not really justify the lack of bug fixes.
Don’t be put off that Elm does not have a rapid cadence like your average javascript framework does. For example, in using Elm for the last 7 years, I have never yet run into a showstopper bug. Just annoying stuff that I was able to work around - often I ended up thinking the workaround was a better idea anyway.
(Maybe not being able to send Bytes out of a port could be a showstopper issue for me soon).
I’m coming from the mystic lands of Go, so I can’t really speak for the JavaScript world. That being said, having bugs for which the solutions are trivial to review and already available, but not applying them is just something I fail to understand. Reviewing all the Pull Requests for Html could be done in an extended toilet break.
Gotta agree. I read something by Linus Torvalds saying that the most important work he does for the Linux kernel is to review all the little pull requests - “gold dust” he called them.
If I had time I would implement this and provide an alternative way to share the patches whilst keeping semantic versioining and avoiding the hacky scripting route:
If you want inspiration for a great way to do modules, I can not recommend Go enough. It follows the distributed nature of git and is just a joy to work with (and significantly lighter on your drives and internet connection than for example npm).
FWIW, Evan just spoke at Strange Loop about The Economics of Programming Languages. While it doesn’t cover all of the topics here, it does touch on some of the why behind timing of things. Should hopefully be out in the next few weeks as Strange Loop publishes their talks to YouTube.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.