24 ms·

Vite – Next Generation Front End Tooling

483 points by legrande 4y ago

colinmegill 4y ago
Vite has been a lovely tool to work with. Haven't looked back.
nchudleigh 4y ago
Vite is one of the best tools I have started using in the last year. Nearly zero configuration and incredible performance. Definitely the build tool I reach for by default now
Rapzid 4y ago
Introduced Vite into our React project but it's still an experimental development option due to some rough edges. Our project has thousands of SCSS and source files(nearly 10k). The motivating factors were 5-12 minute startup times for CRA depending on the power of the developers workstations, and equally burdensome builds requiring now over 8GB of Node heap to complete without hitting OOM events. Really, really convinced this style of tooling is the future however here are some issues we are running into: * 4s full page refreshes Much slower that when Webpack finally gets going. If I'm working on something that may require lots full-page loads I'll opt for CRA. This is in part to do with the sheer number of source files. Part AFAIK they aren't using a strategy such as a Merkel tree to keep track of which import chains are actually invalid and instead re-request every file every reload. Part is SCSS which is a super, major PITA performance wise on a project of this size. Vite doesn't yet support embedded SCSS, and embedded SCSS doesn't support process reuse so it may not even work well with this dev server strategy. * HMR objects Editing certain(mostly non-component) code will cause duplicate class names to be created: MyClass2, MyClass3, and etc. Vite seems to use a different strategy than Webpack which, I believe, use proxy objects.. In any case these can cause "instance of" and other failures that trip people up and send them on wild bug chases. * Weird optimization requirements In your project's src importing from folder index files is considered harmful to Vite performance. When importing from node_modules NOT IMPORTING from the base index is considered harmful to performance!? It will not optimize deep import deps automatically(pre-bundle and browser cache them). ========= Even though I'm convinced this is the direction of dev tooling I'm not sure Vite will be the winner here. I can't help but feel entire server should be written in a language such as Go, and a better incremental build and delivery strategy needs to be in place. A strategy so that the browser only needs to request the files that have changed while going to cache directly for everything else. Otherwise very large projects will continue to be problematic. Yeah, lazy loading components but that's not always desirable particularly in single page "apps".
- strokirk 4y ago
  Have you tried using plain esbuild and sass in watch mode? That was what gave our app an immense speed boost. I’ve seen some of the same issues you have, with large entrypoints causing slow pageloads due to the number of source files, but fortunately not that large yet. Manually splitting the app into multiple smaller entrypoints have helped there. If HMR wasn’t so useful I would just have used raw esbuild instead, though.
matchbok 4y ago
The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.
- xisukar 4y ago
  You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.
  - Waterluvian 4y ago
    In an environment where you have choice, it takes developer maturity not to just leap on every new tool like this. But it’s wonderfully healthy for an environment to be so alive and full of innovation. Bazaar vs. Cathedral and whatnot. It’s easier for some to just be prescribed a specific SDK.
    - JohnBooty 4y ago
      re: Bazaar vs. Cathedral I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there! Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space. (Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster") It’s easier for some to just be prescribed a specific SDK. This is a little bit insulting. Nobody wants to "be prescribed a specific SDK" - there's a large middle ground between that, and the current situation which has been chaotic for nearly a whole generation. I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.
  - JohnBooty 4y ago
hsn915 4y ago
I just use esbuild with a small script to build things to my likings. It has worked wonderfully and infinitely better than all other build setups I've seen people do.
- akmittal 4y ago
  Vite uses esbuild, it is supposed to make esbuild easier to use
- imetatroll 4y ago
  Second this. esbuild is just enough.
nullwarp 4y ago
Recently started a new frontend project with Vite, Typescript and MithrilJS and it's been a real pleasure to work with. Contrast that to my usual dealings with Webpack I couldn't be happier.
- candiddevmike 4y ago
  Happy to see other folks still using Mithril. I've looked at other frameworks (svelte recently) and keep coming back to Mithril. It's so simple and easy to understand, it'll take something special to have me consider something else.
  - nullwarp 4y ago
    Mithril is criminally underrated. Yeah it won't have the same level of community support that things like React and Vue have but it's extremely simple and concise to work with and nothing about it feels "heavy" like the former two. By far it's my favorite tool to reach for when I need more than just plain vanilla JS.
sandreas 4y ago
I think sveltekit[1] uses this :-) 1: https://kit.svelte.dev/ https://kit.svelte.dev/
- sk0g 4y ago
  Yeah, and it's a pleasure to use. Really the only issue I ran into was not realising SvelteKit doesn't support all Svelte functionalities, and you have to vet plugins at times.
  - acoyfellow 4y ago
    Could you elaborate on which functionality? I've been using SK in production since early beta, I've not run into this (yet)
    - sk0g 4y ago
      To be honest I'm not a front end developer, just learned that a few things on GitHub had issues outstanding about SK issues, and avoided them after the first run-in. Massive props to Svelte to allow me to finish my project while actually, somehow, enjoying the front end development portions though! The one I ran into: https://github.com/BulatDashiev/svelte-slider https://github.com/BulatDashiev/svelte-slider
- gedy 4y ago
  It does, but fyi vite cli has built in support for Svelte, and you can bootstrap a project really easily if you don't need all the "stuff" that sveltekit provides: npm create vite@latest my-app -- --template svelte-ts
bladegash 4y ago
Really enjoy working with Vite and it works great with React (many think it’s geared towards Vue, which perhaps it was at one point). Made the switch after some frustrating behavior coming from CRA and having zero flexibility with configuration. As a side note, Vitest is fantastic as well and I highly recommend giving it a try.
- agumonkey 4y ago
  Indeed, it never occurred to me to use it with react. Vue vitesse (vite + project template) was so nice it stopped my quest.
  - 9dev 4y ago
    And it’s from the guy who built Vue - maybe try that out too? You’d be surprised to get the same feeling there :-)
    - bladegash 4y ago
      Not who you responded to, but trust me, I would if I could still use Vue professionally to where I could justify the time in my work and/or personal projects. I was a huge fan of Vue 2 and Nuxt, but the work world has been heavily favoring React for a while now. Not that everything has to be about work, but just haven’t mastered React enough to personally justify the time spent on working with Vue 3.
- steve_taylor 4y ago
  Last year, I converted a CRA to Vite because CRA wouldn't work in a monorepo. It was such a painless experience and it just worked.
  - bladegash 4y ago
    Yep, same! I will say, getting everything playing nicely in terms of TypeScript, ESM, CJS, etc. was a bit challenging on the first go around, but isn’t the fault of Vite (at least not entirely). As an example, if you’re used to CRA being setup for you to handle things like images/fonts, you’ll probably need a loader (same as webpack). Then you might need type definitions for the loader, the file format (e.g., SVGs), etc. After getting past the initial configuration hump it’s not bad and pretty painless to start a new project. I just don’t want to mislead people into thinking it’s entirely painless.
Escapado 4y ago
Just finished migrating the react project at work to vite and vitest after the pleasant experience I had with it in a private project. It was surprisingly little effort and is _so_ much faster and easier than the webpack mess we had before. I wonder if at some point they'll ditch rollup and go full esbuild. however Dev Server cold starts went from 34s to 0.3s and build times from 1m20s to 9s so I won't complain!
canyonero 4y ago
A lot of folks associate Vite with Vue or React. But the ease of use and overall dev experience in a vanilla TS/JS and web components is fantastic. IMO when paired with Vitest, the setup feels powerful, modern and lean. Would recommend.
- 9dev 4y ago
  Can second that, I use Vite to bundle the assets for a static site, and it… just works. Frontend tooling like I expect it to.
- akuji1993 4y ago
  I also feel like this is the actual use case of Vite. Don't want anything else but be able to roll a static site together, while using some vanilla html, css and js with a few assets attached.
candiddevmike 4y ago
I'm a happy vite user, but it troubles me when I think about how complicated everything it abstracts has become. It uses rollup for some things, esbuild for others, workbox for my service worker... I switched from webpack to it, and while my config is certainly less complex, I at least could tell you what webpack is doing. Vite is magic. Can I just use esbuild yet?
- sampullman 4y ago
  I think Vite is waiting for code splitting and plugin support in esbuild. It does seem like magic sometimes, but the the code is relatively straightforward. It's not too complicated to dig into to the internals if you're curious about how specific configuration works under the hood. With Webpack I never really felt that way, but maybe it's some kind of subconscious bias from struggling so often with massive configs.
  - candiddevmike 4y ago
    Code splitting issue: https://github.com/evanw/esbuild/issues/16 https://github.com/evanw/esbuild/issues/16
    - Rapzid 4y ago
      Hard to get a feel for if that will ever land.
  - aidos 4y ago
    Thing is, I did dig into the webpack code after having the watcher not reloading with code changes. I can’t recall the details but there were several different packages that were thin wrappers around each other and ultimately inotify (or something at the bottom). One of those wrappers was silently hiding the error about not having enough watcher available at the file system level. I was not impressed with what I found.
