HMR is nice, but the added complexity seems to make basic stuff like sourcemaps support difficult. Would be nice to have something that adds HMR with the flexibility of a custom build stack(esbuild + a better livereload)
Vite 3.0
171–180 of 202 posts
Re: Vite 3.0
#172Quoted post unavailable.
No post body was provided.
Re: Vite 3.0
#173Earlier quoted context omitted.
>I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML... We did. But people without real problems to solve will continue reinventing the wheel, while we silently churn away on actual products with stable tooling.
This comment and the parent's tells me that neither of you know what vite does or have used it before, if you're implying that it's not fixing "real problems." Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."
>Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."
I've worked on projects with hundreds of thousands of LOC compiling with Webpack. Build time has literally never been a concern for me. The entire point of tooling like Webpack is that it's written in JS because dealing with interop between native binaries is an absolute nightmare. It's a feature, not a bug. The same reason we moved to JS based SASS/PostCSS compilers.
Re: Vite 3.0
#174React Context HMR still has problem. Due to this problem, I think nextjs still the better choice for react dev. Maybe vite supports too many frameworks, do not have enough time to handle the react problems. [1]: https://github.com/vitejs/vite/issues/3301
That issue is disappointing. It's an important issue for making React work, it's been open for over a year, and there isn't any comment from someone who works on vite or the plug-in.
Re: Vite 3.0
#175Earlier quoted context omitted.
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels. If you just want esbuild + hot reloading then dev-server-esbuild might be a good option: https://modern-web.dev/docs/dev-server/plugins/esbuild/ But really vite isn't much more compl…
At least for a small site, you don't actually need a plugin to get hot reloading using esbuild: "scripts": { "build": "esbuild src/app.ts src/app.css --bundle --sourcemap --outdir=site", "dev": "npm run build -- --servedir=site", } Unless you mean something different by "hot reloading" than "recompile on page reload?"
No tools like vite will detect changes, rebuild/bundle/transform, and then inject the changed HTML, JS, and CSS into the page you're viewing automatically. They work by injecting a script into the HTML they serve which connects over a websocket or SSE to monitor changes and slurp them up when notified by the dev server.
It's really a magical experience to have your code open in one window, your browser open next to it, and as soon as you hit ctrl-s instantly see the page change. I won't tweak CSS any other way, changing sizes, colors, etc is amazing with hot reload.
Re: Vite 3.0
#176I can't keep up with this stuff anymore. As a former "full stack" dev, I just quit the frontend part altogether and I'm now just focusing on the backend. It's just too much and changing too fast.
What technologies are you working with on backend? I'm pondering to abandon frontend too.
.NET Core. Always pondering between Razor templates generated on the backend vs front-end templating frameworks.
Re: Vite 3.0
#177I tried using ESBuild directly for a small web app and it seems pretty nice. What would using Vite on top of it give me?
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels. If you just want esbuild + hot reloading then dev-server-esbuild might be a good option: https://modern-web.dev/docs/dev-server/plugins/esbuild/ But really vite isn't much more compl…
Esbuild works just fine with browsersync proxy. Simpler approach.
Re: Vite 3.0
#178The landing page of Vite claims "Next Generation Frontend Tooling" but then go on to describe features that already have been existing for a good while (multiple years). What exactly is the "next generation" part here? The composition? That's also not new, so I think I'm either missing something very obvious, or they need to do a better job explaining how Vite is actually different.
Vite bundles your app for prod, but not for dev. While all previous ones, bundled for both dev and prod. This is what makes vite a different generation. And results in massive performance boost for dev "build" And HMR
Replying to emphasize this comment...
For dev, vite _doesn't_ bundle, it sends your site basically unmodified (as individual files) to the browser since most browsers are already capable of running anything you're using anyway... so if you change one file, that one file is patched, not the whole bundle that depended on it..
since there's no bundling, the initial start time is nearly instant...
webpack hot reload is NOTHING like this hot reload
Re: Vite 3.0
#179Earlier quoted context omitted.
Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro) React falters because there are not many community contributing towards react integration. Note: Vite team has done their job for react, but react itself has many concerns particularly due to commonjs that a dedicated person (or team) is needed for react
>Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro) This is like saying NPM is language agnostic. Sure, technically it is. But we all know what it was built for and what the community is geared toward.
This analogy is plain wrong. The blog post lists multiple non-Vue frameworks/tools using Vite as their default build tool. Compare that to the number of non-JS languages (excluding ones that compile to JS) using NPM as their default package manager (0).
Re: Vite 3.0
#180Question: Is Vite really a serious tool built for production apps? The design decisions don't give me confidence. As your app starts to grow, you'd definitely not want 1000s of modules loading in your browser. Seems like something that gets you from 0-60 quickly, and becomes a pain after. Similarly, the different choice of bundlers in development and production would well lead to difference in behaviour / hard to cat…
Shopify is using it with React. Lavarel now adopted it. It's the default for Vue projects going forward (given it's made by the person who made Vue). Plenty of serious support behind it. Not sure how you'd end up with "1000s of modules in your browser", unless you have some mega-project with an unwieldy package.json. I have a pretty complex Vue project app and it loads I've found it to be way faster than Webpack for…
> 1000s of modules in your browser
Isn't very uncommon with large scale apps (1M LOC +)