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

361–370 of 383 posts

Re: Vite – Next Generation Front End Tooling

#361

Post by Etheryte »

hsn915 wrote: post #317
Etheryte wrote: post #304

Earlier quoted context omitted.

The first sentence of the "Getting started" page tells you the following: > Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects. But of course it's easier to keep ranting and ignore the second part of the sentence you referenced because it doesn't match your narrative.

That's still very generic so as to be almost no information. Imagine if python's homepage had no code samples at all, and the getting started page said "Python is a programming language for high productivity".

While I somewhat see where you're coming from, I don't really agree, but again, I would be biased since I already know plenty about different build tools. The main statement is that it's a build tool for modern web projects, which makes me thing a-la Webpack and similar. Then it's further specified that it's fast (which Webpack usually is not) and lean (which Webpack definitely is not). For me this already gives a rough idea of what to expect, whereas the Python analogy wouldn't tell me that much.

Re: Vite – Next Generation Front End Tooling

#362

Post by strokirk »

Rapzid wrote: post #90

Introduced Vite into our React project but it's still an experimental development option due to some rough edges. Our project has thousands of SCSS and source files(nearly 10k). The motivating factors were 5-12 minute startup times for CRA depending on the power of the developers workstations, and equally burdensome builds requiring now over 8GB of Node heap to complete without hitting OOM events. Really, really conv…

Have you tried using plain esbuild and sass in watch mode? That was what gave our app an immense speed boost.

I’ve seen some of the same issues you have, with large entrypoints causing slow pageloads due to the number of source files, but fortunately not that large yet. Manually splitting the app into multiple smaller entrypoints have helped there. If HMR wasn’t so useful I would just have used raw esbuild instead, though.

Re: Vite – Next Generation Front End Tooling

#363

Post by brunno »

blowski wrote: post #142
sam0x17 wrote: post #131

Earlier quoted context omitted.

Sticking with your analogy, in the early 2000s we built cabinents and intricate mantelpieces and things ike that, and there were essentially no tools. In the early 2022s we still build cabinents and intricate mantelpieces, but there are a million tools. Meanwhile browser support has become way more consistent across the board and CSS has become easier, yet we think we need super complex tools to do the same tasks we…

when I started building websites in the late 90s, I needed to support Internet Explorer and Netscape running 15" CRT monitors. Few cared much about accessibility, performance, security, SEO, experimental releases. Clients wanted a 3 page website with few design requirements. I sliced up some PSDs into HTML pages with tables on it, and uploaded it via FTP to a single server. If I tried to run a web-based business offe…

Interestingly, there's a very high chance that those HTML pages with tables crafted in the 90s still render perfectly fine today (if they're still around).

Re: Vite – Next Generation Front End Tooling

#364

Post by SOLAR_FIELDS »

EarthLaunch wrote: post #216
SOLAR_FIELDS wrote: post #33

Earlier quoted context omitted.

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

It is better. Why are so many people determined to dismiss it on the basis that "things are so bad that we shouldn't try anything new"? That's totally backwards. In a situation of many bad alternatives, searching for new alternatives is the solution, not the problem. Complaining about bad frontend tooling would be more appropriate to do in a thread that's not about a tool that practically solves it . Instead of compl…

I'm not against new tools, we should absolutely embrace innovation. But show me how it's better, don't just make some claims with no evidence and expect me to buy into it.

Re: Vite – Next Generation Front End Tooling

#365

Post by SOLAR_FIELDS »

cercatrova wrote: post #210
SOLAR_FIELDS wrote: post #33

Earlier quoted context omitted.

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…

I think it's a fair argument but I guess time will play it out to see if it succeeds. It's a bit of a chicken and egg thing, like with most newer open source projects intended to replace older ones. To take off, you need contributors. If you can't get contributors, it won't take off. The value add needs to be strong enough to attract enough developers to overcome the Rust/Go hurdle. I'd wager more on Go in this regard, for your average developer not having to worry about garbage collection is probably going to be a significant plus.

Re: Vite – Next Generation Front End Tooling

#366

Post by sebdufbeau »

kitd wrote: post #348
SparkyMcUnicorn wrote: post #200

Earlier quoted context omitted.

Vite is incredibly fast compared to Webpack. I didn't really know how much time I could have been saving, and I never even thought of Webpack as slow.

IIRC Vite wraps esbuild, which is written in Go and very fast.

You can use esbuild with webpack via esbuild-loader, but what makes Vite so fast is mainly the strategy of pre-bundling dependencies when running the dev server, this makes hot starts and hot reloads incredibly quick.

Re: Vite – Next Generation Front End Tooling

#367

Post by BrandoElFollito »

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…

It does not really matter, but vite in French means quickly.

Quick is rapide.

Re: Vite – Next Generation Front End Tooling

#368

Post by runarberg »

ta-run wrote: post #235
darkest_ruby wrote: post #63

Despite all negative comments, I (and my team) switched to vite for create-react-app about two months ago, and never looked back. Builds take seconds, developer experience is amazing.a.m.a.

Not CRA related, but is it as simple to move an existing Vue2 project to Vite?

It depends. I think web-workers are handled differently, so if one of your dependency uses the webpack way to import a web worker then you might have to ditch that library. There might be other painpoints, but I think most projects migrate pretty easily.

I recently migrated a vue2/vue-cli project over to vue3/vite. I had a pretty clear migration path, and did it incrementally over a few months. I needed to ditch a few libraries that didn’t work with either vue3 or vite. Most of the replacements work with both (e.g. vue-composition-api or pinia) so I could keep using vue2 while I migrated and then when the last non-compatible code had been refactored a few months later the final migration was fairly straight forward. The vue-cli switch happened somewhere in the middle of this.

Re: Vite – Next Generation Front End Tooling

#369

Post by mmis1000 »

littlecranky67 wrote: post #350
mmis1000 wrote: post #331

Earlier quoted context omitted.

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 'compil…

I still don't get it. If I assume that Typescript compiler is the slowest component in the build pipeline, and run it in a separate thread, that still means I have to wait for the tsc to complete. There is little to no benefit in all the other stuff being finished faster; that will be optimizing the 5%, while my main time is wasted in the 95% of the tsc compiler process. At least to my experience, for sufficiently la…

> that still means I have to wait for the tsc to complete

Without fork it. the webpack need to wait the checker to finish checking everything before it compiles even just one file.

With a separate checker, it don't. The ts-loader will eject a perfectly normal js file without caring the typing is valid or not. And webpack can do the rest of works as quick as possible.

It like different of do it in serial and do it in parallel. The latter will utilize the resources better although not absolutely more efficient.

Re: Vite – Next Generation Front End Tooling

#370

Post by etherealG »

TechBro8615 wrote: post #358
runarberg wrote: post #336

Earlier quoted context omitted.

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 e…

Insecure non-frontend devs continue to see frontend as an easy programming environment, and therefore assume the problems in it should instantly make sense to them and be easily solvable. Because after all it’s easy, and they’re smart, and if they were a frontend dev, they wouldn’t even need this tooling because it’s so much easier to start from first principles of an index.html page. It’s funny because I’m a fronten…

All because frontend started with “html” + interactive toy “scripting” for fun animation. It’s like they all forgot about Turing completeness.

Programming is programming.

Love your comment :)

Post reply on HN