3 ms·

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 com

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.

weavie 7y ago
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!
- bastawhiz 7y ago
  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.
wereHamster 7y ago
> 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.
manigandham 7y ago
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.
carapace 7y ago
> 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?
- bastawhiz 7y ago
  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.
untog 7y ago
> 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.
amimetic 7y ago
"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).
the_gipsy 7y ago
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.

weavie 7y ago

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!

bastawhiz 7y ago
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.

wereHamster 7y ago

> 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.

manigandham 7y ago

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.

carapace 7y ago

> 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?

bastawhiz 7y ago
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.

untog 7y ago

> 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.

amimetic 7y ago

"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).

the_gipsy 7y ago

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.