6 ms·

Despite all negative comments, I (and my team) switched to vite for create-react-app about two months ago, and never looked back. Builds take seconds, developer

Despite all negative comments, I (and my team) switched to vite for create-react-app about two months ago, and never looked back. Builds take seconds, developer experience is amazing.a.m.a.

dimgl 4y ago
Yep, same. Vite is absolutely incredible. It's a shame that frontend is so looked down upon, but I get it.
edvards 4y ago
is it compatible with what webpack has
- mmis1000 4y ago
  Yes and No. Yes, it has the same ability like webpack, which allow you to plug the logic you need into the system and change the results to fit your requirement. No, the config file or the plugins isn't compatible, because it is based on rollup. So you need to find rollup plugins instead.
  - aidos 4y ago
    But when you make the switch you’ll discover that you don’t need any of the config because it’s all pretty well up and running out of the box.
hardwaregeek 4y ago
You may notice that all of the negative comments are around superficial nitpicking of the website copy or general bemoaning of the state of front end development. The first is sort of useful in a minor way; the second is pretty useless and generally tired. Vite is a great tool that I’d recommend for anyone who wants to speed up their front end build setup.
- monkey_monkey 4y ago
  > the second is pretty useless and generally tired. Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.
  - hardwaregeek 4y ago
    Fragmentation is political though. You can’t really solve this issue unless someone or something is forcing people to coalesce around one tool. Webpack was great but it had noticeable flaws that allowed tools like esbuild/rollup/swc to gain market share. And it’s not like webpack can easily do what esbuild did, I.e. rewrite in multithreaded Go. If you can propose a way to get everybody on the same tool, by all means, let’s do it. What annoys me about this discourse is that anybody in the front end world knows this is an issue. People aren’t contributing anything by complaining about it.
  - gedy 4y ago
    Why can't the "back end community" agree on a single server side language and database and compiler? Gee so much churn!
    - deleted 4y ago
      [deleted]
    - monkey_monkey 4y ago
      We both know those aren't even close to the same thing. All this grunt->gulp->webpack->vite->'the inevitable replacement for vite' are really achieving is finding slightly different ways of doing the same thing.
      - mikewhy 4y ago
        "all this monoliths->microservices are really achieving is finding slightly different ways of doing the same thing" "all this python->go are really achieving is finding slightly different ways of doing the same thing" "all this relational db->document stores are really achieving is finding slightly different ways of doing the same thing"
ta-run 4y ago
Not CRA related, but is it as simple to move an existing Vue2 project to Vite?
- brailsafe 4y ago
  I think it depends, and it's just worth trying. My opinion from a cursory test is that it should be easy to migrate for local dev purposes if you have a single entry point for an app that us essentially one or a series of component trees. The app I work on deoends on an angularjs bootstrapping process, and does some other things that are sort of webpack specific, so we'd need to refactor some bits first. Vue2 should be pretty easy, at least to see the speed improvements locally which is its main pitch afaik
- runarberg 4y ago
  It depends. I think web-workers are handled differently, so if one of your dependency uses the webpack way to import a web worker then you might have to ditch that library. There might be other painpoints, but I think most projects migrate pretty easily. I recently migrated a vue2/vue-cli project over to vue3/vite. I had a pretty clear migration path, and did it incrementally over a few months. I needed to ditch a few libraries that didn’t work with either vue3 or vite. Most of the replacements work with both (e.g. vue-composition-api or pinia) so I could keep using vue2 while I migrated and then when the last non-compatible code had been refactored a few months later the final migration was fairly straight forward. The vue-cli switch happened somewhere in the middle of this.
dclowd9901 4y ago
How big is your application? What level of legacy are you dealing with? Do you also have broccoli as part of your build process? What did you switch from? How are you consuming your build? Do you do server side rendering? Do you build for UI testing? What’s it like building for Jest? Have you had to write any custom plugins?

Despite all negative comments, I (and my team) switched to vite for create-react-app about two months ago, and never looked back. Builds take seconds, developer experience is amazing.a.m.a.

dimgl 4y ago

Yep, same. Vite is absolutely incredible. It's a shame that frontend is so looked down upon, but I get it.

edvards 4y ago

is it compatible with what webpack has

mmis1000 4y ago
Yes and No. Yes, it has the same ability like webpack, which allow you to plug the logic you need into the system and change the results to fit your requirement. No, the config file or the plugins isn't compatible, because it is based on rollup. So you need to find rollup plugins instead.
- aidos 4y ago
  But when you make the switch you’ll discover that you don’t need any of the config because it’s all pretty well up and running out of the box.

hardwaregeek 4y ago

You may notice that all of the negative comments are around superficial nitpicking of the website copy or general bemoaning of the state of front end development. The first is sort of useful in a minor way; the second is pretty useless and generally tired. Vite is a great tool that I’d recommend for anyone who wants to speed up their front end build setup.

monkey_monkey 4y ago
> the second is pretty useless and generally tired. Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.
- hardwaregeek 4y ago
  Fragmentation is political though. You can’t really solve this issue unless someone or something is forcing people to coalesce around one tool. Webpack was great but it had noticeable flaws that allowed tools like esbuild/rollup/swc to gain market share. And it’s not like webpack can easily do what esbuild did, I.e. rewrite in multithreaded Go. If you can propose a way to get everybody on the same tool, by all means, let’s do it. What annoys me about this discourse is that anybody in the front end world knows this is an issue. People aren’t contributing anything by complaining about it.
- gedy 4y ago
  Why can't the "back end community" agree on a single server side language and database and compiler? Gee so much churn!
  - deleted 4y ago
    [deleted]
  - monkey_monkey 4y ago
    We both know those aren't even close to the same thing. All this grunt->gulp->webpack->vite->'the inevitable replacement for vite' are really achieving is finding slightly different ways of doing the same thing.
    - mikewhy 4y ago
      "all this monoliths->microservices are really achieving is finding slightly different ways of doing the same thing" "all this python->go are really achieving is finding slightly different ways of doing the same thing" "all this relational db->document stores are really achieving is finding slightly different ways of doing the same thing"

ta-run 4y ago

Not CRA related, but is it as simple to move an existing Vue2 project to Vite?

brailsafe 4y ago
I think it depends, and it's just worth trying. My opinion from a cursory test is that it should be easy to migrate for local dev purposes if you have a single entry point for an app that us essentially one or a series of component trees. The app I work on deoends on an angularjs bootstrapping process, and does some other things that are sort of webpack specific, so we'd need to refactor some bits first. Vue2 should be pretty easy, at least to see the speed improvements locally which is its main pitch afaik
runarberg 4y ago
It depends. I think web-workers are handled differently, so if one of your dependency uses the webpack way to import a web worker then you might have to ditch that library. There might be other painpoints, but I think most projects migrate pretty easily. I recently migrated a vue2/vue-cli project over to vue3/vite. I had a pretty clear migration path, and did it incrementally over a few months. I needed to ditch a few libraries that didn’t work with either vue3 or vite. Most of the replacements work with both (e.g. vue-composition-api or pinia) so I could keep using vue2 while I migrated and then when the last non-compatible code had been refactored a few months later the final migration was fairly straight forward. The vue-cli switch happened somewhere in the middle of this.

dclowd9901 4y ago

How big is your application? What level of legacy are you dealing with? Do you also have broccoli as part of your build process? What did you switch from? How are you consuming your build? Do you do server side rendering? Do you build for UI testing? What’s it like building for Jest? Have you had to write any custom plugins?