Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

331–340 of 383 posts

Re: Vite – Next Generation Front End Tooling

#331

I'm a sceptic to the claims; most build speedups I've seen come from the bypass of Typescript type checking/compiler errors. Since there is no other competetive compiler to Typescript than the official (and slow) tsc, I think vite works this way too? Getting hot reload and fast page refreshes is nice, but the idea is that if I get a compiler error, I ought to fix it first before I move to the browser to test my code.

Actually most webpack config guides also recommend you to start Typescript checker in separate thread(there is plugin for that) and don't block compilation(transpile mode).

But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.

Re: Vite – Next Generation Front End Tooling

#332

Earlier quoted context omitted.

Yes, and that's the main reason why I like it. You can do advanced UIs and animations that would otherwise be very annoying in other frameworks like React Native. Plus, a canvas makes it easy to port to other platforms like desktop and web because all you need is the ability to draw pixels on a screen.

To be fair web content can also be ported easily pretty much everywhere because browsers run almost everywhere.

But it's more fun to rebuild the DOM inside a canvas. Then you can run it in another DOM inside a canvas inside a DOM, and stream the whole thing from a server into a thin client and call it a native app.

Re: Vite – Next Generation Front End Tooling

#333

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

I dunno if it's just me, but I've always found live reload to be an overstated benefit. I usually have a mental model of what I'm trying to code that I don't want to check until it's at a specific state - the seconds it takes to press reload doesn't really add up to that much. I'd say it's more beneficial for CSS styling but I usually mock up my changes in the dev inspector and then copy it over anyways.

Not just you.

Hotreload can be handy to some extent, annoying in others - I like to preserve state of given app including what the dom looks like + the window/memory state in devtools. Iterate in code, refresh, then compare. You can do that with multiple browser tabs for example. But not with hotreloading; each tab will re-render/reload the global window state.

Re: Vite – Next Generation Front End Tooling

#334

Earlier quoted context omitted.

It's hilarious listening to my friends who do frontend rave about the the incredible framework of the month, every month there's a new one that's supposed to be the last, ultimate, final stop for developing frontends. Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.

This gets repeated in every thread about front-end tech, and every time people have to repeat the same explanation. SSR is not PHP. SSR allows you to run the same code on client and server. You get to use client-side frameworks, but the page is rendered before it even reaches the client. If people could try to understand SSR before diminishing it, we could have much more productive discussions. But as of now the freq…

> but the page is rendered before it even reaches the client

Which is what PHP was built for.

> If people could try to understand SSR before diminishing it, we could have much more productive discussions.

If new generation of frontend people could try to understand PHP before diminishing it, we could have much more productive discussions.

Re: Vite – Next Generation Front End Tooling

#335
post #292
post #72

Earlier quoted context omitted.

You are utterly wrong. There's a huge difference between even Next.js and create-react-app, even though they're both based on React. The JS framework space is huge, messy, complex, and endlessly frustrating, but you can't wave that all away just because you can't keep up with it. I can't keep up either, but I do employ people who do, and they recently moved all our build tooling to Vite, which dramatically improved o…

The hilarious thing is that this is the first time I am seeing DX in this context. Is DX meant to be Developer Experience or something different?

Yes, developer experience.

Re: Vite – Next Generation Front End Tooling

#336
post #179

Incredible amount of negative comments. It takes more time to type all that negativity out than it takes to read about what Vite is and what it does. Frontend dev here. Vite is amazing. It doesn't take long to get what it does if you try it out (you can avoid reading about it that way). I won't bother summarizing what it does, the website literally covers it. Reading really became superpower in this day and age.

I agree. Vite is amazing. And most of the comments here seem to be same old complaints we’ve heard and debunked over and over about the state of frontend dev tools.

I do wonder if other industries act like this to their specialties. E.g. do carpenters complain about the tools that boat builders use? Do butchers complain about bakers having to many tools. Do cobblers complain about marketing materials for tools used exclusively by dress-makers? I doubt it.

Most front end devs I talk to don’t complain about the things commenters here are talking about. Most of us—that I know of—are happy with the tools we use, are fine with the evolving landscape, and are able to read through marketing materials of most of the tools we are picking. Honestly, if you are not a front end developer, why do you care about this?

Re: Vite – Next Generation Front End Tooling

#337

Earlier quoted context omitted.

Terrible landing page for an otherwise excellent tool. It sets up JS transpiling and bundling for you in an easy way, then provide a server with pretty fast hot reload. This solves 2 problems: - the complicated js project stack is now simple to setup, unlike with webpack - saving and seeing the result of your coding is now almost instant, unlike with CRA It's a joy to use, given that it's from VueJS author, and I hig…

Would this replace parcel or be adjacent to it?

https://npmtrends.com/parcel-vs-vite

Re: Vite – Next Generation Front End Tooling

#338

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…

Have any examples of websites or products of yours? Edit: ok so I took a look at the website in your hackernews bio. Some cool stuff there, but honestly in terms of front end work it isn't terribly complicated. So while you might be picking the correct tools for your work, it doesn't really apply for, say, a marketplace website that wants to lazy load long lists of products, or that want to re-use those product cards…

That site is just smaller side projects - in my paid work I do maintain large apps with dozens of screens, modals, workflows, complex state etc. It's not necessarily trivial, you have to think through your design approaches, but JS is a Turing complete language after all, with all the elements you need to build abstractions to fit your task. I haven't personally found virtual DOM to be a win in my projects (I've experimented plenty with react). Things have always been more performant and simpler without it, and the dev experience is much nicer and simpler and easier to debug without a build step.

Of course my projects don't represent everybody's, but I've done a wide variety of them so I'm not speaking from some esoteric niche viewpoint either. There's a certain stockholm syndrome with these tools where people assume they'd be much worse off without them, without actually trying it out.

Re: Vite – Next Generation Front End Tooling

#339
post #280

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…

Apparently you have never built a webapp that is more ambituous than a simple website. The superpower of "modern" frameworks (Vue and React are both 5-10 years old) is abstracting away from the DOM to be able to define your view as a function of state. Vanilla JS doesn't help you in that regard.

See reply to woojoo below - not saying I'm the world's best frontend dev, but I've built complex apps with many screens / modes / complex state. Despite what people seem to think, the world doesn't fall apart without a virtual DOM, indeed it usually gets simpler. Vanilla JS gives you all the essentials to make abstractions to fit your task (i.e. functions and structured data).

Re: Vite – Next Generation Front End Tooling

#340
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…

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

Don't get into devops/infra if JS fatigue is an issue: https://landscape.cncf.io/

Post reply on HN