Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vite – Next Generation Front End Tooling

main.vitejs.dev

Post reply on HN
Print view View original

261–270 of 383 posts

Re: Vite – Next Generation Front End Tooling

#261

Post by selfmodruntime »

vultour wrote: post #239
kossTKR wrote: 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…

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 is really untrue. The complexity of large PHP projects could get insanely high. The advantage of using SSR in JavaScript is that your entire application speaks the same language as the browser does, so sharing code between server and client becomes incredibly easy.

Re: Vite – Next Generation Front End Tooling

#262

Post by selfmodruntime »

QuadrupleA wrote: post #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 fro…

Your entire answer basically becomes moot since this is not a framework. At all.

This is a build tool, something like a compiler. And it's been writtes by arguably one of the greatest dev in the current generation to get rid of every problem you discribe. There is almost no configuration involved in getting your projects to "just work", which is why people love it.

Give frontend some time. Frontend development, like it exists now, is 10 years old. Backend applications and their architecture have a 30 year advantage.

Re: Vite – Next Generation Front End Tooling

#263

Post by selfmodruntime »

ggregoire wrote: post #232

I find it funny that, as usual, half the comments are complaints about "why are frontend developers always reinventing the wheel"... Meanwhile the 1st post on the front page [1] is about a new "modern" scheduling package for Python. What's wrong with just using Celery, APScheduler, Huey or even cron? Why do we need a new scheduling library? Yet I don't see any "reinventing the wheel" critic in the comments. Double st…

Correct. People are arguing as if there wasn't a new Container Library being released every month for C++

Re: Vite – Next Generation Front End Tooling

#264

Post by selfmodruntime »

marmada wrote: post #247

Hey. If you're hear to post about how the web is always changing, and it's so complicated, no one cares. It's been posted 20 times by now and there are good reasons (we build much more complicated webapps these days). I like Vite. A few things I like: - Super fast - Works out of the box (like parcel) - Even production builds are super fast -- this is a bit of an underrated feature because sometimes things only break…

People here love to complain about frontend, but the speed and outreach people can have with modern webapps beats desktop applications by a mile. There is a reason billion dollar companies like AirBnB don't use desktop apps.

Re: Vite – Next Generation Front End Tooling

#265

Post by mrisoli »

rvdginste wrote: post #82
kossTKR wrote: 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.

Because it's easy money(and as others said, to stay employable).

If someone created a framework yesterday there are few experts, and they won't judge experts by years of experience, if you're a relatively new FE in the job market would you go compete with people with 15+ years of jQuery and 8+ years of React or just take on the next new thing?

If you pickup the latest tooling today by the time it's widespread(like React is now) you're way ahead of the crop and it's quite easy to get some nice pay out of that.

Re: Vite – Next Generation Front End Tooling

#266

Post by littlecranky67 »

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.

Re: Vite – Next Generation Front End Tooling

#267

Post by KronisLV »

wslh wrote: post #260
krick wrote: 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?

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

Probably the fact that it's all very opinionated.

Suppose you want to use Vue. Well, do you want Vue 2 or Vue 3? JavaScript or TypeScript? Which of the component libraries do you want: PrimeVue, Quasar, or another one? State management with Pinia or Vuex? What about validations: Vuelidate or maybe something like Vue Formulate, which also includes functionality for forms. Or would you like Vueform instead?

Then again, the same happens if you want to use React or Angular, or any other option out there. There's just too many separate pieces to pick, though I presume that occasionally there are opinionated attempts at giving you a stable base to start out with. Honestly, even something like Ruby on Rails can be a nice option, though it's also understandable that many out there want to create their front ends as separate apps.

Yet the majority of front end projects out there end up a bit like the Dropwizard framework for Java back end development - just stitched together from any number of different pieces, which sometimes will work really well together, but other times less so: https://www.dropwizard.io/en/latest/

Re: Vite – Next Generation Front End Tooling

#268

Post by rglover »

candiddevmike wrote: post #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?

> Can I just use esbuild yet?

Yes. esbuild works great. I use it in my own full-stack framework [1]. Builds take [1] https://github.com/cheatcode/joystick

Re: Vite – Next Generation Front End Tooling

#269

Post by c7DJTLrn »

F*king hell the ecosystem just never stops growing. Vite, Rollup, HMR? What the f*k is all this? Why does building a frontend have to be a titanic project involving a hundred tools including build systems and tree shakers and compilers and whatever else is going on. Web development is an embarrassment and a blight on computing.

Re: Vite – Next Generation Front End Tooling

#270

Post by tpict »

SCLeo wrote: post #135
BiteCode_dev wrote: post #126

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…

I have been using parcel for web development because I thought webpack is very difficult to use. However, for my latest personal project, I tried webpack. To my surprise, I found webpack 5 much simpler to use then I thought it is (significantly easier than make or gradle, the complexity is not even on the same level). Everything pretty much worked out of box now. All I had to do was to copy the starting template for…

Last time I checked NPM the weekly downloads were still heavily slanted in favour of version 4. I wonder if that plays into perception of it.

At work, an engineer in a different team recently recommended we switch to Vite because it’s “so much faster”. Warm builds are 700ms with our very uninteresting Webpack 5 config. It’s hard to imagine that the cost of reconfiguring our entire build would be worth it.

Post reply on HN