Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

251–260 of 383 posts

Re: Vite – Next Generation Front End Tooling

#251

Earlier quoted context omitted.

>> even though the thing they are using is still well maintained. I think you mean "even IF the thing is still maintained". This is a big IF. Something as ubiquitous as a React app may still work fine after a few years, but try updating or fixing something and you're in for a world of hurt.

In my experience dealing with the tooling is fine for ongoing projects by just checking for updates every week. But it is very stressful to update from Webpack 2 to 5 for example. So taking an old project from a couple of years ago and updating the dependencies is not that easy, especially if you were using a lot of the build tools features.

But that's where you have to balance the gain updating the old toolchain against the benefits in your specific situation. Are you going to spend a lot of time on the project, or is it just a few bug fixes? Can you revive the old toolchain? Is the old toolchain churning out good enough production ready assets?

Upgrading dependencies can be a trap. Like, in the past, I've delegated a bugfix that shouldn't take more then an hour or two to a co-worker, only to see them waste an entire day in dependency / NPM hell.

To my mind, there needs to be a compelling case or argument that justifies sinking time in an upgrading exercise.

Re: Vite – Next Generation Front End Tooling

#252
post #185

Earlier quoted context omitted.

> the second is pretty useless and generally tired. Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.

Why can't the "back end community" agree on a single server side language and database and compiler? Gee so much churn!

[deleted]

Re: Vite – Next Generation Front End Tooling

#253

Earlier quoted context omitted.

You may notice that all of the negative comments are around superficial nitpicking of the website copy or general bemoaning of the state of front end development. The first is sort of useful in a minor way; the second is pretty useless and generally tired. Vite is a great tool that I’d recommend for anyone who wants to speed up their front end build setup.

> the second is pretty useless and generally tired. Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.

> I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.

This is simply a false statement. Chrome increases its dominance every year, which actually makes it a lot easier to write frontend code, but that isn't necessarily "better".

In other areas:

- Typescript has been a huge boon to the ecosystem and is widely adopted

- Babel is the standard for transpiling code and has allowed for all these compile-to-JS projects to exist

  - ESBuild/SWC exist if you want to do things faster and less flexibly, but they're still a minor part of the ecosystem
- React has existed for nearly a decade and continues to enjoy regular updates and an enormous community

Re: Vite – Next Generation Front End Tooling

#254

Earlier quoted context omitted.

Front-end tooling that I have to run on the server? Even people familiar with the JS ecosystem might be confused by that.

You don't have to run this on a server. This would never run on a server. This would be used in your local dev environment.

your local dev environment is running a server

Re: Vite – Next Generation Front End Tooling

#255

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…

I think you are being a bit disingenuous to suggest it could be a framework. Is there a framework or JS target language project you are aware of that references itself as "front end tooling"?

I wanna say it's been a decade of front end build tools that have come and gone (or stayed.. we still use a grunt file from 2013) and they all do more or less the same things a front end dev needs.

Re: Vite – Next Generation Front End Tooling

#256

Earlier quoted context omitted.

>> even though the thing they are using is still well maintained. I think you mean "even IF the thing is still maintained". This is a big IF. Something as ubiquitous as a React app may still work fine after a few years, but try updating or fixing something and you're in for a world of hurt.

In my experience dealing with the tooling is fine for ongoing projects by just checking for updates every week. But it is very stressful to update from Webpack 2 to 5 for example. So taking an old project from a couple of years ago and updating the dependencies is not that easy, especially if you were using a lot of the build tools features.

The biggest problems come in when your apps are doing hacky things they shouldn't be doing. This is a common issue with things like Electron, or React Router, and of course, Webpack.

If you are fairly careful and conservative, and lucky enough to be using software after it has matured, I think most upgrades will wind up being pretty uneventful for you.

I'm saying it explicitly: your exception project probably sucked. That's probably why it was tricky to upgrade. It may not have been your fault or even the fault of the people who wrote it. But for example, it was never architecturally a good idea to have Webpack automatically import browserify Node stubs. It was never a good idea to load Node modules from within an Electron renderer thread. Not always your fault. A reasonably well-archirected app usually refactors decently into changes that fix these issues. A poorly architecture app is so fragile it's hard to imagine refactoring anything without something breaking a few miles away. If you have the latter, then no shit that upgrading dependencies sucks... I mean, changing anything else sucks too.

This isn't the root cause of every horror story... But it's a lot of them

Re: Vite – Next Generation Front End Tooling

#257
post #185

Earlier quoted context omitted.

> the second is pretty useless and generally tired. Is it really useless though? I wish the front end community tried to make existing things better instead of reinventing the wheel every year and causing immense fragmentation, especially for something like the build toolchain.

Why can't the "back end community" agree on a single server side language and database and compiler? Gee so much churn!

We both know those aren't even close to the same thing.

All this grunt->gulp->webpack->vite->'the inevitable replacement for vite' are really achieving is finding slightly different ways of doing the same thing.

Re: Vite – Next Generation Front End Tooling

#258
post #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, a…

> ...and you never really grasp before moving on to the next thing. Then why do you move on to the next thing? Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.

If we're being really honest, I switch to the next thing because it's fun.

The more official reason to move to the next thing is because browsers are a moving target. Browsers are constantly releasing new capabilities. And the overall population of users is always moving onto newer versions of those browsers; even if that migration lags a bit, it happens. When we can use those newer browser features, we can provide better services to users.

Vite is exciting because it's built on top of the native ES6 features that are now ubiquitously supported by most browsers. It's such a smooth ride compared to older tools. The dev experience is great, and the end-user bundles are light. I've been very impressed with it.

I sympathize with your sentiment when it comes to the back-end. I want stable tools there. But until the front-end platform (browsers) is similarly stable, some churn will be welcome to support emerging possibilities.

Re: Vite – Next Generation Front End Tooling

#259

Earlier quoted context omitted.

You don't have to run this on a server. This would never run on a server. This would be used in your local dev environment.

your local dev environment is running a server

Clearly the word server is the same, but that's not really what's meant by a server in front end / back end developer discussions.

Re: Vite – Next Generation Front End Tooling

#260
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 remember that Visual Basic (90s) opened with an empty Dialog and UI controls like Windows Forms, Delphi and Xcode now. Just waiting for a tool as easy to use as Google Slides or diagrams.net (draw.io) but produceing the skeleton of an web/mobile app.

Does the software industry have a pathology that avoids making such tool and makes front-end engineers irrelevant except for very complex use cases?

Post reply on HN