6 ms·

> modern javascript ecosystem. I recently was convinced to start using a packer (webpack, parcel) and was blown away by the hoops people have to jump through t

> modern javascript ecosystem. I recently was convinced to start using a packer (webpack, parcel) and was blown away by the hoops people have to jump through to make stuff work. I've been spending an hour or so a day coming up to speed for the past few weeks, and every yarn/npm package I installed had some kind of error/warning that required a hack, or version contortion. I naively thought I could webpack with electron+vue+pug+ts and was soundly smacked down repeatedly, even after trying the boilerplate from each components' docs. I appreciate what the developers are trying to do, I really do. Only, it is too many cooks + death by a thousand cuts. As I read through pages of closed-but-not-really GitHub issues for each package, sometimes going back years and years, it feels like a constant stream of hacking that erodes the well-intentioned first versions. > but a bozo like me does not. This is actually causing me stress irl. Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above.

earthboundkid 6y ago
To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.
- dntrkv 6y ago
  That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
  - ch4s3 6y ago
    They usually have fewer features as well, and not having to support features with weird edge cases always helps.
- fn1 6y ago
  That is because it is NOT written in JavaScript. I have written JS since 1997 and kept up with ES6 and so on over the years. Used it in frontend until now. The JavaScript-ecosystem just isn't very productive [1] for multiple reasons. The language is untyped. You have no multi-threading. It's hard to debug. You have to spend many brain-cycles on learning Browser-problems, which muddles your understanding of the language. The web-way of: we can fix it and everyone will reload the browser, leads to a "don't care" attitude. For web/backend this is approachable, though still not good. For build-systems this is terrible. Why? Because if a bug shows up in a build-system you stop a million developers from being productive. The bug won't get fixed right away, most will just work around it, use different plugins, copy/paste yet another webpack config etc. Plus JavaScript tends makes people realized what FP is, and they all start putting functions in their functions and making everything modular and plugin-able. (See high-order-components in React). While this can be nice, it leads to even more confusing bugs. Writing plugin-architectures is hard in any language. Writing it in JavaScript is a recipe for disaster. Hence the modern JS-ecosystem. [1] Google: nullpointerexception -> 4.360.000 results Google: undefined is not a function -> 800.000.000 results
  - eurleif 6y ago
    > Google: nullpointerexception -> 4.360.000 results > Google: undefined is not a function -> 800.000.000 results You didn't put quotation marks around the second, and the first has no spaces, so this is not a fair comparison. "undefined is not a function" with the quotation marks has 449,000 results.
    - fn1 6y ago
      Right, thank you.
    - dimitropoulos 6y ago
      see above, but this basically this is inaccurate. I don't doubt that there are many results for "undefined is not a function", but I feel quite confident saying there aren't anywhere near 449,000. If you ask google for just 111 of them, you'll get "In order to show you the most relevant results, we have omitted some entries very similar to the 110 already displayed."
- sibeliuss 6y ago
  > It’s basically already better than any of the existing JS JS bundlers This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.
  - regularfry 6y ago
    And that assumes that more features is necessarily better, which is also false.
    - sibeliuss 6y ago
      I think it's more a misunderstanding of the domain. Bundlers are not all about speed.
- thiht 6y ago
  This is because it doesn't do anything yet. I look forward to the day it's usable in production, but today is not the day. And don't forget Parcel which also have the simplest possible UI.
  - RobertKerans 6y ago
    This categorically not true. It does exactly the thing it's supposed to do. Yes, it is best that potential users wait for now, but that isn't because it "doesn't do anything". What it _doesn't_ do currently is provide an API which would allow it to be plugged in a similar way to Webpack (not exactly the same, as the deliberate aim is not to cover every usecase, as Webpack allows). This is a requirement for wider adoption as a competitor (rather than just as the module bundling step). Plus the tree shaking needs work, though I think that is less important than has sometimes been made out. Parcel may have a simple API for simple things, but it's extremely slow and generally suffers from exactly the same issues outlined by OP.
