Hacker News new | past | comments | ask | show | jobs | submit login
Asset minification with Elm (2018) (elm-lang.org)
68 points by lelf 55 days ago | hide | past | web | favorite | 57 comments

Has anyone started a project with elm and continued it for a long time?

I have been writing Elm for 5 years now. I work at Humio, where our front end is 100k lines of Elm code.

What would you like to know? I love Elm. I'm absolutely hooked. I don't want to go back to doing Frontend work in JS, and I hope one day there can be an Elm-like experience for backend development as well.

Just off the top of my head a few bits of what I like about Elm: - You can actually write code, have no errors, and then move on, and never return to the project again. When I was doing JS, everyone I knew just took it for granted that you would be maintaining everything you ever wrote for the rest of your career. Not with Elm! You can actually finish projects and never return to them. - Its a simple and small language that is designed to interact with human beings. The compiler really talks to you instead of spitting out error codes or spaghetti. Apis and variables have human readable names instead of mathy terms of symbols. - For everything theres one way of doing things and the one way is usually really good. This strong consensus orientation of the Elm community means everyone is speaking the same language about every problem.

Gotta go, bye.

I'm curious if you tried out ReasonML[0] at all, for any length of time, before Elm, or even after.


I've really been digging slowly into ReasonML and the biggest gain I can see is that valid reason === valid ocaml (and there's some good server libraries out there for ocaml)

I also like that JSX is the templating language, not that it matters.

Also, have you had any success with manipulating Elm to output static HTML/CSS as well as JS? I know it can do it, but I've never been able to manipulate how it does it (most recent version I tried with: 0.18)

I havent actually written any ReasonML, but I once had to review some my former coworker wrote. Thats the extent of my ReasonML experience, so I dont have much of an opinion. However, I was surprised that the ReasonML code I looked at relied on impure functions. I like pure functions so that scares me off a bit from the OCaml as a whole.

Regarding static html/css, I havent done that either, so I dont know about it.

> the ReasonML code I looked at relied on impure functions. I like pure functions so that scares me off a bit from the OCaml as a whole.

ReasonML (OCaml) allows impure functions but the best practice is to stay pure whenever possible. It's a very pragmatic language so despite providing all the functional and immutable programming features, it allows you to cut through the bureaucracy if you need to.

One way to get static HTML/CSS from Elm is to execute the JS it produces and serialise the results from the DOM. That's what I do in my static site generator Elmstatic: https://korban.net/elm/elmstatic

> I hope one day there can be an Elm-like experience for backend development as well.


They are pretty different. They have similar syntax, and their type systems are similarly strong, but beyond that they are pretty different.

Haskell has a huge syntax and a ton of language features. It has a big ecosystem. Haskell is very mathy. Elm is the opposite in each of those regards.

Unfortunately there is a large gap between the developer experience of both ecosystems.

> You can actually finish projects and never return to them

How do you manage that? Migrating from 0.18 to 0.19 wasn't hard in my limited experience, but it wasn't "finish and never return" either.

I dont even think upgrading to 0.19. If you have 0.18 code that works, why upgrade? I think NoRedInk has some very old versions of Elm still in production, like 0.16 or something.

Years ago we had some 0.18 and 0.16 code coexisting, but last year we updated everything to 0.19!

How is your experience with more "advanced" stateful interactions such as drag&drop?

Good. I have written drag and drop functionality in Elm a few times. I have a clear enough idea on how that code looks that if I had to write a drag and drop today, I think I could crank it out quickly.

You call it stateful tho. I dont know that drag and drop needs to be all that stateful. For drag and drop, the information your model needs is whether you have mouse-down-ed on something, the coordinates on the html element you mouse-down-ed, and the coordinates the mouse's current location is. 2 pairs of coordinates and a maybe type? Not too bad. I guess there is the code too, but at least the data is just few values, and not a complex and nested data structure.

On my team at work, we avoid state. Complex nested state is a big code smell for us.

