4 ms·

> include entire frameworks instead of just writing a couple helper functions > unhealthy insistence of code reuseability The problem you're alluding is that u

> include entire frameworks instead of just writing a couple helper functions > unhealthy insistence of code reuseability The problem you're alluding is that until recently, there was very poor support on the web for the equivalent of Unix strip[1] or Proguard[2] (often used by Android devs). We need reliable and accurate dependency analysis to be able to properly eliminate unused code. Today, with ES6 modules and a recent version of webpack, this is partly possible. Unused modules are not included in the final output file. I noticed a drastic drop in the final minified JS file size, after moving to a configuration that enabled this sort of (module) stripping. [1] https://en.wikipedia.org/wiki/Strip_(Unix) https://en.wikipedia.org/wiki/Strip_(Unix) [2] https://stuff.mit.edu/afs/sipb/project/android/sdk/android-sdk-linux/tools/proguard/docs/index.html#manual/introduction.html https://stuff.mit.edu/afs/sipb/project/android/sdk/android-s...

Sohcahtoa82 8y ago
Those shouldn't even be needed. To give an example, let's say you need to calculate SHA-256 hashes in your program. People would rather include the OpenSSL library than just add a SHA-256 function to their code. Instead of a single function (that maybe has a couple helper functions), they add a massive library full of features they don't need, taking up memory, bloating the executable size, and increasing load time. If you're using less than 10% of a module, you should be questioning if you even need that module at all.
- winter_blue 8y ago
  If I understand correctly, I think you're suggesting they copy the functions they need from the library into their own source tree. I think that makes sense for something simple like left-pad, but I don't think it's advisable in most cases. For instance, the SHA-256 function is non-trivial[1]. Even thought it's just around 100 lines, it's a fairly intricate function, and I would want to use a library for it. Preferably a heavily-used library like OpenSSL. Using a library reduces the size of my own code base, and places the responsibility for fixing bugs and optimizing the SHA-256 with the open source community / the maintainers of the library. SHA-256 is particularly interesting, because modern Intel and AMD CPUs have dedicated instructions[2] for performing it. If I copied the source code for SHA, and later the library was updated to use the x86 instruction if available, then I would lose out on this performance gain. Ultimately, the solution should be in constructing reliable and correct dependency management systems, and using the operating system's dynamic/shared library infrastructure to not bloat code size. Modern operating systems are incredibly efficient when it comes to DLLs/shared libraries. They load up the DLL only once, and every subsequent program that needs it reads off the same shared memory pages for the DLL. Whenever, some data (in the shared library), it forks that memory page alone for the process. It's incredibly efficient, and except for the first time the library is loaded, it is fast at loading. I think due to a fear of the so-called "DLL Hell", at some point people decided to statically link everything, and create giant executables. The smart solution would have been to find a solution to the dependency hell problem (where a good start would be simply versioning .so/.dll files). The limitation to this approach of course is that using (.so/.dll) shared libraries is only possible with native programs. Although, I think with web pages/apps, if you link to the same resource (script/CSS/etc) in multiple pages, the browser should only download/load it once; with a request sent to server to see if the resource has been modified (getting back a "304 Not Modified" response most of the time). [1] https://www.movable-type.co.uk/scripts/sha256.html https://www.movable-type.co.uk/scripts/sha256.html [2] https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions

Sohcahtoa82 8y ago

Those shouldn't even be needed. To give an example, let's say you need to calculate SHA-256 hashes in your program. People would rather include the OpenSSL library than just add a SHA-256 function to their code. Instead of a single function (that maybe has a couple helper functions), they add a massive library full of features they don't need, taking up memory, bloating the executable size, and increasing load time. If you're using less than 10% of a module, you should be questioning if you even need that module at all.

winter_blue 8y ago
If I understand correctly, I think you're suggesting they copy the functions they need from the library into their own source tree. I think that makes sense for something simple like left-pad, but I don't think it's advisable in most cases. For instance, the SHA-256 function is non-trivial[1]. Even thought it's just around 100 lines, it's a fairly intricate function, and I would want to use a library for it. Preferably a heavily-used library like OpenSSL. Using a library reduces the size of my own code base, and places the responsibility for fixing bugs and optimizing the SHA-256 with the open source community / the maintainers of the library. SHA-256 is particularly interesting, because modern Intel and AMD CPUs have dedicated instructions[2] for performing it. If I copied the source code for SHA, and later the library was updated to use the x86 instruction if available, then I would lose out on this performance gain. Ultimately, the solution should be in constructing reliable and correct dependency management systems, and using the operating system's dynamic/shared library infrastructure to not bloat code size. Modern operating systems are incredibly efficient when it comes to DLLs/shared libraries. They load up the DLL only once, and every subsequent program that needs it reads off the same shared memory pages for the DLL. Whenever, some data (in the shared library), it forks that memory page alone for the process. It's incredibly efficient, and except for the first time the library is loaded, it is fast at loading. I think due to a fear of the so-called "DLL Hell", at some point people decided to statically link everything, and create giant executables. The smart solution would have been to find a solution to the dependency hell problem (where a good start would be simply versioning .so/.dll files). The limitation to this approach of course is that using (.so/.dll) shared libraries is only possible with native programs. Although, I think with web pages/apps, if you link to the same resource (script/CSS/etc) in multiple pages, the browser should only download/load it once; with a request sent to server to see if the resource has been modified (getting back a "304 Not Modified" response most of the time). [1] https://www.movable-type.co.uk/scripts/sha256.html https://www.movable-type.co.uk/scripts/sha256.html [2] https://en.wikipedia.org/wiki/Intel_SHA_extensions https://en.wikipedia.org/wiki/Intel_SHA_extensions