3 ms·

Vite uses esbuild, so it doesn't make much sense to put it in a different generation of tooling.

by Timon3 3y ago

WorldMaker 3y ago
My view of it is that the kitchen sink/"swiss army knife" mentality is the "previous generation" of Webpack/Babel that Vite fits, and esbuild is the closest to next generation mentality (something of a return to "do one thing/do it well/limit scope"). Vite is obviously at the generation transition boundary by being built on top of esbuild, but that doesn't make it "next generation" in my mind, that just makes it the "last of the dinosaurs, the smart one that figured out some of the meteor about to strike".
- 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

Vite uses esbuild, so it doesn't make much sense to put it in a different generation of tooling.

by Timon3 3y ago

Vite uses esbuild, so it doesn't make much sense to put it in a different generation of tooling.

My view of it is that the kitchen sink/"swiss army knife" mentality is the "previous generation" of Webpack/Babel that Vite fits, and esbuild is the closest to next generation mentality (something of a return to "do one thing/do it well/limit scope"). Vite is obviously at the generation transition boundary by being built on top of esbuild, but that doesn't make it "next generation" in my mind, that just makes it the "last of the dinosaurs, the smart one that figured out some of the meteor about to strike".

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