Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

51–60 of 383 posts

Re: Vite – Next Generation Front End Tooling

#51
post #46

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. "Gettin…

I had exactly the same experience. I gave it maybe 20 seconds then I was gone.

Re: Vite – Next Generation Front End Tooling

#52
post #46

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. "Gettin…

I'm not a developer and particularly not a front-end one. I have this problem all the time.

Even some of the more "obvious" ones, say, nuxtjs, I have a hard time to get what exactly it offers and why I should use it.

Re: Vite – Next Generation Front End Tooling

#53
post #46

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. "Gettin…

The feature list on the home page indicate it’s a dev server.

Re: Vite – Next Generation Front End Tooling

#55

Earlier quoted context omitted.

I downvoted it. I did so because, IMO, the comment is superfluous noise seen on every js thread. A tool exists to solve a problem, if you don't understand why it was built or don't like it, that's ok, but the hackneyed complaining about open source software merely existing deserves to be at the bottom of the thread.

I'm not the grandparent poster but I'll ask the question in a non-superflous way: Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet? Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow"…

The reason frontend dev moves "So quickly" is because of new browser developments & capabilities. Esbuild & vite are currently popular because they are one of the first build tools to fully utilize browser ES Modules. This is fundamentally different than what webpack does. Webpack was solving a Pre-ESM problem, "how do we modularize frontend code?" and as such as taken on a lot of bloat to solve this problem which has largely been solved by browser ESM.

Re: Vite – Next Generation Front End Tooling

#57
post #43

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…

The "Why Vite?" button on the homepage is fairly "front and center" to me and is only a single click away: https://main.vitejs.dev/guide/why

The front page is right there and could've included the copy "Next generation replacement for Webpack" and I would've known exactly what it's for.

Literally one sentence.

Re: Vite – Next Generation Front End Tooling

#58
I've used Vite in a simple vuejs project and love its simplicity over webpack.

However, debugging Vue3 with hot-module-reload seems to be broken. The moment HRM changes a source file, the line numbers and breakpoints not always line up and breakpoints. (https://github.com/vitejs/vite/issues/5916). The inability to debug properly is not a minor issue so I'm torn to go back to webpack or disable HMR to keep using Vite.

Other than that, the simplification that Vite brings to the build process is sorely needed. I can only imagine how many developer hours have been lost in dealing with Webpack configuration issues. It is ironic that setting up a web development environment is more complicated than building a basic application. Thank you Vite developers for offering relief :)!

Re: Vite – Next Generation Front End Tooling

#59
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.

Re: Vite – Next Generation Front End Tooling

#60
I can’t find a vite solution for NodeJS which is disappointing. If anyone has figured out a way to ship the minimal amount of code from a NodeJS monorepo (ideally with web and server code, but generally decoupled) I’d enjoy seeing the solution!
Post reply on HN