3 ms·

My experience with the “Webpage tax” is every couple of weeks when I upgrade build tooling around one of my Webpack Workspaces, something somewhere silently bre

My experience with the “Webpage tax” is every couple of weeks when I upgrade build tooling around one of my Webpack Workspaces, something somewhere silently breaks in the system outputs an exit 0 but with fundamental mistakes. Last week and experimental flag was implicitly enabled with a Webpage version upgrade that broke MiniCSSExtraPlugin (which why at v5 is this still a thing to output CSS as not JS?) and all of a sudden I had no styles. It's in the CHANGELOG for a minor version bump but running NPM/Yarn upgrade gave me a broken build, and trying to tweak my build scripts to find the problem, I got styles outputting but no JavaScript was built. And this has happened on multiple occasions every couple of weeks/months where minor version upgrades to plugins gave me an exit 0 broken build. Parcel’s implicit plugin loading with node-gyp and randomly-dowloading-from-the-internet binaries system (rightfully) does not play well with Nix. Considering I’m not even leveraging code splitting or many of Webpack’s advanced features, I’m now investigating the cost of switching to something built on esbuild to lessen my Webpack burden and get much better build performance. Honestly makes me miss Tup and Make as front-end tooling exploded with complexity.

devongovett 5y ago
Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.
- toastal 5y ago
  That wasn't my experience, but it's been several months since I tested v2. I may have had to specify which plugins to use, but downloading of random binaries was an issues -- albeit this is a larger NPM ecosystem issue assuming read-write capabilities, glibc, x86_64 arch, etc. I've even made some small contributions to Parcel, its blog, and wrote a plugin, but this was before I started using Nix for a lot of things and node-gyp does not like to play well. That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.
  - Vinnl 5y ago
    Note that Devon Govett, who you replied to, is the main driving force behind Parcel.
    - toastal 5y ago
      And? I just looked up my old package.json and see the NPM script use `parcel build --no-autoinstall ...` and a pinned version `2.0.0-beta.3.1` which to me says there some genuine autoinstall going on, which is what I meant by "implicit plugin loading", loading/installing some plugins from the ether. Perhaps my wording wasn't clear, but it still was an issue for me. Parcel in my experience still came with less issues than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (https://news.ycombinator.com/item?id=28861732 https://news.ycombinator.com/item?id=28861732)
      - Vinnl 5y ago
        Just thought the additional context could help the conversation :)
        toastal 5y ago
        Also as the esbuild thread alluded, Phoenix (Elixir) and Rails alpha are switching to esbuild because of how many issues were raised in their projects related to things breaking in the Webpack tooling.

devongovett 5y ago

Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.

toastal 5y ago
That wasn't my experience, but it's been several months since I tested v2. I may have had to specify which plugins to use, but downloading of random binaries was an issues -- albeit this is a larger NPM ecosystem issue assuming read-write capabilities, glibc, x86_64 arch, etc. I've even made some small contributions to Parcel, its blog, and wrote a plugin, but this was before I started using Nix for a lot of things and node-gyp does not like to play well. That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.
- Vinnl 5y ago
  Note that Devon Govett, who you replied to, is the main driving force behind Parcel.
  - toastal 5y ago
    And? I just looked up my old package.json and see the NPM script use `parcel build --no-autoinstall ...` and a pinned version `2.0.0-beta.3.1` which to me says there some genuine autoinstall going on, which is what I meant by "implicit plugin loading", loading/installing some plugins from the ether. Perhaps my wording wasn't clear, but it still was an issue for me. Parcel in my experience still came with less issues than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (https://news.ycombinator.com/item?id=28861732 https://news.ycombinator.com/item?id=28861732)
    - Vinnl 5y ago
      Just thought the additional context could help the conversation :)
      - toastal 5y ago
        Also as the esbuild thread alluded, Phoenix (Elixir) and Rails alpha are switching to esbuild because of how many issues were raised in their projects related to things breaking in the Webpack tooling.