Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

11–20 of 383 posts

Re: Vite – Next Generation Front End Tooling

#11

Really enjoy working with Vite and it works great with React (many think it’s geared towards Vue, which perhaps it was at one point). Made the switch after some frustrating behavior coming from CRA and having zero flexibility with configuration. As a side note, Vitest is fantastic as well and I highly recommend giving it a try.

Indeed, it never occurred to me to use it with react. Vue vitesse (vite + project template) was so nice it stopped my quest.

Re: Vite – Next Generation Front End Tooling

#12
I'm a happy vite user, but it troubles me when I think about how complicated everything it abstracts has become. It uses rollup for some things, esbuild for others, workbox for my service worker... I switched from webpack to it, and while my config is certainly less complex, I at least could tell you what webpack is doing. Vite is magic.

Can I just use esbuild yet?

Re: Vite – Next Generation Front End Tooling

#15
post #8
post #2

The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.

You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.

In an environment where you have choice, it takes developer maturity not to just leap on every new tool like this.

But it’s wonderfully healthy for an environment to be so alive and full of innovation.

Bazaar vs. Cathedral and whatnot. It’s easier for some to just be prescribed a specific SDK.

Re: Vite – Next Generation Front End Tooling

#16
post #8
post #2

The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.

You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.

Yeah it's just wild. I don't ever remember seeing this level of.... sideways.... churn before. Feels like it's been absolute mayhem for close to ten years now.

I thought that for sure, by 2017 or so, we'd have seen a relatively long lived consensus winner like we saw during jQuery's reign.

Instead, it's just been constant roiling.

The roiling is hard to understand because it's not like the other parts of the stack are really mutating that quickly. Backend dev practices/technologies and browser capabilities are not evolving or roiling at anywhere close to this rate. This sort of churn would have made sense during say 1997-2002 when the entire stack was being invented and reinvented and the basic idea of browsers themselves were changing rapidly.

Re: Vite – Next Generation Front End Tooling

#18

Really enjoy working with Vite and it works great with React (many think it’s geared towards Vue, which perhaps it was at one point). Made the switch after some frustrating behavior coming from CRA and having zero flexibility with configuration. As a side note, Vitest is fantastic as well and I highly recommend giving it a try.

Last year, I converted a CRA to Vite because CRA wouldn't work in a monorepo. It was such a painless experience and it just worked.

Re: Vite – Next Generation Front End Tooling

#19
post #2

The constant iteration and revolution of basic front-end web dev makes me happy to be a mobile dev.

Are you sticking with the tired old 2019 tech, or have you rewritten everything with Kotlin, Compose, Swift, and SwiftUI?

No, those are old news. We've moved on to Flutter

Re: Vite – Next Generation Front End Tooling

#20
post #8

Earlier quoted context omitted.

You're being downvoted but it's wild how frontend frameworks pop up, take hold, and then quietly disappear with the next iteration of the same thing with different syntactic sugar.

In an environment where you have choice, it takes developer maturity not to just leap on every new tool like this. But it’s wonderfully healthy for an environment to be so alive and full of innovation. Bazaar vs. Cathedral and whatnot. It’s easier for some to just be prescribed a specific SDK.

re: Bazaar vs. Cathedral

I think it's an obvious truth that too little innovation/choice is bad. I don't think you'll find any arguments there!

Is there a point where too much of it becomes harmful? For close to ten years now, I feel that experienced and inexperienced devs alike have been confused and repulsed by the utter state of constant wheel-reinvention in the frontend space.

(Perhaps to my own detriment, I've focused on backend work because I'm waiting for the front-end situation to stabilize. Which of course may never happen. Maybe "full-stack dev" is something that will wind up in the history bin next to "webmaster")

     It’s easier for some to just be prescribed a specific SDK. 
This is a little bit insulting. Nobody wants to "be prescribed a specific SDK" - there's a large middle ground between that, and the current situation which has been chaotic for nearly a whole generation.

I think the situation with backend frameworks is sort of what many would like to see. Django, Rails, Express, etc. No shortage of choice and there is innovation. Yet I don't think anybody would call it chaotic. For me that is a happy middle ground.

Post reply on HN