Vite – Next Generation Front End Tooling
main.vitejs.dev
main.vitejs.dev
"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…
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.
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.
in the words of Jack Borrough, Senior JS Developer, "JQuery, what are you, five? We use JJQuery." https://jjquery.io/
Is DX meant to be Developer Experience or something different?
I don't know much about carpentry, and if I look at a website selling saws, I will struggle to understand the difference between different models. Dumbing down to an extent that I understand (when I probably won't buy the product anyway) risks alienating the target market that will.
Due to customer demands, end-user requirements, and device fragmentation, front-end development has genuinely become _that_ demanding. So as a non-specialist in the field, you can't look at relatively specialist tools like Vite and Nuxt and expect to understand them straight away.
Sure, many of us long for the halcyon days of "front end" meaning at most pulling in jQuery and embedding something in the page. But then I sound like my Grandad longing for the days when there was no internet at all.
For example at my $DAYJOB I know what we do but if I didn't the website wouldn't help me to understand.
I'd honestly include things like the what and why as critical to documentation. Most libraries, tools, and tech in general are bad at documentation. It's an active choice to omit discussing these things when they should obviously be included but writing good copy is hard.
IDK seems like a good thing to invest in especially if you want your tool to become a dominate player instead of an encroaching tangent.
While there are separate pages for the why and comparisons for vite (but it's only comparing itself to other bleeding edge tools rather than popular ones like webpack, browserify, gulp, grunt) they should be snippets of these sections on the front page. Right now there are 6 title cards of with wasted space with very little information. Compare this with playwright's home page you and immediately know why you want to use the tool:
For a personal taste thing, I'm not really a fan of these open source tools creating homepages similar to as you would see for various startups/products. My mind immediately goes "oh paid tool, oh well." They do say it's free in a lovely medium size text that doesn't standout much and is beyond the fold.
Instead, this homepage is trying to convince some CxO this is a serious tool worth adopting.
Either way, I'd assume there's a good reason you find the homepages of so many popular projects homepages rather vacuous. I doubt it's incompetence.
It's a shite landing page that communicates little, and as a front end framework, well....shouldn't we expect more?
If I tried to run a web-based business offering that today, I'd get very litle business.
To use an analogy closer to home, if the average front-end dev were to look at a page talking about some new C++ compiler, they'd say "wat?".
Vite is a set of front end tooling - it provides a local dev server, allows you to work with JSX, CSS and TypeScript, as well as lets you build your app, amongst other things. It handles most things that go between editing your source files and having distribution bundles.
Nuxt is a framework for Vue, that attempts to provide a lot of defaults for your Vue apps and also supports server side rendering or static site generation. It has functionality for handling views, routing, state, configuration, as well as middleware, fetching data and validations.
You can probably describe anything in a way that people would get the gist of it straight away. It doesn't have to be all encompassing, it doesn't even have to be 100% correct, just easy to understand, maybe even with a comparison in there (e.g. npm + webpack). Many such descriptions might just fit into a single paragraph of text, or even a tooltip.
The OP said:
> 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.
We know that it is “tooling”. But what is “next gen” and “catch up with you”? Are those terms that the appropriate audience is just supposed to get?
The frontend tooling and framework market is so flooded and noisy, with extremely high churn. At this point it's so hard to keep up with and build things with the latest thing, it's become a hilariously bad joke.
What other language ecosystem is this insane?
Anyway, it's a replacement for Webpack based toolchains focused on fast startup and HMR.
Why Vite goes into details: https://vitejs.dev/guide/why.html
I wrote a post[0] recently on using Vite with Lit. It shows a real use case and setup scenario.
Here's the relevant summary: "Vite (pronounced “veet” and French for quick) is a development and build server you can run locally. It’s perfect for writing and debugging Typescript apps because it updates the browser every time you make changes. And it’s perfect for deploying your finished app because Vite can easily build a static copy for publication to an inexpensive hosting website. You can keep a local copy at one stage of development and the production build at another, which is often what you need.
As a bonus, Vite comes with built-scaffolding for Lit apps built with Typescript, which is just what we have in mind."
[0] https://medium.com/@mimixco/getting-started-with-web-compone...
Curiously, both are true. Give OP some slack.
For a long time Babel and Webpack played these roles, respectively, but in the last couple years people have realized things can be way faster and simpler if you integrate the two steps into a single tool and make it opinionated and write it in a native language. As a result we've seen the explosion of options like esbuild, SWC, Parcel, etc. I assume Vite is somewhere in that space
But I agree it's better to be explicit and not assume the reader has all the contextual background
Edit: If you click "Why Vite?" they actually have a wonderful explainer that goes into the above and how Vite relates to it
Not every front page has to assume the person going to it knows nothing.
Consequently a build tool (or dev-tool) that offers you a dev-server is really nothing weird in frontend development world. Same as 10-15 years ago when using jQuery and PHP and you would use XAMPP or LAMPP.
They need to read up on https://posthog.com/blog/hacker-news-premortem
It sets up JS transpiling and bundling for you in an easy way, then provide a server with pretty fast hot reload.
This solves 2 problems:
- the complicated js project stack is now simple to setup, unlike with webpack
- saving and seeing the result of your coding is now almost instant, unlike with CRA
It's a joy to use, given that it's from VueJS author, and I highly recommend it to anyone that has a lof of frontend to do.
I didn't really know how much time I could have been saving, and I never even thought of Webpack as slow.
Ive had Webpack break more of my deploys than any other piece of software in the last 3 years.
Vite was basically a plug and play replacement (almost zero config) and I also got to drop Babel, so that meant replacing about 12 packages in my package.json and who knows how many in Yarn.lock (Mostly babel and webpack plugins) with 2 vite packages. It's much faster at builds and the chunking of small js files seemed more intelligent and better integrated with Vue.
At work, an engineer in a different team recently recommended we switch to Vite because it’s “so much faster”. Warm builds are 700ms with our very uninteresting Webpack 5 config. It’s hard to imagine that the cost of reconfiguring our entire build would be worth it.
It’s not the most graceful setup, but it works if your backend build isn’t as flexible as you need.
It might also affect your production build times, but prod builds are far less frequent and performance isn’t important here
"Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects."
Ultimately it makes the dev process more productive because builds are generally much faster than most other build tools.
https://main.vitejs.dev/guide/why.html might also be worth a read
Just run ‘npm init vite@latest’ and you get a basic well-organized React/Vue project ready for components and other dependencies to be dropped in.
Uses esbuild+rollup behind the scenes I believe.
If you have the luxury of picking your tools for a completely fresh web project this is a great way to do it.
The bundle only really needs to change if the underlying code does, but in pretty much all cases your customers/users are not actually triggering any changes in your underlying code, that's a security risk.
An understatement to be sure: you can set VS Code to auto-save every 1 second and that way whatever you type instantly appears via Vite's Hot Reload in your dev browser. No waiting multiple seconds for a recompile.
It's game-changing workflow (for some tasks).
And yes - I'm (mostly) kidding. But I did write my first programs on punched cards at a university course while I was still in grade school. Probably the last generation of programmers to experience that discipline.
In theory, there's no reason that you shouldn't be able to backtrace from the website to the filesystem. If you can do that, then your "it reloads every second" becomes even faster, it becomes WYSIWYG, you are writing in the live constantly-refreshing UI. Well, almost: your text editor has Undo and Git and your web browser doesn't. But we could build those into the browser. Heck, Redux is basically Git except without any standardized verbs, just give Redux some standardized verbs for tracking revisions in a living app and you've got everything you need.
If you follow that trend to its logical conclusion ("OK I want a special way to ctrl-click or right-click or something to edit the HTML of a component I see") you eventually get Smalltalk, and we're finally back as productive as we could be in the 70s :)
I'd say it's more beneficial for CSS styling but I usually mock up my changes in the dev inspector and then copy it over anyways.
I’ve found vite to be an awesome dev experience.
Hotreload can be handy to some extent, annoying in others - I like to preserve state of given app including what the dom looks like + the window/memory state in devtools. Iterate in code, refresh, then compare. You can do that with multiple browser tabs for example. But not with hotreloading; each tab will re-render/reload the global window state.
But for any homepage describing any product / project: If you solve a similar problem as a better know competitor, that's a huge advantage! Mention them explicitly and then state what makes you different. That's one of the fastest avenues to understanding anything "it's like [well known thing] but different in that it [differences here]".
Perhaps just having this:
Vite is a javascript bundler for web development that uses native ES modules. Projects are adopting Vite in lieu of Webpack to gain near-instant HMR and much simpler setup and configuration.
This entirely depends on your situation but for a tool like this (the selling point being that it does it all for you) I think this is less about catching up with you and more about providing you with the tooling that catches up to the myriad of things in JS that you may feel the need to catch up with.
In this case it's most likely referring to the decision to use native es modules to serve non-dependency code. This means and code you write can use native browser cutting edge without you needing to worry about "what build tooling supports the latest documented standard native browser features" - one of the pains of building is using X standard native tech documented clearly on MDN and finding out it doesn't work cleanly with a specific combination of webpack/rollup plugins I'm leveraging right now. This just lets you use what's standard.
I only keep one foot in the webdev sphere as it's not my primary focus any more, but still - I feel that I should be able to 'get it'.
- ed : I should've read the comments first. Glad I'm not alone!
My studio is in a building that also does musical events and there are always posters up for various gigs and I so often have a similar complaint - they're 'designed' (as in, imho, poorly) by someone who's had their head buried in the thing they're promoting and forget that people slightly outside their context need a bit more of a nudge. There's one new one out there today that doesn't have any links to help define context, and the name of the artist is so generic as to be tricky to filter on a web search.
"""
# The Problems
Before ES modules were available in browsers, developers had no native mechanism for authoring JavaScript in a modularized fashion. This is why we are all familiar with the concept of "bundling": using tools that crawl, process and concatenate our source modules into files that can run in the browser.
Over time we have seen tools like webpack, Rollup and Parcel, which greatly improved the development experience for frontend developers.
However, as we start to build more and more ambitious applications, the amount of JavaScript we are dealing with also increased exponentially. It is not uncommon for large scale projects to contain thousands of modules. We are starting to hit a performance bottleneck for JavaScript based tooling: it can often take an unreasonably long wait (sometimes up to minutes!) to spin up a dev server, and even with HMR, file edits can take a couple seconds to be reflected in the browser. The slow feedback loop can greatly affect developers' productivity and happiness.
Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages.
"""
Does the software industry have a pathology that avoids making such tool and makes front-end engineers irrelevant except for very complex use cases?
Probably the fact that it's all very opinionated.
Suppose you want to use Vue. Well, do you want Vue 2 or Vue 3? JavaScript or TypeScript? Which of the component libraries do you want: PrimeVue, Quasar, or another one? State management with Pinia or Vuex? What about validations: Vuelidate or maybe something like Vue Formulate, which also includes functionality for forms. Or would you like Vueform instead?
Then again, the same happens if you want to use React or Angular, or any other option out there. There's just too many separate pieces to pick, though I presume that occasionally there are opinionated attempts at giving you a stable base to start out with. Honestly, even something like Ruby on Rails can be a nice option, though it's also understandable that many out there want to create their front ends as separate apps.
Yet the majority of front end projects out there end up a bit like the Dropwizard framework for Java back end development - just stitched together from any number of different pieces, which sometimes will work really well together, but other times less so: https://www.dropwizard.io/en/latest/
> Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects.
But of course it's easier to keep ranting and ignore the second part of the sentence you referenced because it doesn't match your narrative.
Imagine if python's homepage had no code samples at all, and the getting started page said "Python is a programming language for high productivity".
Quick is rapide.
We get react and scss compilation/bundling with 4 lines of config (it basically just says "react()").
production builds take under a minute. npm install takes 6 seconds tops. it starts dev mode in a second with hot reloading enabled.
you can tell me how awesome its tech is under the hood for hours, but i dont care. it STAYS OUT OF THE WAY and thats wha i want.
just as it should.
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.
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.
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.
And for another, you can use React without writing a single useEffect(). Class components are still very much a thing!
Heaven help you if you need to go back to a site you built for a client 4 years ago and try to make changes now. 90% chance that your build toolchain will be completely broken and fail to work.
But I don't think that it is necessary to literally switch technology every 1-2 years to keep up, if we can use React (or Vue) which has been stable for a while and is still wildly popular.
I think you mean "even IF the thing is still maintained". This is a big IF. Something as ubiquitous as a React app may still work fine after a few years, but try updating or fixing something and you're in for a world of hurt.
But it is very stressful to update from Webpack 2 to 5 for example. So taking an old project from a couple of years ago and updating the dependencies is not that easy, especially if you were using a lot of the build tools features.
Upgrading dependencies can be a trap. Like, in the past, I've delegated a bugfix that shouldn't take more then an hour or two to a co-worker, only to see them waste an entire day in dependency / NPM hell.
To my mind, there needs to be a compelling case or argument that justifies sinking time in an upgrading exercise.
If you are fairly careful and conservative, and lucky enough to be using software after it has matured, I think most upgrades will wind up being pretty uneventful for you.
I'm saying it explicitly: your exception project probably sucked. That's probably why it was tricky to upgrade. It may not have been your fault or even the fault of the people who wrote it. But for example, it was never architecturally a good idea to have Webpack automatically import browserify Node stubs. It was never a good idea to load Node modules from within an Electron renderer thread. Not always your fault. A reasonably well-archirected app usually refactors decently into changes that fix these issues. A poorly architecture app is so fragile it's hard to imagine refactoring anything without something breaking a few miles away. If you have the latter, then no shit that upgrading dependencies sucks... I mean, changing anything else sucks too.
This isn't the root cause of every horror story... But it's a lot of them
For me React have been doing all and beyond for me on a dev and business pov and will continues for a log time hopefully a decade. But it's frontend so it's already weird that it stayed that long.
The more official reason to move to the next thing is because browsers are a moving target. Browsers are constantly releasing new capabilities. And the overall population of users is always moving onto newer versions of those browsers; even if that migration lags a bit, it happens. When we can use those newer browser features, we can provide better services to users.
Vite is exciting because it's built on top of the native ES6 features that are now ubiquitously supported by most browsers. It's such a smooth ride compared to older tools. The dev experience is great, and the end-user bundles are light. I've been very impressed with it.
I sympathize with your sentiment when it comes to the back-end. I want stable tools there. But until the front-end platform (browsers) is similarly stable, some churn will be welcome to support emerging possibilities.
If someone created a framework yesterday there are few experts, and they won't judge experts by years of experience, if you're a relatively new FE in the job market would you go compete with people with 15+ years of jQuery and 8+ years of React or just take on the next new thing?
If you pickup the latest tooling today by the time it's widespread(like React is now) you're way ahead of the crop and it's quite easy to get some nice pay out of that.
https://docs.flutter.dev/development/accessibility-and-local...
You never really think this stuff matters until you're exposed to it.
Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.
That's pretty useful and it's not "PHP 25 years later with 100x the complexity"
If people could try to understand SSR before diminishing it, we could have much more productive discussions. But as of now the frequency of these uninformed comments makes me feel like people who are ignorant about front-end, are somehow proud of their ignorance.
Which is what PHP was built for.
> If people could try to understand SSR before diminishing it, we could have much more productive discussions.
If new generation of frontend people could try to understand PHP before diminishing it, we could have much more productive discussions.
> You get to use client-side frameworks, but the page is rendered before it even reaches the client
Does PHP run in the client? No? Then it's not the same as SSR. You have it completely backwards. I understand PHP but you clearly don't understand SSR
The server code will use the framework to handle SSR and hydration. Meaning that all you have to do is write the frontend and you get SSR for free.
Yes, it's stupid that sometimes you have to set a breakpoint inside a webpack plugin to figure out what's going on, but at least it's an option.
And as other commenters have echoed - you don't have to use any of this stuff. Most of it is short-lived and low-quality anyway. Half the time it's just an excuse for someone to write a blog post for clout. Expertise is as much about filtering out noise as it is digging deep into things.
People complain a lot about bundlers in particular. Bundlers are "just" string concatenation. It's an easily understandable problem with a lot of weird edge cases. So you wind up with bikeshedding and a lot of bundlers and what looks like unnecessary complexity. But there's little payoff to really "learn" a particular bundler. It's more important to learn why bundling is necessary (the Vite FAQ does a decent job of this) and then some of the features that can make it complicated (e.g code transformation). Then you become an expert on the underlying problem of shipping the minimal amount of code to the browser, which isn't going anywhere. You can then understand what differentiates bundler A from B. It's usually not much beyond a simpler config file. Despite all the new hotness that exists today, the outdated Webpack 4 has feature parity with pretty much any bundler out there.
It could still do without the framework of the month trendiness, but eventually dumb ideas die and good ideas succeed.
We had built a web application and had an existing rollup build process configured for all the obvious things you can think of (including SVG and JSON files, path aliases, development server with watch, typescript support, etc).
One week I got approval to try migrate to Vite and it was pretty much: delete the existing config, use the default Vite one, and remove all your rollup plugins from package.json (since Vite does all the obvious stuff out of the box).
I was using Rider and had no issues at all. It was automatically using my path aliases. It understood importing SVG and JSON files. I got intellisense for all Vite APIs. Maybe I had some plugins installed or settings enabled from when I was using rollup, but there's nothing obscure as my IDE setup is pretty vanilla.
Don't get into devops/infra if JS fatigue is an issue: https://landscape.cncf.io/
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.
Well, good criticism is not negativity, but I'd argue it is positivity.
Instead, I'm about 100 comments down and so far all I can see is endless repetition of the same nitpicking complaint that the landing page is not good. The landing page!
If you use this tool you'll spend about 5 minutes on the landing page and potentially hundreds or thousands of hours in the code, API, and docs. So who cares about the damn landing page?
I want discussion of the actual tool, that's what I come to HN for. There doesn't appear to be much of that happening here, unfortunately.
If there was a single comment thread somewhere criticizing the landing page that would be fine, it's a valid complaint. But if pretty much all the top comments are exclusively doing that, or pointing out how pointless a criticism that is (like this one) then this discussion is a failure.
EDIT: scrolling further down I appear to have hit the "oh no frontend dev is so complicated, poor me" section of the discussion. I'm gonna keep digging, wish me luck!
What's positive about that? A complaint with proposed action is what can be considered positive, but most complaints here were "I am not frontend dev, I clicked the link, I don't understand anything. They need to telepathically understand what I want and make the page that's to my liking".
It's just pseudointellectuals trying to pose as experts in a field they're not even working in. And here we are, a bunch of bottom feeders arguing over a landing page in year 2022. Oh, how entitled have we become. This situation is absolutely disgusting and not positive.
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.
I do wonder if other industries act like this to their specialties. E.g. do carpenters complain about the tools that boat builders use? Do butchers complain about bakers having to many tools. Do cobblers complain about marketing materials for tools used exclusively by dress-makers? I doubt it.
Most front end devs I talk to don’t complain about the things commenters here are talking about. Most of us—that I know of—are happy with the tools we use, are fine with the evolving landscape, and are able to read through marketing materials of most of the tools we are picking. Honestly, if you are not a front end developer, why do you care about this?
It’s funny because I’m a frontend dev and I can do the job of a backend dev better than most backend devs. Yet I don’t go into every thread about Python and complain about what a horrible experience it is to install and manage.
Programming is programming.
Love your comment :)
The speed gains are super impressive from Vite.
I don't know what's involved with Laravel's front-end stuff but Rails is using https://github.com/rails/jsbundling-rails which lets you pick whichever front-end tool you want to use that's supported (esbuild + webpack + rollup at the moment). You're no longer bound to a specific tool that's been modified to work with Rails like the old Webpacker, instead you can use the native tool with its native configuration. Although DHH has already given an opinion on not adding Vite support in https://github.com/rails/jsbundling-rails/issues/25#issuecom..., but there is third party support for it at https://vite-ruby.netlify.app/guide/introduction.html.
Technically the Rails default is not to use any of that and instead you can use a Node-less import maps solution (personally I've gone with esbuild because there's certain things you can't do with Tailwind's pre-built binary).
esbuild with Rails 7 is extremely easy nowadays. It's pretty much running a single esbuild command with a couple of flags, there's not even a config file you need to mess around with.
They did the same thing with css with https://github.com/rails/cssbundling-rails, there's tailwind, bootstrap, bulma, postcss and dart sass that works out of the box all with their native configuration.
It's the best of both worlds. You have flexibility in being able to pick whatever you want but Rails pulls it all together to make using them easy without breaking away from using the native tool's configuration.
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.
Literally one sentence.
- 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
Just have a hyper link that directions to a comparison page explaining the nuance. Even without the hyperlink I wouldn’t assume people would think it’s a 1:1 clone drop in replacement. People don’t just drop in a new tool without research and comparing it against their new tool.
"WTF IS IT?" is an endemic problem with marketing and startups.
Marketing is a skill, that many people in marketing so often don't have, and lot of leaders fail to grasp. It's so sad.
Imagine losing 1/2 of your potential uptake because of poor choice of words.
You have to deal with various layers of transpilation on your JS, styles and assets and that all needs to be flexible enough to fit a wide set of use cases for the community. It's gotten to the point you need to be an expert in all of the different ways you can bundle and deploy a JS app in order for the jargon associated with these tools to make any sense.
I see it over, over and over again.
I see young people pitching their tech and I have no f*ing clue what they are talking about.
I would say >50% of web sites don't do a very good job of explaining anything.
Vercel is one of the worst offenders.
That said - I feel for some of these dudes just wanting to make a framework, struggling a bit with the 'communication' part.
Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects. It consists of two major parts:
* A dev server that provides rich feature enhancements over native ES modules, for example extremely fast Hot Module Replacement (HMR).
* A build command that bundles your code with Rollup, pre-configured to output highly optimized static assets for production.
And next week there will be yet another "revolutionary" front-end thingamajig.
Edit: the "why" page mentioned by the sibling comment actually explains it
- fast (very important) - Fully Typed APIs (very important)
Just those two points would convince me to try it and I can see it right away on the landing page.
At my company, I looked at Vite 6+ months ago and decided it doesn't make sense for us, yet, because of some specific tooling gaps, but it's a tool that I consider "cutting edge" in the frontend tooling world. I think they're doing just fine and their page doesn't have any major issues with their copy. Do you actually do frontend dev?
"We have some amazing fast tech, that will make your life better -> read our white paper! We have good APIs"
Tell people what it is first, roughly what it's for, then the benefits. Then the article.
There's a great page on how it's cutting edge here: https://main.vitejs.dev/guide/why.html. I suggest you try using it to see for yourself.
Those are completely generic descriptors.
Those are arguably 'differentiators' to the problem they are solving, but they don't first explain the problem they are solving.
I think you're right about this and the "hero text" on their landing page should explain that in one crisp sentence. I imagine the authors of the project just aren't good at this stuff so hope they read this thread and refine the messaging.
I wanna say it's been a decade of front end build tools that have come and gone (or stayed.. we still use a grunt file from 2013) and they all do more or less the same things a front end dev needs.
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.
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.
What annoys me about this discourse is that anybody in the front end world knows this is an issue. People aren’t contributing anything by complaining about it.
All this grunt->gulp->webpack->vite->'the inevitable replacement for vite' are really achieving is finding slightly different ways of doing the same thing.
"all this python->go are really achieving is finding slightly different ways of doing the same thing"
"all this relational db->document stores are really achieving is finding slightly different ways of doing the same thing"
This is simply a false statement. Chrome increases its dominance every year, which actually makes it a lot easier to write frontend code, but that isn't necessarily "better".
In other areas:
- Typescript has been a huge boon to the ecosystem and is widely adopted
- Babel is the standard for transpiling code and has allowed for all these compile-to-JS projects to exist
- ESBuild/SWC exist if you want to do things faster and less flexibly, but they're still a minor part of the ecosystem
We're now firmly in the age of complexity and thousands of new tools and projects - it's important that people provide a very simple introduction/overview to 'what something is'.
That said, I agree, it's not hugely helpful to have all our discussion be about that.
The app I work on deoends on an angularjs bootstrapping process, and does some other things that are sort of webpack specific, so we'd need to refactor some bits first.
Vue2 should be pretty easy, at least to see the speed improvements locally which is its main pitch afaik
I recently migrated a vue2/vue-cli project over to vue3/vite. I had a pretty clear migration path, and did it incrementally over a few months. I needed to ditch a few libraries that didn’t work with either vue3 or vite. Most of the replacements work with both (e.g. vue-composition-api or pinia) so I could keep using vue2 while I migrated and then when the last non-compatible code had been refactored a few months later the final migration was fairly straight forward. The vue-cli switch happened somewhere in the middle of this.
Can I just use esbuild yet?
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.
If you're just bundling JS, transforming typescript, maybe doing JSX, etc. then it's just a simple esbuild CLI command to do it. Toss it in a makefile or your CI tooling and you're done.
Yes. esbuild works great. I use it in my own full-stack framework [1]. Builds take < 1s, even for big projects. It's a really impressive tool.
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.?
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.
Other times, I just feel like I’ve been fighting a framework for hours to achieve something that really should have only take a few minutes.
IMO, it’s about having as many weapons in your arsenal as possible and always selecting the most appropriate for the task at hand. You can only really do this if you have a good broad working knowledge of as many tools as possible, to understand their unique strengths and limitations.
Typically I just avoid the latest shiny new thing entirely for at least a couple of years until it’s stabilised somewhat. I got burnt early adopting Swift and spending countless unbillable hours updating thousands of LOC every time Apple seemed to break the entire thing with each new release.
Edit: ok so I took a look at the website in your hackernews bio. Some cool stuff there, but honestly in terms of front end work it isn't terribly complicated. So while you might be picking the correct tools for your work, it doesn't really apply for, say, a marketplace website that wants to lazy load long lists of products, or that want to re-use those product cards across different pages, etc. This is where vanilla JS starts to be too low-level, and you start to see the benefits of the structure that frameworks provide.
Of course my projects don't represent everybody's, but I've done a wide variety of them so I'm not speaking from some esoteric niche viewpoint either. There's a certain stockholm syndrome with these tools where people assume they'd be much worse off without them, without actually trying it out.
IMO when paired with Vitest, the setup feels powerful, modern and lean. Would recommend.
Definitely the build tool I reach for by default now
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.
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.
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.
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.
The one I ran into: https://github.com/BulatDashiev/svelte-slider
npm create vite@latest my-app -- --template svelte-ts
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.
Contrast that to my usual dealings with Webpack I couldn't be happier.
By far it's my favorite tool to reach for when I need more than just plain vanilla JS.
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.
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".
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.
* 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)
It is kind of incredible. They've found "a sweet spot between zero config and full config" you are mentionning.
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
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.
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.
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.
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). 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 :)!
- 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.
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.
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.
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.
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!
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.
https://twitter.com/brandontroberts/status/15429548608989102...
Build A Library With esbuild - How to bundle ESM, IIFE or CommonJS libraries with esbuild
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
}),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.
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.
>>> 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.
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.
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.
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.
Actually I'm the one trying to catch up with all the front-end changes in the last 10 years..
Does anyone have insight into why? Parcel apparently rewrote in Rust, but I guess that's not necessarily the bottleneck here?
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.
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.
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.
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.
I thought that for sure, by 2017 or so, we'd have seen a relatively long lived consensus winner like we saw during jQuery's reign.
Instead, it's just been constant roiling.
The roiling is hard to understand because it's not like the other parts of the stack are really mutating that quickly. Backend dev practices/technologies and browser capabilities are not evolving or roiling at anywhere close to this rate. This sort of churn would have made sense during say 1997-2002 when the entire stack was being invented and reinvented and the basic idea of browsers themselves were changing rapidly.
According to the latest Stack Overflow survey[0], the most popular is React, which hasn't been the top for the last 7 years. And I wouldn't call jQuery the obvious choice before that, as it's been consistently fading in popularity.
https://insights.stackoverflow.com/survey/2021#most-popular-...
Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet?
Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow". Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently. And how much faster IS Vite when bundling a large project? Nothing on that, only some charts with lines saying that they do it differently. They say 10-100x speedup on "prebundling", but if that part of the build is only a small portion of the overall build it might be negligible. Also, they say it's faster because Go. Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?
Not trying to be a naysayer here, I'm just asking why mindshare should be devoted to yet another project that looks like reinvention of the wheel and starting the cycle anew again when we could instead contribute mindshare to existing mature projects - the reasoning given on the site doesn't seem to be very compelling.
You might find this answer helpful, about Rome which is like Vite but in Rust rather than Go [0], crucially:
> This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.
Speed matters. It is not a sideline consideration, it should be one of the main considerations, over and above a tool being in the same language. In fact, many say that rewriting JS tools in non-JS faster languages will be the future [1].
[0] https://news.ycombinator.com/item?id=28609474
[1] https://leerob.io/blog/rust#the-future-of-javascript-tooling (https://news.ycombinator.com/item?id=29192088)
Complaining about bad frontend tooling would be more appropriate to do in a thread that's not about a tool that practically solves it.
Instead of complaining about other tools, these people who don't know what Vite is should be curious and asking what it is, or what it has that's new. That is easy to find out.
> Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently.
Good luck with your bet.
Js is an ever changing mass of stuff. I feel bad for frontend guys for this reason. Always writing for a language that does not even exist... always changing how you shove it all together.
Even worse as soon as you put a foot down and pick something you are behind.
It is exhausting even to watch much less to be in it.
It took me about an hour to figure out nothing I tried to set up worked because I had installed Vue 3 and mostly everything else was still on Vue 2.
Reminds me of Angular 2 rewriting their router every 6 weeks - to the point that they just moved on to calling it Angular 3 at release to rid themselves of the information on StackOverflow that was in a constant state of deprecation.
Maybe plastering a power strip into a wall rather than doing proper electrical work is a better metaphor. Everybody knows it’s a bad idea, but someone made a thing that automatically provisions and deploys new strips, and someone made a thing that plugs stuff in, and someone made a thing that mixes and applies plaster which was replaced by a drywall thing but we still call it plaster, and someone else made a thing that does it in 10 rooms at once…
That said, this seems like a bigger step towards simplifying both the development process AND the toolchain. It only works in newer browsers so it doesn't immediately work for all use cases, but it's good enough for some. We're quickly approaching the point where browser-native implementations of more recent, better designed scripting features are widespread enough to rely on. That should both simplify and stabilize front-end web development for quite some time.
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.
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.