Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

221–230 of 383 posts

Re: Vite – Next Generation Front End Tooling

#221
The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems.

I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the frontend world endlessly frets about like state management, build times (I don't use builds), polyfills (I just use whatever raw JS subset is about 97% supported), server-side rendering (just design your app with an intelligent division of labor between client and server), dependency management (minimize them, and understand the ones you use fully so you can adapt them to your needs), etc.

Like this site demonstrates, reasoning for using all this cruft is always vague too - "best practice", "modern", "next gen", whatever. Seriously, the whole frontend ecosystem seems a rube goldberg tower built on pseudo-technical marketing fluff that has everyone chasing their tail and adding more unnecessary layers. I don't get it.

If you're deep in this world, I highly recommend: go a layer down. Try implementing your next feature with and without the library / framework du joir. Can you simplify, remove layers, and still accomplish your goals? How much code is it for each version, including the framework? Is the dependency worth all its baggage, like build times, module incompatibilities, leaky abstractions, loss of control, etc.?

Re: Vite – Next Generation Front End Tooling

#222

Earlier quoted context omitted.

> pretty fast hot reload An understatement to be sure: you can set VS Code to auto-save every 1 second and that way whatever you type instantly appears via Vite's Hot Reload in your dev browser. No waiting multiple seconds for a recompile. It's game-changing workflow (for some tasks).

Game-changer perhaps in a bad way ;) We're losing the art of writing solid code and instead flail with the "hot reload" crutch. I miss the days of punching cards and submitting a deck to be compiled and run - at least in terms of it forcing me to verify my work ahead of time. And yes - I'm (mostly) kidding. But I did write my first programs on punched cards at a university course while I was still in grade school. Pr…

We are also writing far more complicated software. Punch cards didn’t have to support thousands of different devices, resolutions, screen densities, input methods, etc. It’s a totally different world.

Re: Vite – Next Generation Front End Tooling

#223
post #94

Earlier quoted context omitted.

Ah, the age old HN pass-time of feeling like everything needs to fit your niche, leaving a comment about how a website didn't fill in your blind spot for you rather than googling what something is with the time.

I don't think that's what OP is saying. To me, it reads like, "I'd love to know what this is, but based on the linked document and others within near proximity - I can't" which means the link requires that OP has knowledge of the frontend build world - which I will tell you is niche and disparate or that there is a big unsaid problem in this space that is non-obvious to anyone outside of it. Curiously, both are true.…

If they don't have knowledge of the frontend build world, then maybe they'll have to do a bit more reading. Who should Vite's landing page target?

Re: Vite – Next Generation Front End Tooling

#224

The frontend world seems to be drowning in its own accidental complexity, with each new framework trying to solve the ecosystem's self-created problems. I've been developing complicated full stack apps for years with nearly-vanilla JS, CSS and HTML, plus a helping of basic software design skills, and I have no trouble managing complexity, delivering features fast, etc. I've never related to all these problems the fro…

If anything, Vite is less complexity. It's much easier to use and configure than any other build tool I've used. If you don't have a need/want for Vite, that's fine, but others enjoy using it. I am not fretting over the next build tool, I'm simply switching to something I prefer to use.

Re: Vite – Next Generation Front End Tooling

#225
For anyone interested, these are the docs for the upcoming 3.0 release. https://vitejs.dev is for 2.x, which is the current, released version.

The sites are largely similar. Other than features that have changed, the major differences appear to be aesthetic.

I'm looking forward to the v3 release.

Re: Vite – Next Generation Front End Tooling

#226

There is no way I'm leaving webpack after those 100 years of frustration and pain. Now that I have reached an almost mediocre level of understanding of it, I am never letting it go.

Leaving Webpack was one of the most liberating technology choice I ever did. Top 10 easily.

Re: Vite – Next Generation Front End Tooling

#227

Earlier quoted context omitted.

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

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

Re: Vite – Next Generation Front End Tooling

#228

"It's fast" is not going to sell me on a build tool. Make files are fast too. What we learned with the evolution from Gulp/Grunt etc. to Webpack is that you need to find a sweet spot between zero config and full config. The "batteries included" approach works until it doesn't, and for small projects I'm sure it's fine. But every large project inevitably ends up with all kinds of snowflake config that Webpack handles…

It's one of the software that is the easiest to move to. For the vast majority of people, you go from a 150 lines Webpack config to a 15 lines Vite config, possibly the default values.

It is kind of incredible. They've found "a sweet spot between zero config and full config" you are mentionning.

Re: Vite – Next Generation Front End Tooling

#229
post #94

Earlier quoted context omitted.

I don't think that's what OP is saying. To me, it reads like, "I'd love to know what this is, but based on the linked document and others within near proximity - I can't" which means the link requires that OP has knowledge of the frontend build world - which I will tell you is niche and disparate or that there is a big unsaid problem in this space that is non-obvious to anyone outside of it. Curiously, both are true.…

If they don't have knowledge of the frontend build world, then maybe they'll have to do a bit more reading. Who should Vite's landing page target?

By knowledge, what I really mean is intimate knowledge. I'm not a frontend dev, but I do hack away on hobby projects which eventually caused me to make changes to the default tooling that the project starters pre-configure. Given that the landscape so heavily relies on preconfiguration and post-customization, who they're selling to are people who started with a template and know little about what webpack, vite, or next are doing.

Re: Vite – Next Generation Front End Tooling

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

You aren't alone.

The frontend tooling and framework market is so flooded and noisy, with extremely high churn. At this point it's so hard to keep up with and build things with the latest thing, it's become a hilariously bad joke.

What other language ecosystem is this insane?

Post reply on HN