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

201–210 of 383 posts

Re: Vite – Next Generation Front End Tooling

#201

Post by cercatrova »

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…

Looks like you're looking for the Why Vite page [0].

"""

# The Problems

Before ES modules were available in browsers, developers had no native mechanism for authoring JavaScript in a modularized fashion. This is why we are all familiar with the concept of "bundling": using tools that crawl, process and concatenate our source modules into files that can run in the browser.

Over time we have seen tools like webpack, Rollup and Parcel, which greatly improved the development experience for frontend developers.

However, as we start to build more and more ambitious applications, the amount of JavaScript we are dealing with also increased exponentially. It is not uncommon for large scale projects to contain thousands of modules. We are starting to hit a performance bottleneck for JavaScript based tooling: it can often take an unreasonably long wait (sometimes up to minutes!) to spin up a dev server, and even with HMR, file edits can take a couple seconds to be reflected in the browser. The slow feedback loop can greatly affect developers' productivity and happiness.

Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages.

"""

[0] https://main.vitejs.dev/guide/why.html

Re: Vite – Next Generation Front End Tooling

#202

Post by noduerme »

Am I alone in that I don't webpack or otherwise bundle anything until I deploy? If I'm building a large typescript project, I just run it directly out of source JS and CSS files on my dev server. Only when upgrades are finished and tested do I bundle them and put them on the production server.

Re: Vite – Next Generation Front End Tooling

#203

Post by nazka »

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.

And then you have someone down the comment telling him to try the next thing Flutter or whatever. It's a never ending. HN and tech is both full of people like you say and want stable stacks but also full of people wanting to try the new thing.

For me React have been doing all and beyond for me on a dev and business pov and will continues for a log time hopefully a decade. But it's frontend so it's already weird that it stayed that long.

Re: Vite – Next Generation Front End Tooling

#204

Post by aidos »

boredtofears wrote: post #195
unsupp0rted wrote: post #173

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.

Exactly that though. For a SPA you’re going to have a bunch of state loaded and you don’t want to refresh. If you’re using something like tailwind where you’re transpiling your css too then it’s a major boon to have it hot reloaded.

I’ve found vite to be an awesome dev experience.

Re: Vite – Next Generation Front End Tooling

#205

Post by dmix »

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…

Webpack is probably fine for new or small projects. It's when you've been using it for a while, do anything complex, or worst of all your framework libraries update then you have to update Webpack which is a nightmare.

Ive had Webpack break more of my deploys than any other piece of software in the last 3 years.

Vite was basically a plug and play replacement (almost zero config) and I also got to drop Babel, so that meant replacing about 12 packages in my package.json and who knows how many in Yarn.lock (Mostly babel and webpack plugins) with 2 vite packages. It's much faster at builds and the chunking of small js files seemed more intelligent and better integrated with Vue.

Re: Vite – Next Generation Front End Tooling

#206

Post by noduerme »

monkey_monkey wrote: post #117
rvdginste wrote: post #82

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.

Because all the upkeep happens on the new shiny toy, leaving the old ones to fester and rot away. Heaven help you if you need to go back to a site you built for a client 4 years ago and try to make changes now. 90% chance that your build toolchain will be completely broken and fail to work.

This is why I just roll my own and don't use frameworks like React. I've been building and rebuilding apps for clients for 15 years, so basically have my own ways to spin up an app within hours. Yeah, I still use jQuery for some things, who cares if it works?

Re: Vite – Next Generation Front End Tooling

#207

Post by noduerme »

cercatrova wrote: post #197
finfinfin wrote: post #136

Earlier quoted context omitted.

Does Flutter still render everything in a canvas? This has been a huge turn off for me.

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.

aaand we're all the way back to Flash.

Re: Vite – Next Generation Front End Tooling

#208

Post by aidos »

mmis1000 wrote: post #108
edvards wrote: post #68

Earlier quoted context omitted.

is it compatible with what webpack has

Yes and No. Yes, it has the same ability like webpack, which allow you to plug the logic you need into the system and change the results to fit your requirement. No, the config file or the plugins isn't compatible, because it is based on rollup. So you need to find rollup plugins instead.

But when you make the switch you’ll discover that you don’t need any of the config because it’s all pretty well up and running out of the box.

Re: Vite – Next Generation Front End Tooling

#209

Post by EarthLaunch »

emptysea wrote: post #49

Curious how Parcel stacks up to Vite. Vite seems to have the Vue community behind it which is pretty larger. Both have much better performance than webpack, so between the two probably doesn't matter too much.

I found Parcel and Snowpack years ago, before Vite, because I knew an integrated and ESM-based system was the future.

Both were incomplete and buggy, both had tool combinations that they just couldn't handle. I've forgotten the details but from the tickets I was reading, I doubt that's improved.

Vite solves all of that, it's incredibly easy to work with and I never have problems with it. For a fairly esoteric frontend situation, too.

Re: Vite – Next Generation Front End Tooling

#210

Post by cercatrova »

SOLAR_FIELDS wrote: post #33
root_axis wrote: post #23

Earlier quoted context omitted.

I downvoted it. I did so because, IMO, the comment is superfluous noise seen on every js thread. A tool exists to solve a problem, if you don't understand why it was built or don't like it, that's ok, but the hackneyed complaining about open source software merely existing deserves to be at the bottom of the thread.

I'm not the grandparent poster but I'll ask the question in a non-superflous way: Is this actually better than Webpack and esbuild/Parcel/Rollup/whatever that came before it? Or is it just another opinionated way of packaging stuff up that's faster because it doesn't support 10% of the feature set the other tools do yet? Looking at the "Why Vite" page, most of the blurbs are basically saying "Existing tools are slow"…

> Well I kind of like the dogfooding of all the build tools for JS being written in JS - why introduce a whole new ecosystem here?

You might find this answer helpful, about Rome which is like Vite but in Rust rather than Go [0], crucially:

> This justification -- Rome should be written in JS otherwise Rome users are less likely to contribute -- irresponsibly focuses on a secondary goal of the project, at the cost of the primary goal, which is to be a end-to-end toolchain for one of the most popular languages in the world.

Speed matters. It is not a sideline consideration, it should be one of the main considerations, over and above a tool being in the same language. In fact, many say that rewriting JS tools in non-JS faster languages will be the future [1].

[0] https://news.ycombinator.com/item?id=28609474

[1] https://leerob.io/blog/rust#the-future-of-javascript-tooling (https://news.ycombinator.com/item?id=29192088)

Post reply on HN