2 ms·

Same, and I wrote a blog article about it because front end development has a lot of unique challenges. https://erock.prose.sh/my-love-letter-to-front-end-web-

by qudat 4y ago

Same, and I wrote a blog article about it because front end development has a lot of unique challenges. https://erock.prose.sh/my-love-letter-to-front-end-web-development https://erock.prose.sh/my-love-letter-to-front-end-web-devel...

soulofmischief 4y ago
I enjoyed your article, thanks for sharing. > Modern javascript code is compiled and that's not going away anytime soon Absolutely, I think most opponents of this change in the workflow have failed to understand the requirements being placed on developers to push a cutting-edge, performant and platform-neutral service ecosystem.
aragilar 4y ago
I agree the need to keep things small is a key part of front-end tooling, but it is worth noting that the choice by the ecosystem to effectively statically link everything (vs having a versioned stdlib which could be cached in a privacy-preserving way) does mean that sometimes size is traded off in detrimental-to-user ways (e.g. dropping support for older/unpopular browsers ASAP, worse implementations are chosen over better ones due to file size). I do wonder what's going to happen with the use of WASM, I doubt it's going to produce libraries any smaller than ELF, so are people going to try and use caching tools like indexeddb to avoid repeated downloads (and is that the next key bit of tooling to arrive), or are we going to burn our mobile data just so people can avoid building native apps? As a side note, I find the numpy comment quite interesting: I'm guessing the ~30MB is based on the wheel? It looks to me (based on the size of numpy in Debian) that ~1/2 of that is shared libraries (e.g. BLAS) which isn't part of numpy. There's also things like: f2py (which helps wrap Fortran libs for use in python), which is just over 1MB; tests including test data, which looks to be about ~5MB; and SIMD support which is almost 2MB. I suspect there's other things you could strip out which would make the size smaller to make things more comparable to front-end work (I've noticed on shared systems that the size of people's conda installs is comparable to my container with a full dev environment, both doing similar things with python). I do think you'd struggle to get it under a few MBs though, as for comparison the FFTW shared lib on my system alone is 2.1MB (with the static one sitting at 4.3MB), and I'd be concerned if there was a different FFT codebase which was much smaller than that (as you'd start wondering what's been left out/incorrectly implemented).

by qudat 4y ago

soulofmischief 4y ago

I enjoyed your article, thanks for sharing. > Modern javascript code is compiled and that's not going away anytime soon Absolutely, I think most opponents of this change in the workflow have failed to understand the requirements being placed on developers to push a cutting-edge, performant and platform-neutral service ecosystem.

aragilar 4y ago

I agree the need to keep things small is a key part of front-end tooling, but it is worth noting that the choice by the ecosystem to effectively statically link everything (vs having a versioned stdlib which could be cached in a privacy-preserving way) does mean that sometimes size is traded off in detrimental-to-user ways (e.g. dropping support for older/unpopular browsers ASAP, worse implementations are chosen over better ones due to file size). I do wonder what's going to happen with the use of WASM, I doubt it's going to produce libraries any smaller than ELF, so are people going to try and use caching tools like indexeddb to avoid repeated downloads (and is that the next key bit of tooling to arrive), or are we going to burn our mobile data just so people can avoid building native apps? As a side note, I find the numpy comment quite interesting: I'm guessing the ~30MB is based on the wheel? It looks to me (based on the size of numpy in Debian) that ~1/2 of that is shared libraries (e.g. BLAS) which isn't part of numpy. There's also things like: f2py (which helps wrap Fortran libs for use in python), which is just over 1MB; tests including test data, which looks to be about ~5MB; and SIMD support which is almost 2MB. I suspect there's other things you could strip out which would make the size smaller to make things more comparable to front-end work (I've noticed on shared systems that the size of people's conda installs is comparable to my container with a full dev environment, both doing similar things with python). I do think you'd struggle to get it under a few MBs though, as for comparison the FFTW shared lib on my system alone is 2.1MB (with the static one sitting at 4.3MB), and I'd be concerned if there was a different FFT codebase which was much smaller than that (as you'd start wondering what's been left out/incorrectly implemented).