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.
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.
I didn't really know how much time I could have been saving, and I never even thought of Webpack as slow.
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.
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).
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.
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 :)
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.
"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.
It might also affect your production build times, but prod builds are far less frequent and performance isn’t important here
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.
It’s not the most graceful setup, but it works if your backend build isn’t as flexible as you need.
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 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.
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
Curiously, both are true. Give OP some slack.
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.
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.
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.
For example at my $DAYJOB I know what we do but if I didn't the website wouldn't help me to understand.
If I tried to run a web-based business offering that today, I'd get very litle business.
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?
It's a shite landing page that communicates little, and as a front end framework, well....shouldn't we expect more?
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?".
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.
Is DX meant to be Developer Experience or something different?
in the words of Jack Borrough, Senior JS Developer, "JQuery, what are you, five? We use JJQuery." https://jjquery.io/
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?
"""
# 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.
"""
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 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...
> 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".
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/
They need to read up on https://posthog.com/blog/hacker-news-premortem
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.
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.
Quick is rapide.
tldr: "They don't get paid" is not an escape hatch for genuine, level-headed criticism, and criticism is important for FOSS to stay strong and relevant.
And if you do already know what webpack is, then "frontend tooling" and its list of features should make it very obvious what Vite is.
"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…