amelius 6y ago
> Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above. To all package manager developers: make sure you have a rollback function, and make sure it is flawless.
- fiddlerwoaroof 6y ago
  Committing the package-lock.json file should do this for you: I always upgrade one dependency per commit and I put code changes in separate changes from upgrades. Also, you just have to learn which packages to avoid: react-router, for example, likes incompatible major version updates. Something simple like routedux that’s stable is almost always a better choice.
  - amelius 6y ago
    With all the different package managers out there, it's just not much fun to keep track of all the rules and special cases for each tool. Better to just have a "--rollback" option.
    - fiddlerwoaroof 6y ago
      Isn’t this solved more generically by version control? As long as your package manager uses files to control the packages searched for, them you commit those files between upgrades and revert them to rollback. nix handles this at the system-level by making your system configuration match a declarative specification.
- harrygeez 6y ago
  or... you can rollback to an older version yourself
rane 6y ago
Strange, because parcel in particular is zero configuration and I have used to it build client projects running in production. No complicated webpack configuration needed.
- Chris_Newton 6y ago
  Parcel is a rare thing in the JS world: a tool I’ve actually found useful and efficient. As a bundler, it does indeed do a lot of things correctly out of the box, and as a direct result the experience of using it is far more pleasant than most such tools. However, it is also a tool for one job: bundling. If you also want to do things like unit testing or running any sort of linter or style checker over your code, you probably need to figure out how to get those tools to read your TS or ES20xx code as well. You might still need a handful of additional libraries to implement your test suite. You might still need to configure your preferred style and which rules you want to enforce in your static analyser(s). So even if Parcel was flawless about installing what you needed for your dev and production builds automatically, you’d still end up needing to install a bunch of other tools and write a bunch of other configuration files. The overall efficiency of setting up a realistic development environment, even using Parcel, is still limited by a kind of Amdahl’s Law problem.
kaishiro 6y ago
Would be interested to hear what issues you ran into with Parcel. I've used it on dozens of projects without doing any sort of deep dive into their pipeline - just using the default no config compilation and it's worked pretty much perfect every time.
- thiht 6y ago
  Agree. The only flaw of Parcel is that its tree shaking support sucks.
- SoSoRoCoCo 6y ago
  Sorry, my post was misleading, I was convinced to use -A- packer, so WebPack, Parcel and FuseBox in that order. WebPack had the best documentation hands-down because 4 weeks ago I didn't know what a packer did, I had been purposefully avoiding them for years. Now that I know way more about the concept/theory, I'll go down the list. Although I'm reluctant to waste too much time because my experience trying to bring all of the frameworks I already use into webpacker was so painful. But I really am pulled in by hot module swapping...

earthboundkid 6y ago

To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.

dntrkv 6y ago
That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
- ch4s3 6y ago
  They usually have fewer features as well, and not having to support features with weird edge cases always helps.
fn1 6y ago
That is because it is NOT written in JavaScript. I have written JS since 1997 and kept up with ES6 and so on over the years. Used it in frontend until now. The JavaScript-ecosystem just isn't very productive [1] for multiple reasons. The language is untyped. You have no multi-threading. It's hard to debug. You have to spend many brain-cycles on learning Browser-problems, which muddles your understanding of the language. The web-way of: we can fix it and everyone will reload the browser, leads to a "don't care" attitude. For web/backend this is approachable, though still not good. For build-systems this is terrible. Why? Because if a bug shows up in a build-system you stop a million developers from being productive. The bug won't get fixed right away, most will just work around it, use different plugins, copy/paste yet another webpack config etc. Plus JavaScript tends makes people realized what FP is, and they all start putting functions in their functions and making everything modular and plugin-able. (See high-order-components in React). While this can be nice, it leads to even more confusing bugs. Writing plugin-architectures is hard in any language. Writing it in JavaScript is a recipe for disaster. Hence the modern JS-ecosystem. [1] Google: nullpointerexception -> 4.360.000 results Google: undefined is not a function -> 800.000.000 results
- eurleif 6y ago
  > Google: nullpointerexception -> 4.360.000 results > Google: undefined is not a function -> 800.000.000 results You didn't put quotation marks around the second, and the first has no spaces, so this is not a fair comparison. "undefined is not a function" with the quotation marks has 449,000 results.
  - fn1 6y ago
    Right, thank you.
  - dimitropoulos 6y ago
    see above, but this basically this is inaccurate. I don't doubt that there are many results for "undefined is not a function", but I feel quite confident saying there aren't anywhere near 449,000. If you ask google for just 111 of them, you'll get "In order to show you the most relevant results, we have omitted some entries very similar to the 110 already displayed."