Been suggesting we use it for a complicated bit of interface for a company I was working at two years ago, we were pleasantly surprised at how well it held both in requiring low (almost no) maintenance once written and how easy it was to improve on the codebase.

We migrated pretty easily from 0.18 to 0.19, we only had to import a bit of code here and there from libs that would not migrate or update where changes had been made, strong typing and the compiler made it a rather pleasant experience.

The only thing we did not do was migrate to an SPA ; the scope of the app was wide and the cost to achieve this was too high I guess.

Few pain points, amongst which:

- Sometimes you have to do something you would expect to find off-the-shelf (like a souped-up drop-down or a tag editing system) but it's ususally a matter of designing your ui well and can be fun (plus you get to really design the user experience).

- Sometimes you have to do a bit of JS for stuff that aren't designed in Elm (anymore, ie websockets) and use ports to communicate.

- If you're building incrementally, and make mistakes (over-design, useless code to conform to an unrequired philosophy, etc.) it's a good thing to sometimes challenge the bad old choices and get them smoothed down ; thankfully the compiler is your friend here too.

- The learning curve, especially if your team isn't fond of functional programming, can be daunting if you don't have an Elm advocate. That was me in my team, and we grew fond of it, but made quite a few beginners mistakes on the way. All very fixable though.

Well, that's about it ; if you want help getting people started and boosted on the functional programming paradigm, please have a look at my blog: it's Elm-centric, focusing on the most important functional programming concepts that'll get you up and running on what's happening there :) https://medium.com/wat-the-elm-ist And it might even explain what monads are ;)

We've been using it in production since the end of 2015. We have two main products whose front-end is written entirely in Elm, a third one in development, totalling about 80k loc.

It's a blast, it's a wonderful developer experience, it's changed my life as a developer after having to fight with Angular and React and the myriad of tools you need to use to have a decent experience.

It would be difficult for me to consider a position where I would not use Elm anymore, and if I did it would have to satiate my thirst for functional programming by letting me work with other cool similar languages.

I've worked on two (2) substantial production Elm applications.

1. Healthcare

Fall 2017, I started integrating Elm into an AngularJS application after experimenting with it on a couple of side projects. After a successful initial feature, I convinced the team to use it for new features. Another couple of developers helped to create the initial version until late 2018. We started in Elm 0.18 and converted it to 0.19. Now a sole part-time college student maintains and adds new features to it.

2. Transportation management

Since January 2019, I work on an Elm project, once again weaved into an existing AngularJS app, with ~34k lines of Elm code. I inherited it with no interaction from the previous developer. It looks like it was introduced in mid-2017 and is currently on Elm 0.19. Although it is not perfect, not always following best practices, it is much easier to maintain than anything I've worked on in the past. On JS apps, I've torn my hair out trying to figure out what is going on and attempting to add new features.

With Elm, I refactor daringly and rest more easily.

Please let me know if you have any specific questions.

Since January 2019, I work on an Elm project, once again weaved into an existing AngularJS app, with ~34k lines of Elm code.

Watching a simple example in the elm website, the codes make judicious use of new lines, would you say those 34k lines would represent 17K in js?

Yes, something like that. Almost everyone who writes Elm code uses elm-format which is very "spacey". So foo = 1 is formatted with foo = on one line and 1 on the next, with some leading space.

Yep we build CircuitHub (YC startup) on Elm. I know quite a few companies that also have large Elm code bases.

The “example” is crashing my safari on iphone xs. Impressive product though.


Thanks for the bug report, I'll let the dev team know!

I wouldn't consider that a problem with Elm it's just that our users are mostly on desktop Chrome so we don't test very often on mobile Safari.

We've used it pretty heavily at Drip for nearly two years now. It's been great for taking on some complex UI and making it maintainable.

I wrote a library that parses a subset of LaTeX and renders it as HTML. See https://demo.minilatex.app/ or more at https://minilatex.io I was astonished by what is possible to do with Elm. This is a continuing project. It is easy to go back to the code even after leaving it untouched for several months. I've engaged in "extreme refactoring" many times. No fears!

