3 ms·

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 c

by 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.
    - Timon3 3y ago
      I have had the same experience you describe with Webpack, and I've never felt anything similar with 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. But I don't want to do that. For me, the "new generation" of frontend tooling is characterized by great UX and speed, which puts Vite and esbuild in the same new generation. :)

by 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.
  - Timon3 3y ago
    I have had the same experience you describe with Webpack, and I've never felt anything similar with 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. But I don't want to do that. For me, the "new generation" of frontend tooling is characterized by great UX and speed, which puts Vite and esbuild in the same new generation. :)