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…
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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:
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.
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 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/
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.
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.
> 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.
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."
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.
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/
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.
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.
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.
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.
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.
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.
Whether the project is FOSS or not is irrelevant. They're seeking distribution and in order to further distribute a project needs to be able to cleanly communicate why it deserves more distribution. Ironically, based on your comment, FOSS products are generally very good at this. What OP provided was criticism, and FOSS needs and welcomes criticism to stay strong and relevant. If OP was opening a GitHub issue and berating the maintainers I would agree with you.
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.
I find it extra funny that most of the comments recommend that they just say it's a webpack replacement. If you don't know what webpack is and visit webpack's site, you'll just see it's an asset bundler which Vite explicitly is not.
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.
Working with front end for 5+ years have nearly made me switch careers.
There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing.
I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, an expert og know your way around the codebase before you're suddenly 2 years behind.
It's a shitshow and no one really seems to know what the hell they are doing - even the teachers of this stuff - they just know "how" rarely why.
Way, way too much complexity and abstraction for simple tasks. Some things "should have" become easier with quick scaffolding, auth templates or whatever, but they always only work 95% and you use an endless amount of time fixing the last 5% instead of building creatively.
Vite was the same thing, faster yes, but my VSCODE broke because of the myriad of build tools and plugins on top of each other from older projects.
> ...and you never really grasp before moving on to the next thing.
Then why do you move on to the next thing?
Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.
If we're being really honest, I switch to the next thing because it's fun.
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.
This. As someone who's hung back and not switched to the hot new thing in frontend - I've learned the "old" stuff seems to mature and tends to get better. Look at React, CRA, or Redux Toolkit - they're all so much better (performant, more concise) than the original few releases now!
i dont think you find words like "deprecated" or "sunsetted" in any field as much as front end websh*t.
react has changed a lot. i mean hooks pretty much is a rewrite or rethink of core concepts. nothing wrong with that per se, just that things just move to fast, there is no respect for long term stability and web seems to have a greater share of shiny new thing contrarian hipsters.
>> even though the thing they are using is still well maintained.
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.
In my experience dealing with the tooling is fine for ongoing projects by just checking for updates every week.
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.
The biggest problems come in when your apps are doing hacky things they shouldn't be doing. This is a common issue with things like Electron, or React Router, and of course, Webpack.
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
But that's where you have to balance the gain updating the old toolchain against the benefits in your specific situation. Are you going to spend a lot of time on the project, or is it just a few bug fixes? Can you revive the old toolchain? Is the old toolchain churning out good enough production ready assets?
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.
Because all the upkeep happens on the new shiny toy, leaving the old ones to fester and rot away.
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.
This is why I just roll my own and don't use frameworks like React. I've been building and rebuilding apps for clients for 15 years, so basically have my own ways to spin up an app within hours. Yeah, I still use jQuery for some things, who cares if it works?
And then you have someone down the comment telling him to try the next thing Flutter or whatever. It's a never ending. HN and tech is both full of people like you say and want stable stacks but also full of people wanting to try the new thing.
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.
But React is now probably about 7-8 years old. Is it really this shiny new technology that "everyone must jump to"? Yes jQuery devs probably don't get a lot of work right now, and yes you probably should keep up with React itself.
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.
But aren't the React devs of today the jQuery devs of tomorrow ? Meaning that if you keep that same technology forever you will lose relevance in the market.
Because it's easy money(and as others said, to stay employable).
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.
It's hilarious listening to my friends who do frontend rave about the the incredible framework of the month, every month there's a new one that's supposed to be the last, ultimate, final stop for developing frontends.
Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.
I don't really understand these sorts of low-effort comments. You're probably referencing the React Server Components that were recently proposed. React has supported server side rendering basically since its inception. The problem with most existing SSR implementations in any language is that it's a one-shot synchronous process which doesn't allow for out of order streaming. For example, you might want to render a loading state and replace it with content once some network call returns. This used to take multiple requests; you get the initial page, some JS makes the network call, then you might need to download even more JS to render the result. Now you can do it all in one shot with (almost) no JS; the server can stream this entire sequence of HTML chunks in one response.
That's pretty useful and it's not "PHP 25 years later with 100x the complexity"
This gets repeated in every thread about front-end tech, and every time people have to repeat the same explanation. SSR is not PHP. SSR allows you to run the same code on client and server. You get to use client-side frameworks, but the page is rendered before it even reaches the client.
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.
It's not PHP. It's not even close to being PHP... SSR frameworks are truly impressive pieces of technology that might impress you too if you weren't raging uncontrollably.
This is really untrue. The complexity of large PHP projects could get insanely high. The advantage of using SSR in JavaScript is that your entire application speaks the same language as the browser does, so sharing code between server and client becomes incredibly easy.
The saving grace of frontend is that debugging is really easy. You can inspect the actual code of all your dependencies in node_modules, and they're almost always on github too (in case they bundled/minified code). The programs are mostly single-process and single-threaded. The same Chrome devtools you use to debug in the browser are used to debug NodeJS code.
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.
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.
I too find this exhausting. However, to be completely fair, front end was a 100% no-go for me before 2015, and improvements to the language and improvements to the ecosystem have turned it into something that I can deal with occasionally without wanting to murder anybody. ES2016+, better build systems, better package management, typescript, etc., have all made huge strides in front end development.
It could still do without the framework of the month trendiness, but eventually dumb ideas die and good ideas succeed.
> Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools"
Yes, and that's the main reason why I like it. You can do advanced UIs and animations that would otherwise be very annoying in other frameworks like React Native. Plus, a canvas makes it easy to port to other platforms like desktop and web because all you need is the ability to draw pixels on a screen.
hah. I remember having to build HTML-only fallback versions of fancy Flash UI sites back in... 2002 to around 2008. We marketed this as an add-on for improved SEO. Allegedly Google used to manually check if the content matched what was in the Flash version and knock you down if it wasn't. That was probably just a rumor.
But it's more fun to rebuild the DOM inside a canvas. Then you can run it in another DOM inside a canvas inside a DOM, and stream the whole thing from a server into a thin client and call it a native app.
was just reading about them, the were trending on github today.. if we want to port an existing typescript project to deno any ideas how complex it would be ?
I'd guess it would not be trivial. NPM packages are not compatible out of the box. There are workarounds, but generally speaking it's still (relatively) early days in Deno-land. Having said that, I've been playing around with the Deno Fresh framework and it's been a refreshing experience compared to typical TS based web app development.
At this point it would almost require a full rewrite. I use it for a new projects. But things like using Vue is really hard, some packages help but they are also buggy.
I agree. Vite is amazing. And most of the comments here seem to be same old complaints we’ve heard and debunked over and over about the state of frontend dev tools.
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?
Insecure non-frontend devs continue to see frontend as an easy programming environment, and therefore assume the problems in it should instantly make sense to them and be easily solvable. Because after all it’s easy, and they’re smart, and if they were a frontend dev, they wouldn’t even need this tooling because it’s so much easier to start from first principles of an index.html page.
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.
I came to this discussion because I wanted good criticism of ViteJS . I genuinely wanted to see it picked apart by experts because I have been thinking about trying it for a while now.
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!
I'm not seeing a lot of "good criticisms" here. Just the typical HN curmudgeons complaining about things that were introduced half a decade ago being too new.
There was no criticism of the tool itself, but how landing page is not instantly clear to developers who are not even frontend-related devs.
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.
I think Rails should have done the same, vite_ruby is amazing. Thankfully it's easy enough to replace the current options, which feel a bit half-hearted.
It feels like DHH really doesn't want this tooling at all in Rails, but did so reluctantly because so much view tech and mindshare had moved to the client.
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.
No. CSS source maps are a recent addition to Vue, and JS source maps have had multiple problems in dev and prod. Check the GitHub issues for full details.
Almost all the comments are from those who have tried it. (And most people apparently love it).
Why?
Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else.
The features don’t help: it’s fast. That could apply to anything.
It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what it does. That’s several clicks in to figure it out.
I think is more of an indictment on the javascript ecosystem generally, because there's so much more to building an app that runs JS than just your standard MVC/MVVM/pick-your-pattern web frameworks.
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 the same issue with libraries and frameworks in any language. For example, I came across Dark Lang [1] yesterday, and the front page is similarly cryptic if you aren't familiar with back end work.
- 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
Rather imprecise then have people confused of what it does - especially when the confusion could be fixed by a sentence.
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.
It's in the first section when you click the one colored button ("Getting Started") on the front page:
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.
You are repeating the feedback "...when you click...".
Get rid of the click. Landing page should say what it does. If the author doesn't know or accept feedback on this website 101 topic, I doubt they revolutionized much elsewhere.
I think you are being a bit disingenuous to suggest it could be a framework. Is there a framework or JS target language project you are aware of that references itself as "front end tooling"?
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.
They actually do right in the hero section of the landing page. For me:
- 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?
> 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.
What is cutting edge about it? What gaps is it lacking, and why not put thodr in more established tools? Basically, what problem is this solving and way throw out years of experience in the other tools?
Despite all negative comments, I (and my team) switched to vite for create-react-app about two months ago, and never looked back. Builds take seconds, developer experience is amazing.a.m.a.
You may notice that all of the negative comments are around superficial nitpicking of the website copy or general bemoaning of the state of front end development. The first is sort of useful in a minor way; the second is pretty useless and generally tired. Vite is a great tool that I’d recommend for anyone who wants to speed up their front end build setup.
It's not superficial or nitpicking, it's just not directly related to the quality of the product.
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 second is pretty useless and generally tired.
Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.
Fragmentation is political though. You can’t really solve this issue unless someone or something is forcing people to coalesce around one tool. Webpack was great but it had noticeable flaws that allowed tools like esbuild/rollup/swc to gain market share. And it’s not like webpack can easily do what esbuild did, I.e. rewrite in multithreaded Go. If you can propose a way to get everybody on the same tool, by all means, let’s do it.
What annoys me about this discourse is that anybody in the front end world knows this is an issue. People aren’t contributing anything by complaining about it.
We both know those aren't even close to the same thing.
All this grunt->gulp->webpack->vite->'the inevitable replacement for vite' are really achieving is finding slightly different ways of doing the same thing.
Once again, we both know those aren't even close to being the same. Your attempts at snidey mimicry just expose the poverty of the point you think you're making.
As a backend developer, I’d say that it is a very apt comparison to your point. The backend and infrastructure space also has a lot of new projects solving old problems being released.
All this make->ant->maven->gradle->'the inevitable replacement for gradle' are really achieving is finding slightly different ways of doing the same thing.
As another commenter pointed out [1], backend "reinventions" don't seem to receive the same criticisms, so in general there really does seem to be a double standard
> 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.
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
- React has existed for nearly a decade and continues to enjoy regular updates and an enormous community
How big is your application? What level of legacy are you dealing with? Do you also have broccoli as part of your build process? What did you switch from? How are you consuming your build? Do you do server side rendering? Do you build for UI testing? What’s it like building for Jest? Have you had to write any custom plugins?
It depends. I think web-workers are handled differently, so if one of your dependency uses the webpack way to import a web worker then you might have to ditch that library. There might be other painpoints, but I think most projects migrate pretty easily.
I recently migrated a vue2/vue-cli project over to vue3/vite. I had a pretty clear migration path, and did it incrementally over a few months. I needed to ditch a few libraries that didn’t work with either vue3 or vite. Most of the replacements work with both (e.g. vue-composition-api or pinia) so I could keep using vue2 while I migrated and then when the last non-compatible code had been refactored a few months later the final migration was fairly straight forward. The vue-cli switch happened somewhere in the middle of this.
I think it depends, and it's just worth trying. My opinion from a cursory test is that it should be easy to migrate for local dev purposes if you have a single entry point for an app that us essentially one or a series of component trees.
The app I work on deoends on an angularjs bootstrapping process, and does some other things that are sort of webpack specific, so we'd need to refactor some bits first.
Vue2 should be pretty easy, at least to see the speed improvements locally which is its main pitch afaik
I'm a happy vite user, but it troubles me when I think about how complicated everything it abstracts has become. It uses rollup for some things, esbuild for others, workbox for my service worker... I switched from webpack to it, and while my config is certainly less complex, I at least could tell you what webpack is doing. Vite is magic.
You can totally just use esbuild, it is extremely well documented and easy to grok. It's very easy to embed in a go app too, but you don't have to do that or be a go programmer to use it (they put it on NPM and gave it a super basic CLI). The docs are great: https://esbuild.github.io/getting-started/
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.
I think Vite is waiting for code splitting and plugin support in esbuild.
It does seem like magic sometimes, but the the code is relatively straightforward. It's not too complicated to dig into to the internals if you're curious about how specific configuration works under the hood. With Webpack I never really felt that way, but maybe it's some kind of subconscious bias from struggling so often with massive configs.
Thing is, I did dig into the webpack code after having the watcher not reloading with code changes. I can’t recall the details but there were several different packages that were thin wrappers around each other and ultimately inotify (or something at the bottom). One of those wrappers was silently hiding the error about not having enough watcher available at the file system level. I was not impressed with what I found.
I agree with your sentiment. It's magic until it isn't. When something breaks, you need to often need to dig into the implementation and understand how everything works. This becomes harder and harder when there are more and more layers of code and libraries, many written by completely different people. Seems like frontend is still going in this direction of "magic > simple". I wonder when we'll reach some point where we see a dramatic shift.
Yes you can. Code splitting will potentially not land in near future, but of already there if you output esm - which you can then (if wanted) convert with a simpler tooling (e.g. Babel or swc) to another format of you want. We switched to es build a year ago and never looked back.
Just finished migrating the react project at work to vite and vitest after the pleasant experience I had with it in a private project.
It was surprisingly little effort and is _so_ much faster and easier than the webpack mess we had before.
I wonder if at some point they'll ditch rollup and go full esbuild. however Dev Server cold starts went from 34s to 0.3s and build times from 1m20s to 9s so I won't complain!
The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems.
I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the frontend world endlessly frets about like state management, build times (I don't use builds), polyfills (I just use whatever raw JS subset is about 97% supported), server-side rendering (just design your app with an intelligent division of labor between client and server), dependency management (minimize them, and understand the ones you use fully so you can adapt them to your needs), etc.
Like this site demonstrates, reasoning for using all this cruft is always vague too - "best practice", "modern", "next gen", whatever. Seriously, the whole frontend ecosystem seems a rube goldberg tower built on pseudo-technical marketing fluff that has everyone chasing their tail and adding more unnecessary layers. I don't get it.
If you're deep in this world, I highly recommend: go a layer down. Try implementing your next feature with and without the library / framework du joir. Can you simplify, remove layers, and still accomplish your goals? How much code is it for each version, including the framework? Is the dependency worth all its baggage, like build times, module incompatibilities, leaky abstractions, loss of control, etc.?
I absolutely agree with you on the surface, as I’m of exactly the same mind. However, I’ve forced myself to use a few shiny new things on projects over the last couple of years and it’s been a mixed bag. Some new frameworks like Vue have absolutely shrunk development times for certain types of projects by a serious order of magnitude, as we are now worrying way less about state and writing far less code overall. Mutating certain changes just cascades down without us worrying too much and writing loads of code to handle those changes/updates. Hot reloads alone have easily saved countless development hours.
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.
Apparently you have never built a webapp that is more ambituous than a simple website. The superpower of "modern" frameworks (Vue and React are both 5-10 years old) is abstracting away from the DOM to be able to define your view as a function of state. Vanilla JS doesn't help you in that regard.
See reply to woojoo below - not saying I'm the world's best frontend dev, but I've built complex apps with many screens / modes / complex state. Despite what people seem to think, the world doesn't fall apart without a virtual DOM, indeed it usually gets simpler. Vanilla JS gives you all the essentials to make abstractions to fit your task (i.e. functions and structured data).
Sure it's possible. You can also program in assembly instead of Java. But you'll soon be creating your own abstraction layer, why not use one that is very thin too and battle tested by millions of users?
Your entire answer basically becomes moot since this is not a framework. At all.
This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it.
Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.
If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.
Have any examples of websites or products of yours?
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.
That site is just smaller side projects - in my paid work I do maintain large apps with dozens of screens, modals, workflows, complex state etc. It's not necessarily trivial, you have to think through your design approaches, but JS is a Turing complete language after all, with all the elements you need to build abstractions to fit your task. I haven't personally found virtual DOM to be a win in my projects (I've experimented plenty with react). Things have always been more performant and simpler without it, and the dev experience is much nicer and simpler and easier to debug without a build step.
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.
I find it funny that, as usual, half the comments are complaints about "why are frontend developers always reinventing the wheel"... Meanwhile the 1st post on the front page [1] is about a new "modern" scheduling package for Python. What's wrong with just using Celery, APScheduler, Huey or even cron? Why do we need a new scheduling library? Yet I don't see any "reinventing the wheel" critic in the comments. Double standard I guess.
I also feel like this is the actual use case of Vite. Don't want anything else but be able to roll a static site together, while using some vanilla html, css and js with a few assets attached.
This is an excellent tool, beats webpack to ashes.
Evan You did this after his vuejs work, it's kind of like Linus did git after his linux kernel work, well, on a smaller scale. Per Linus, he did git to approve that he is not an accidental one time genius.
Yep, same! I will say, getting everything playing nicely in terms of TypeScript, ESM, CJS, etc. was a bit challenging on the first go around, but isn’t the fault of Vite (at least not entirely).
As an example, if you’re used to CRA being setup for you to handle things like images/fonts, you’ll probably need a loader (same as webpack). Then you might need type definitions for the loader, the file format (e.g., SVGs), etc.
After getting past the initial configuration hump it’s not bad and pretty painless to start a new project.
I just don’t want to mislead people into thinking it’s entirely painless.
Exactly same here. Scaffolded a small project with Create React App. At one point tried to organize all the config files in a subfolder and ran into the problem of CRA literally hardcoding the location. Was annoyed enough to look at alternatives and Vite was a fantastic substitute that not only provided all the configurability I wanted, but also let me remove all kinds of craft from the project (eg random React and ASP.NET proxy files generated by CRA). It was also fast and way leaner than CRA in terms of dependencies. Quite happy with the outcome.
Not who you responded to, but trust me, I would if I could still use Vue professionally to where I could justify the time in my work and/or personal projects.
I was a huge fan of Vue 2 and Nuxt, but the work world has been heavily favoring React for a while now.
Not that everything has to be about work, but just haven’t mastered React enough to personally justify the time spent on working with Vue 3.
Yeah, and it's a pleasure to use. Really the only issue I ran into was not realising SvelteKit doesn't support all Svelte functionalities, and you have to vet plugins at times.
To be honest I'm not a front end developer, just learned that a few things on GitHub had issues outstanding about SK issues, and avoided them after the first run-in. Massive props to Svelte to allow me to finish my project while actually, somehow, enjoying the front end development portions though!
It does, but fyi vite cli has built in support for Svelte, and you can bootstrap a project really easily if you don't need all the "stuff" that sveltekit provides:
I was looking at this recently and it’s interesting. But a couple of points.
Webpack 5 is actually pretty easy to configure these days. I have a use case of supporting angularjs with web workers, service worker (full PWA - it’s a POS that is built to handle low bandwidth, intermittent connections etc while still providing 90% of functionality in offline mode - lots of indexeddb, local storage and service worker magic) and typescript.
It handles it all like magic. The workers are in typescript and yet they “just work” with shared imports (indexeddb wrapper mostly). Service workers get all your /dist resources added and you can still add any custom code you need - which I do.
Also you can use esbuild with webpack (there’s a plug-in of course)
I was dreading using webpack bc my last experience with it in 2015 was not great, but wow, it’s really powerful and actually easy to work with.
Also using it for an electron side project and it’s also great there.
I have to say, parcel and a lot I’d other bundlers just can’t do what webpack handles almost effortlessly.
YMMV of course but webpack 5 is worth a look if you haven’t used it lately.
The negativity about the annoying landing page is fair enough, but vite is actually awesome to work with as a dev! I've been using it as a dev server for sveltekit, its performance claims are very true.
Happy to see other folks still using Mithril. I've looked at other frameworks (svelte recently) and keep coming back to Mithril. It's so simple and easy to understand, it'll take something special to have me consider something else.
Mithril is criminally underrated. Yeah it won't have the same level of community support that things like React and Vue have but it's extremely simple and concise to work with and nothing about it feels "heavy" like the former two.
By far it's my favorite tool to reach for when I need more than just plain vanilla JS.
I like that you can use —watch if you don’t want or can’t use HMR for whatever reason (eg. testing with other legacy code).
Also it outputs a "dependency" file during build which you can use to infer the correct js/css includes - and this lets you add Webpack like modern js and all plugins like markdown and icons, to a LEGACY app in php. I did it with a Symfony 1.4 app it’s awesome.
Introduced Vite into our React project but it's still an experimental development option due to some rough edges.
Our project has thousands of SCSS and source files(nearly 10k).
The motivating factors were 5-12 minute startup times for CRA depending on the power of the developers workstations, and equally burdensome builds requiring now over 8GB of Node heap to complete without hitting OOM events.
Really, really convinced this style of tooling is the future however here are some issues we are running into:
* 4s full page refreshes
Much slower that when Webpack finally gets going. If I'm working on something that may require lots full-page loads I'll opt for CRA.
This is in part to do with the sheer number of source files. Part AFAIK they aren't using a strategy such as a Merkel tree to keep track of which import chains are actually invalid and instead re-request every file every reload.
Part is SCSS which is a super, major PITA performance wise on a project of this size. Vite doesn't yet support embedded SCSS, and embedded SCSS doesn't support process reuse so it may not even work well with this dev server strategy.
* HMR objects
Editing certain(mostly non-component) code will cause duplicate class names to be created: MyClass2, MyClass3, and etc. Vite seems to use a different strategy than Webpack which, I believe, use proxy objects.. In any case these can cause "instance of" and other failures that trip people up and send them on wild bug chases.
* Weird optimization requirements
In your project's src importing from folder index files is considered harmful to Vite performance.
When importing from node_modules NOT IMPORTING from the base index is considered harmful to performance!? It will not optimize deep import deps automatically(pre-bundle and browser cache them).
=========
Even though I'm convinced this is the direction of dev tooling I'm not sure Vite will be the winner here. I can't help but feel entire server should be written in a language such as Go, and a better incremental build and delivery strategy needs to be in place. A strategy so that the browser only needs to request the files that have changed while going to cache directly for everything else. Otherwise very large projects will continue to be problematic.
Yeah, lazy loading components but that's not always desirable particularly in single page "apps".
Have you tried using plain esbuild and sass in watch mode? That was what gave our app an immense speed boost.
I’ve seen some of the same issues you have, with large entrypoints causing slow pageloads due to the number of source files, but fortunately not that large yet. Manually splitting the app into multiple smaller entrypoints have helped there. If HMR wasn’t so useful I would just have used raw esbuild instead, though.
* 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's fast" is not going to sell me on a build tool. Make files are fast too. What we learned with the evolution from Gulp/Grunt etc. to Webpack is that you need to find a sweet spot between zero config and full config. The "batteries included" approach works until it doesn't, and for small projects I'm sure it's fine. But every large project inevitably ends up with all kinds of snowflake config that Webpack handles really well, while also having a robust plugin ecosystem with standard defaults.
It's one of the software that is the easiest to move to. For the vast majority of people, you go from a 150 lines Webpack config to a 15 lines Vite config, possibly the default values.
It is kind of incredible. They've found "a sweet spot between zero config and full config" you are mentionning.
Hey. If you're hear to post about how the web is always changing, and it's so complicated, no one cares. It's been posted 20 times by now and there are good reasons (we build much more complicated webapps these days).
I like Vite. A few things I like:
- Super fast
- Works out of the box (like parcel)
- Even production builds are super fast -- this is a bit of an underrated feature because sometimes things only break in prod builds, so having fast prod builds = more frequent prod tests = better
People here love to complain about frontend, but the speed and outreach people can have with modern webapps beats desktop applications by a mile. There is a reason billion dollar companies like AirBnB don't use desktop apps.
Speed gains aside, it's pretty great, though I did have to provide a manual path to node_modules/some_package_here because it wouldn't serve those files in dev mode. On my computer alone. No one else. Guess I had a weird setup.
It has many years until it turns into yet another bloated "builder" if you could call it that
Overall, I continue to be impressed by whatever these guys (it's not just Ewan) do even it's getting hard to keep up at my age.
I'm a sceptic to the claims; most build speedups I've seen come from the bypass of Typescript type checking/compiler errors. Since there is no other competetive compiler to Typescript than the official (and slow) tsc, I think vite works this way too? Getting hot reload and fast page refreshes is nice, but the idea is that if I get a compiler error, I ought to fix it first before I move to the browser to test my code.
Actually most webpack config guides also recommend you to start Typescript checker in separate thread(there is plugin for that) and don't block compilation(transpile mode).
But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.
I still don't get it. If I assume that Typescript compiler is the slowest component in the build pipeline, and run it in a separate thread, that still means I have to wait for the tsc to complete. There is little to no benefit in all the other stuff being finished faster; that will be optimizing the 5%, while my main time is wasted in the 95% of the tsc compiler process. At least to my experience, for sufficiently large projects, tsc becomes super slow.
> that still means I have to wait for the tsc to complete
Without fork it. the webpack need to wait the checker to finish checking everything before it compiles even just one file.
With a separate checker, it don't.
The ts-loader will eject a perfectly normal js file without caring the typing is valid or not. And webpack can do the rest of works as quick as possible.
It like different of do it in serial and do it in parallel. The latter will utilize the resources better although not absolutely more efficient.
F*king hell the ecosystem just never stops growing. Vite, Rollup, HMR? What the f*k is all this? Why does building a frontend have to be a titanic project involving a hundred tools including build systems and tree shakers and compilers and whatever else is going on. Web development is an embarrassment and a blight on computing.
Perhaps you should take the time to find out. Many of the things you mention create a development experience that is pretty cool. It allows you to dynamically change your code and instantly see the result. I do backend systems, embedded systems, and have done a lot of native UI apps.... modern web development with things like vite and vue are really quite nice in comparison. The development feedback loop is very quick
I've used Vite in a simple vuejs project and love its simplicity over webpack.
However, debugging Vue3 with hot-module-reload seems to be broken. The moment HRM changes a source file, the line numbers and breakpoints not always line up and breakpoints. (https://github.com/vitejs/vite/issues/5916). 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 :)!
I know everyone is here to complain about the mess that is "modern" frontend work. But I have to say, I started using Vite a week ago to bootstrap a new project using Typescript, Preact, and Tailwind, and I'm loving it. There is one weird quirk in where it insists the index.html file should be. But if you can live with that, Vite takes care of the details for me and gets out of my way. It also bundles everything exactly how I would have set it up by hand. I think it's weird that it insists its mostly a dev server. It does that well. But it's also a very good bundler with good defaults. I'd recommended it to anyone who just wants to get started, and wants a good middle ground between esbuild and parcel.
I am feeling like this era of frontend javascript is too much focused on tooling and frameworks that developers spend most of their time dealing with complexities associated with them rather than focusing on creating something meaningful and useful.
Actually, you can just run 'npm init vite', choose a plain js starter, and make something 'meaningful and useful' with an awesome dev server and great bundler once you are ready to go live.
So I just streamed myself taking vite for a test drive. My thoughts:
- Very fast to reload
- Seemed pretty damn simple and non-magical. Your main code doesn't get transpiled, just your dependencies.
- IMHO the scaffolding stuff was superfluous, at least for vanilla JS. I'm a minimalist and it initially turned me off, but then I discovered it was basically just a thin wrapper around the `vite` binary. Will probably just install vite as a dev dependency and go from there next time.
Over all a positive experience and might end up re-using it.
Vite is kind of nice because it weaves together some more modern tools, but if you're doing something simple, you might be able to just use esbuild directly on it's own. Bonus: if you're writing Go software, you can use esbuild's (slightly cumbersome) Go API directly in your app server and avoid needing to have JS tooling in your serving/building path, just using Node to handle things like JS package management, typechecking, and linting.
I yesterday migrated our Laravel project from Laravel Mix (which uses webpack) to Vite (https://laravel.com/docs/9.x/vite), and couldn't be more happier.
Earlier, webpack took 3-4 seconds to re-bundle on file changes when running npm run watch (It is a quite large typescript + react project). In Vite, it is less than 300ms. And, React Hot-Reloading is awesome.
So is it safe to say that this tool is mostly trying to solve the developer experience side of front-end development, instead of trying to create a "new" technology such as SSR?
I've just mostly seen "fast" and "HMR" as the features of Vite, but I can't see a team switching over an entire project just to solve something that was probably decently "solved" to begin with.
I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.
Sorry but if it requires NPM then I am not interested. I have been burnt too many times to want to use anything related to NPM.
I would hope that a next generation framework would not have hard dependencies on the cess pit that is NPM :(. Please give us something fresh and interesting.
This is why I am so excited by deno on the backend - finally no more NPM!
Am I alone in that I don't webpack or otherwise bundle anything until I deploy? If I'm building a large typescript project, I just run it directly out of source JS and CSS files on my dev server. Only when upgrades are finished and tested do I bundle them and put them on the production server.
I switched from CRA to Vite for create-rust-app[1]. If you ever needed to bundle JS/TS in an SSR framework (language agnostic), vite is a great choice :)
how does this benchmark against doing back end development with any language and pushing vanillajs (standard javascript) to the browser? whats the big difference and why should anyone want to make this more abstract/complicated? is it trying to reduce development time?
Plain JavaScript is of course faster. Not doing something is always faster than doing something. But highly interactive web apps have some problems that need to be addressed:
First is syntax extensions: TypeScript (a strictly type JavaScript superset), JSX (a syntax extension for describing DOM nodes popularized by React) and special template syntaxes of other UI libraries/frameworks like Vue and Svelte need to be processed before being sent to the browser. You may also need processing to iron out some of the incompatibilities between JS engines but it's less important nowadays since the IE died.
The second problem is the sheer size: Highly interactive web applications have lots of moving parts. For example at work, my company's product's frontend code contains 4709 modules, roughly 3/4 of which are 3rd party libraries. At this scale you need some level of optimization (like eliminating unused bits of the libraries) and the ability to split the bundled code into chunks depending on what pages they are used.
No offense man I can’t really tell what this is… hmr and dev tools cli with a new transpiler?… it’s not next generation it’s a patch/minor upgrade to current generation tooling and it comes with a [extremely] major upgrade to swap it with whatever is currently used.
I can’t find a vite solution for NodeJS which is disappointing. If anyone has figured out a way to ship the minimal amount of code from a NodeJS monorepo (ideally with web and server code, but generally decoupled) I’d enjoy seeing the solution!
I'd recommend using ESBuild directly. The following article helped me recently to figure out how to build a browser-side library to publish to NPM, as well as bundling a Node.js server to deploy.
Build A Library With esbuild - How to bundle ESM, IIFE or CommonJS libraries with esbuild
It's possible. I often use vite with multiple build targets (decoupled but with code sharing) .. this can be specified in the rollup config options but my specific build process uses two separate vite configs to resolve some chunking challenges. Everything is parallelised for dev/build in an npm script. From memory there's a bunch of conversations relating to this kind of setup in the GitHub issues.
Edit: vite allows you to specify (e.g. node specific) exclusions/globals in the config, it also allows you to specify a 'library' build if that's what you're interested in .. with named exports, etc.
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.
This is excellent! The frontend ecosystem in general has been very stagnant for years, without much innovation or experimentation. Great to finally see a new library for frontend development come along.
There is no way I'm leaving webpack after those 100 years of frustration and pain. Now that I have reached an almost mediocre level of understanding of it, I am never letting it go.
I don't know much about parcel, but Vite has incredible mindshare.
Except react and angular, all other leading js framework authors are on vite eg: vue (obviously), solid, svelte,astro,qwik etc.
With framework authors siding with vite, it is natural that those framework users will be switching to vite as well.
Vite is gaining popularity in react community as well though not too much because of some issues with commonjs libraries. It is expected to have very bright future.
I found Parcel and Snowpack years ago, before Vite, because I knew an integrated and ESM-based system was the future.
Both were incomplete and buggy, both had tool combinations that they just couldn't handle. I've forgotten the details but from the tickets I was reading, I doubt that's improved.
Vite solves all of that, it's incredibly easy to work with and I never have problems with it. For a fairly esoteric frontend situation, too.
I just use esbuild with a small script to build things to my likings. It has worked wonderfully and infinitely better than all other build setups I've seen people do.
Compilation/transpilation is only part of the work traditionally being done by build tools like webpack and parcel (well, webpack offloads the work to babel or similar). I believe that a lot of the speed or perceived responsiveness with Vite comes simply from not bundling the code during development.
For a long time front end tooling has been bundling your dependencies and code into one or more bundles each time you save your code and then that gets shipped to your browser. Vite on the other hand just transpile the changed module(s) and then ship that over to the browser. This works great because browser support ES modules and module resolution natively now.
I get your frustration: only being partially invested in front-end web dev, the constant churn of what people consider viable stacks, techniques and architectures can be maddening. It can all seem like a race to implement the hottest javascript du jour in some finicky framework or library while sweeping inscrutable, increasingly complex webpack implementation details under the rug... until they pop out, or the rug catches on fire, or the floor gives out, or any other inevitable thing happens that precludes ignoring them.
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.
You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.
I downvoted it. I did so because, IMO, the comment is superfluous noise seen on every js thread. A tool exists to solve a problem, if you don't understand why it was built or don't like it, that's ok, but the hackneyed complaining about open source software merely existing deserves to be at the bottom of the thread.
I'm not the grandparent poster but I'll ask the question in a non-superflous way:
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.
The reason frontend dev moves "So quickly" is because of new browser developments & capabilities. Esbuild & vite are currently popular because they are one of the first build tools to fully utilize browser ES Modules. This is fundamentally different than what webpack does. Webpack was solving a Pre-ESM problem, "how do we modularize frontend code?" and as such as taken on a lot of bloat to solve this problem which has largely been solved by browser ESM.
> 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?
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].
I think it's a fair argument but I guess time will play it out to see if it succeeds. It's a bit of a chicken and egg thing, like with most newer open source projects intended to replace older ones. To take off, you need contributors. If you can't get contributors, it won't take off. The value add needs to be strong enough to attract enough developers to overcome the Rust/Go hurdle. I'd wager more on Go in this regard, for your average developer not having to worry about garbage collection is probably going to be a significant plus.
It is better. Why are so many people determined to dismiss it on the basis that "things are so bad that we shouldn't try anything new"? That's totally backwards. In a situation of many bad alternatives, searching for new alternatives is the solution, not the problem.
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.
I'm not against new tools, we should absolutely embrace innovation. But show me how it's better, don't just make some claims with no evidence and expect me to buy into it.
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.
Yeah it's just wild. I don't ever remember seeing this level of.... sideways.... churn before. Feels like it's been absolute mayhem for close to ten years now.
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.
I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there!
Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space.
(Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster")
It’s easier for some to just be prescribed a specific SDK.
This is a little bit insulting. Nobody wants to "be prescribed a specific SDK" - there's a large middle ground between that, and the current situation which has been chaotic for nearly a whole generation.
I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.
Javascript UI frameworks last longer the Microsoft UI frameworks. It's not like a newer framework is just replacing an old one because of hype. React/Vue are massive improvements over Angular 1.
To be completely fair, changes occur way too often even when the name doesn't change. I tried to find a nice component library for starting out with Vue after not doing any frontend or JavaScript in years (I kind of quit when JSPM, the package manager, was hot).
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.
Which web framework has been the frontrunner for 7 years? jQuery?
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.
NPM download stats paint a more accurate picture. I didn't include jQuery because it's not a framework. (React calls itself a view library, but it's definitely a framework.)
I find it really funny that the word "javascript" doesn't appear anywhere on the entire first landing page. You have to click into "Why Vite" and then about 1/2 way into the first sentence, then you see "javascript"
I was wondering "exactly what kind of front end?" C? C++? Swift? iOS front end? some kind of GUI framework? Windows app development?
Modern day Javascript web ecosystem is a nightmare.
With respect, this suggests to me that you haven't actually read about how Vite works. It's not aiming to be just another contender, it sort of positions itself as a "best of both worlds" abstraction layer on other tools, whereby esbuild is used for faster compilation and rollup is used for configurable builds. It's not as drastic of a change as you're making it out to be, unless someone is coming from like a Gulp-based setup or something.
My work uses Webpack 3 and 4 (in a monorepo) and I was able to get Vite up and running on a test branch (as a sandbox) within a day, even though it's using roll-up instead of Webpack and even though our code was pretty old. It compiled in like a few seconds, it was wild.
"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…