Hacker News Reader

Comment by krick | Hacker News Reader

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…

View on HN

Terrible landing page for an otherwise excellent tool.

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 have been using parcel for web development because I thought webpack is very difficult to use. However, for my latest personal project, I tried webpack. To my surprise, I found webpack 5 much simpler to use then I thought it is (significantly easier than make or gradle, the complexity is not even on the same level). Everything pretty much worked out of box now. All I had to do was to copy the starting template for typescript from their website (~20 lines, half of which are open/closing brackets) and copy the setup for dev server. HMR, code splitting via dynamic imports, etc. all worked without any setup.

Webpack is probably fine for new or small projects. It's when you've been using it for a while, do anything complex, or worst of all your framework libraries update then you have to update Webpack which is a nightmare.

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.

Vite is incredibly fast compared to Webpack.

I didn't really know how much time I could have been saving, and I never even thought of Webpack as slow.

IIRC Vite wraps esbuild, which is written in Go and very fast.

You can use esbuild with webpack via esbuild-loader, but what makes Vite so fast is mainly the strategy of pre-bundling dependencies when running the dev server, this makes hot starts and hot reloads incredibly quick.

Vite is just a few lines, and it’s a much better experience than webpack

Last time I checked NPM the weekly downloads were still heavily slanted in favour of version 4. I wonder if that plays into perception of it.

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.

> pretty fast hot reload

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 dunno if it's just me, but I've always found live reload to be an overstated benefit. I usually have a mental model of what I'm trying to code that I don't want to check until it's at a specific state - the seconds it takes to press reload doesn't really add up to that much.

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.

Exactly that though. For a SPA you’re going to have a bunch of state loaded and you don’t want to refresh. If you’re using something like tailwind where you’re transpiling your css too then it’s a major boon to have it hot reloaded.

I’ve found vite to be an awesome dev experience.

Not just you.

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.

Game-changer perhaps in a bad way ;) We're losing the art of writing solid code and instead flail with the "hot reload" crutch. I miss the days of punching cards and submitting a deck to be compiled and run - at least in terms of it forcing me to verify my work ahead of time.

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.

We are also writing far more complicated software. Punch cards didn’t have to support thousands of different devices, resolutions, screen densities, input methods, etc. It’s a totally different world.

That's totally fair but the tooling is still not where you'd like it.

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 think it does this by not even recompiling. It just links all the uncompiled, uncompressed files and dependencies using a few functions to make them work in the browser.

Credit to them for a nice "Why Vite" button backed by a very informative page.

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.

One question .. Is the main goal to make development process easy or does it also have an impact on production performance as well ?

From https://main.vitejs.dev/guide/

"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

I can attest that it is a great way to spin up (and compile for server-ready HTML/CSS/JS) a React or Vue project.

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’s mainly for dev rebuild performance. I also use vite and it’s a pretty nice build tool that’s relatively easy to configure and quite fast.

It might also affect your production build times, but prod builds are far less frequent and performance isn’t important here

Ideally, for production you're not constantly rebuilding a JS bundle but instead just building once with all the required package versions and then just serving that bundle all the time.

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.

So, this is not a framework like React, right?

It’s more like Webpack, the software that processes your React code into JavaScript bundles that are optimized for the browser. ie puts together what belongs together, removes the unused code, provides a test server to develop and get instant refresh.

How would one use it together with a backend that already serves the frontend code? As a compiler only?

I’ve had similar backend projects where I setup a reverse-proxy to a backend, along with the frontend dev server, to allow the full site and api to run in the browser from local host.

It’s not the most graceful setup, but it works if your backend build isn’t as flexible as you need.

If you're talking about something like Django where you would want to serve frontend JS from a static assets directory, you would have to output a build bundle into your static directory. You would not get hot reloading that way, though.

You could yes, however you’ll probably have to write your configuration from scratch. You’ll have to define the JavaScript entry files (those that call the others) and put that into your HTMLs. Depending on how many scripts etc you have this might be a lot of work, but this should optimize your JavaScript to ist what you need.

I don't think Webpack is designed for that use case, it is pretty apples and oranges

Got it, thanks

Thanks for the info, will switch from CRA as soon as I can :D

Would this replace parcel or be adjacent to it?

https://npmtrends.com/parcel-vs-vite

Replace it.

I feel the title is accurate but I'm familiar with Vite so recognize it's perhaps not adequate..

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

