8 ms·

As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes brows

As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?

vijaybritto 5y ago
You still can do polyfills manually via browserify packages
- deleted 5y ago
  [deleted]
judofyr 5y ago
Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier. Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving imports. I often need to look into the webpack.config.js to understand how everything work. After: Use PostCSS and its tooling for CSS. Yes, there's now a separate process I also need to run in order to watch and build CSS. Yes, I can no longer `import "./style.css"` from the JavaScript files. But it's so much easier to reason about! The CSS tooling creates a CSS file; the JavaScript tooling creates a JavaScript file. Do I want to build SVG sprites? Well, that can very easily be a separate script which I can debug independently and _not_ couple into my builder's plugin system. In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. Once the successor to ESBuild comes out I will most likely be able to point it at index.js and everything will work.
- acdha 5y ago
  > In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. That's been my feeling for years, too: if your team is less than, say, several dozen people there's a significant amount of merit to having something which doesn't require continous care and feeding for anyone to work, especially when it's combining a number of complex libraries with independent development teams.
- jeswin 5y ago
  This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while. As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app (our CRA equivalent) takes 3-4 seconds, and running it is instantaneous. Faster builds actually change the way developers write code.
  - viklove 5y ago
    One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.
    - eliseumds 5y ago
      Plus effortless code splitting.
    - panzerklein 5y ago
      You're talking about css modules. It's a different feature.
- girvo 5y ago
  It’s funny to me that we’ve sort of ended up back where I started with Browserify and a seperate Less compile step, or even further back with require.js in some ways. It’s smart though. Despite having built webpack plugins myself, my main gripe with it was how overloaded it became.
desireco42 5y ago
You still need webpack for production build :). So all is good.
- darekkay 5y ago
  Vite uses Rollup for production builds, which is still much faster than webpack.
- simlevesque 5y ago
  Why can't you use esbuild for production builds ?
  - RobertKerans 5y ago
    Tree shaking isn't sorted, so can't currently get an bundle optimised to same extent as you do with Webpack/Rollup et al. It'll come, but not quite there yet.
    - eliseumds 5y ago
      Correct.
  - desireco42 5y ago
    Yes you can, my bad/ But some people have webpack configs, so the easiest for them is to keep those and can use Vite for development. Like if you are not doing new project.
- IggleSniggle 5y ago
  I use esbuild for prod...?
jakelazaroff 5y ago
In my experience, the vast majority of use cases are covered by these "no config" tools. If your app isn't a typical CRUD app you might fall into that long tail, but FWIW almost every app I've built has not :)

vijaybritto 5y ago

You still can do polyfills manually via browserify packages

deleted 5y ago
[deleted]

judofyr 5y ago

Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier. Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving imports. I often need to look into the webpack.config.js to understand how everything work. After: Use PostCSS and its tooling for CSS. Yes, there's now a separate process I also need to run in order to watch and build CSS. Yes, I can no longer `import "./style.css"` from the JavaScript files. But it's so much easier to reason about! The CSS tooling creates a CSS file; the JavaScript tooling creates a JavaScript file. Do I want to build SVG sprites? Well, that can very easily be a separate script which I can debug independently and _not_ couple into my builder's plugin system. In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. Once the successor to ESBuild comes out I will most likely be able to point it at index.js and everything will work.

acdha 5y ago
> In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. That's been my feeling for years, too: if your team is less than, say, several dozen people there's a significant amount of merit to having something which doesn't require continous care and feeding for anyone to work, especially when it's combining a number of complex libraries with independent development teams.
jeswin 5y ago
This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while. As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app (our CRA equivalent) takes 3-4 seconds, and running it is instantaneous. Faster builds actually change the way developers write code.
- viklove 5y ago
  One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.
  - eliseumds 5y ago
    Plus effortless code splitting.
  - panzerklein 5y ago
    You're talking about css modules. It's a different feature.
girvo 5y ago
It’s funny to me that we’ve sort of ended up back where I started with Browserify and a seperate Less compile step, or even further back with require.js in some ways. It’s smart though. Despite having built webpack plugins myself, my main gripe with it was how overloaded it became.

desireco42 5y ago

You still need webpack for production build :). So all is good.

darekkay 5y ago
Vite uses Rollup for production builds, which is still much faster than webpack.
simlevesque 5y ago
Why can't you use esbuild for production builds ?
- RobertKerans 5y ago
  Tree shaking isn't sorted, so can't currently get an bundle optimised to same extent as you do with Webpack/Rollup et al. It'll come, but not quite there yet.
  - eliseumds 5y ago
    Correct.
- desireco42 5y ago
  Yes you can, my bad/ But some people have webpack configs, so the easiest for them is to keep those and can use Vite for development. Like if you are not doing new project.
IggleSniggle 5y ago
I use esbuild for prod...?

jakelazaroff 5y ago

In my experience, the vast majority of use cases are covered by these "no config" tools. If your app isn't a typical CRUD app you might fall into that long tail, but FWIW almost every app I've built has not :)