I've also written a bunch of small mathy apps, e.g. https://jxxcarlson.io/apps/

Elm has been a joy to work with.

If you're interested in an open-source project, I've been using Elm in https://github.com/icidasset/diffuse for 2 and half years now.

Looks great!

We've been using it for almost two years. I wrote this just after the 0.19 release and still stand by it; I wouldn't start a project in Elm again until I'd explored more options (in particular purescript).


Yeah, our work frontends are done in Elm, my side-project SaaS is done in Elm, etc. The maintainability is fantastic. Do you have more specific questions / concerns?

Is ELM a good fit for non-SPAs web apps?

We have been using for about 3 years now. Myself and the two other devs enjoy working in it more than the other languages we use (Ruby, Go and vanilla JS).

Upgrades have been pretty painless, and each new release brings a new level of ease of use.

We have made some architectural mistakes as we have learned the language. And since it is a newer language there are not as many established conventions for code organization – but we are figuring out.

I've had a hobby game in Elm which I worked on for about a year and a half and I was the second engineer ( frontend lead ) hired to 'rescue' a greenfield project with Elm as the frontend. That is now at 100k+ LOC, 2.5 years later. Our team has grown from 3 to 9, we have 3 frontend devs all writing in Elm and looking for our 4th.

The company now has 4 production projects with Elm as the sole frontend tech.

We have elm running in prod for about 2 years in my team, and our story has motivated a couple more teams to use it.

Do you have specific questions ?

I know NoRedInk has a lot of Elm components; however, they employ Evan Czaplicki, who is the creator of the language.

It’s worth noting that they first used Elm very extensively, then because of that they hired Evan to maintain the language there.

I've used Elm for frontend pretty much exclusively since 2016. In the last two months I changed jobs and now write a bunch of typescript, and it's fine, but would much prefer to be writing elm...I mean, I'm only working on backend right now, but still...

I'm curious about why you prefer Elm over TypeScript, as both are statically typed

Been using Elm exclusively for 2 years. Many projects of different sizes. Very pleased with it.

ITPro.TV is using Elm to build all their new dynamic frontends, and is refactoring their legacy app using Elm.

How about cross mobile apps (ionic/cordova)?

I developed mobile app on Elm with Cordova. Works great. Will be published to store soon.

I don't want to downplay Elm's accomplishments here, but I really disagree with the "RealWorld" example here. Does a 29kb asset make a meaningful difference compared to a 100kb asset? Especially if the framework is a fixed chunk of that, the space savings as the project grows in size is not incredibly meaningful in the grand scheme of things. 50kb of excess code on my page due to missed optimizations isn't going to keep me up at night.

A more meaningful comparison would be "we ported these actual production apps to Elm and here's the difference." Finding comparisons between languages like Elm and JS often feels like an exercise in microoptimization: I don't care if it can update the DOM 20% faster if React or Angular already does it within 16ms, or if the download time for my bundle is reduced by 50% if it already loads in 200ms for my 95th percentile. What's going to get me interested in tools like Elm are solutions for actual issues that I'm toiling over, like providing better tools for mocking in tests, ways to build custom lint rules that don't involve me becoming a metaprogramming expert, isomorphic rendering without heartache, etc.

Microoptimizations performed by someone else is only really a problem if they sacrifice something else to acheive them. So if it meant that writing Elm code was a horrendous buggy experience in order to achieve that extra 50kb, then sure that's a problem.

But when its added on top of a really pleasant development experience then you don't really need to to think about it too much. All it really is saying is that you aren't paying for it with extra code bloat.. Which is a great thing!

I don't disagree that it's a net positive. My point is that aside from being a post about the technical accomplishments of Elm, it does little to sell me on changing my tools and language. I don't doubt that Elm is pleasant to work with, but I find React really pleasant to work with.

If the goal is to convince me to learn a new language for the weekend and play with it, telling me how I can save 50kb isn't huge motivation. Seeing actual examples of real world benefits are compelling for me, not artificial samples.

> I don't care if it can update the DOM 20% faster if React or Angular already does it within 16ms […]

