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

151–160 of 202 posts

Re: Vite 3.0

#151

Post by dmix »

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…

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 dev build times which is all that really matters to me.

Re: Vite 3.0

#152

Post by ForSpareParts »

FinalBriefing wrote: post #2

I had no idea so many other frameworks are using Vite as their default. Event server-side frameworks are picking it up! Has Webpack really been dethroned as the go-to bundler?

Webpack really messed up IMO -- v5 took a really, really long time to drop because they were making huge changes ostensibly for performance... and then when it came out it actually made performance worse for many projects. I think they've fixed that now, but the damage is done.

I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next winner in the space will be something like vite that uses a compiled language under the hood (vite uses esbuild, which is written in Go).

Re: Vite 3.0

#153

Post by sph »

papruapap wrote: post #40
sph wrote: post #37

Earlier quoted context omitted.

Because that's the meaning of major version number. Additionally JS/npm modules are supposed to follow semver, and you increment the major version when you break compatibility. I get it, Linux does its own thing with versions, and so do browsers, so it's hip to just increment major whenever you feel like it apparently. EDIT: LOL at people downvoting GP because they dared to wonder if the frontend world needs another…

How do you know they use semver? Major version is just a marketing thing for many frameworks. Node is one of them too. Even Go, one of the most boring (in the good sense) languages, considered to do the same thing at some point (when included generics).

It's not a "marketing thing". The whole version requirement syntax in package.json (i.e. "^1.2.3") and other non-JS package managers really only works if a package follows semver, so that's the reason 99% of JS packages do.

This is why when you npm add a dependency it defaults to the "^1.2.3" syntax, which means the dependency is upgradeable to the next minor version, which, as SemVer states, should be guaranteed to be backwards compatible.

Of course you can just disregard that, make breaking changes whenever you want and annoy your users enormously.

https://docs.npmjs.com/cli/v8/configuring-npm/package-json#v...

https://docs.npmjs.com/about-semantic-versioning

AFAIK Go doesn't follow any kind of versioning scheme (since they don't use a versioned module manager), but the project itself is semver-compliant. No breaking changes are introduced since Go 1.0 was released. The proposals for breaking language changes will be planned for Go 2.0. Generics aren't breaking old code.

There is no reason, unless your name is Linus Torvalds or you're marketing driven such as your browser, not to follow Semver. It's a good and simple idea.

Re: Vite 3.0

#154

Post by NonNefarious »

qorrect wrote: post #61
enw wrote: post #39

Earlier quoted context omitted.

That’s what semantic versioning is: https://semver.org/ https://docs.npmjs.com/about-semantic-versioning

What an asinine interpretation. No thanks.

I agree. It's up to the publisher to decide the significance of version numbers. Just because Node does it one way doesn't mean everyone else has to follow suit.

Re: Vite 3.0

#155

Post by sph »

dannyphantom wrote: post #123
arthurcolle wrote: post #74

Earlier quoted context omitted.

are you French? means quick in French

Both Italian and French, actually! Family is from NE Italy :)

It just means "screw" or "grape" (the plant) in Italian. The French "vite" would be "veloce/velocemente".

Re: Vite 3.0

#156

Post by capableweb »

collegeburner wrote: post #11
capableweb wrote: post #3

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.

Vite is way faster and takes way less config. We been using it in prod for almost a year now and it's just way better. One of the few new js tools thats actually better and doesn't just exist to get stars on github and pad a resume.

> Vite is way faster and takes way less config

That sounds like "incremental improvement", not "next generation tooling". But maybe my expectations are too high.

Re: Vite 3.0

#157

Post by dmix »

ForSpareParts wrote: post #152
FinalBriefing wrote: post #2

I had no idea so many other frameworks are using Vite as their default. Event server-side frameworks are picking it up! Has Webpack really been dethroned as the go-to bundler?

Webpack really messed up IMO -- v5 took a really, really long time to drop because they were making huge changes ostensibly for performance... and then when it came out it actually made performance worse for many projects. I think they've fixed that now, but the damage is done. I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next wi…

For me using Webpacker with rails was a nightmare in the last two years.

The move to 3->4 was painful as 25% of my projects started to move to 4 and no longer worked with 3. So I was stuck with some legacy packages during a time I was upgrading from Vue 2 -> 3. AFAIK they Rails didn't even get to Webpack 5 in practice by the time I left.

Vite came to the rescue at a perfect time.

Re: Vite 3.0

#158

Post by dmix »

capableweb wrote: post #156
collegeburner wrote: post #11

Earlier quoted context omitted.

Vite is way faster and takes way less config. We been using it in prod for almost a year now and it's just way better. One of the few new js tools thats actually better and doesn't just exist to get stars on github and pad a resume.

> Vite is way faster and takes way less config That sounds like "incremental improvement", not "next generation tooling". But maybe my expectations are too high.

That's a fair assessment. You could argue esbuild which it's built on is 'next generation' in terms of JS tooling, with how it integrates with ESM and HTTP2. But in practice this is basically Webpack 2.0 (not v2, but the evolution of it).

Re: Vite 3.0

#159

Post by 5e92cb50239222b »

_fat_santa wrote: post #99
FinalBriefing wrote: post #2

I had no idea so many other frameworks are using Vite as their default. Event server-side frameworks are picking it up! Has Webpack really been dethroned as the go-to bundler?

> Has Webpack really been dethroned as the go-to bundler? At this point yes. I'm sure there are still some things that you will need Webpack for, but in my experience I have yet to find one of those instances. Vite is not just way way way faster than Webpack, it's also way simpler. Configuring a React project from scratch with Webpack is an undertaking, especially if you're not seasoned with Webpack configurations. V…

> Configuring a React project from scratch with Webpack

Why do people do this? I've always used the official way (CRA), and never had any issues with it. If you need to adjust webpack configuration, there are third-party packages that work very well in practice (like craco). Yet reinventing the wheel over and over again seems to be popular.

https://create-react-app.dev/docs/getting-started

Re: Vite 3.0

#160

Post by nobleach »

b0afc375b5 wrote: post #28
skybrian wrote: post #25

I tried using ESBuild directly for a small web app and it seems pretty nice. What would using Vite on top of it give me?

I was curious as well. I think this answers the question: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... > While esbuild is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards.…

Using the same tool for prod building is really a value-add. I'd love to seem them get there. I realize though that there's a fundamental difference in dev mode vs prod bundles. In dev, Vite is emitting 25-50 or so JS scripts. In prod, those will all be built into bundles. I just worry about small inconsistencies between esbuild and Rollup when it comes to things like CSS bundling or TS to JS transpilation.
Post reply on HN