At least it includes the "why?" button (link? why does it look like a button to me?) unlike so many other projects that only have "get started" (I don't want to start something I have no clue about).

Thank you for saying this, because often when this sort of thing pops up on HN I click on the link and stare blankly at the page wondering "Just what the hell IS this?!" and I feel particularly stupid.

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.

If you're immersed in the front-end world today you would probably know that "build tooling" (and could guess that just "tooling") typically means a) transpilation, and b) bundling; "take my source and turn it into something I can ship and run". Usually there are also related features like minification and/or a live-reloading dev server.

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

Ah, the age old HN pass-time of feeling like everything needs to fit your niche, leaving a comment about how a website didn't fill in your blind spot for you rather than googling what something is with the time.

I don't think that's what OP is saying. To me, it reads like, "I'd love to know what this is, but based on the linked document and others within near proximity - I can't" which means the link requires that OP has knowledge of the frontend build world - which I will tell you is niche and disparate or that there is a big unsaid problem in this space that is non-obvious to anyone outside of it.

Curiously, both are true. Give OP some slack.

If they don't have knowledge of the frontend build world, then maybe they'll have to do a bit more reading. Who should Vite's landing page target?

By knowledge, what I really mean is intimate knowledge. I'm not a frontend dev, but I do hack away on hobby projects which eventually caused me to make changes to the default tooling that the project starters pre-configure. Given that the landscape so heavily relies on preconfiguration and post-customization, who they're selling to are people who started with a template and know little about what webpack, vite, or next are doing.

And that's a pastime i welcome, as it saved me many clicks. And, it also confirms what i have been seeing across several websites of late: difficult to penetrate, even in areas i would consider myself well-versed in.

If the official homepage of something doesn't tell you what it is, where are you supposed to obtain that inforation?

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.

Devil's Advocate position here.

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.

This is a good point if we were selling physical goods and limited by the amount of information we can convey on a screen but we aren't.

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:

https://playwright.dev/

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.

Different way of thinking about this - maybe the devs aren't even the target user of the homepage. If the first time a front end dev hears of Vite is via the homepage, their marketing has a problem. (I first heard of Vite maybe 18 months ago in a discussion on the upcoming Nuxt v3.)

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.

Developer here. I think I can speak for everyone when I say that even when we work with the thing, we can't understand the homepage of the thing.

For example at my $DAYJOB I know what we do but if I didn't the website wouldn't help me to understand.

You might work at a sales-oriented company then, rather than a consumer or prosumer (self-service) oriented company. Sales-oriented company websites are purposefully opaque so as to not make a potential customer be able to easily compare and contrast tools without going through an in-depth demo for each one, led by salespeople and perhaps engineers.

I'm also a developer and this is a terrible overstatement. My company sells a product that isn't particularly hard to understand, and our www site makes it pretty clear what we're selling.

Sticking with your analogy, in the early 2000s we built cabinents and intricate mantelpieces and things ike that, and there were essentially no tools. In the early 2022s we still build cabinents and intricate mantelpieces, but there are a million tools. Meanwhile browser support has become way more consistent across the board and CSS has become easier, yet we think we need super complex tools to do the same tasks we did back in the day.

when I started building websites in the late 90s, I needed to support Internet Explorer and Netscape running 15" CRT monitors. Few cared much about accessibility, performance, security, SEO, experimental releases. Clients wanted a 3 page website with few design requirements. I sliced up some PSDs into HTML pages with tables on it, and uploaded it via FTP to a single server.

If I tried to run a web-based business offering that today, I'd get very litle business.

Interestingly, there's a very high chance that those HTML pages with tables crafted in the 90s still render perfectly fine today (if they're still around).

> 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.

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.

Nothing like a carpentry analogy to obliterate all nuance.

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?

I am a developer and still took a while to realize what it does. Also, that snowpack is probably just as sufficient.

It's a shite landing page that communicates little, and as a front end framework, well....shouldn't we expect more?

Snowpack is no longer maintained and they recommend switching to Vite.

It feels like this big struggle and effort to end up with another jquery in a few years because in the end that's what works and feels right

But he is a developer.

They are not a specialist front-end dev.

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?".

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

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.

The hilarious thing is that this is the first time I am seeing DX in this context.

Is DX meant to be Developer Experience or something different?

Yes, developer experience.

