Hacker News Reader

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.