Has anyone started a project with elm and continued it for a long time?
I know NoRedInk has a lot of Elm components; however, they employ Evan Czaplicki, who is the creator of the language.
Asset minification with Elm (2018)
11–20 of 59 posts
Re: Asset minification with Elm (2018)
#12Describing this as just "minification" downplays the compiler improvements, here.
Agreed. 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…
Re: Asset minification with Elm (2018)
#13I 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 k…
… 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.
Re: Asset minification with Elm (2018)
#14I 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 k…
Re: Asset minification with Elm (2018)
#15Has anyone started a project with elm and continued it for a long time?
Re: Asset minification with Elm (2018)
#16I 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 k…
Then refrain, eh?
How is 71% size reduction not a meaningful difference? You don't pay for bandwidth?
Re: Asset minification with Elm (2018)
#17Has anyone started a project with elm and continued it for a long time?
Re: Asset minification with Elm (2018)
#18Has anyone started a project with elm and continued it for a long time?
Yep we build CircuitHub (YC startup) on Elm. I know quite a few companies that also have large Elm code bases.
Re: Asset minification with Elm (2018)
#19Has anyone started a project with elm and continued it for a long time?
Re: Asset minification with Elm (2018)
#20I 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 k…
> 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.