I'm so glad to see this, congrats to Evan and everyone who helped get 0.19 out the door!
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.
We had a lot of trouble doing things without typesafety and declarations, so we tried a few things. Elm was one of the better ones, and we migrated a few minor systems to it. A few others to typescript and we even made a few pocs with Xamarin and Wasm.
Then one of my older employees randomly watched “JavaScript the better parts”, and recommended it to me and we’ve been doing classless JavaScript ever since.
Elm is great, certainly one of the better alternatives, but now it really feels like a step backwards.
What is classless JavaScript? I don't understand how you had trouble doing things without typesafety but found that going from JavaScript to Elm is a step backwards? Maybe I'm missing something here?
Once you start doing this, most other languages become obsolete. Because you avoid most of the problems of JS that things like elm try to fix, while maintaining the freedom and also writing a lot less code because you don’t have to write a “recipe” for half the things you write.
The disadvantage of JS is that it’s actually going in the wrong direction. Class is an attempt to copy C-style languages, and that really what you don’t want to do, because as soon as you use inheritance, the “this” keyword or “new” you’re basically doing JAVA/C#/whatever with all the downfalls of JS.
Classes is only a tiny part of what's broken in JS.
TS (coupled to "JS, the good parts") saves the day though, but I have no idea how avoiding classes also somehow made you abandon the usage of a type system (whether Elm's or TS's) It all seems so unrelated.
Many people (myself included) have never meaningfully used the OOP elements of JS you are referring to. The approaches listed above are common JS patterns and ones that I and I think most JS devs have used extensively.
However, they don't really solve any of the problems that Elm sets out to try and tackle. Do you have any examples?
Also these patterns certainly do not make any other languages obsolete, and as far as I'm concerned it doesn't solve _any_ of the problems with JS that people complain about.
Your comparison doesn't make any sense. You would use a language like Elm/Purescript/Reason etc for the type safety, that's completely orthogonal to whether something has classes or not.
Except you don’t need typesafety when you do this because you’re never expecting a specific type, and at the same time, you don’t have to waste time writing the recipe for what you’re going to do.
Just wanted to say what a joy it has been to work with the 0.19 compiler. For the project at https://knode.io, it was a game-changer: the elm/parser library is so fast that it makes live rendering of LaTeX to HTML a reality.
One more point. Writing something like the MiniLatex parser would be somewhere between impossible altogether and nightmarish without an expressive type system. Below is the definition of the type of the abstract syntax tree (AST) for MiniLatex. Just eleven lines of code. Yes, I know. No typeclasses in Elm. But Elm's type system is surprisingly expressive, and with it one can do some rather sophisticated work. I've been very happy with it.
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.
Gatsby produces static html sites and then rehydrates them once loaded, which is what makes it feel so fast. Elm dynamically generates the html.
There has been some work to generate static html from Elm - https://github.com/eeue56/elm-static-html - and there's no technical reason I'm aware of that prevents it from being taken as far as Gatsby does.
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.
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.
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.
Regardless, this release looks great for people using it in production already!
> this is more of an issue of expecting Elm to be more like Haskell than it is.
Yep, that's it right there.
I wonder if there's some way we could make it clearer that Elm is not Haskell, and trying to use it like it's Haskell won't likely to lead to a good experience.
At any rate, thank you for the feedback! It's definitely an ongoing communication challenge since the two languages have so much syntax in common.
> Perhaps this is more of an issue of expecting Elm to be more like Haskell than it is.
Some people have a hard time in Elm because they expect Elm to behave like a language that they are already familiar with. The most frequent impedance mismatch issues I've seen are reaching for `type-classes` or attempting to implement various polymorphic behaviors and people who are too hungover on imperative constructs (Elm is declarative).
Once people start using Elm the way it was designed to be used, things become simple and start to flow.
> Once people start using Elm the way it was designed to be used, things become simple and start to flow.
But how will anyone ever get anything done, when they can't make everything in their code exceptionally clear by wrapping it all up in a 15 monad thick monad-combinator? /s
But yes, I totally agree. Elm is a simpler, safer and easier Haskell for the front-end. I just love it :)
The idea that wanting to use typeclasses in Elm is an impedance mismatch would be more convincing if Elm and its standard library truly did everything without them, using alternate approaches like explicit dictionary passing. But as you probably know, they don’t. Instead, the language has special syntax for three builtin “typeclasses”: comparable, appendable, and number. And the standard library uses them: its Dict, for example, requires the key type to be comparable. These classes are automatically implemented for various builtin types, but there’s no way to implement them for custom types, so you can’t have Dicts with custom types as keys (unless that changed very recently). And if you want to, say, implement a hash map data structure, which requires the keys to be hashable, you have to use a completely different design, since “hashable” is not one of the three magic typeclasses.
To me, rather than principled, that just feels incomplete.
While I agree, I honestly don't care. It's a bit of magic, yeah, but at least we're rid of the insane amount of mental masturbation that permeates the Haskell ecosystem.
> Elm handles those things the way Standard ML does, not the way Haskell does.
That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow use of dictionary passing as a substitute for typeclasses, and as you noted, this approach has some resemblance to how ML modules work – albeit with less sugar. However, Elm's standard library does not seem to think this is the best approach, since it instead uses the aforementioned special-cased typeclasses.
> use of dictionary passing as a substitute for typeclasses
No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses.
Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses.
Another example of their being different is that Haskell offers custom user-defined operators, whereas Elm intentionally does not allow user-defined operators. There are a fixed list of them, and that's it. A great many languages have that policy too, and I would not call them wrong to do it that way.
Again, there are sound design reasons to make either choice! There are costs and benefits to making things user-definable. If you prefer the way Haskell did it, great! That's why we have different programming languages. :)
> Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses.
That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system).
Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.
I guess Go is the only language which comes close, which has map and array/slice which cannot be implemented in the language itself. Though it's the lack of generics, not ad-hoc polymorphism which is Go's lack.
Then again, it wouldn't surprise me if of all the languages you've thought about, Elm is the only one which hasn't reached 1.0 yet.
I think Elm will get some mechanism of ad-hoc polymorphism before it reaches 1.0, but I don't think it will be type classes. Though, I have been wrong before.
> No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses.
Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedious to pass around module definitions all the time, which is why they added equality types when the language was originally designed. This is considered an ugly hack though, even by its own creators [0].
Definitely agree that folks should aim for better than type classes, especially due to complications around global instance coherence. One nice solution is modular implicits/instance arguments [1][2]. Tricky thing is to do it without adding too much complexity to the language.
I do wish that there would just be some acknowledgment that it's a hard, but real problem to solve for Elm's point in the design space, rather than just pretending it isn't there. It's ok just to say that you're not spending design capital on it at the moment due to more pressing issues!
I don't think it's crazy to wish for some kind of interface or trait-like abstraction mechanism in a language. Anything taken to the extreme can sound stupid.
edit: I'm not saying Elm should change, the time for that is long gone. Just that the idea someone would want an interface (to do things like bound on generically) isn't that far fetched.
That's like saying Go will never get generics because it doesn't have it right now. Evan doesn't believe type classes are a right fit for Elm, but he has never to my knowledge ruled out that ad-hoc polymorphism will be added to the language.
Concur. Elm is an excellent addition to one's development quiver. Its strictness made me a far better, more careful programmer, and the push toward functional, side-effect free programming styles (something also coming from the React community) has been a huge boon to the JS world. Loving the current state of JS!
> All high-level programming languages are on board with abstractions, pretty much by definition!
They all provide abstractions, but they're not necessarily on board with letting users build new abstractions. Go is famously absolutely not on board with it for instance. Elm significantly less so — and I think the more restricted use-case also makes the issue significantly less problematic, at least it was in my (admittedly limited) experience — but it's still way downslope from the likes of Haskell or OCaml.
I love Elm and I recommend it to everyone who wants to get into functional programming, especially Haskell.
Additionally I'm glad .19 finally came out. But 18 months was really long.
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.
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.
The SPA improvements look to have been released as the new `Browser` package, there's some good stuff in the guides on it - https://guide.elm-lang.org/webapps/
> Additionally I'm glad .19 finally came out. But 18 months was really long.
On the basis that nothing was actually broken 18 months is not that long. I think there are benefits to be derived from working with a language/platform/ecosystem that doesn't change every few weeks. Just think about how many changes Angular has had in that time...
Although many people have seared-in memories about the transition from AngularJS 1.x to Angular 2.0, since 2.0 the improvements and Angular have a lot in common with today's Elm release. The same code still compiles, to smaller and faster output. The few breaking changes or deprecations happen slowly, with plenty of warning, and very little effort to keep up.
Of course it's more dramatic to find and discuss stark differences between "competing" platforms, but the boring truth here is that Angular and Elm are on the same side of the "should we be careful and methodical about development and change?" question.
> 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
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.
CLJS is awesome too! For what it's worth, Elm 0.19 likely also works with Closure Compiler in Advanced Mode - it did in a quick proof of concept I tried, but obviously that's something you want to be really confident in before suggesting people use it!
Did Elm change how it uses strings as a fundamental part of certain language constructs? That would break the advanced optimizations. According to the github issues tracker as well as mailing list comments from last year, these were not likely going to change in the language and therefore advanced optimizations are very fragile and likely to break on code in subtle ways.
Note that Elm has always appeared to work on the surface with advanced optimizations, but the bugs would creep in and show up eventually, and the official advice has always been not to use those optimizations.
Just glanced through the code for 0.19 (I originally wrote an issue about the advanced opts incompatabilities for 0.18) and the things which caused problems before are gone.
That's not to say that there are not other issues, though.
Leveraging what is already in Closure Compiler was (and is) such a brilliant maneuver by ClojureScript - over the last few years I've seen various current tools gradually gain optimizations that were already in the box with ClojureScript when I built some things with it "forever ago".
The big surprise though, is how few other new library/framework/platform/languages/whatever have followed this path.
Google Closure Compiler doesn't get any use because Google has entirely neglected it for a decade. They could have been where TypeScript is today, but instead they entirely ignored external users, hardly staffed the project, and now have an inconsistent mess with a non-coherent super-buggy type system and no users. It's a disaster, and if you try to do anything non-trivial it will fall to dust.
Good riddance to that abandoned pile of rubbish, and fuck Google management for letting it get so bad. They had a five-year lead on the rest of the industry in serious JavaScript development, and now they're ten years behind.
10 years behind? There might be competitors (perhaps) but the Closure compiler does quite a lot of impressive engineering -- not just the tree shaking and identifier renaming that Elm is trying finally to do, but also automatic function inlining, loop unrolling, numerous other performance tweaks. And it all works fantastically, very reliable. I've been using it for 4 years on a huge codebase and I've not once had a problem that was due to the Closure compiler. It's robust and stable.
This is false. It's not abandoned. There are many commits per day and that wouldn't happen without a dedicated team [1]. There are frequent releases with impressive-looking changes [2].
But this does look like a team that's focused on the needs of Google's internal customers? An external-focused project would have better docs and do more outreach.
Yes everything I write in Clojurescript gets ADVANCED_OPTIMIZATIONS and works fine. Also I have found that I get a lot more gain without having the language get in my way with functional programming vs strong static typing. Especially when you want to interact with the rest of the JavaScript ecosystem. The development story in Clojurescript is amazing too with figwheel.
The "problem" with ClojureScript's integration is that you have to be careful when integrating other javascript libraries (which ClojureScript encourage you to do to save code size) as they might not be compatible with advanced mode. You could also write code in cljs which isn't compatible with advanced mode. Elm doesn't have this problem.
Elm also outputs smaller assets than cljs+closure.
That being said, I do love cljs, having used it on numerous projects myself :)
This is almost never a problem since you simply use normal externs file for whatever library you are using. You never take an external library and run it through the closure compilation process, only your clojurescript code is put through those optimizations.
> This is almost never a problem since you simply use normal externs file for whatever library you are using.
"almost never" and "simply use externs file (which you may or may not need to write yourself)" does underpin my point that you have to take care. I'm not saying it is necessarily difficult or takes a long time to get right, but it does require that someone makes sure everything survives the advanced opts compilation.
This has burned me on a past cljs project, it's not even a concern on my Elm projects.
I guess it all boils down to how you want to spend your time. Elm typically requires at least 4x the lines of code and at least 10x the time of dealing compilation issues compared to Clojurescript. So ultimately I think this is just a question of a desired workflow in one language vs. another. Any time spent on Closure-related issues (which have never personally bit me on any project -- I just use the library itself as an extern file and everything has always worked with no effort), is made up for with the fast development cycle on Clojure projects. Even including the increased runtime debugging in Clojurescript vs. Elm, Clojurescript has always provided me a significant productivity advantage over every other JS-family toolkit.
Your experience is different than mine, but I don't believe externs inference was in last time I built a cljs web app.
I still use Clojure as a backend language (I'll never give up Datomic) and while writing code in Clojure is usually faster, I spend much, much more time in debugging, often because of type errors, and especially after re-factoring. In Elm I spend more time up front, but less time overall.
I've been writing Clojure for six years now, Elm for three. There are definitely usecases where I'd pick Clojure(Script) over Elm, but for those usecases where it doesn't matter which of those you pick, I'd choose Elm any day of the week.
This is not to say Clojure(Script) is bad. In my opinion, Clojure and Elm are the best languages around.
Your whole reason for replying to the submission seems to be "heh, ClojureScript already had this, but better ;)" but I'll chime in to say that the differences between Clojure and Elm, having used both extensively, especially become apparent when it comes time to refactor.
I would say that Elm lets me refactor front-end code fearlessly. I can confidently rewrite abstractions that are so fundamental that I'd be stuck with them forever in a dynamically-typed language because the rewrite would be so much more costly.
It reminds me of when people say that Mongo is better than Postgres for prototyping because it doesn't have a schema. In my experience, the very concept of having explicit schema transformation as the schema changes is why I'd consider Postgres to be better for prototyping: it's precisely the time when your schema is changing the most.
Of course, if we could unanimously agree on these trade-offs, then we would all be using the same stack and there would be no dynamic vs static typing debates.
I agree there are valid tradeoffs. In my experience, because Clojure code is so concise and tiny by comparison to Elm or most other language's, refactoring is usually replaced by actual re-writing, since the small amount of code is just as easy to architect again, maybe just saving particular functions, rewriting others.
The only way Elm uses node is for `elm repl`, since that needs a way to evaluate the compiled JS on the command line.
The only way Elm uses npm is for `npm install --global elm` - but that's just as a convenient way to get a cross-platform installer. All it does is download the `elm` executable and put it on your PATH!
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.
> Most compilers that target WebAssembly can also target asm.js, which is compatible with IE.
asm.js is different enough that it's just not about adding a seperate asmjs "compatibility" target. On the top of my head you don't have 64-bit ints or floats and I believe the way you call asm.js fns from/to JS is different from wasm. Adding asm.js support just for IE 11 wouldn't be worth the effort.
To target the web, you need a team dedicated to building HTML library stuff like interaction with the DOM. It's unclear whether Go even has that, and it will take longer to see if it proves popular, so waiting for Go for generic UI seems very premature.
On the other hand, Elm is not 1.0 yet. They are still breaking the ecosystem with new releases.
Do not post about the alpha/RC version of elm-upgrade on reddit, twitter, HN , discourse etc
That's already an issue about alpha.elm-lang.org being broken, changing it to point at package.elm-lang.org gets me further but the next set of errors are so unhelpful I'm giving up.
It's just telling you that it's pointless to post about issues on social media because the tool is in alpha and is obviously going to fail in many cases…
avh4 has a tool called `elm-upgrade`[0] that gets you 80% of the way there. It worked fine for 0.17 -> 0.18 for me and helped me upgrade some libraries for 0.18 -> 0.19. The dev branches worked during the 0.19 alpha phase, so I'm sure it will be released shortly.
> 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!
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?
I updated the official guide (https://guide.elm-lang.org/) to try to do a better job at that. It covers "routing" and JS interop much more clearly I think. So I recommend starting there and then asking around in the community if you run into anything!
Atm yes. But there is a trick. Backend can check the request if it is a crawler (google, twitter and other bots) and serve a custom page for SEO. And for normal requests serve the normal SPA
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)?
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?
Thank you for the quick response. Just out of interest are the examples working for you? E.g. Leaflet's Hello World is just ridiculously simple and short (if you check out the source): https://leafletjs.com/examples/quick-start/example.html
I am searching for something similar in Elm. I'll head over to other channels for more questions, thanks.
I honestly have never used LeafletJS, so I'd be the wrong person to ask - I'm just familiar with the technique to embed things like that in Elm applications. :)
No problem. :) I just wondered if you also have problems with my (Elm) example link, i.e. the scroll (zoom) events seem to get missed. However I followed your advice and headed over to the Slack channel.
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 (https://elmtown.audio/the-risk-of-elm-dhruv-dang).
This sounds really cool, and it's exciting to see Elm come along!
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: https://github.com/BuckleScript/bucklescript/wiki/Why-buckle....
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.
That's reaffirming to hear. I love reason! Work has been BUSY and unfortunately haven't been able to keep up with the changes. Thanks for the heads up :)
We sure do in the Elm community! I suspect this has more to do with who you follow than anything else. :)
For example, if you follow a lot of React folks, you're naturally going to hear a lot more about Reason, because there's a lot of overlap in the people who work on those projects.
Come check out our #beginners channel on Elm Slack sometime! It's constantly buzzing with activity:
True, probably a lot of bias in my environment but I interview a lot of people for frontend roles - a couple of years ago Elm was the next exciting language to learn, it's now more often than not Reason.
The last time I interviewed someone who applied because they wanted to use Elm in production was an hour ago.
Elm continues to be our #1 source of applicants, and none of them mention an interest in Reason...but then again, it would make sense that Reason, being newer and endorsed by Facebook, would have more interest in the overall JS community!
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.
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?
Can’t wait for what comes next, especially, hopefully, some interesting things in Elm-Explorations.
reply