Comment by capableweb
2 years ago
> tbh, this seems pretty far out there. Sourcemap file size is a non-issue, they're not gigabytes
Sure, by themselves, but replicate that across everyone repeatedly downloading the library in various build processess, in various projects and with different versions.
Sure, by itself a sourcemap might not add up to much. But then there is various projects with different versions, who download the library repeatedly in different build steps. Then it starts to add up both in bandwidth, and in storage taken.
Luckily, there are still package and library maintainers who care about making things less, instead of more, both in architectures and size.
> Just so that people can modify the source code directly a little bit easier?
This is a real thing that is useful to think about, how to make your software easier to change in the future, while just solving the current concern without over-engineering the solution.
> it starts to add up both in bandwidth, and in storage taken
Are we really talking about disk space in 2023? Seriously?
And bandwidth? Like we don't have several cache systems - including npm's - that can help?
> how to make your software easier to change in the future
Ok, is there someone who can explain in details how would that help?
> Are we really talking about disk space in 2023? Seriously?
Well, it adds up, if you're doing multiple projects.
Doing a quick scan of my work desktop, I find 43,237 filenames matching ".js.map". The biggest is at ~10,000 KB, the smallest at 1KB. If we assume the average is just 200KB, in total they represent ~8.6 gigabytes (200 kilobytes 43237). That's not nothing.
> And bandwidth? Like we don't have several cache systems - including npm's - that can help?
Being conservative with bandwidth is a good thing for most. Not only will everything download faster because less is needed, but it'll probably be cheaper for you to run your application as serving less bandwidth either gives you a small bill if you use cloud, or requires less hardware if you're going the dedicated route.
Not to mention not everyone sits with the latest maxxed out Apple hardware for working, especially outside the SV bubble. These people deserve to be able to have a good development environment as well.
Overall, everything gets faster and cheaper if you save bandwidth.
> Ok, is there someone who can explain in details how would that help?
It's easy, the lesser moving parts your application has in the abstraction ladder, the safer and easier it gets to change things in the future.
Transpiling from one language to another to get a benefit you can also get by not transpiling a language from one to another, seems like a no-brainer to me in most cases.