- christophilus 4y ago
  I just use esbuild. If your use case is simple enough, it’s totally fine.
jbrooksuk 4y ago
We (Laravel) have just switched the frontend tooling from Laravel Mix (a webpack wrapper) for Vite. https://laravel.com/docs/9.x/vite#main-content https://laravel.com/docs/9.x/vite#main-content The speed gains are super impressive from Vite.
- config_yml 4y ago
  I think Rails should have done the same, vite_ruby is amazing. Thankfully it's easy enough to replace the current options, which feel a bit half-hearted.
  - gedy 4y ago
    It feels like DHH really doesn't want this tooling at all in Rails, but did so reluctantly because so much view tech and mindshare had moved to the client.
    - redbar0n 4y ago
      https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b https://world.hey.com/dhh/rails-7-will-have-three-great-answ...
  - yeskia 4y ago
    esbuild through jsbundling-rails is very quick too.
- porker 4y ago
  Interesting you've made the change. Does that mean that Vite source maps for TS/JS and CSS are now up to scratch?
  - brailsafe 4y ago
    Were they not before?
    - 4y ago
peter_retief 4y ago
I have written some information sites in vite and must commend it as the best tool I have used for a very long time.
omarhaneef 4y ago
Almost all the comments are from those who have tried it. (And most people apparently love it). Why? Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else. The features don’t help: it’s fast. That could apply to anything. It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what it does. That’s several clicks in to figure it out. Please put what the thing does front and center.
- mgomez 4y ago
  The "Why Vite?" button on the homepage is fairly "front and center" to me and is only a single click away: https://main.vitejs.dev/guide/why https://main.vitejs.dev/guide/why
  - XorNot 4y ago
    The front page is right there and could've included the copy "Next generation replacement for Webpack" and I would've known exactly what it's for. Literally one sentence.
    - brundolf 4y ago
      It's not really a correct sentence though
      - Volundr 4y ago
        Isn't it? I use it and it's not clear to me what's incorrect about it.
        brundolf 4y ago
        It's too imprecise: - People might interpret that as "drop-in replacement for webpack", which is definitely not true - Even as just "a replacement for webpack"; Webpack and Vite have a lot of overlap, and it makes sense to compare them, but I think there are too many asterisks and nuances to say they're equivalent, in official materials, unqualified
supz_k 4y ago
I yesterday migrated our Laravel project from Laravel Mix (which uses webpack) to Vite (https://laravel.com/docs/9.x/vite https://laravel.com/docs/9.x/vite), and couldn't be more happier. Earlier, webpack took 3-4 seconds to re-bundle on file changes when running npm run watch (It is a quite large typescript + react project). In Vite, it is less than 300ms. And, React Hot-Reloading is awesome.
krick 4y ago
It gave me a pause to think about how it came that I can never really tell what am I looking at anymore. Forget the HN title, which is stupid — what does this landing page tell me? Well, that it's… next gen, and it apparently can catch up with me, which is not much, since I'm not really catching up with what's going on anyway. Also, that it's "tooling". Like IDE, or framework, or maybe a chainsaw. Can't tell. "Getting started" page tells me that "Vite" (pronounced as "veet") is "quick" in French, then it proceeds with quite wordy installation guide. It also quickly mentions that it's a "build tool". Finally. So, like gulp or grunt, I guess? But it doesn't even mention those, or any other build tools it supposedly replaces. And it seems unlikely, since everybody uses some script that comes with angular or vue or any other framework of your choice nowadays…
- ianpurton 4y ago
  I had exactly the same experience. I gave it maybe 20 seconds then I was gone.
- thrdbndndn 4y ago
  I'm not a developer and particularly not a front-end one. I have this problem all the time. Even some of the more "obvious" ones, say, nuxtjs, I have a hard time to get what exactly it offers and why I should use it.
  - konfusinomicon 4y ago
    at this point I've come to realize that all you need to know about front end frameworks anymore is that they are not jquery
    - smt88 4y ago
      You are utterly wrong. There's a huge difference between even Next.js and create-react-app, even though they're both based on React. The JS framework space is huge, messy, complex, and endlessly frustrating, but you can't wave that all away just because you can't keep up with it. I can't keep up either, but I do employ people who do, and they recently moved all our build tooling to Vite, which dramatically improved our DX.
emptysea 4y ago
Curious how Parcel stacks up to Vite. Vite seems to have the Vue community behind it which is pretty larger. Both have much better performance than webpack, so between the two probably doesn't matter too much.
- rk06 4y ago
  I don't know much about parcel, but Vite has incredible mindshare. Except react and angular, all other leading js framework authors are on vite eg: vue (obviously), solid, svelte,astro,qwik etc. With framework authors siding with vite, it is natural that those framework users will be switching to vite as well. Vite is gaining popularity in react community as well though not too much because of some issues with commonjs libraries. It is expected to have very bright future.
- EarthLaunch 4y ago
  I found Parcel and Snowpack years ago, before Vite, because I knew an integrated and ESM-based system was the future. Both were incomplete and buggy, both had tool combinations that they just couldn't handle. I've forgotten the details but from the tickets I was reading, I doubt that's improved. Vite solves all of that, it's incredibly easy to work with and I never have problems with it. For a fairly esoteric frontend situation, too.
zanethomas 4y ago
I've been using Vite since it first became available, works very well for me.
lionside 4y ago
I switched from CRA to Vite for create-rust-app[1]. If you ever needed to bundle JS/TS in an SSR framework (language agnostic), vite is a great choice :) [1] https://github.com/Wulf/create-rust-app https://github.com/Wulf/create-rust-app
razzio 4y ago
I've used Vite in a simple vuejs project and love its simplicity over webpack. However, debugging Vue3 with hot-module-reload seems to be broken. The moment HRM changes a source file, the line numbers and breakpoints not always line up and breakpoints. (https://github.com/vitejs/vite/issues/5916 https://github.com/vitejs/vite/issues/5916). The inability to debug properly is not a minor issue so I'm torn to go back to webpack or disable HMR to keep using Vite. Other than that, the simplification that Vite brings to the build process is sorely needed. I can only imagine how many developer hours have been lost in dealing with Webpack configuration issues. It is ironic that setting up a web development environment is more complicated than building a basic application. Thank you Vite developers for offering relief :)!
darkest_ruby 4y ago
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.
- 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.
kossTKR 4y ago
Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, an expert og know your way around the codebase before you're suddenly 2 years behind. It's a shitshow and no one really seems to know what the hell they are doing - even the teachers of this stuff - they just know "how" rarely why. Way, way too much complexity and abstraction for simple tasks. Some things "should have" become easier with quick scaffolding, auth templates or whatever, but they always only work 95% and you use an endless amount of time fixing the last 5% instead of building creatively. Vite was the same thing, faster yes, but my VSCODE broke because of the myriad of build tools and plugins on top of each other from older projects.
- rvdginste 4y ago
  > ...and you never really grasp before moving on to the next thing. Then why do you move on to the next thing? Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.
  - nikodunk 4y ago
    This. As someone who's hung back and not switched to the hot new thing in frontend - I've learned the "old" stuff seems to mature and tends to get better. Look at React, CRA, or Redux Toolkit - they're all so much better (performant, more concise) than the original few releases now!
    - 5350-uiop-1130 4y ago
      i dont think you find words like "deprecated" or "sunsetted" in any field as much as front end websh*t. react has changed a lot. i mean hooks pretty much is a rewrite or rethink of core concepts. nothing wrong with that per se, just that things just move to fast, there is no respect for long term stability and web seems to have a greater share of shiny new thing contrarian hipsters.
dfee 4y ago
I can’t find a vite solution for NodeJS which is disappointing. If anyone has figured out a way to ship the minimal amount of code from a NodeJS monorepo (ideally with web and server code, but generally decoupled) I’d enjoy seeing the solution!
- lioeters 4y ago
  I'd recommend using ESBuild directly. The following article helped me recently to figure out how to build a browser-side library to publish to NPM, as well as bundling a Node.js server to deploy. Build A Library With esbuild - How to bundle ESM, IIFE or CommonJS libraries with esbuild https://medium.com/geekculture/build-a-library-with-esbuild-23235712f3c https://medium.com/geekculture/build-a-library-with-esbuild-... --- I had to figure out a trick for Node side to exclude external modules. In my build script: const esbuild = require('esbuild') const { dependencies, peerDependencies } = require('./package.json') const external = [ ...Object.keys(dependencies), ...Object.keys(peerDependencies) ] await esbuild .build({ entryPoints: ['src/index.ts'], outfile: 'lib/index.mjs', bundle: true, sourcemap: false, minify: false, splitting: false, format: 'esm', target: ['esnext'], external }),
