(no title)
antew | 5 years ago
0.19 introduced a new restriction on Native code (javascript), previously you could compile kernel code in your own projects, now you can't. You've never been able to publish a package using native code to the package site (only packages under the elm or elm-explorations github namespace can).
If you feel strongly about it there are ways around it, forking the compiler, or giving your project a fake "elm/whatever" name so that the compiler will build it, there is also a set of shell scripts on github that allows you to get around the restrictions. I've used it before to make some tooling to track virtual-dom performance.
The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs. Having a custom element where you pass in a posix time and have it formatted using the Intl APIs is very possible, and it also allows you to wrap up the interface between Elm and JS in a nice, type-safe way.
The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it hugely improved our build times. I had actually forked the 0.18 compiler to improve build times, full builds took around 2 minutes, and incremental builds around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds less than a second.
I share in some of his experiences as well, I have had posts deleted on the Elm Discourse page for mentioning a way for someone to run a fork of a core package to get a fix. I stopped working on a private package manager for Elm after someone described an existing solution as a hostile attack on Elm.
Overall the benefits of Elm still outweigh the downsides for me, no other language I have used has made development a joy like Elm has, refactoring is honestly fun, change whatever you want, follow the compiler errors, and at the end everything works again. Packages are generally high quality and work, an Elm package that hasn't received any updates in a year probably isn't abandoned, it's finished. Coming back to code I haven't worked on in a while is easy, the type system has my back, and most Elm code looks similar due to using the elm architecture and elm-format.
dorian-graph|5 years ago
Who's questions? The author didn't have questions about those things.
And I'm quite certain that the author is well aware of being able to edit a shell script to get around that restriction—and even if they don't, that doesn't change the content of the post.
> The 0.19 upgrade was fairly large, but manageable ..
For _you_, but not for everyone. Can you discount all of the experiences for those whom it wasn't manageable, and for those for whom it was impossible?
> .. an Elm package that hasn't received any updates in a year probably isn't abandoned ...
This wasn't always true. It's one of the reasons why the community forked several packages that authors had abandoned.
> .. most Elm code looks similar due to using the elm architecture ...
Oh dear. There's still so many approaches, and packages, about the different ways that people approach it.
* I wrote Elm professionally for 3 years from 2017-2019
alecthomas|5 years ago
[1] https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14
jfkebwjsbx|5 years ago
maxhille|5 years ago
palimpsests|5 years ago
? This wasn't really a technical blog post so I don't think this was a "miss", the points being shared around i18n efforts were meant to support the primary message of the article.