4 ms·

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one

by nine_k 1y ago

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package. A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but still is tricky and not widespread.)

skydhash 1y ago
Doesn’t the bundler already do tree shaking? Optimizing via dependency listing is very wrong.
- tracker1 1y ago
  Tree shaking is less than reliable... for it to work well, all the dependencies need to be TS/ESModule imports/exports and even then may not shake out properly. It helps, but not as much as judicious imports. I've been using Deno more for my personal projects which does have a pretty good @std library, though I do think they should keep methods that simply pass through to the Deno runtime, and should probably support working in Node and Bun as well.
palmfacehn 1y ago
Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.
- nine_k 1y ago
  This is because you cannot easily remove problematic stuff from the browser. It's actively being used by someone, so the vendors keep it, so it continues to be used. The process takes decades, literally. On the server side, of course, you can do whatever you like, see Node / Deno / Bun. But the code bundle size plays a minor role there.
- crabmusket 1y ago
  I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have wrestled with these issues as best they can and that has shaped what we see today.
  - skydhash 1y ago
    > what other language needs to distribute to an unknown runtime environment over the network? What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated. And most time, the browser is already downloading lot of images and other resources. Arguing about bundle size is very hypocritical of developers that won't blink at adding 17 analytics modules.
    - crabmusket 1y ago
      > Checking the existence of features and polyfilling is not that complicated. Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a standard library) is not trivial. And that's not even considering browser bugs and regressions. > very hypocritical of developers that won't blink Not a great argument, as developers don't necessarily get to choose how to add analytics, and plenty of them try to push back against doing so. Also, the cost of parsing and JIT'ing JS code is byte-for-byte different to the cost of decoding an image.
      - skydhash 1y ago
        > Judging by what we see in the world, most developers don't agree with you. And neither do I. From my POV, most developers just test on the most popular browser (and the latest version of that) without checking if the API is standard or its changelog. Or they do dev on the most powerful laptop while the rest of the world is still on 8gb, FHD screen with integrated gpu.
0cf8612b2e1e 1y ago
Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality. Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.
- palmfacehn 1y ago
  There's also the option of including that standard lib with the runtime.
  - crabmusket 1y ago
    That is exactly what happens today. JS has a standard library. It's just not evenly distributed.
    - int_19h 1y ago
      JS standard library is missing very basic things like maps with value semantics for keys that aren't primitives.
  - 9dev 1y ago
    And never ever be able to correct your past mistakes, because some sites might still be using them? The web platform is no .NET runtime you can just update.
    - int_19h 1y ago
      Web browsers update far more often than .NET runtime, if anything. And .NET still supports a lot of deprecated stuff going all the way back to 1.0; so does Java (old-style collections, for example). Also, JavaScript is a shining example of "never ever be able to correct your past mistakes" already, so it's not like this is something new for the web.

by nine_k 1y ago

skydhash 1y ago

Doesn’t the bundler already do tree shaking? Optimizing via dependency listing is very wrong.

tracker1 1y ago
Tree shaking is less than reliable... for it to work well, all the dependencies need to be TS/ESModule imports/exports and even then may not shake out properly. It helps, but not as much as judicious imports. I've been using Deno more for my personal projects which does have a pretty good @std library, though I do think they should keep methods that simply pass through to the Deno runtime, and should probably support working in Node and Bun as well.

palmfacehn 1y ago

Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.

nine_k 1y ago
This is because you cannot easily remove problematic stuff from the browser. It's actively being used by someone, so the vendors keep it, so it continues to be used. The process takes decades, literally. On the server side, of course, you can do whatever you like, see Node / Deno / Bun. But the code bundle size plays a minor role there.
crabmusket 1y ago
I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have wrestled with these issues as best they can and that has shaped what we see today.
- skydhash 1y ago
  > what other language needs to distribute to an unknown runtime environment over the network? What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated. And most time, the browser is already downloading lot of images and other resources. Arguing about bundle size is very hypocritical of developers that won't blink at adding 17 analytics modules.
  - crabmusket 1y ago
    > Checking the existence of features and polyfilling is not that complicated. Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a standard library) is not trivial. And that's not even considering browser bugs and regressions. > very hypocritical of developers that won't blink Not a great argument, as developers don't necessarily get to choose how to add analytics, and plenty of them try to push back against doing so. Also, the cost of parsing and JIT'ing JS code is byte-for-byte different to the cost of decoding an image.
    - skydhash 1y ago
      > Judging by what we see in the world, most developers don't agree with you. And neither do I. From my POV, most developers just test on the most popular browser (and the latest version of that) without checking if the API is standard or its changelog. Or they do dev on the most powerful laptop while the rest of the world is still on 8gb, FHD screen with integrated gpu.

0cf8612b2e1e 1y ago

Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality. Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.

palmfacehn 1y ago
There's also the option of including that standard lib with the runtime.
- crabmusket 1y ago
  That is exactly what happens today. JS has a standard library. It's just not evenly distributed.
  - int_19h 1y ago
    JS standard library is missing very basic things like maps with value semantics for keys that aren't primitives.
- 9dev 1y ago
  And never ever be able to correct your past mistakes, because some sites might still be using them? The web platform is no .NET runtime you can just update.
  - int_19h 1y ago
    Web browsers update far more often than .NET runtime, if anything. And .NET still supports a lot of deprecated stuff going all the way back to 1.0; so does Java (old-style collections, for example). Also, JavaScript is a shining example of "never ever be able to correct your past mistakes" already, so it's not like this is something new for the web.