3 ms·

Okay, I understand. I don't think this way of divvying up generations is useful, but I see how you get there. For me "generations" are a lot more about how the

by Timon3 3y ago

Okay, I understand. I don't think this way of divvying up generations is useful, but I see how you get there. For me "generations" are a lot more about how they approach things than how much they implement. Esbuild kicked off a new generation of fast tooling, and Vite builds on it and integrates other tooling with a shared and stable API, without falling into the same pitfalls Webpack etc. did.

WorldMaker 3y ago
Yeah, I think we are agreeing that the dividing lines are "how they approach things", I just have a very different idea of the approaches to divide. Vite stills "smells" to me like Webpack because it takes a "kitchen sink" approach and I keep finding that I don't need kitchen sinks in my living rooms when all I want is a sofa in there (the occasional spot-bundle of maybe even just a single lone dependency via esbuild; to bend the metaphor near to its breaking point). The "pitfalls" of Webpack et al, as I've come to see them included that "everything is nearly always bundled and the bundle should always support everything and the kitchen sink" mentality that Vite inherited pretty directly from Webpack. (API instability and speed were rarely my worst problems with Webpack. Obviously everyone's mileage has varied here.) It's the "kitchen sink approach" that I find a useful marker for "last generation" and why I find it useful to lump Vite into that group.
- Timon3 3y ago
  I disagree that Vite takes a "kitchen sink" approach, and I disagree that the amount of features is relevant to "generations of tooling". But that's fine, who cares that I disagree? :)
  - WorldMaker 3y ago
    As I said, "kitchen sink" is almost a broken metaphor here. I don't think it has to do with "amount" of features, but "approach" to features. I look at the Vite feature list and lot of it reads to me as "Vite does this thing because Webpack did". It isn't doing something innovatively different from Webpack, even if the underpinning toolset is newer and different and faster and maybe has a more stable API. It makes sense for me to categorize Vite with Webpack despite its relative "youth" because of such similarities in approach (whether or not "kitchen sink" is exactly the right metaphor to describe whatever you want to call that approach). Meanwhile, esbuild is unequivocally a different thing than Webpack. (If it is a different thing than Parcel or Rollup, other than implementation language and speed, is a different conversation, of course.) But yeah, I don't expect you to agree with me either, and I'm not exactly trying to change your mind, just offering a perspective as someone that looks at Vite and neither sees a need to upgrade legacy Webpack configs to Vite nor to use Vite where I'd just use esbuild directly without the ceremony or the extra wrappers or the API I don't need/use or the extra "tools" I don't see a need for post-Webpack/post-ESM Everywhere.
    - Timon3 3y ago
      > I look at the Vite feature list and lot of it reads to me as "Vite does this thing because Webpack did". That's the thing - I don't believe this is true. I can honestly say that I've used most Vite features at some point. I love playing around with silly and over-complicated ideas, and with Vite there is pretty much always a feature that allows me to implement exactly what I want, or if there isn't, there is a plugin! This wasn't the case for me with Webpack. Let me show you a simple example: glob imports[1] are probably not something you think should be part of a "next generation" bundler, but when I tried implementing a feature based on the same requirement with Webpack, I simply couldn't! With Vite it just works out of the box, in all situations, without me having to manually implement it. It allowed me to implement a code browser that contains its own source code through glob imports in roughly 20 minutes (5 for trying it out, and 15 for implementing a web worker to keep performance up). Because Vite also makes web workers and everything else extremely simple. And this goes for most features of Vite - they are features that would be a nightmare to pull together with plugins and the like, which I can simply enable in a wonderful config file. > Meanwhile, esbuild is unequivocally a different thing than Webpack. (If it is a different thing than Parcel or Rollup, other than implementation language and speed, is a different conversation, of course.) That's kind of my point, esbuild doesn't do anything really new. It just does what it does extremely well, same as Vite. [1] https://vitejs.dev/guide/features.html#glob-import https://vitejs.dev/guide/features.html#glob-import
      - WorldMaker 3y ago
        I think I spent too much time configuring Webpack in previous lives that I got all of that out of Webpack at some point or another (and Webpack always had plenty of plugins, too). I'm glad you feel productive in Vite, I'm not arguing to take Vite away from anyone. I just already have Webpack configurations doing everything Vite does that I don't have reason to touch and I prefer to do things in a lighter-weight way going forward (including "no bundling" as much as possible). > That's kind of my point, esbuild doesn't do anything really new. It just does what it does extremely well, same as Vite. Ah, yeah, if you want to argue that there is no "new generation" at all yet in frontend tooling, then I can agree with that. To some extent with ESM Everywhere and trusting things like HTTP/2+ the nice thing is we're very close to a revenge of "no tools" is the "new generation of tools", which I think is great.

by Timon3 3y ago

WorldMaker 3y ago

Yeah, I think we are agreeing that the dividing lines are "how they approach things", I just have a very different idea of the approaches to divide. Vite stills "smells" to me like Webpack because it takes a "kitchen sink" approach and I keep finding that I don't need kitchen sinks in my living rooms when all I want is a sofa in there (the occasional spot-bundle of maybe even just a single lone dependency via esbuild; to bend the metaphor near to its breaking point). The "pitfalls" of Webpack et al, as I've come to see them included that "everything is nearly always bundled and the bundle should always support everything and the kitchen sink" mentality that Vite inherited pretty directly from Webpack. (API instability and speed were rarely my worst problems with Webpack. Obviously everyone's mileage has varied here.) It's the "kitchen sink approach" that I find a useful marker for "last generation" and why I find it useful to lump Vite into that group.

Timon3 3y ago
I disagree that Vite takes a "kitchen sink" approach, and I disagree that the amount of features is relevant to "generations of tooling". But that's fine, who cares that I disagree? :)
- WorldMaker 3y ago
  As I said, "kitchen sink" is almost a broken metaphor here. I don't think it has to do with "amount" of features, but "approach" to features. I look at the Vite feature list and lot of it reads to me as "Vite does this thing because Webpack did". It isn't doing something innovatively different from Webpack, even if the underpinning toolset is newer and different and faster and maybe has a more stable API. It makes sense for me to categorize Vite with Webpack despite its relative "youth" because of such similarities in approach (whether or not "kitchen sink" is exactly the right metaphor to describe whatever you want to call that approach). Meanwhile, esbuild is unequivocally a different thing than Webpack. (If it is a different thing than Parcel or Rollup, other than implementation language and speed, is a different conversation, of course.) But yeah, I don't expect you to agree with me either, and I'm not exactly trying to change your mind, just offering a perspective as someone that looks at Vite and neither sees a need to upgrade legacy Webpack configs to Vite nor to use Vite where I'd just use esbuild directly without the ceremony or the extra wrappers or the API I don't need/use or the extra "tools" I don't see a need for post-Webpack/post-ESM Everywhere.
  - Timon3 3y ago
    > I look at the Vite feature list and lot of it reads to me as "Vite does this thing because Webpack did". That's the thing - I don't believe this is true. I can honestly say that I've used most Vite features at some point. I love playing around with silly and over-complicated ideas, and with Vite there is pretty much always a feature that allows me to implement exactly what I want, or if there isn't, there is a plugin! This wasn't the case for me with Webpack. Let me show you a simple example: glob imports[1] are probably not something you think should be part of a "next generation" bundler, but when I tried implementing a feature based on the same requirement with Webpack, I simply couldn't! With Vite it just works out of the box, in all situations, without me having to manually implement it. It allowed me to implement a code browser that contains its own source code through glob imports in roughly 20 minutes (5 for trying it out, and 15 for implementing a web worker to keep performance up). Because Vite also makes web workers and everything else extremely simple. And this goes for most features of Vite - they are features that would be a nightmare to pull together with plugins and the like, which I can simply enable in a wonderful config file. > Meanwhile, esbuild is unequivocally a different thing than Webpack. (If it is a different thing than Parcel or Rollup, other than implementation language and speed, is a different conversation, of course.) That's kind of my point, esbuild doesn't do anything really new. It just does what it does extremely well, same as Vite. [1] https://vitejs.dev/guide/features.html#glob-import https://vitejs.dev/guide/features.html#glob-import
    - WorldMaker 3y ago
      I think I spent too much time configuring Webpack in previous lives that I got all of that out of Webpack at some point or another (and Webpack always had plenty of plugins, too). I'm glad you feel productive in Vite, I'm not arguing to take Vite away from anyone. I just already have Webpack configurations doing everything Vite does that I don't have reason to touch and I prefer to do things in a lighter-weight way going forward (including "no bundling" as much as possible). > That's kind of my point, esbuild doesn't do anything really new. It just does what it does extremely well, same as Vite. Ah, yeah, if you want to argue that there is no "new generation" at all yet in frontend tooling, then I can agree with that. To some extent with ESM Everywhere and trusting things like HTTP/2+ the nice thing is we're very close to a revenge of "no tools" is the "new generation of tools", which I think is great.