7 ms·

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct depen

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fundamentally broken. Every single one of these tools is a raging dumpster fire because it's built on top of all of these layers of low-quality interdependent crap. I'm increasingly moving towards module-type script tags and standard ES modules everywhere, with no build step during development. It's still challenging to use node-targeted modules in this fashion, so I really do appreciate that people are working on finding ways to make it work. I just wish that we could do it without pulling in so much third-party code and the large surface area for failure and security problems that go with it.

MuffinFlavored 8y ago
> with no build step during development and then what do you do for production, webpack?
- segphault 8y ago
  I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
  - anonytrary 8y ago
    Sorry if this is a dumb question -- but that means you don't write ES6?
    - Touche 8y ago
      It doesn't mean that, they might only support ES6 browsers (even IE11 has some ES6 support).
      - anonytrary 8y ago
        Ah, thanks that's true... touche...
      - toastal 8y ago
        The support is really shallow, but using `let` and `const` is still superior to `var` where applicable.
    - segphault 8y ago
      At this point, ES6 support is sufficiently widespread that I don't really have a problem using it natively. Major features like the const, classes, template literals, and async functions are all at least at 90% market penetration. I can get away with not supporting Internet Explorer, though I understand that it's not a trade-off that everybody is comfortable making.
      - ioulian 8y ago
        I think (thought) also like you, just use the latest es6 code to do everything. The workflow is very fast, I can write my app 20%-50% faster than es5. I develop mostly on Chrome. My application/website works. Then we test the website on different browsers (we all work with OSX), FireFox works (of course), Opera works (is Chromium), Safari, naah, it's the new IE. We do some minor fixes for Safari. When we send it to the client, nothing works, of course the client uses IE so we need to rewrite a lot of stuff to make it work for "most" people. (I live in Belgium, there are "a lot of" IE users still. And even if IE is not widely used, our clients always use IE :( ) But wait, why rewrite our application, this can be fully automated! We run our code through babel/webpack. It automagically works everywhere! Now I understand there is some performance penalty by using transpilers, but using them leaves our code mostly bugfree on all browsers and the client is happy. The big problem with those fancy new features is browsersupport. If every browser followed specs correctly, we wouldn't need these tools. They make the job of the developer easy, the bosses wallet full and the client happy.
frou_dh 8y ago
I like the philosophy of no required build step. Once you make that decision, it's like a guardrail keeping you away from the tooling circus. Do you know of any listings of third-party ES Modules that are designed to be used directly? i.e. their full URLs being present in import statements that the browser sees at runtime. Even toy stuff would be interesting to look at.
pier25 8y ago
I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.
- zdragnar 8y ago
  We had several other languages once upon a time, but all were proprietary and most only worked through plugins. All were eventally removed from default installs in browsers due to awful security and mobile performance.
  - pier25 8y ago
    I was a Flash dev for some 10 years and I can count with one hand the number of third party libraries I regularly used. I don't disagree about the security issues, mobile performance, and energy consumption though, but as a dev I preferred the experience of writing AS3 apps by a long shot.
- deleted 8y ago
  [deleted]
- h1d 8y ago
  Agree. JS standard library has been very immature and was so slow to improve as it was primarily targeted for browser and people thought that wasn't the place to do complicated stuff, not even md5. I still have some array helper methods just to shuffle array or randomly pick one. I think it's time to put everything in future JS.
- rtfeldman 8y ago
  > a decent standard library and language This is what a lot of people love about Elm: it's a lovely language with a first-rate standard library. The Elm ecosystem is smaller than the JS ecosystem, but of course that's a hard requirement of a nicer foundation. More info: https://elm-lang.org https://elm-lang.org
  - toastal 8y ago
curry-castaway 8y ago
> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain its own custom CLI spinner animations? Are you saying the CLI spinners should be standardized in the next version of ECMAScript itself? How is this worse than the same thing written in Python, for example? (I mainly use javascript, so maybe I haven't been exposed to the kinds of alternatives you're thinking about.)
- intertextuality 8y ago
  It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector that’s impossible to spot because it’s loaded as the 567th package in a dependency tree? The answer here is to have a strong stdlib where do you don’t need to pull in 3rd party packages all the time for trivial things, and not including a million small packages in every single project.
  - curry-castaway 8y ago
    > The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't seem to be a solution. If anything, more dependencies are a good sign because they imply that other people have spent more time and effort on a solution than anything you'll be able to hand-roll for single-use. It sounds like the root issue here is just dependency management. If our package managers were solving this issue well enough, there should be no practical difference between 2 big dependencies with significant functionality (and more code to review) or 20 tiny, easy-to-review dependencies.

