Live data from Hacker News

Vite 3.0

vitejs.dev

131–140 of 202 posts

Re: Vite 3.0

#131
post #94

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

Our frontend is mostly class-based react components compiled with webpack 4 and babel 6 (for context: those are old versions). and guess what? it all just works. new 3rd party components also just work. adding modern hooks-based functional components just works. and everything that worked 5 years ago still just works. I think the JS our tooling emits is backward compatible with IE9 and up, which is ridiculous and was…

That's fine, but what do you do when your applicants back out of the hiring process when you tell them you use React 15? I guess all we can do is upgrade, specifically for this reason.

Re: Vite 3.0

#132
post #130
post #94

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

You don't need to keep up with this stuff. Just need to be aware that these tech exists and evaluate them when need arises. In many companies, you won't be tinkering with vite at all. The build person will do that, you will be reaping the benefits of it only.

People back out of the hiring process because we don't use new stuff. This really is a problem for us atm.

Re: Vite 3.0

#133
post #94

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

I was just telling my friend yesterday that after a decade of full stack I just don't feel that I can do it anymore. Serverless, bundlers, frameworks, CI / CDs, virtual doms, non-virtual doms, semi-virtual doms, JSON responses, HTML responses, SSR, UI / UX... on and on and on. I have to go through documentation for at least 3 of these things and mush my brain until product decides that that feature is not worthwhile…

Exactly. My favorite part is how they discover stuff like "SSR" and "serverless" now, both being concepts as old as the web.

Re: Vite 3.0

#134

Earlier quoted context omitted.

Parcel has been praised on here many times when it originally came out. I was an avid user but the nail in the coffin was the horrid and long release of v2 which took forever, the docs were in disarray, and overall just left a bad taste in my mouth. I also think there was some common issue where v1 didn’t support some version of postcss for quite some time and I and many others jumped ship to vite.

One other thing is that is was "zero config". While everyone likes the idea of "zero config", in reality there are some things you will want to configure. It drove me up a wall with Parcel where I wanted to do X but couldn't and had to do Y instead because there was no way to configure parcel to make X work, not that X wouldn't work with Parcel, there's just no way to configure anything and you're at the mercy of "go…

Ironically, Parcel is the only build tool that ever forced me to change my IDE configuration to [get file watchers to work](https://parceljs.org/features/development/#known-issues-with...). If other non-zero-config tools don't require this to be changed, I'd expect a tool focused on zero-config to support this.

Vite on the other hand hasn't had any such suprises so far.

Re: Vite 3.0

#135

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

As someone who has worked in a lot of frontend (Vue, react, various microframeworks) I would heavily disagree that the tooling is "stable". It's incredibly fickle and breaks in ways that are hard to debug. Microframeworks are slightly better, especially if they support no-build setups since then a "build step" for prod is only bundling and minification.

[deleted]

Re: Vite 3.0

#136

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

What I think they are referring to is the bundler is built with Go/Rust rather than JS (like Webpack). The difference in speed between Webpack and any bundler built in Rust/Go (SWC, Vite, Parcel, etc) is that the latter are like 10X faster, not "this is building faster" but "how the hell did it build this quick". That difference in speed is what I think of when they refer to "next generation".

Vite is not built in Go, esbuild is. esbuild is not the only reason why it's fast either, see https://vitejs.dev/guide/why.html.

Re: Vite 3.0

#138
post #131

Earlier quoted context omitted.

Our frontend is mostly class-based react components compiled with webpack 4 and babel 6 (for context: those are old versions). and guess what? it all just works. new 3rd party components also just work. adding modern hooks-based functional components just works. and everything that worked 5 years ago still just works. I think the JS our tooling emits is backward compatible with IE9 and up, which is ridiculous and was…

That's fine, but what do you do when your applicants back out of the hiring process when you tell them you use React 15? I guess all we can do is upgrade, specifically for this reason.

We tell them that they're free to do something about it. It's not uncommon for our newest hires to find some itch that was better in a previous job and make our setup better accordingly. They'll soon find that there's much more exciting stuff to work on but it's a good first or second task.

Note that we're on React 17 now - 15 to 16 was hard but 17 was largely backward compatible. I expect 18 will be worth it too, the breakage is tiny. Like I said, React's backward compat story is real nice IMO :-) (and so is the tooling to help you address breaking changes)

Re: Vite 3.0

#139

Earlier quoted context omitted.

Why so?

If you care a little bit about those critical / major security vulnerability alerts, and are working with NPM professionally, I shouldn't need to answer the question. If you are not, it's because NPM moves very fast, you can lock in your dependencies but soon enough they'll start signaling vulnerabilities.

We check out all these reports but in 99% of the cases it's something like "if you pipe user data into to this command line tool, then it's hackable!!" and said tool only gets used by our build toolchain and not by runtime code, so no user code ever gets piped there. We've not yet run into a must-upgrade dependabot vuln that was also non-trivial to upgrade to because of the infamous (but, to our experience, untrue) NPM dependency hell story.

Re: Vite 3.0

#140

> Vite is powering a renewed innovation race in Web frameworks. Wait what, again? 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...

The description is maybe a little misleading. Vite is a development experience improvement for existing frontend frameworks; most people using it are on React or Vue (which is the other of the "big 3" along with React and Angular). It's about making projects build and start faster.
Post reply on HN