- somishere 4y ago
  It's possible. I often use vite with multiple build targets (decoupled but with code sharing) .. this can be specified in the rollup config options but my specific build process uses two separate vite configs to resolve some chunking challenges. Everything is parallelised for dev/build in an npm script. From memory there's a bunch of conversations relating to this kind of setup in the GitHub issues. Edit: vite allows you to specify (e.g. node specific) exclusions/globals in the config, it also allows you to specify a 'library' build if that's what you're interested in .. with named exports, etc.
- gkiely 4y ago
  There is vite-node: https://www.npmjs.com/package/vite-node https://www.npmjs.com/package/vite-node Here's a monorepo example, it's using cloudflare workers instead of node. But you could set up a vite-node server using concurrently or create a vite plugin. https://github.com/gkiely/vite-app-starter https://github.com/gkiely/vite-app-starter
jijji 4y ago
how does this benchmark against doing back end development with any language and pushing vanillajs (standard javascript) to the browser? whats the big difference and why should anyone want to make this more abstract/complicated? is it trying to reduce development time?
- LtWorf 4y ago
  I'd also like to know.
- cyco130 4y ago
  Plain JavaScript is of course faster. Not doing something is always faster than doing something. But highly interactive web apps have some problems that need to be addressed: First is syntax extensions: TypeScript (a strictly type JavaScript superset), JSX (a syntax extension for describing DOM nodes popularized by React) and special template syntaxes of other UI libraries/frameworks like Vue and Svelte need to be processed before being sent to the browser. You may also need processing to iron out some of the incompatibilities between JS engines but it's less important nowadays since the IE died. The second problem is the sheer size: Highly interactive web applications have lots of moving parts. For example at work, my company's product's frontend code contains 4709 modules, roughly 3/4 of which are 3rd party libraries. At this scale you need some level of optimization (like eliminating unused bits of the libraries) and the ability to split the bundled code into chunks depending on what pages they are used.
fionic 4y ago
No offense man I can’t really tell what this is… hmr and dev tools cli with a new transpiler?… it’s not next generation it’s a patch/minor upgrade to current generation tooling and it comes with a [extremely] major upgrade to swap it with whatever is currently used.
NaN1352 4y ago
I like that you can use —watch if you don’t want or can’t use HMR for whatever reason (eg. testing with other legacy code). Also it outputs a "dependency" file during build which you can use to infer the correct js/css includes - and this lets you add Webpack like modern js and all plugins like markdown and icons, to a LEGACY app in php. I did it with a Symfony 1.4 app it’s awesome.
ramesh31 4y ago
"It's fast" is not going to sell me on a build tool. Make files are fast too. What we learned with the evolution from Gulp/Grunt etc. to Webpack is that you need to find a sweet spot between zero config and full config. The "batteries included" approach works until it doesn't, and for small projects I'm sure it's fine. But every large project inevitably ends up with all kinds of snowflake config that Webpack handles really well, while also having a robust plugin ecosystem with standard defaults.
- simlevesque 4y ago
  It's one of the software that is the easiest to move to. For the vast majority of people, you go from a 150 lines Webpack config to a 15 lines Vite config, possibly the default values. It is kind of incredible. They've found "a sweet spot between zero config and full config" you are mentionning.
pragmatic 4y ago
I was looking at this recently and it’s interesting. But a couple of points. Webpack 5 is actually pretty easy to configure these days. I have a use case of supporting angularjs with web workers, service worker (full PWA - it’s a POS that is built to handle low bandwidth, intermittent connections etc while still providing 90% of functionality in offline mode - lots of indexeddb, local storage and service worker magic) and typescript. It handles it all like magic. The workers are in typescript and yet they “just work” with shared imports (indexeddb wrapper mostly). Service workers get all your /dist resources added and you can still add any custom code you need - which I do. Also you can use esbuild with webpack (there’s a plug-in of course) I was dreading using webpack bc my last experience with it in 2015 was not great, but wow, it’s really powerful and actually easy to work with. Also using it for an electron side project and it’s also great there. I have to say, parcel and a lot I’d other bundlers just can’t do what webpack handles almost effortlessly. YMMV of course but webpack 5 is worth a look if you haven’t used it lately.
CSDude 4y ago
It’s amazingly fast, cant recommend it enough.
JeanMeche 4y ago
Brandon Roberts created a POC starter for Angular+Vite : https://twitter.com/brandontroberts/status/1542954860898910211 https://twitter.com/brandontroberts/status/15429548608989102...
- moystard 4y ago
  This is to generate a vanilla Angular project using vit, not a vite powered Angular project.
tzm 4y ago
Last I tested Vite (6 mo ago) it didn't support web3 lib and a few others. Has anyone tested recently?
gtm1260 4y ago
The negativity about the annoying landing page is fair enough, but vite is actually awesome to work with as a dev! I've been using it as a dev server for sveltekit, its performance claims are very true.
cod3rboy 4y ago
I am feeling like this era of frontend javascript is too much focused on tooling and frameworks that developers spend most of their time dealing with complexities associated with them rather than focusing on creating something meaningful and useful.
- dzogchen 4y ago
  Actually, you can just run 'npm init vite', choose a plain js starter, and make something 'meaningful and useful' with an awesome dev server and great bundler once you are ready to go live.
- deleted 4y ago
  [deleted]
jb1991 4y ago
This is excellent! The frontend ecosystem in general has been very stagnant for years, without much innovation or experimentation. Great to finally see a new library for frontend development come along.
barkingcat 4y ago
I find it really funny that the word "javascript" doesn't appear anywhere on the entire first landing page. You have to click into "Why Vite" and then about 1/2 way into the first sentence, then you see "javascript" I was wondering "exactly what kind of front end?" C? C++? Swift? iOS front end? some kind of GUI framework? Windows app development? Modern day Javascript web ecosystem is a nightmare.
- dzogchen 4y ago
  No it is not a nightmare. It is actually quite pleasant thanks to Vite.
  - barkingcat 4y ago
    You say that now, but 3 years in the future you'll be posting "Vite destroyed the Javascript ecosystem"
    - cmykk4 4y ago
      With respect, this suggests to me that you haven't actually read about how Vite works. It's not aiming to be just another contender, it sort of positions itself as a "best of both worlds" abstraction layer on other tools, whereby esbuild is used for faster compilation and rollup is used for configurable builds. It's not as drastic of a change as you're making it out to be, unless someone is coming from like a Gulp-based setup or something. My work uses Webpack 3 and 4 (in a monorepo) and I was able to get Vite up and running on a test branch (as a sandbox) within a day, even though it's using roll-up instead of Webpack and even though our code was pretty old. It compiled in like a few seconds, it was wild.
dazhbog 4y ago
"Get ready for a development environment that can finally catch up with you." Actually I'm the one trying to catch up with all the front-end changes in the last 10 years..
dsjfladjsfkl 4y ago
GiorgioG 4y ago
Vite is excellent and https://swc.rs https://swc.rs is another one to keep an eye on.
- sachinraja 4y ago
  Vite could use swc for compiling in the future.
albertTJames 4y ago
There is no way I'm leaving webpack after those 100 years of frustration and pain. Now that I have reached an almost mediocre level of understanding of it, I am never letting it go.
- simlevesque 4y ago
  Leaving Webpack was one of the most liberating technology choice I ever did. Top 10 easily.
