Not for anything new, but we still have a couple of active Elm codebases. See my blog post: kevinyank.com/posts/on-endings-why-how-we-retired-elm-at-culture-amp/
@@KevinNYank for what reasons did you stop using Elm in new projects? Are you able to sum it up overall from the perspective of so many years? I'm starting to learn Elm and I'm a bit worried about whether it's a COBOL-style learning venture
It's been over a year and I'm really curious how it's been going with ELM. Did you find any pain points besides the "DOM is off-limits" you couldn't solve?
@@KevinNYank it must be really great not to have to go through upgrading a large codebase very frequently, and if your worst pain points are being tackled in the upgrade, instead of the common featuritis with only unwanted bulk of new options?
@@KevinNYank cool! Looking forward to hearing how it goes for you. You also mentioned that 0.19 was planned to have those code splitting, tree shaking and other stuff implemented. Looks (elm-lang.org/blog/small-assets-without-the-headache) like you're right about only dead code elimination/tree shaking actually got implemented, which is still quite an improvement.
@@KevinNYank I had hello world example working in 30 min (opposed to 5 min in Elm), that is using Hedwig, which is very similar to Elm architecture. After my initial excitement over Elm, I found two major problems with Elm: 1) single person controls language and libraries 2) type system is limiting. You probably you felt (1) with 0.19, which killed custom operators and native modules. (2), among others, leads to non-existence of typeclasses, and because of that user-defined types cannot be used as keys in dicts. Lack of typeclasses leads to problems with code reuse and boilerplate. As for initial setup - it is done once in a project, so it's not a concern for longer projects. As general framework (not webapp-specific) it can be adopted to server-side rendering, and also some code sharing is possible between front and back. Elm is wonderfull tech, and easy to get into, but in some ways limiting - which would not be a problem if creator would not enforce his vision on all users.
