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…
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.
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.
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"
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.
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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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".
[+] [-] krick|3 years ago|reply
"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…
[+] [-] kossTKR|3 years ago|reply
I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, an expert og know your way around the codebase before you're suddenly 2 years behind.
It's a shitshow and no one really seems to know what the hell they are doing - even the teachers of this stuff - they just know "how" rarely why.
Way, way too much complexity and abstraction for simple tasks. Some things "should have" become easier with quick scaffolding, auth templates or whatever, but they always only work 95% and you use an endless amount of time fixing the last 5% instead of building creatively.
Vite was the same thing, faster yes, but my VSCODE broke because of the myriad of build tools and plugins on top of each other from older projects.
[+] [-] rvdginste|3 years ago|reply
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.
[+] [-] vultour|3 years ago|reply
Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.
[+] [-] wonnage|3 years ago|reply
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.
[+] [-] Nu-biscuit|3 years ago|reply
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.
[+] [-] darksaints|3 years ago|reply
It could still do without the framework of the month trendiness, but eventually dumb ideas die and good ideas succeed.
[+] [-] qudat|3 years ago|reply
Don't get into devops/infra if JS fatigue is an issue: https://landscape.cncf.io/
[+] [-] devxpy|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] zmxz|3 years ago|reply
Frontend dev here. Vite is amazing. It doesn't take long to get what it does if you try it out (you can avoid reading about it that way).
I won't bother summarizing what it does, the website literally covers it. Reading really became superpower in this day and age.
[+] [-] jbrooksuk|3 years ago|reply
The speed gains are super impressive from Vite.
[+] [-] omarhaneef|3 years ago|reply
Why?
Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else.
The features don’t help: it’s fast. That could apply to anything.
It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what it does. That’s several clicks in to figure it out.
Please put what the thing does front and center.
[+] [-] mgomez|3 years ago|reply
[+] [-] sascha_sl|3 years ago|reply
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.
[+] [-] raverbashing|3 years ago|reply
And next week there will be yet another "revolutionary" front-end thingamajig.
Edit: the "why" page mentioned by the sibling comment actually explains it
[+] [-] chrisan|3 years ago|reply
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.
[+] [-] exhaze|3 years ago|reply
- 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?
[+] [-] darkest_ruby|3 years ago|reply
[+] [-] hardwaregeek|3 years ago|reply
[+] [-] dclowd9901|3 years ago|reply
[+] [-] dimgl|3 years ago|reply
[+] [-] ta-run|3 years ago|reply
[+] [-] edvards|3 years ago|reply
[+] [-] candiddevmike|3 years ago|reply
Can I just use esbuild yet?
[+] [-] Escapado|3 years ago|reply
[+] [-] QuadrupleA|3 years ago|reply
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.?
[+] [-] christoph|3 years ago|reply
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.
[+] [-] mmcnl|3 years ago|reply
[+] [-] selfmodruntime|3 years ago|reply
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.
[+] [-] sachinraja|3 years ago|reply
[+] [-] woojoo666|3 years ago|reply
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.
[+] [-] ggregoire|3 years ago|reply
[1] https://news.ycombinator.com/item?id=31969345
[+] [-] selfmodruntime|3 years ago|reply
[+] [-] canyonero|3 years ago|reply
IMO when paired with Vitest, the setup feels powerful, modern and lean. Would recommend.
[+] [-] nchudleigh|3 years ago|reply
Definitely the build tool I reach for by default now
[+] [-] synergy20|3 years ago|reply
Evan You did this after his vuejs work, it's kind of like Linus did git after his linux kernel work, well, on a smaller scale. Per Linus, he did git to approve that he is not an accidental one time genius.
[+] [-] simlevesque|3 years ago|reply
[+] [-] bladegash|3 years ago|reply
Made the switch after some frustrating behavior coming from CRA and having zero flexibility with configuration.
As a side note, Vitest is fantastic as well and I highly recommend giving it a try.
[+] [-] sandreas|3 years ago|reply
1: https://kit.svelte.dev/
[+] [-] sk0g|3 years ago|reply
[+] [-] gedy|3 years ago|reply
npm create vite@latest my-app -- --template svelte-ts
[+] [-] pragmatic|3 years ago|reply
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.
[+] [-] gtm1260|3 years ago|reply
[+] [-] nullwarp|3 years ago|reply
Contrast that to my usual dealings with Webpack I couldn't be happier.
[+] [-] candiddevmike|3 years ago|reply
[+] [-] NaN1352|3 years ago|reply
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.
[+] [-] Rapzid|3 years ago|reply
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".