MuffinFlavored 8y ago

> with no build step during development and then what do you do for production, webpack?

segphault 8y ago
I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
- anonytrary 8y ago
  Sorry if this is a dumb question -- but that means you don't write ES6?
  - Touche 8y ago
    It doesn't mean that, they might only support ES6 browsers (even IE11 has some ES6 support).
    - anonytrary 8y ago
      Ah, thanks that's true... touche...
    - toastal 8y ago
      The support is really shallow, but using `let` and `const` is still superior to `var` where applicable.
  - segphault 8y ago
    At this point, ES6 support is sufficiently widespread that I don't really have a problem using it natively. Major features like the const, classes, template literals, and async functions are all at least at 90% market penetration. I can get away with not supporting Internet Explorer, though I understand that it's not a trade-off that everybody is comfortable making.
    - ioulian 8y ago
      I think (thought) also like you, just use the latest es6 code to do everything. The workflow is very fast, I can write my app 20%-50% faster than es5. I develop mostly on Chrome. My application/website works. Then we test the website on different browsers (we all work with OSX), FireFox works (of course), Opera works (is Chromium), Safari, naah, it's the new IE. We do some minor fixes for Safari. When we send it to the client, nothing works, of course the client uses IE so we need to rewrite a lot of stuff to make it work for "most" people. (I live in Belgium, there are "a lot of" IE users still. And even if IE is not widely used, our clients always use IE :( ) But wait, why rewrite our application, this can be fully automated! We run our code through babel/webpack. It automagically works everywhere! Now I understand there is some performance penalty by using transpilers, but using them leaves our code mostly bugfree on all browsers and the client is happy. The big problem with those fancy new features is browsersupport. If every browser followed specs correctly, we wouldn't need these tools. They make the job of the developer easy, the bosses wallet full and the client happy.

frou_dh 8y ago

I like the philosophy of no required build step. Once you make that decision, it's like a guardrail keeping you away from the tooling circus. Do you know of any listings of third-party ES Modules that are designed to be used directly? i.e. their full URLs being present in import statements that the browser sees at runtime. Even toy stuff would be interesting to look at.

pier25 8y ago

I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.

zdragnar 8y ago
We had several other languages once upon a time, but all were proprietary and most only worked through plugins. All were eventally removed from default installs in browsers due to awful security and mobile performance.
- pier25 8y ago
  I was a Flash dev for some 10 years and I can count with one hand the number of third party libraries I regularly used. I don't disagree about the security issues, mobile performance, and energy consumption though, but as a dev I preferred the experience of writing AS3 apps by a long shot.
deleted 8y ago
[deleted]
h1d 8y ago
Agree. JS standard library has been very immature and was so slow to improve as it was primarily targeted for browser and people thought that wasn't the place to do complicated stuff, not even md5. I still have some array helper methods just to shuffle array or randomly pick one. I think it's time to put everything in future JS.
rtfeldman 8y ago
> a decent standard library and language This is what a lot of people love about Elm: it's a lovely language with a first-rate standard library. The Elm ecosystem is smaller than the JS ecosystem, but of course that's a hard requirement of a nicer foundation. More info: https://elm-lang.org https://elm-lang.org
- toastal 8y ago

curry-castaway 8y ago

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain its own custom CLI spinner animations? Are you saying the CLI spinners should be standardized in the next version of ECMAScript itself? How is this worse than the same thing written in Python, for example? (I mainly use javascript, so maybe I haven't been exposed to the kinds of alternatives you're thinking about.)

intertextuality 8y ago
It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector that’s impossible to spot because it’s loaded as the 567th package in a dependency tree? The answer here is to have a strong stdlib where do you don’t need to pull in 3rd party packages all the time for trivial things, and not including a million small packages in every single project.
- curry-castaway 8y ago
  > The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't seem to be a solution. If anything, more dependencies are a good sign because they imply that other people have spent more time and effort on a solution than anything you'll be able to hand-roll for single-use. It sounds like the root issue here is just dependency management. If our package managers were solving this issue well enough, there should be no practical difference between 2 big dependencies with significant functionality (and more code to review) or 20 tiny, easy-to-review dependencies.