… on your beefy 1st world country developer machine. But some of us are building websites and apps which are used by people in 3rd world countries, where CPUs are not as fast, RAM is not as plentiful, bandwidth costs more and latency is much higher.

It all comes down to what is the target user group. If I'm building an intranet app, where I know people will be using their local 10G LAN to load the page, and run it on their powerful office machines, then not even a 10MB bundle size would keep me up at night. But then there are projects for NGOs which need to be accessible in 3rd world countries and so my priorities shift.

Yes, every byte counts, but bigger payloads also take longer to parse and execute. This second step makes a major difference in user experience, especially with mobile networks and slower devices.

> I don't want to downplay Elm's accomplishments here

Then refrain, eh?

How is 71% size reduction not a meaningful difference? You don't pay for bandwidth?

Because it's a pointless benchmark. Comparing percentages for an artificial app that's small enough to reasonably print out at 12pt text doesn't show anything meaningful. Seventy kilobytes, even on a bad device on a slow connection is hardly noticeable. Show me real meaningful data.

"better tools for mocking in tests, ways to build custom lint rules": thanks to Elm being pure functional you don't really need mocking. And the amazing DX/tooling would make linting in style of JS completely unnecessary. So no need to toil over these issues at all in Elm. It won't help with isomorphic rendering.

(I write this as someone who mainly does TypeScript, but did a few months of paid Elm work. The main problems with Elm I see are the lack of jobs + as of 0.19 the hostile (NB technically, not personally) approach to those not aligned with Evan's direction for Elm).

Of course it is meaningful. Go ahead and do your next demo on a shitty android phone.

> mocks in tests, lint rules, isomorphic

What, is that like the stuff that irked you this week? Elm has tons of stuff to offer, some drawbacks too.

> I don't care if it can update the DOM 20% faster if React or Angular already does it within 16ms, or if the download time for my bundle is reduced by 50% if it already loads in 200ms for my 95th percentile.

> What's going to get me interested in tools like Elm are solutions for actual issues that I'm toiling over, like providing better tools for mocking in tests

Basically: "I don't care about the user experience, I only care about my own developer experience".

Sad, really. Any performance impact is huge when you imagine the sheer number of devices that code will run on once it's published to the web. And the variety of devices - does it render within 16ms on an old Android phone? I'll bet it doesn't. And that KBs of download isn't just download time, it's parse time too. Again, an old device is going to be sluggish parsing JS.

Even if you're talking about 95th percentile, prioritising your own development comfort over the experience of that last 5th of users feels wrong to me.

Elm is not consensual but is definitely influential specially considering the small investment involved. From the top of my mind:

- TEA (the elm architecture) -> Redux

- Elm compiler error messages -> Rust error messages

Elm's BDFL, according to his talks or his twitter account, seems to be a thinker, not a politician. Every new release brings something new. I wonder what 0.20 will be.

> Every new release brings something new.

Elm giveth, and Elm taketh away. I remember seeing stories about how new Elm versions removed some bits of functionality available in the previous versions...

It is true. Elm has taken some syntax away and native packages, and made the language better by being simpler and error free (I have never had a runtime error).

Upgrades since 0.17 have been pretty easy too - there is automated tooling that does the heavy lifting.

Migration ease really depends on your use case. I am currently doing the upgrade on a production application, and some changes (dates, navigation/fullscreen) have been a pain.

The more automatic stuff that can be caught by the compiler is usually a breeze, though.

Describing this as just "minification" downplays the compiler improvements, here.


But ... minification is totally relatable and "better error messages" is less-so. The problem with benchmarks is they over-emphasize things that are measurable. Honestly, I don't care as much about binary size as I do about, e.g. maintainability. But the latter is harder to quantify.

It's not Elm's fault they have to play that game. People search for, "fastest javascript framework" when maybe that's not what they actually want. Maybe all they want is a good friend.

I don't really care about errors. That is important for newcomers but after sometime people eventually learn idiosyncratic stuff in languages. The motivating part of .19 is the improved compile times.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact