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

211–220 of 383 posts

Re: Vite – Next Generation Front End Tooling

#211

Post by simlevesque »

matt89 wrote: post #146
francisofascii wrote: post #128

Earlier quoted context omitted.

Unfortunately it is necessary to stay employable. I hope I am wrong, but a react novice might get more interviews than a JQuery expert.

But React is now probably about 7-8 years old. Is it really this shiny new technology that "everyone must jump to"? Yes jQuery devs probably don't get a lot of work right now, and yes you probably should keep up with React itself. But I don't think that it is necessary to literally switch technology every 1-2 years to keep up, if we can use React (or Vue) which has been stable for a while and is still wildly popular.

But aren't the React devs of today the jQuery devs of tomorrow ? Meaning that if you keep that same technology forever you will lose relevance in the market.

Re: Vite – Next Generation Front End Tooling

#212

Post by cyco130 »

jijji wrote: post #67

how does this benchmark against doing back end development with any language and pushing vanillajs (standard javascript) to the browser? whats the big difference and why should anyone want to make this more abstract/complicated? is it trying to reduce development time?

Plain JavaScript is of course faster. Not doing something is always faster than doing something. But highly interactive web apps have some problems that need to be addressed:

First is syntax extensions: TypeScript (a strictly type JavaScript superset), JSX (a syntax extension for describing DOM nodes popularized by React) and special template syntaxes of other UI libraries/frameworks like Vue and Svelte need to be processed before being sent to the browser. You may also need processing to iron out some of the incompatibilities between JS engines but it's less important nowadays since the IE died.

The second problem is the sheer size: Highly interactive web applications have lots of moving parts. For example at work, my company's product's frontend code contains 4709 modules, roughly 3/4 of which are 3rd party libraries. At this scale you need some level of optimization (like eliminating unused bits of the libraries) and the ability to split the bundled code into chunks depending on what pages they are used.

Re: Vite – Next Generation Front End Tooling

#213

Post by aidos »

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

I think Vite is waiting for code splitting and plugin support in esbuild. It does seem like magic sometimes, but the the code is relatively straightforward. It's not too complicated to dig into to the internals if you're curious about how specific configuration works under the hood. With Webpack I never really felt that way, but maybe it's some kind of subconscious bias from struggling so often with massive configs.

Thing is, I did dig into the webpack code after having the watcher not reloading with code changes. I can’t recall the details but there were several different packages that were thin wrappers around each other and ultimately inotify (or something at the bottom). One of those wrappers was silently hiding the error about not having enough watcher available at the file system level. I was not impressed with what I found.

Re: Vite – Next Generation Front End Tooling

#214

Post by simlevesque »

cto_official wrote: post #147
somenewaccount1 wrote: post #132

Earlier quoted context omitted.

I can't wait for deno.js to really skyrocket. It solves all of this garbage packaging dependency nonsense.

was just reading about them, the were trending on github today.. if we want to port an existing typescript project to deno any ideas how complex it would be ?

At this point it would almost require a full rewrite. I use it for a new projects. But things like using Vue is really hard, some packages help but they are also buggy.

Re: Vite – Next Generation Front End Tooling

#215

Post by sachinraja »

canaus wrote: post #184

So is it safe to say that this tool is mostly trying to solve the developer experience side of front-end development, instead of trying to create a "new" technology such as SSR? I've just mostly seen "fast" and "HMR" as the features of Vite, but I can't see a team switching over an entire project just to solve something that was probably decently "solved" to begin with.

I don't think anyone is expecting an existing production project to switch over. Vite offers amazing DX for new projects though. Just because something is solved doesn't mean it can't get better.

Re: Vite – Next Generation Front End Tooling

#216

Post by EarthLaunch »

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

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 complaining about other tools, these people who don't know what Vite is should be curious and asking what it is, or what it has that's new. That is easy to find out.

> Well, I bet those existing tools are probably capable of doing 10x of what Vite can do currently.

Good luck with your bet.

Re: Vite – Next Generation Front End Tooling

#217

Post by simlevesque »

synergy20 wrote: post #199

This is an excellent tool, beats webpack to ashes. Evan You did this after his vuejs work, it's kind of like Linus did git after his linux kernel work, well, on a smaller scale. Per Linus, he did git to approve that he is not an accidental one time genius.

And now he's working on Volar, to make tooling more awesome.

Re: Vite – Next Generation Front End Tooling

#219

Post by sachinraja »

quest88 wrote: post #62
exhaze wrote: post #48

Earlier quoted context omitted.

They actually do right in the hero section of the landing page. For me: - fast (very important) - Fully Typed APIs (very important) Just those two points would convince me to try it and I can see it right away on the landing page. At my company, I looked at Vite 6+ months ago and decided it doesn't make sense for us, yet, because of some specific tooling gaps, but it's a tool that I consider "cutting edge" in the fro…

What is cutting edge about it? What gaps is it lacking, and why not put thodr in more established tools? Basically, what problem is this solving and way throw out years of experience in the other tools?

Vite does not throw out any experience. It builds upon Rollup, esbuild, and other existing tools.

There's a great page on how it's cutting edge here: https://main.vitejs.dev/guide/why.html. I suggest you try using it to see for yourself.

Re: Vite – Next Generation Front End Tooling

#220

Post by jollybean »

thr0wawayf00 wrote: post #183
jollybean wrote: post #84

Earlier quoted context omitted.

It's still not concise enough. It's a long article you have to read to figure out what you are reading about. "WTF IS IT?" is an endemic problem with marketing and startups. Marketing is a skill, that many people in marketing so often don't have, and lot of leaders fail to grasp. It's so sad. Imagine losing 1/2 of your potential uptake because of poor choice of words.

I think is more of an indictment on the javascript ecosystem generally, because there's so much more to building an app that runs JS than just your standard MVC/MVVM/pick-your-pattern web frameworks. You have to deal with various layers of transpilation on your JS, styles and assets and that all needs to be flexible enough to fit a wide set of use cases for the community. It's gotten to the point you need to be an ex…

You're right that JS is a mess, but this is not a JS problem, it's a tech problem.

I see it over, over and over again.

I see young people pitching their tech and I have no f*ing clue what they are talking about.

I would say >50% of web sites don't do a very good job of explaining anything.

Vercel is one of the worst offenders.

Post reply on HN