I'm so glad to see this, congrats to Evan and everyone who helped get 0.19 out the door!<p>I've been working in Elm for about a year now and it is a joy to work with, moving from vanilla JS/Angular/React to Elm has been a boon to productivity and I actually have confidence that when I refactor something and have fixed any compiler errors that it is going to work.
Congrats on the release! I have very high hopes for Elm in the future, and I think it truly shifts the paradigm of frontend development.<p>On an attempt to use Elm in production I ended up switching back to Javascript. The biggest issue I faced was lack of type-classes, which made certain parts of the code feel like I was pulling teeth to get Elm's type system to be happy. Perhaps this is more of an issue of expecting Elm to be more like Haskell than it is.<p>I hope Elm is able to get more adoption, and with it more examples of idiomatic approaches to problems in Elm's style. However this somewhat feels like a chicken-and-egg problem.<p>Regardless, this release looks great for people using it in production already!
> If you have ever tried to use ADVANCED_OPTIMIZATIONS in Google Closure Compiler, you know that this is extremely difficult even when you write all the code yourself<p>Perhaps, but it’s quite nice when you use languages that were built to support Google Closure from the beginning, like Clojurescript. Then it is painless and built into the build process automatically, and you get to benefit from all the other great advantages of advanced optimizations in Google Closure that this article does not mention, and which Elm still cannot support or offer an alternative for, like automatic loop unrolling and other notable performance improvements.
This sounds really cool, and it's exciting to see Elm come along!<p>I always feel like Bucklescript and the Ocaml ecosystem doesn't get enough love when Elm crops up. Bucklescript has been doing aggressive dead code elimination for some time, and comes with the full type system of ocaml — plus easy JS interop: <a href="https://github.com/BuckleScript/bucklescript/wiki/Why-bucklescript-matters-for-Javascript-platform" rel="nofollow">https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...</a>.<p>As Elm develops I'm finding it harder and harder to choose between bucklescript/ocaml/reason and Elm. It's awesome to have all of these modern tools to work with on the frontend.
I love Elm and I recommend it to everyone who wants to get into functional programming, especially Haskell.<p>Additionally I'm glad .19 finally came out. But 18 months was really long.<p>I'm guessing this was a good release point to show some major benefits, and I'm assuming that past 18 months was spent on more stuff that will come out later which is not ready yet.<p>The main change seems to be a smaller codebase. Which is great. This is done by dead code elimination and not including unused modules in addition of some incremental size reduction by record field renaming (replacing someReallyLong.name with s.n) . However some of the other concepts that supposedly was going to improve SPAs etc. are not released yet.
It’s been a long time coming but this is great. Thanks to everyone on the Core Team, and especially Evan, for their hard work.<p>Can’t wait for what comes next, especially, hopefully, some interesting things in Elm-Explorations.
Congratulations! I don't use Elm in production (yet), but have been following it's evolution for the past few years, built a few small side projects with it, and have gotten the chance to attend both Elm conferences. What a great community and great piece of technology.
Congrats to the core team! I'm super happy to see 0.19. We recently went live with a website that was fully written in Elm 0.18 (www.project6.com). I'm excited to upgrade to 0.19 and take advantage of the new browser package. If anyone is interested in learning more about the decision-making process behind choosing Elm for that project, I discussed it during an Elm Town podcast episode (<a href="https://elmtown.audio/the-risk-of-elm-dhruv-dang" rel="nofollow">https://elmtown.audio/the-risk-of-elm-dhruv-dang</a>).
One of the benefits of React and its components is that components built with design and prototyping tools (e.g. Figma) translate well to it. You design prototypes, test them, and translate the design components into react components.<p>Elm seems more like a prototyping language itself, where you create your architecture as you go, easy to refactor (and thus live test I guess). Those of you who made the jump from React to Elm, did your approach to prototyping and evaluating what to build change? Do you prototype less before you jump into code?
> Note that the React library itself is 32kb. Just the library without any application code. The entire Elm RealWorld App is 29kb, so no amount of code splitting can make the React version smaller than the Elm version!<p>That's plain wrong. Code splitting doesn't work only on package level, it goes all the way down to individual module exports (ie. constants or functions). So it really depends on how well React is structured, and how well the minifier can do static and dynamic analysis.
I've dabbeled in Elm and have some trivial single static pages in Elm on one of my sites. Is there a book or blog series anybody could recommend that's less about the language and more about the practical steps of building a full single page app in Elm? How does routing work, do you need JS to integrate with your API, how to configure the compilation/build/deploy step, etc?
They forgot Mithril[0] in the size comparisons -- I haven't seen anything useful beat it in size/value ratio.<p>[0]: <a href="https://mithril.js.org/" rel="nofollow">https://mithril.js.org/</a>
Since there are some Elm users in this thread, I'll ask here: What's currently the best way to integrate an interactive map (i.e. zoom, pan, draw polygons, etc.) into an Elm application (something like leafletjs)?<p>If I search for it, I find <a href="https://package.elm-lang.org/packages/kennib/elm-maps/latest" rel="nofollow">https://package.elm-lang.org/packages/kennib/elm-maps/latest</a> but the examples are not working for me, it feels like some mouse events get missed?<p>E.g. here: <a href="https://kennib.github.io/elm-maps/examples/Fullscreen" rel="nofollow">https://kennib.github.io/elm-maps/examples/Fullscreen</a><p>[edit]<p>Ok, it's not working for me on Firefox, but does seem to work better on Chromium (although some tiles are not rendered, but that might also be a server-side issue). Map support is crucial for me and was the reason I didn't dive into Elm so far, but maybe the problem is resolved now?
I’m an happy Elm user; but I wonder if it’s a worth investment to start using Elm when we’re heading to a new ecosystem on top of WebAssembly. I use Go on backend, and would feel satisfied when Go and Webassembly works together fine.
Any upgrade guide? My 0.18 elm project doesn't seem to work with the latest version and the links it tells you to go to don't exist.<p>This is pretty much consistent with my elm experience, I've never found it professional enough to consider for a production application.
Seeing that and liking Elm I have to tell that GatsbyJS (<a href="https://www.gatsbyjs.org/" rel="nofollow">https://www.gatsbyjs.org/</a>) outputs really fast end-products. Is that possible with Elm too?