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!
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.
… 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.
Then refrain, eh?
How is 71% size reduction not a meaningful difference? You don't pay for bandwidth?
(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).
> 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.
> 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.
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.