Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vite 3.0

vitejs.dev

Post reply on HN
Print view View original

141–150 of 202 posts

Re: Vite 3.0

#141

Post by s1k3s »

skrebbel wrote: post #138
s1k3s wrote: post #131

Earlier quoted context omitted.

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, th…

> We tell them that they're free to do something about it.

Ha, this is actually a good idea that I didn't consider. I'll push for this, thanks!

Re: Vite 3.0

#142

Post by pastelsky »

no_wizard wrote: post #23

I know that this is all about Vite but if you like Vite, I want to give a shout-out to Parcel[0] as well. Its a very similar philosophy, built on top of SWC[1] and has its own set of great optimizations. I've regularly gotten smaller overall bundle sizes with parcel than with Vite (though that gap is very narrow now) in my experience. I wish Parcel got more mention, especially in the React community (where it shines…

I really like the defaults Parcel comes with, it is very quick to get started with Parcel.

However, the promise of zero config is made possible in part by "magic" (strange conventions), and by having configuration spread across multiple files (package.json, . parcelrc, custom plugins which for some grave reason you can't use until you publish them to npm)

I really wish Parcel had sane configuration — I want to like it so much, but alas, it falls pray to the pendulum effect.

Re: Vite 3.0

#144

Post by pastelsky »

Question: 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 catch bugs.

Re: Vite 3.0

#145

Post by rk06 »

s1k3s wrote: post #132
rk06 wrote: post #130

Earlier quoted context omitted.

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.

People back out because you are not using new tools? Or because you are using old tools and are not willing to upgrade?

Well, there are cobol devs for hire. So, tech alone is not sufficient to drive away all potential hires.

There might be other red flags

Re: Vite 3.0

#146

Post by ForSpareParts »

s1k3s wrote: 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 really do believe this is getting better -- though not at a rate where it's obvious yet if you aren't plugged in.

A few years ago there were tons of frameworks and they all worked a bit differently. New shit every week. IMO that's because no one had really figured out the right paradigm yet. Now we have (it's components) and the framework race has slowed way down (it's pretty much React, Vue, and Angular now). Even big changes in React like Hooks didn't break backwards compatibility. You can move pretty slow and steady on that front, if you want to.

Tooling is the next frontier. It's become obvious that compiling js in js itself is just not performant enough for large applications. We need a faster solution. There are a few contenders right now (esbuild, swc, bun; vite wraps esbuild) but I suspect within two years we'll have a pretty clear winner.

In general I think things move faster when we haven't found the right ideas yet, and that's why backend is more stable -- it's just older. There has been more time to iterate and figure out what works and what doesn't. Frontend will probably always be more chaotic than backend, but I think it'll be much less so as we start to agree on the web want it to look like.

Re: Vite 3.0

#149

Post by ForSpareParts »

pastelsky wrote: post #144

Question: 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…

It serves unbundled for development and bundled in production. In practice this works pretty well as long as you do decent code splitting (and you should be doing code splitting!)

Edit: lol I should have read your post more closely. Yes, the different strategies can cause bugs; there's much more shared between the two pipelines than there used to be so this situation is improving. We actually had really bad compatibility with problems six months ago and it was still easily worth the trouble for the performance improvement.

Re: Vite 3.0

#150

Post by rickbergfalk »

pastelsky wrote: post #144

Question: 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…

Yes. Currently using it in production and couldn't be happier.

The individual modules are only served during development, but even then startup/load is faster than our previous webpack setup by an order of magnitude. When you build for production, you still end up with a bundle like you had previously.

Post reply on HN