sibeliuss 6y ago
> It’s basically already better than any of the existing JS JS bundlers This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.
- regularfry 6y ago
  And that assumes that more features is necessarily better, which is also false.
  - sibeliuss 6y ago
    I think it's more a misunderstanding of the domain. Bundlers are not all about speed.
thiht 6y ago
This is because it doesn't do anything yet. I look forward to the day it's usable in production, but today is not the day. And don't forget Parcel which also have the simplest possible UI.
- RobertKerans 6y ago
  This categorically not true. It does exactly the thing it's supposed to do. Yes, it is best that potential users wait for now, but that isn't because it "doesn't do anything". What it _doesn't_ do currently is provide an API which would allow it to be plugged in a similar way to Webpack (not exactly the same, as the deliberate aim is not to cover every usecase, as Webpack allows). This is a requirement for wider adoption as a competitor (rather than just as the module bundling step). Plus the tree shaking needs work, though I think that is less important than has sometimes been made out. Parcel may have a simple API for simple things, but it's extremely slow and generally suffers from exactly the same issues outlined by OP.

amelius 6y ago

> Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above. To all package manager developers: make sure you have a rollback function, and make sure it is flawless.

fiddlerwoaroof 6y ago
Committing the package-lock.json file should do this for you: I always upgrade one dependency per commit and I put code changes in separate changes from upgrades. Also, you just have to learn which packages to avoid: react-router, for example, likes incompatible major version updates. Something simple like routedux that’s stable is almost always a better choice.
- amelius 6y ago
  With all the different package managers out there, it's just not much fun to keep track of all the rules and special cases for each tool. Better to just have a "--rollback" option.
  - fiddlerwoaroof 6y ago
    Isn’t this solved more generically by version control? As long as your package manager uses files to control the packages searched for, them you commit those files between upgrades and revert them to rollback. nix handles this at the system-level by making your system configuration match a declarative specification.
harrygeez 6y ago
or... you can rollback to an older version yourself

rane 6y ago

Strange, because parcel in particular is zero configuration and I have used to it build client projects running in production. No complicated webpack configuration needed.

Chris_Newton 6y ago
Parcel is a rare thing in the JS world: a tool I’ve actually found useful and efficient. As a bundler, it does indeed do a lot of things correctly out of the box, and as a direct result the experience of using it is far more pleasant than most such tools. However, it is also a tool for one job: bundling. If you also want to do things like unit testing or running any sort of linter or style checker over your code, you probably need to figure out how to get those tools to read your TS or ES20xx code as well. You might still need a handful of additional libraries to implement your test suite. You might still need to configure your preferred style and which rules you want to enforce in your static analyser(s). So even if Parcel was flawless about installing what you needed for your dev and production builds automatically, you’d still end up needing to install a bunch of other tools and write a bunch of other configuration files. The overall efficiency of setting up a realistic development environment, even using Parcel, is still limited by a kind of Amdahl’s Law problem.

kaishiro 6y ago

Would be interested to hear what issues you ran into with Parcel. I've used it on dozens of projects without doing any sort of deep dive into their pipeline - just using the default no config compilation and it's worked pretty much perfect every time.

thiht 6y ago
Agree. The only flaw of Parcel is that its tree shaking support sucks.
SoSoRoCoCo 6y ago
Sorry, my post was misleading, I was convinced to use -A- packer, so WebPack, Parcel and FuseBox in that order. WebPack had the best documentation hands-down because 4 weeks ago I didn't know what a packer did, I had been purposefully avoiding them for years. Now that I know way more about the concept/theory, I'll go down the list. Although I'm reluctant to waste too much time because my experience trying to bring all of the frameworks I already use into webpacker was so painful. But I really am pulled in by hot module swapping...