oblak 4y ago
Speed gains aside, it's pretty great, though I did have to provide a manual path to node_modules/some_package_here because it wouldn't serve those files in dev mode. On my computer alone. No one else. Guess I had a weird setup. It has many years until it turns into yet another bloated "builder" if you could call it that Overall, I continue to be impressed by whatever these guys (it's not just Ewan) do even it's getting hard to keep up at my age.
zmxz 4y ago
Incredible amount of negative comments. It takes more time to type all that negativity out than it takes to read about what Vite is and what it does. Frontend dev here. Vite is amazing. It doesn't take long to get what it does if you try it out (you can avoid reading about it that way). I won't bother summarizing what it does, the website literally covers it. Reading really became superpower in this day and age.
- rco8786 4y ago
  > to read about what Vite is and what it does. This is actually my main complaint. I read everything on the landing page and Getting Started page and still have literally zero idea what Vite does.
  - martpie 4y ago
    Secondary call-to-action is literally "Learn more" [0] and explains in details all the problems it solves [0] https://vitejs.dev/guide/why https://vitejs.dev/guide/why
    - deleted 4y ago
      [deleted]
    - rco8786 4y ago
      That’s an essay.
- weejewel 4y ago
  Writing an objective, clear landing page seems to be a superpower as well.
  - zmxz 4y ago
    You can complain all you like, but in the end it's you who has to read and understand the text written on the landing page. No one can do it for you.
- 4y ago
deleted 4y ago
[deleted]
canaus 4y ago
So is it safe to say that this tool is mostly trying to solve the developer experience side of front-end development, instead of trying to create a "new" technology such as SSR? I've just mostly seen "fast" and "HMR" as the features of Vite, but I can't see a team switching over an entire project just to solve something that was probably decently "solved" to begin with.
- sachinraja 4y ago
  I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.
synergy20 4y ago
This is an excellent tool, beats webpack to ashes. Evan You did this after his vuejs work, it's kind of like Linus did git after his linux kernel work, well, on a smaller scale. Per Linus, he did git to approve that he is not an accidental one time genius.
- simlevesque 4y ago
  And now he's working on Volar, to make tooling more awesome.
noduerme 4y ago
Am I alone in that I don't webpack or otherwise bundle anything until I deploy? If I'm building a large typescript project, I just run it directly out of source JS and CSS files on my dev server. Only when upgrades are finished and tested do I bundle them and put them on the production server.
QuadrupleA 4y ago
The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems. I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the frontend world endlessly frets about like state management, build times (I don't use builds), polyfills (I just use whatever raw JS subset is about 97% supported), server-side rendering (just design your app with an intelligent division of labor between client and server), dependency management (minimize them, and understand the ones you use fully so you can adapt them to your needs), etc. Like this site demonstrates, reasoning for using all this cruft is always vague too - "best practice", "modern", "next gen", whatever. Seriously, the whole frontend ecosystem seems a rube goldberg tower built on pseudo-technical marketing fluff that has everyone chasing their tail and adding more unnecessary layers. I don't get it. If you're deep in this world, I highly recommend: go a layer down. Try implementing your next feature with and without the library / framework du joir. Can you simplify, remove layers, and still accomplish your goals? How much code is it for each version, including the framework? Is the dependency worth all its baggage, like build times, module incompatibilities, leaky abstractions, loss of control, etc.?
- sachinraja 4y ago
  If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.
- selfmodruntime 4y ago
  Your entire answer basically becomes moot since this is not a framework. At all. This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it. Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.
krinn_silver 4y ago
For anyone interested, these are the docs for the upcoming 3.0 release. https://vitejs.dev https://vitejs.dev is for 2.x, which is the current, released version. The sites are largely similar. Other than features that have changed, the major differences appear to be aesthetic. I'm looking forward to the v3 release.
mattlondon 4y ago
Sorry but if it requires NPM then I am not interested. I have been burnt too many times to want to use anything related to NPM. I would hope that a next generation framework would not have hard dependencies on the cess pit that is NPM :(. Please give us something fresh and interesting. This is why I am so excited by deno on the backend - finally no more NPM!
ggregoire 4y ago
I find it funny that, as usual, half the comments are complaints about "why are frontend developers always reinventing the wheel"... Meanwhile the 1st post on the front page [1] is about a new "modern" scheduling package for Python. What's wrong with just using Celery, APScheduler, Huey or even cron? Why do we need a new scheduling library? Yet I don't see any "reinventing the wheel" critic in the comments. Double standard I guess. [1] https://news.ycombinator.com/item?id=31969345 https://news.ycombinator.com/item?id=31969345
- selfmodruntime 4y ago
  Correct. People are arguing as if there wasn't a new Container Library being released every month for C++
dclowd9901 4y ago
Anyone tried just swapping this in with their current web pack pipeline? What are the pain points? Is it even possible?
Stampo00 4y ago
I know everyone is here to complain about the mess that is "modern" frontend work. But I have to say, I started using Vite a week ago to bootstrap a new project using Typescript, Preact, and Tailwind, and I'm loving it. There is one weird quirk in where it insists the index.html file should be. But if you can live with that, Vite takes care of the details for me and gets out of my way. It also bundles everything exactly how I would have set it up by hand. I think it's weird that it insists its mostly a dev server. It does that well. But it's also a very good bundler with good defaults. I'd recommended it to anyone who just wants to get started, and wants a good middle ground between esbuild and parcel.
fasteo 4y ago
Old backend coder here. All I see here is >>> it’s fast That's the same thought I 30 years ago when going from compiling a Fortran program (minutes) to compiling programs with Turbo Pascal 3.0 (instant) History repeats itself I guess.
marmada 4y ago
Hey. If you're hear to post about how the web is always changing, and it's so complicated, no one cares. It's been posted 20 times by now and there are good reasons (we build much more complicated webapps these days). I like Vite. A few things I like: - Super fast - Works out of the box (like parcel) - Even production builds are super fast -- this is a bit of an underrated feature because sometimes things only break in prod builds, so having fast prod builds = more frequent prod tests = better
- selfmodruntime 4y ago
  People here love to complain about frontend, but the speed and outreach people can have with modern webapps beats desktop applications by a mile. There is a reason billion dollar companies like AirBnB don't use desktop apps.
jchw 4y ago
Vite is kind of nice because it weaves together some more modern tools, but if you're doing something simple, you might be able to just use esbuild directly on it's own. Bonus: if you're writing Go software, you can use esbuild's (slightly cumbersome) Go API directly in your app server and avoid needing to have JS tooling in your serving/building path, just using Node to handle things like JS package management, typechecking, and linting.
littlecranky67 4y ago
I'm a sceptic to the claims; most build speedups I've seen come from the bypass of Typescript type checking/compiler errors. Since there is no other competetive compiler to Typescript than the official (and slow) tsc, I think vite works this way too? Getting hot reload and fast page refreshes is nice, but the idea is that if I get a compiler error, I ought to fix it first before I move to the browser to test my code.
- deleted 4y ago
  [deleted]
- mmis1000 4y ago
  Actually most webpack config guides also recommend you to start Typescript checker in separate thread(there is plugin for that) and don't block compilation(transpile mode). But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.
  - littlecranky67 4y ago
    I still don't get it. If I assume that Typescript compiler is the slowest component in the build pipeline, and run it in a separate thread, that still means I have to wait for the tsc to complete. There is little to no benefit in all the other stuff being finished faster; that will be optimizing the 5%, while my main time is wasted in the 95% of the tsc compiler process. At least to my experience, for sufficiently large projects, tsc becomes super slow.
    - mmis1000 4y ago
      > that still means I have to wait for the tsc to complete Without fork it. the webpack need to wait the checker to finish checking everything before it compiles even just one file. With a separate checker, it don't. The ts-loader will eject a perfectly normal js file without caring the typing is valid or not. And webpack can do the rest of works as quick as possible. It like different of do it in serial and do it in parallel. The latter will utilize the resources better although not absolutely more efficient.
c7DJTLrn 4y ago
F*king hell the ecosystem just never stops growing. Vite, Rollup, HMR? What the f*k is all this? Why does building a frontend have to be a titanic project involving a hundred tools including build systems and tree shakers and compilers and whatever else is going on. Web development is an embarrassment and a blight on computing.
- mikewhy 4y ago
  HMR is 6 years old at this point. Rollup is 6-7 years old. At what point should you start to think maybe you've been a reactionary for too long?
- keithnz 4y ago
  Perhaps you should take the time to find out. Many of the things you mention create a development experience that is pretty cool. It allows you to dynamically change your code and instantly see the result. I do backend systems, embedded systems, and have done a lot of native UI apps.... modern web development with things like vite and vue are really quite nice in comparison. The development feedback loop is very quick
- figmaheart255 4y ago
qiller 4y ago
Upgrading to Vue 3 and Vite soon, is there a danger in having different dev vs production build tools?
shepherdjerred 4y ago
Aisde from the typical HN comments of: * Front-end is a mess; who needs anything other than hand written HTML and jQuery * This site doesn't explain what this is Vite is pretty great. It is a huge improvement on webpack and other competitors that I've used. Configuring Vite for the common use case of some front end framework + optional TypeScript + unit testing + hot reloading is something that can be done with a literally just 5 lines of configuration. At work I switched over a 1000 line webpack script for 40 lines of Vite. Vite is superior in every way compared to webpack (at least as far as my use cases)
nikolqy 4y ago
This is actually really impressive. The documentation site is insanely fast which is usually a sign that it's a well performing framework.
haolez 4y ago
Its source code is quite interesting. It's a medium-sized TypeScript project and it doesn't look like a C# or Java ripoff. Well done!
fkyrframework 4y ago
fkyrframework 4y ago
LAC-Tech 4y ago
So I just streamed myself taking vite for a test drive. My thoughts: - Very fast to reload - Seemed pretty damn simple and non-magical. Your main code doesn't get transpiled, just your dependencies. - IMHO the scaffolding stuff was superfluous, at least for vanilla JS. I'm a minimalist and it initially turned me off, but then I discovered it was basically just a thin wrapper around the `vite` binary. Will probably just install vite as a dev dependency and go from there next time. Over all a positive experience and might end up re-using it.
asciiresort 4y ago
Many claims here of Vite being fast. Does anyone have insight into why? Parcel apparently rewrote in Rust, but I guess that's not necessarily the bottleneck here?
- snorremd 4y ago
  Compilation/transpilation is only part of the work traditionally being done by build tools like webpack and parcel (well, webpack offloads the work to babel or similar). I believe that a lot of the speed or perceived responsiveness with Vite comes simply from not bundling the code during development. For a long time front end tooling has been bundling your dependencies and code into one or more bundles each time you save your code and then that gets shipped to your browser. Vite on the other hand just transpile the changed module(s) and then ship that over to the browser. This works great because browser support ES modules and module resolution natively now.
gw67 4y ago
What CSS template did you use for https://main.vitejs.dev/guide/ https://main.vitejs.dev/guide/ ?

483 points by legrande 4y ago

Vite has been a lovely tool to work with. Haven't looked back.

Vite is one of the best tools I have started using in the last year. Nearly zero configuration and incredible performance. Definitely the build tool I reach for by default now

Rapzid 4y ago

Introduced Vite into our React project but it's still an experimental development option due to some rough edges. Our project has thousands of SCSS and source files(nearly 10k). The motivating factors were 5-12 minute startup times for CRA depending on the power of the developers workstations, and equally burdensome builds requiring now over 8GB of Node heap to complete without hitting OOM events. Really, really convinced this style of tooling is the future however here are some issues we are running into: * 4s full page refreshes Much slower that when Webpack finally gets going. If I'm working on something that may require lots full-page loads I'll opt for CRA. This is in part to do with the sheer number of source files. Part AFAIK they aren't using a strategy such as a Merkel tree to keep track of which import chains are actually invalid and instead re-request every file every reload. Part is SCSS which is a super, major PITA performance wise on a project of this size. Vite doesn't yet support embedded SCSS, and embedded SCSS doesn't support process reuse so it may not even work well with this dev server strategy. * HMR objects Editing certain(mostly non-component) code will cause duplicate class names to be created: MyClass2, MyClass3, and etc. Vite seems to use a different strategy than Webpack which, I believe, use proxy objects.. In any case these can cause "instance of" and other failures that trip people up and send them on wild bug chases. * Weird optimization requirements In your project's src importing from folder index files is considered harmful to Vite performance. When importing from node_modules NOT IMPORTING from the base index is considered harmful to performance!? It will not optimize deep import deps automatically(pre-bundle and browser cache them). ========= Even though I'm convinced this is the direction of dev tooling I'm not sure Vite will be the winner here. I can't help but feel entire server should be written in a language such as Go, and a better incremental build and delivery strategy needs to be in place. A strategy so that the browser only needs to request the files that have changed while going to cache directly for everything else. Otherwise very large projects will continue to be problematic. Yeah, lazy loading components but that's not always desirable particularly in single page "apps".

strokirk 4y ago
Have you tried using plain esbuild and sass in watch mode? That was what gave our app an immense speed boost. I’ve seen some of the same issues you have, with large entrypoints causing slow pageloads due to the number of source files, but fortunately not that large yet. Manually splitting the app into multiple smaller entrypoints have helped there. If HMR wasn’t so useful I would just have used raw esbuild instead, though.

matchbok 4y ago

The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.

xisukar 4y ago
You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.
- Waterluvian 4y ago
  In an environment where you have choice, it takes developer maturity not to just leap on every new tool like this. But it’s wonderfully healthy for an environment to be so alive and full of innovation. Bazaar vs. Cathedral and whatnot. It’s easier for some to just be prescribed a specific SDK.
  - JohnBooty 4y ago
    re: Bazaar vs. Cathedral I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there! Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space. (Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster") It’s easier for some to just be prescribed a specific SDK. This is a little bit insulting. Nobody wants to "be prescribed a specific SDK" - there's a large middle ground between that, and the current situation which has been chaotic for nearly a whole generation. I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.
- JohnBooty 4y ago

hsn915 4y ago

I just use esbuild with a small script to build things to my likings. It has worked wonderfully and infinitely better than all other build setups I've seen people do.

akmittal 4y ago
Vite uses esbuild, it is supposed to make esbuild easier to use
imetatroll 4y ago
Second this. esbuild is just enough.

nullwarp 4y ago

Recently started a new frontend project with Vite, Typescript and MithrilJS and it's been a real pleasure to work with. Contrast that to my usual dealings with Webpack I couldn't be happier.

candiddevmike 4y ago
Happy to see other folks still using Mithril. I've looked at other frameworks (svelte recently) and keep coming back to Mithril. It's so simple and easy to understand, it'll take something special to have me consider something else.
- nullwarp 4y ago
  Mithril is criminally underrated. Yeah it won't have the same level of community support that things like React and Vue have but it's extremely simple and concise to work with and nothing about it feels "heavy" like the former two. By far it's my favorite tool to reach for when I need more than just plain vanilla JS.

sandreas 4y ago

I think sveltekit[1] uses this :-) 1: https://kit.svelte.dev/ https://kit.svelte.dev/

sk0g 4y ago
Yeah, and it's a pleasure to use. Really the only issue I ran into was not realising SvelteKit doesn't support all Svelte functionalities, and you have to vet plugins at times.
- acoyfellow 4y ago
  Could you elaborate on which functionality? I've been using SK in production since early beta, I've not run into this (yet)
  - sk0g 4y ago
    To be honest I'm not a front end developer, just learned that a few things on GitHub had issues outstanding about SK issues, and avoided them after the first run-in. Massive props to Svelte to allow me to finish my project while actually, somehow, enjoying the front end development portions though! The one I ran into: https://github.com/BulatDashiev/svelte-slider https://github.com/BulatDashiev/svelte-slider
gedy 4y ago
It does, but fyi vite cli has built in support for Svelte, and you can bootstrap a project really easily if you don't need all the "stuff" that sveltekit provides: npm create vite@latest my-app -- --template svelte-ts

bladegash 4y ago

Really enjoy working with Vite and it works great with React (many think it’s geared towards Vue, which perhaps it was at one point). Made the switch after some frustrating behavior coming from CRA and having zero flexibility with configuration. As a side note, Vitest is fantastic as well and I highly recommend giving it a try.

agumonkey 4y ago
Indeed, it never occurred to me to use it with react. Vue vitesse (vite + project template) was so nice it stopped my quest.
- 9dev 4y ago
  And it’s from the guy who built Vue - maybe try that out too? You’d be surprised to get the same feeling there :-)
  - bladegash 4y ago
    Not who you responded to, but trust me, I would if I could still use Vue professionally to where I could justify the time in my work and/or personal projects. I was a huge fan of Vue 2 and Nuxt, but the work world has been heavily favoring React for a while now. Not that everything has to be about work, but just haven’t mastered React enough to personally justify the time spent on working with Vue 3.
steve_taylor 4y ago
Last year, I converted a CRA to Vite because CRA wouldn't work in a monorepo. It was such a painless experience and it just worked.
- bladegash 4y ago
  Yep, same! I will say, getting everything playing nicely in terms of TypeScript, ESM, CJS, etc. was a bit challenging on the first go around, but isn’t the fault of Vite (at least not entirely). As an example, if you’re used to CRA being setup for you to handle things like images/fonts, you’ll probably need a loader (same as webpack). Then you might need type definitions for the loader, the file format (e.g., SVGs), etc. After getting past the initial configuration hump it’s not bad and pretty painless to start a new project. I just don’t want to mislead people into thinking it’s entirely painless.

Escapado 4y ago

Just finished migrating the react project at work to vite and vitest after the pleasant experience I had with it in a private project. It was surprisingly little effort and is _so_ much faster and easier than the webpack mess we had before. I wonder if at some point they'll ditch rollup and go full esbuild. however Dev Server cold starts went from 34s to 0.3s and build times from 1m20s to 9s so I won't complain!

canyonero 4y ago

A lot of folks associate Vite with Vue or React. But the ease of use and overall dev experience in a vanilla TS/JS and web components is fantastic. IMO when paired with Vitest, the setup feels powerful, modern and lean. Would recommend.

9dev 4y ago
Can second that, I use Vite to bundle the assets for a static site, and it… just works. Frontend tooling like I expect it to.
akuji1993 4y ago
I also feel like this is the actual use case of Vite. Don't want anything else but be able to roll a static site together, while using some vanilla html, css and js with a few assets attached.

candiddevmike 4y ago

I'm a happy vite user, but it troubles me when I think about how complicated everything it abstracts has become. It uses rollup for some things, esbuild for others, workbox for my service worker... I switched from webpack to it, and while my config is certainly less complex, I at least could tell you what webpack is doing. Vite is magic. Can I just use esbuild yet?

sampullman 4y ago
I think Vite is waiting for code splitting and plugin support in esbuild. It does seem like magic sometimes, but the the code is relatively straightforward. It's not too complicated to dig into to the internals if you're curious about how specific configuration works under the hood. With Webpack I never really felt that way, but maybe it's some kind of subconscious bias from struggling so often with massive configs.
- candiddevmike 4y ago
  Code splitting issue: https://github.com/evanw/esbuild/issues/16 https://github.com/evanw/esbuild/issues/16
  - Rapzid 4y ago
    Hard to get a feel for if that will ever land.
- aidos 4y ago
  Thing is, I did dig into the webpack code after having the watcher not reloading with code changes. I can’t recall the details but there were several different packages that were thin wrappers around each other and ultimately inotify (or something at the bottom). One of those wrappers was silently hiding the error about not having enough watcher available at the file system level. I was not impressed with what I found.
christophilus 4y ago
I just use esbuild. If your use case is simple enough, it’s totally fine.

jbrooksuk 4y ago

We (Laravel) have just switched the frontend tooling from Laravel Mix (a webpack wrapper) for Vite. https://laravel.com/docs/9.x/vite#main-content https://laravel.com/docs/9.x/vite#main-content The speed gains are super impressive from Vite.

config_yml 4y ago
I think Rails should have done the same, vite_ruby is amazing. Thankfully it's easy enough to replace the current options, which feel a bit half-hearted.
- gedy 4y ago
  It feels like DHH really doesn't want this tooling at all in Rails, but did so reluctantly because so much view tech and mindshare had moved to the client.
  - redbar0n 4y ago
    https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b https://world.hey.com/dhh/rails-7-will-have-three-great-answ...
- yeskia 4y ago
  esbuild through jsbundling-rails is very quick too.
porker 4y ago
Interesting you've made the change. Does that mean that Vite source maps for TS/JS and CSS are now up to scratch?
- brailsafe 4y ago
  Were they not before?
  - 4y ago

peter_retief 4y ago

I have written some information sites in vite and must commend it as the best tool I have used for a very long time.

omarhaneef 4y ago

Almost all the comments are from those who have tried it. (And most people apparently love it). Why? Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else. The features don’t help: it’s fast. That could apply to anything. It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what it does. That’s several clicks in to figure it out. Please put what the thing does front and center.

mgomez 4y ago
The "Why Vite?" button on the homepage is fairly "front and center" to me and is only a single click away: https://main.vitejs.dev/guide/why https://main.vitejs.dev/guide/why
- XorNot 4y ago
  The front page is right there and could've included the copy "Next generation replacement for Webpack" and I would've known exactly what it's for. Literally one sentence.
  - brundolf 4y ago
    It's not really a correct sentence though
    - Volundr 4y ago
      Isn't it? I use it and it's not clear to me what's incorrect about it.
      - brundolf 4y ago
        It's too imprecise: - People might interpret that as "drop-in replacement for webpack", which is definitely not true - Even as just "a replacement for webpack"; Webpack and Vite have a lot of overlap, and it makes sense to compare them, but I think there are too many asterisks and nuances to say they're equivalent, in official materials, unqualified

supz_k 4y ago

I yesterday migrated our Laravel project from Laravel Mix (which uses webpack) to Vite (https://laravel.com/docs/9.x/vite https://laravel.com/docs/9.x/vite), and couldn't be more happier. Earlier, webpack took 3-4 seconds to re-bundle on file changes when running npm run watch (It is a quite large typescript + react project). In Vite, it is less than 300ms. And, React Hot-Reloading is awesome.

krick 4y ago

It gave me a pause to think about how it came that I can never really tell what am I looking at anymore. Forget the HN title, which is stupid — what does this landing page tell me? Well, that it's… next gen, and it apparently can catch up with me, which is not much, since I'm not really catching up with what's going on anyway. Also, that it's "tooling". Like IDE, or framework, or maybe a chainsaw. Can't tell. "Getting started" page tells me that "Vite" (pronounced as "veet") is "quick" in French, then it proceeds with quite wordy installation guide. It also quickly mentions that it's a "build tool". Finally. So, like gulp or grunt, I guess? But it doesn't even mention those, or any other build tools it supposedly replaces. And it seems unlikely, since everybody uses some script that comes with angular or vue or any other framework of your choice nowadays…

ianpurton 4y ago
I had exactly the same experience. I gave it maybe 20 seconds then I was gone.
thrdbndndn 4y ago
I'm not a developer and particularly not a front-end one. I have this problem all the time. Even some of the more "obvious" ones, say, nuxtjs, I have a hard time to get what exactly it offers and why I should use it.
- konfusinomicon 4y ago
  at this point I've come to realize that all you need to know about front end frameworks anymore is that they are not jquery
  - smt88 4y ago
    You are utterly wrong. There's a huge difference between even Next.js and create-react-app, even though they're both based on React. The JS framework space is huge, messy, complex, and endlessly frustrating, but you can't wave that all away just because you can't keep up with it. I can't keep up either, but I do employ people who do, and they recently moved all our build tooling to Vite, which dramatically improved our DX.

emptysea 4y ago

Curious how Parcel stacks up to Vite. Vite seems to have the Vue community behind it which is pretty larger. Both have much better performance than webpack, so between the two probably doesn't matter too much.

rk06 4y ago
I don't know much about parcel, but Vite has incredible mindshare. Except react and angular, all other leading js framework authors are on vite eg: vue (obviously), solid, svelte,astro,qwik etc. With framework authors siding with vite, it is natural that those framework users will be switching to vite as well. Vite is gaining popularity in react community as well though not too much because of some issues with commonjs libraries. It is expected to have very bright future.
EarthLaunch 4y ago
I found Parcel and Snowpack years ago, before Vite, because I knew an integrated and ESM-based system was the future. Both were incomplete and buggy, both had tool combinations that they just couldn't handle. I've forgotten the details but from the tickets I was reading, I doubt that's improved. Vite solves all of that, it's incredibly easy to work with and I never have problems with it. For a fairly esoteric frontend situation, too.

zanethomas 4y ago

I've been using Vite since it first became available, works very well for me.

lionside 4y ago

I switched from CRA to Vite for create-rust-app[1]. If you ever needed to bundle JS/TS in an SSR framework (language agnostic), vite is a great choice :) [1] https://github.com/Wulf/create-rust-app https://github.com/Wulf/create-rust-app

razzio 4y ago

I've used Vite in a simple vuejs project and love its simplicity over webpack. However, debugging Vue3 with hot-module-reload seems to be broken. The moment HRM changes a source file, the line numbers and breakpoints not always line up and breakpoints. (https://github.com/vitejs/vite/issues/5916 https://github.com/vitejs/vite/issues/5916). The inability to debug properly is not a minor issue so I'm torn to go back to webpack or disable HMR to keep using Vite. Other than that, the simplification that Vite brings to the build process is sorely needed. I can only imagine how many developer hours have been lost in dealing with Webpack configuration issues. It is ironic that setting up a web development environment is more complicated than building a basic application. Thank you Vite developers for offering relief :)!

darkest_ruby 4y ago

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.

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.

kossTKR 4y ago

Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, an expert og know your way around the codebase before you're suddenly 2 years behind. It's a shitshow and no one really seems to know what the hell they are doing - even the teachers of this stuff - they just know "how" rarely why. Way, way too much complexity and abstraction for simple tasks. Some things "should have" become easier with quick scaffolding, auth templates or whatever, but they always only work 95% and you use an endless amount of time fixing the last 5% instead of building creatively. Vite was the same thing, faster yes, but my VSCODE broke because of the myriad of build tools and plugins on top of each other from older projects.

rvdginste 4y ago
> ...and you never really grasp before moving on to the next thing. Then why do you move on to the next thing? Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.
- nikodunk 4y ago
  This. As someone who's hung back and not switched to the hot new thing in frontend - I've learned the "old" stuff seems to mature and tends to get better. Look at React, CRA, or Redux Toolkit - they're all so much better (performant, more concise) than the original few releases now!
  - 5350-uiop-1130 4y ago
    i dont think you find words like "deprecated" or "sunsetted" in any field as much as front end websh*t. react has changed a lot. i mean hooks pretty much is a rewrite or rethink of core concepts. nothing wrong with that per se, just that things just move to fast, there is no respect for long term stability and web seems to have a greater share of shiny new thing contrarian hipsters.

dfee 4y ago

I can’t find a vite solution for NodeJS which is disappointing. If anyone has figured out a way to ship the minimal amount of code from a NodeJS monorepo (ideally with web and server code, but generally decoupled) I’d enjoy seeing the solution!

lioeters 4y ago
I'd recommend using ESBuild directly. The following article helped me recently to figure out how to build a browser-side library to publish to NPM, as well as bundling a Node.js server to deploy. Build A Library With esbuild - How to bundle ESM, IIFE or CommonJS libraries with esbuild https://medium.com/geekculture/build-a-library-with-esbuild-23235712f3c https://medium.com/geekculture/build-a-library-with-esbuild-... --- I had to figure out a trick for Node side to exclude external modules. In my build script: const esbuild = require('esbuild') const { dependencies, peerDependencies } = require('./package.json') const external = [ ...Object.keys(dependencies), ...Object.keys(peerDependencies) ] await esbuild .build({ entryPoints: ['src/index.ts'], outfile: 'lib/index.mjs', bundle: true, sourcemap: false, minify: false, splitting: false, format: 'esm', target: ['esnext'], external }),
somishere 4y ago
It's possible. I often use vite with multiple build targets (decoupled but with code sharing) .. this can be specified in the rollup config options but my specific build process uses two separate vite configs to resolve some chunking challenges. Everything is parallelised for dev/build in an npm script. From memory there's a bunch of conversations relating to this kind of setup in the GitHub issues. Edit: vite allows you to specify (e.g. node specific) exclusions/globals in the config, it also allows you to specify a 'library' build if that's what you're interested in .. with named exports, etc.
gkiely 4y ago
There is vite-node: https://www.npmjs.com/package/vite-node https://www.npmjs.com/package/vite-node Here's a monorepo example, it's using cloudflare workers instead of node. But you could set up a vite-node server using concurrently or create a vite plugin. https://github.com/gkiely/vite-app-starter https://github.com/gkiely/vite-app-starter

jijji 4y ago

how does this benchmark against doing back end development with any language and pushing vanillajs (standard javascript) to the browser? whats the big difference and why should anyone want to make this more abstract/complicated? is it trying to reduce development time?

LtWorf 4y ago
I'd also like to know.
cyco130 4y ago
Plain JavaScript is of course faster. Not doing something is always faster than doing something. But highly interactive web apps have some problems that need to be addressed: First is syntax extensions: TypeScript (a strictly type JavaScript superset), JSX (a syntax extension for describing DOM nodes popularized by React) and special template syntaxes of other UI libraries/frameworks like Vue and Svelte need to be processed before being sent to the browser. You may also need processing to iron out some of the incompatibilities between JS engines but it's less important nowadays since the IE died. The second problem is the sheer size: Highly interactive web applications have lots of moving parts. For example at work, my company's product's frontend code contains 4709 modules, roughly 3/4 of which are 3rd party libraries. At this scale you need some level of optimization (like eliminating unused bits of the libraries) and the ability to split the bundled code into chunks depending on what pages they are used.

fionic 4y ago

No offense man I can’t really tell what this is… hmr and dev tools cli with a new transpiler?… it’s not next generation it’s a patch/minor upgrade to current generation tooling and it comes with a [extremely] major upgrade to swap it with whatever is currently used.

NaN1352 4y ago

I like that you can use —watch if you don’t want or can’t use HMR for whatever reason (eg. testing with other legacy code). Also it outputs a "dependency" file during build which you can use to infer the correct js/css includes - and this lets you add Webpack like modern js and all plugins like markdown and icons, to a LEGACY app in php. I did it with a Symfony 1.4 app it’s awesome.

ramesh31 4y ago

"It's fast" is not going to sell me on a build tool. Make files are fast too. What we learned with the evolution from Gulp/Grunt etc. to Webpack is that you need to find a sweet spot between zero config and full config. The "batteries included" approach works until it doesn't, and for small projects I'm sure it's fine. But every large project inevitably ends up with all kinds of snowflake config that Webpack handles really well, while also having a robust plugin ecosystem with standard defaults.

simlevesque 4y ago
It's one of the software that is the easiest to move to. For the vast majority of people, you go from a 150 lines Webpack config to a 15 lines Vite config, possibly the default values. It is kind of incredible. They've found "a sweet spot between zero config and full config" you are mentionning.

pragmatic 4y ago

I was looking at this recently and it’s interesting. But a couple of points. Webpack 5 is actually pretty easy to configure these days. I have a use case of supporting angularjs with web workers, service worker (full PWA - it’s a POS that is built to handle low bandwidth, intermittent connections etc while still providing 90% of functionality in offline mode - lots of indexeddb, local storage and service worker magic) and typescript. It handles it all like magic. The workers are in typescript and yet they “just work” with shared imports (indexeddb wrapper mostly). Service workers get all your /dist resources added and you can still add any custom code you need - which I do. Also you can use esbuild with webpack (there’s a plug-in of course) I was dreading using webpack bc my last experience with it in 2015 was not great, but wow, it’s really powerful and actually easy to work with. Also using it for an electron side project and it’s also great there. I have to say, parcel and a lot I’d other bundlers just can’t do what webpack handles almost effortlessly. YMMV of course but webpack 5 is worth a look if you haven’t used it lately.

CSDude 4y ago

It’s amazingly fast, cant recommend it enough.

JeanMeche 4y ago

Brandon Roberts created a POC starter for Angular+Vite : https://twitter.com/brandontroberts/status/1542954860898910211 https://twitter.com/brandontroberts/status/15429548608989102...

moystard 4y ago
This is to generate a vanilla Angular project using vit, not a vite powered Angular project.

tzm 4y ago

Last I tested Vite (6 mo ago) it didn't support web3 lib and a few others. Has anyone tested recently?

gtm1260 4y ago

The negativity about the annoying landing page is fair enough, but vite is actually awesome to work with as a dev! I've been using it as a dev server for sveltekit, its performance claims are very true.

cod3rboy 4y ago

I am feeling like this era of frontend javascript is too much focused on tooling and frameworks that developers spend most of their time dealing with complexities associated with them rather than focusing on creating something meaningful and useful.

dzogchen 4y ago
Actually, you can just run 'npm init vite', choose a plain js starter, and make something 'meaningful and useful' with an awesome dev server and great bundler once you are ready to go live.
deleted 4y ago
[deleted]

jb1991 4y ago

This is excellent! The frontend ecosystem in general has been very stagnant for years, without much innovation or experimentation. Great to finally see a new library for frontend development come along.

barkingcat 4y ago

I find it really funny that the word "javascript" doesn't appear anywhere on the entire first landing page. You have to click into "Why Vite" and then about 1/2 way into the first sentence, then you see "javascript" I was wondering "exactly what kind of front end?" C? C++? Swift? iOS front end? some kind of GUI framework? Windows app development? Modern day Javascript web ecosystem is a nightmare.

dzogchen 4y ago
No it is not a nightmare. It is actually quite pleasant thanks to Vite.
- barkingcat 4y ago
  You say that now, but 3 years in the future you'll be posting "Vite destroyed the Javascript ecosystem"
  - cmykk4 4y ago
    With respect, this suggests to me that you haven't actually read about how Vite works. It's not aiming to be just another contender, it sort of positions itself as a "best of both worlds" abstraction layer on other tools, whereby esbuild is used for faster compilation and rollup is used for configurable builds. It's not as drastic of a change as you're making it out to be, unless someone is coming from like a Gulp-based setup or something. My work uses Webpack 3 and 4 (in a monorepo) and I was able to get Vite up and running on a test branch (as a sandbox) within a day, even though it's using roll-up instead of Webpack and even though our code was pretty old. It compiled in like a few seconds, it was wild.

dazhbog 4y ago

"Get ready for a development environment that can finally catch up with you." Actually I'm the one trying to catch up with all the front-end changes in the last 10 years..

dsjfladjsfkl 4y ago

GiorgioG 4y ago

Vite is excellent and https://swc.rs https://swc.rs is another one to keep an eye on.

sachinraja 4y ago
Vite could use swc for compiling in the future.

albertTJames 4y ago

There is no way I'm leaving webpack after those 100 years of frustration and pain. Now that I have reached an almost mediocre level of understanding of it, I am never letting it go.

simlevesque 4y ago
Leaving Webpack was one of the most liberating technology choice I ever did. Top 10 easily.

oblak 4y ago

Speed gains aside, it's pretty great, though I did have to provide a manual path to node_modules/some_package_here because it wouldn't serve those files in dev mode. On my computer alone. No one else. Guess I had a weird setup. It has many years until it turns into yet another bloated "builder" if you could call it that Overall, I continue to be impressed by whatever these guys (it's not just Ewan) do even it's getting hard to keep up at my age.

zmxz 4y ago

Incredible amount of negative comments. It takes more time to type all that negativity out than it takes to read about what Vite is and what it does. Frontend dev here. Vite is amazing. It doesn't take long to get what it does if you try it out (you can avoid reading about it that way). I won't bother summarizing what it does, the website literally covers it. Reading really became superpower in this day and age.

rco8786 4y ago
> to read about what Vite is and what it does. This is actually my main complaint. I read everything on the landing page and Getting Started page and still have literally zero idea what Vite does.
- martpie 4y ago
  Secondary call-to-action is literally "Learn more" [0] and explains in details all the problems it solves [0] https://vitejs.dev/guide/why https://vitejs.dev/guide/why
  - deleted 4y ago
    [deleted]
  - rco8786 4y ago
    That’s an essay.
weejewel 4y ago
Writing an objective, clear landing page seems to be a superpower as well.
- zmxz 4y ago
  You can complain all you like, but in the end it's you who has to read and understand the text written on the landing page. No one can do it for you.
4y ago

deleted 4y ago

[deleted]

canaus 4y ago

So is it safe to say that this tool is mostly trying to solve the developer experience side of front-end development, instead of trying to create a "new" technology such as SSR? I've just mostly seen "fast" and "HMR" as the features of Vite, but I can't see a team switching over an entire project just to solve something that was probably decently "solved" to begin with.

sachinraja 4y ago
I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.

synergy20 4y ago

This is an excellent tool, beats webpack to ashes. Evan You did this after his vuejs work, it's kind of like Linus did git after his linux kernel work, well, on a smaller scale. Per Linus, he did git to approve that he is not an accidental one time genius.

simlevesque 4y ago
And now he's working on Volar, to make tooling more awesome.

noduerme 4y ago

Am I alone in that I don't webpack or otherwise bundle anything until I deploy? If I'm building a large typescript project, I just run it directly out of source JS and CSS files on my dev server. Only when upgrades are finished and tested do I bundle them and put them on the production server.

QuadrupleA 4y ago

The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems. I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the frontend world endlessly frets about like state management, build times (I don't use builds), polyfills (I just use whatever raw JS subset is about 97% supported), server-side rendering (just design your app with an intelligent division of labor between client and server), dependency management (minimize them, and understand the ones you use fully so you can adapt them to your needs), etc. Like this site demonstrates, reasoning for using all this cruft is always vague too - "best practice", "modern", "next gen", whatever. Seriously, the whole frontend ecosystem seems a rube goldberg tower built on pseudo-technical marketing fluff that has everyone chasing their tail and adding more unnecessary layers. I don't get it. If you're deep in this world, I highly recommend: go a layer down. Try implementing your next feature with and without the library / framework du joir. Can you simplify, remove layers, and still accomplish your goals? How much code is it for each version, including the framework? Is the dependency worth all its baggage, like build times, module incompatibilities, leaky abstractions, loss of control, etc.?

sachinraja 4y ago
If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.
selfmodruntime 4y ago
Your entire answer basically becomes moot since this is not a framework. At all. This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it. Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.

krinn_silver 4y ago

For anyone interested, these are the docs for the upcoming 3.0 release. https://vitejs.dev https://vitejs.dev is for 2.x, which is the current, released version. The sites are largely similar. Other than features that have changed, the major differences appear to be aesthetic. I'm looking forward to the v3 release.

mattlondon 4y ago

Sorry but if it requires NPM then I am not interested. I have been burnt too many times to want to use anything related to NPM. I would hope that a next generation framework would not have hard dependencies on the cess pit that is NPM :(. Please give us something fresh and interesting. This is why I am so excited by deno on the backend - finally no more NPM!

ggregoire 4y ago

I find it funny that, as usual, half the comments are complaints about "why are frontend developers always reinventing the wheel"... Meanwhile the 1st post on the front page [1] is about a new "modern" scheduling package for Python. What's wrong with just using Celery, APScheduler, Huey or even cron? Why do we need a new scheduling library? Yet I don't see any "reinventing the wheel" critic in the comments. Double standard I guess. [1] https://news.ycombinator.com/item?id=31969345 https://news.ycombinator.com/item?id=31969345

selfmodruntime 4y ago
Correct. People are arguing as if there wasn't a new Container Library being released every month for C++

dclowd9901 4y ago

Anyone tried just swapping this in with their current web pack pipeline? What are the pain points? Is it even possible?

Stampo00 4y ago

I know everyone is here to complain about the mess that is "modern" frontend work. But I have to say, I started using Vite a week ago to bootstrap a new project using Typescript, Preact, and Tailwind, and I'm loving it. There is one weird quirk in where it insists the index.html file should be. But if you can live with that, Vite takes care of the details for me and gets out of my way. It also bundles everything exactly how I would have set it up by hand. I think it's weird that it insists its mostly a dev server. It does that well. But it's also a very good bundler with good defaults. I'd recommended it to anyone who just wants to get started, and wants a good middle ground between esbuild and parcel.

fasteo 4y ago

Old backend coder here. All I see here is >>> it’s fast That's the same thought I 30 years ago when going from compiling a Fortran program (minutes) to compiling programs with Turbo Pascal 3.0 (instant) History repeats itself I guess.

marmada 4y ago

Hey. If you're hear to post about how the web is always changing, and it's so complicated, no one cares. It's been posted 20 times by now and there are good reasons (we build much more complicated webapps these days). I like Vite. A few things I like: - Super fast - Works out of the box (like parcel) - Even production builds are super fast -- this is a bit of an underrated feature because sometimes things only break in prod builds, so having fast prod builds = more frequent prod tests = better

selfmodruntime 4y ago
People here love to complain about frontend, but the speed and outreach people can have with modern webapps beats desktop applications by a mile. There is a reason billion dollar companies like AirBnB don't use desktop apps.

jchw 4y ago

Vite is kind of nice because it weaves together some more modern tools, but if you're doing something simple, you might be able to just use esbuild directly on it's own. Bonus: if you're writing Go software, you can use esbuild's (slightly cumbersome) Go API directly in your app server and avoid needing to have JS tooling in your serving/building path, just using Node to handle things like JS package management, typechecking, and linting.

littlecranky67 4y ago

I'm a sceptic to the claims; most build speedups I've seen come from the bypass of Typescript type checking/compiler errors. Since there is no other competetive compiler to Typescript than the official (and slow) tsc, I think vite works this way too? Getting hot reload and fast page refreshes is nice, but the idea is that if I get a compiler error, I ought to fix it first before I move to the browser to test my code.

deleted 4y ago
[deleted]
mmis1000 4y ago
Actually most webpack config guides also recommend you to start Typescript checker in separate thread(there is plugin for that) and don't block compilation(transpile mode). But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.
- littlecranky67 4y ago
  I still don't get it. If I assume that Typescript compiler is the slowest component in the build pipeline, and run it in a separate thread, that still means I have to wait for the tsc to complete. There is little to no benefit in all the other stuff being finished faster; that will be optimizing the 5%, while my main time is wasted in the 95% of the tsc compiler process. At least to my experience, for sufficiently large projects, tsc becomes super slow.
  - mmis1000 4y ago
    > that still means I have to wait for the tsc to complete Without fork it. the webpack need to wait the checker to finish checking everything before it compiles even just one file. With a separate checker, it don't. The ts-loader will eject a perfectly normal js file without caring the typing is valid or not. And webpack can do the rest of works as quick as possible. It like different of do it in serial and do it in parallel. The latter will utilize the resources better although not absolutely more efficient.

c7DJTLrn 4y ago

F*king hell the ecosystem just never stops growing. Vite, Rollup, HMR? What the f*k is all this? Why does building a frontend have to be a titanic project involving a hundred tools including build systems and tree shakers and compilers and whatever else is going on. Web development is an embarrassment and a blight on computing.

mikewhy 4y ago
HMR is 6 years old at this point. Rollup is 6-7 years old. At what point should you start to think maybe you've been a reactionary for too long?
keithnz 4y ago
Perhaps you should take the time to find out. Many of the things you mention create a development experience that is pretty cool. It allows you to dynamically change your code and instantly see the result. I do backend systems, embedded systems, and have done a lot of native UI apps.... modern web development with things like vite and vue are really quite nice in comparison. The development feedback loop is very quick
figmaheart255 4y ago

qiller 4y ago

Upgrading to Vue 3 and Vite soon, is there a danger in having different dev vs production build tools?

shepherdjerred 4y ago

Aisde from the typical HN comments of: * Front-end is a mess; who needs anything other than hand written HTML and jQuery * This site doesn't explain what this is Vite is pretty great. It is a huge improvement on webpack and other competitors that I've used. Configuring Vite for the common use case of some front end framework + optional TypeScript + unit testing + hot reloading is something that can be done with a literally just 5 lines of configuration. At work I switched over a 1000 line webpack script for 40 lines of Vite. Vite is superior in every way compared to webpack (at least as far as my use cases)

nikolqy 4y ago

This is actually really impressive. The documentation site is insanely fast which is usually a sign that it's a well performing framework.

haolez 4y ago

Its source code is quite interesting. It's a medium-sized TypeScript project and it doesn't look like a C# or Java ripoff. Well done!

fkyrframework 4y ago

LAC-Tech 4y ago

So I just streamed myself taking vite for a test drive. My thoughts: - Very fast to reload - Seemed pretty damn simple and non-magical. Your main code doesn't get transpiled, just your dependencies. - IMHO the scaffolding stuff was superfluous, at least for vanilla JS. I'm a minimalist and it initially turned me off, but then I discovered it was basically just a thin wrapper around the `vite` binary. Will probably just install vite as a dev dependency and go from there next time. Over all a positive experience and might end up re-using it.

asciiresort 4y ago

Many claims here of Vite being fast. Does anyone have insight into why? Parcel apparently rewrote in Rust, but I guess that's not necessarily the bottleneck here?

snorremd 4y ago
Compilation/transpilation is only part of the work traditionally being done by build tools like webpack and parcel (well, webpack offloads the work to babel or similar). I believe that a lot of the speed or perceived responsiveness with Vite comes simply from not bundling the code during development. For a long time front end tooling has been bundling your dependencies and code into one or more bundles each time you save your code and then that gets shipped to your browser. Vite on the other hand just transpile the changed module(s) and then ship that over to the browser. This works great because browser support ES modules and module resolution natively now.

gw67 4y ago

What CSS template did you use for https://main.vitejs.dev/guide/ https://main.vitejs.dev/guide/ ?