I agree! my comment was in jest and was just poking fun at the madness that is the JS ecosystem and it's often overly complex, and ever growing list of solutions to problems that could be probably be solved with a few lines of jQuery.

in the words of Jack Borrough, Senior JS Developer, "JQuery, what are you, five? We use JJQuery." https://jjquery.io/

You aren't alone.

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?

It seems dev has become a subculture forest. Everything is simple if you're in that group and follow the problems and ideas around.

Looks like you're looking for the Why Vite page [0].

"""

# 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.

"""

[0] https://main.vitejs.dev/guide/why.html

> it apparently can catch up with me, which is not much, since I'm not really catching up with what's going on anyway

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 had exactly the same experience. I gave it maybe 20 seconds then I was gone.

The page might not be great, but the product is! TL;DR is that Vite is a development and build server that requires very little setup. It's "quick" to scaffold a site in Lit, Angular, or React. And easy to build the static version for hosting. That's it!

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...

The first sentence of the "Getting started" page tells you the following:

> 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.

That's still very generic so as to be almost no information.

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".

While I somewhat see where you're coming from, I don't really agree, but again, I would be biased since I already know plenty about different build tools. The main statement is that it's a build tool for modern web projects, which makes me thing a-la Webpack and similar. Then it's further specified that it's fast (which Webpack usually is not) and lean (which Webpack definitely is not). For me this already gives a rough idea of what to expect, whereas the Python analogy wouldn't tell me that much.

I remember that Visual Basic (90s) opened with an empty Dialog and UI controls like Windows Forms, Delphi and Xcode now. Just waiting for a tool as easy to use as Google Slides or diagrams.net (draw.io) but produceing the skeleton of an web/mobile app.

Does the software industry have a pathology that avoids making such tool and makes front-end engineers irrelevant except for very complex use cases?

> 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/

The feature list on the home page indicate it’s a dev server.

> It gave me a pause to think about how it came that I can never really tell what am I looking at anymore.

They need to read up on https://posthog.com/blog/hacker-news-premortem

Personally, I feel like it's rare that I stumble on a tool and need to read its landing page. If I know of it, it's probably because someone told me about it or it's already part of something I inherited. And that's probably the only way I would consider it anyway. I don't care what their pitch is if I don't know anyone using it. Much more common is stumbling across a repo with tooling I'm specifically looking for (because I don't know anyone doing that specific thing and I'm not looking for an alternative to something I'm already using) and the repo docs are even worse.

The Why page imo does a better job of explaining the reason it exists:

https://vitejs.dev/guide/why.html

Lol, I was about to comment here that I opened the docs, read a few pages, and still don't know how this works or how is it different from react for example.

We switched to vite not for what it is but because what it isn't.

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.

Terrible landing page indeed, when their "Why" page [1] has most of the answers new users would be looking for.

[1]: https://main.vitejs.dev/guide/why.html

This might be stupid and petty but the only reason why I want enough Karma on HN is to be able to downvote these kinds of comments. They make me irrationally angry. Especially if they are under a link to a release announcement or changelog link, which at least, this is not.

"Next gen front end tooling" - for anyone with some vague knowledge of front end development would understand that this is going to be something like webpack, or mix, or grunt, or gulp.

Not every front page has to assume the person going to it knows nothing.

Front-end tooling that I have to run on the server? Even people familiar with the JS ecosystem might be confused by that.

I believe you are overexaggerating. It has always been true that you needed some kind of local server when doing frontend development. There are multiple browser mechanism that would not work in any way other than when rendering html/css/js that was returned from a server.

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.

Just google “front-end tools” and look at the few top results. There are many tools for front-end development that are not build tools or have to run on the server.

You don't have to run this on a server. This would never run on a server. This would be used in your local dev environment.

your local dev environment is running a server

Clearly the word server is the same, but that's not really what's meant by a server in front end / back end developer discussions.

Over the last few years I've noticed a new heuristic I use for determining if something is good/worth investigating or not; Can I tell what it is within 60 seconds of looking at its website.

Funny. The landing page told me immediately what it is. And I'm not some expert, I've only done a little bit of hobbyist JS development.

It does not really matter, but vite in French means quickly.

Quick is rapide.

click "Why Vite?". I think it has a pretty good explanation about what it is doing and the tools that are similar to it and the problem it is trying to solve.

Reply on news.ycombinator.com