I have an itch. I need a little web app to scratch it with. It's a simple single-screen app with a search widget. A few hours in react or even plain old jQuery at most.

But that would be going over a well trodden ground. A waste of opportunity to learn something new. Let's instead do this project in a tech I know nothing about. My itch can wait.

I spun the wheel of javascript technologies that are hip this week, and it landed on elm.

What I know about elm going in

Elm is a pure functional programming language. It compiles down to javascript so it can run inside a browser (I don't know if there is a node version of elm). It seems to fill the same niche as react + redux combo, with which I am familiar. All the javascript hipsters seem very impressed with it, even more so than with react (or is react still cool?).

Yet, elm doesn't seem to be gaining a lot of traction. While there are plenty of CS nerds gushing about it, most "ordinary" developers are gravitating towards the familiarity of react, vue and angular.

This is an old problem with functional languages. Plenty of great features and buzz within certain circles, but they never quite manage to win the favor of the "masses". Long term, I expect elm as well to remain a great incubator of ideas, but go nowhere in terms of wide adoption.

These are my thoughts as I open the Elm's homepage.

Home page

My first impression of elm's website is - nice. The design is clean and programer-y. There is no marketing gunk anywhere in sight. This is clearly made by a community of enthusiasts.

Jumbotron

The headline is "A delightful language for reliable webapps." Like it.

The subtitle is: "Generate JavaScript with great performance and no runtime exceptions."

This "runtime exceptions" thing is strange. It's obviously a big deal for Elm's authors, but I'm not so sure it is for the rest of the world. Most of my frontend voes stem from wrestling with CSS quirks, code organization and UX design in general. Will elm's lack of "runtime exceptions" help me with any of that?

In this top section, there are also two immediate call to action buttons: "Try Online" and "Install". It kind of reminds me of Linux distributions. Very good choice, in my opinion.

Features

Next section highlights some of Elm's most important features.

JavaScript Interop

They show a bit of code which demonstrates how you can plop elm right into an existing app, straight out of vue's school of "get one foot in the door".

My immediate concern here is compilation speed. Startup time is already a problem for these big js frameworks that need to load a lot of code before they can show anything. Babel + JSX compilation speed is what's killing this use case for react.js. Is elm compiler really that fast?

Coming back to this later, I realize they presume you'll already have a build system set up and just add elm into the mix. Yes, that'd make more sense. Less likely to happen in reality, though.

No Runtime Exceptions

Again with this exceptions thing.

Elm uses type inference to detect problems during compilation and give friendly hints.

So it's basically static typing. This is a known quantity for me, with well understood upsides and downsides. Yet, they describe it like it's some mysterious secret sauce they figured out (I had similar issue with how Facebook's Flow markets itself).

I am still not impressed by this whole "runtime exceptions" selling point.

Great Performance

They show a little graph there, in which elm dutifully outperforms all the top frameworks.

I've grown increasingly jaded by comparisons like this. Every new library comes shooting at the big guys with charts and graphs. Then you dig into it, and realize all the tradeoffs they had to make, on top of the lack of libraries, support and developer mindshare in general. Then it fades into obscurity, to be replaced with the next contender, with their own charts.

I mean, yes, performance is important. But IMO it's not the big selling point it used to be back in the angular vs ember days.

I'd find it much more interesting if they mentioned something about the package size or isomorphic app support. Startup speed is where the game is now.

Enforced Semantic Versioning

Elm can detect all API changes automatically thanks to its type system. We use that information to force everything in our package catalog to follow semantic versioning precisely.

That's another strange point to bring up. I don't remember ever being bitten by poor versioning. So far, elm has solved 2 problems I never knew I had, without successfully convincing me I actually have them.

This brief mention of "package catalogue" is much more interesting. How big is it? Will I be able to find elm wrappers for the libraries I need. Is there elm-bootstrap ready and available for me to plop in? Instead of this versioning nonsense, they should have a bullet point about that.

Examples

The examples section has 6 project links in varying levels of complexity, with the good old Todo app first in the list. Very nice way to introduce people to some real world elm code. I make a mental note to come back here later.

Featured users

Frankly, I've never heard of any of these companies. As this was the end of their sales pitch, I scroll back to the top.

Installation

Since I've already decided to make a weekend project in Elm, I am not interested in the online editor. I move straight to install.

I do the usual Stalin's photos comparison of which OS is closest to the top. Windows is second, which is good for poor old Windows. No linux in the list is a bit worrying, though. How does "installer" differs from "npm installer"?

Since I am doing this on Linux, I click that link.

It leads to elm's npm page with the familiar npm install instruction on top.

I've done this dance before.

So far so good. What now?

Great! I love it when language designers put some care into the editor support. I am itching to try eml-reactor, but sure, let's set up the editor first.

I click the link for my current editor, VS Code, and it leads me to the github page for VS Code Elm plugin. But surely, this must already be in VS Code's extension manager?

Yup. The extension looks popular and well maintained. It installed without a hitch.

It's time to try out those elm commands.

elm-repl is the first on on the list, of course. Functional programming people sure love them their repls.

I try out the first example (1 / 2), and... is it stuck? Did I do something wrong? Nothing is happening.

I exit, and the repl spews an error: "elm-repl: <stdin>: hGetChar: hardware fault (Input/output error)". My terminal gets corrupted by some control character, so I have to restart the session.

I try elm-repl again.

This time, things seem to work a bit better. Simple math expressions evaluate in about a second. Exiting the repl still produces that error, but at least my terminal doesn't get borked again.

Time to try making an app using elm-reactor. The docs offer the following instructions:

git clone https://github.com/evancz/elm-architecture-tutorial.git
cd elm-architecture-tutorial
elm-reactor

Well, this is interesting. I was expecting elm-reactor to work like create-react-app, and just scaffold a little hello-world project for me to start with. But it seems it will only provide the auto-reloading dev server part of it.

While messing with this, I discover another surprise.

I don't remember creating elm-package.json and elm-stuff. Hmm...

I delete the two files, start the elm-repl, type in a simple expression and, sure enough, I again have to wait 20-30 seconds to get a response. When I exit the repl, the two files are back. This is obviously something repl installs the first time when you try to run a command.

My issues with this:

• Why does it pollute my current directory? Following *nix conventions, stuff like this should go into ~/.elm directory or similar.

• Why isn't there any indication of what's going on? A simple "Initializing environment..." message would have sufficed.

This whole bit with the repl could have gone a lot better.

Back to scaffolding.

The cloned project seems to be an introductory elm tutorial.

I am somewhat surprised that there are no html or css files anywhere. Is this a frontend project? Are assets included inside elm files?

I run elm-reactor, which sets up some kind of server on http://localhost:8000 (I appreciate them not trying to be clever with the port).

Okay... This README text is from the README.md file in the project root (like on github). In the file manager at the top, I can click on various files and see their source, with some basic syntax highlighting. If I enter the examples folder and click on an .elm file, I get a big "compiling" message. After about 30 seconds of that (I presume this will be faster after caching), I see the running demo of the "button" app I've chosen.

Clicking on the "Explore History" widget in the bottom, I get a popup showing the history of all actions that had passed through the app, kind of like in redux.

And yes, I am aware redux nixed this concept from elm, not the other way around.

Anyway, it turns out this reactor thing is not just a build server, but kind of like Apache's directory browser + a dev server + a debugging environment packaged into one. Neat!

What's less neat is what happens when I open Chrome's dev tools.

Nothing. No source code. No source maps. No javascript-like debugger.

Now, that window that popped up is titled "Debugger", so I guess they expect it to fully replace Chrome's native tooling.

I remain skeptical. In my experience, all these elegant FP abstractions start to leak once you hit against messy stateful nature of the underlying reality (in this case, the DOM). But we'll see once I try to actually code something.

The remaining two cli commands are meant for advanced production use, so I'll skip those for now.

The tutorial is clearly meant to continue with me following code examples in this "eml architecture" project. But since that is veering into learning the elm language itself, I'll consider the onboarding process done at this point.

Conclusion

The onboarding was... pretty good, actually. The site is pleasant. The installation was painless. The language and the tooling are clearly a labor of love of the Elm community. Their hearts are clearly in the right place.

There are problems, of course. Repl was a bit too free with dumping its files in my current directory. Compilation startup speed is low.

The choice of onboarding messaging is strange. Why spend so much time on crap like versioning, and never mention the live debugging server with history traversal, which seems to be elm's actual main feature?

I remain skeptical about the language itself too. Some of the problems it is trying to solve certainly feel misaligned with the problems I actually need solved.

But my final conclusion about Elm can wait for me to actually try making my weekend project (this or some other weekend).

For now, consider me onboarded.