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

81–90 of 383 posts

Re: Vite – Next Generation Front End Tooling

#81

Post by pragmatic »

I was looking at this recently and it’s interesting. But a couple of points.

Webpack 5 is actually pretty easy to configure these days. I have a use case of supporting angularjs with web workers, service worker (full PWA - it’s a POS that is built to handle low bandwidth, intermittent connections etc while still providing 90% of functionality in offline mode - lots of indexeddb, local storage and service worker magic) and typescript.

It handles it all like magic. The workers are in typescript and yet they “just work” with shared imports (indexeddb wrapper mostly). Service workers get all your /dist resources added and you can still add any custom code you need - which I do.

Also you can use esbuild with webpack (there’s a plug-in of course)

I was dreading using webpack bc my last experience with it in 2015 was not great, but wow, it’s really powerful and actually easy to work with.

Also using it for an electron side project and it’s also great there.

I have to say, parcel and a lot I’d other bundlers just can’t do what webpack handles almost effortlessly.

YMMV of course but webpack 5 is worth a look if you haven’t used it lately.

Re: Vite – Next Generation Front End Tooling

#82

Post by rvdginste »

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.

Re: Vite – Next Generation Front End Tooling

#83

Post by brundolf »

XorNot wrote: post #57
mgomez wrote: post #43

Earlier quoted context omitted.

The "Why Vite?" button on the homepage is fairly "front and center" to me and is only a single click away: https://main.vitejs.dev/guide/why

The front page is right there and could've included the copy "Next generation replacement for Webpack" and I would've known exactly what it's for. Literally one sentence.

It's not really a correct sentence though

Re: Vite – Next Generation Front End Tooling

#84

Post by jollybean »

mgomez wrote: post #43
omarhaneef wrote: post #35

Almost all the comments are from those who have tried it. (And most people apparently love it). Why? Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else. The features don’t help: it’s fast. That could apply to anything. It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what…

The "Why Vite?" button on the homepage is fairly "front and center" to me and is only a single click away: https://main.vitejs.dev/guide/why

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.

Re: Vite – Next Generation Front End Tooling

#85

Post by LtWorf »

blowski wrote: post #69
thrdbndndn wrote: post #52

Earlier quoted context omitted.

I'm not a developer and particularly not a front-end one. I have this problem all the time. Even some of the more "obvious" ones, say, nuxtjs, I have a hard time to get what exactly it offers and why I should use it.

Devil's Advocate position here. I don't know much about carpentry, and if I look at a website selling saws, I will struggle to understand the difference between different models. Dumbing down to an extent that I understand (when I probably won't buy the product anyway) risks alienating the target market that will. Due to customer demands, end-user requirements, and device fragmentation, front-end development has genu…

Developer here. I think I can speak for everyone when I say that even when we work with the thing, we can't understand the homepage of the thing.

For example at my $DAYJOB I know what we do but if I didn't the website wouldn't help me to understand.

Re: Vite – Next Generation Front End Tooling

#86

Post by nikodunk »

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.

This. As someone who's hung back and not switched to the hot new thing in frontend - I've learned the "old" stuff seems to mature and tends to get better. Look at React, CRA, or Redux Toolkit - they're all so much better (performant, more concise) than the original few releases now!

Re: Vite – Next Generation Front End Tooling

#87

Post by azemetre »

blowski wrote: post #69
thrdbndndn wrote: post #52

Earlier quoted context omitted.

I'm not a developer and particularly not a front-end one. I have this problem all the time. Even some of the more "obvious" ones, say, nuxtjs, I have a hard time to get what exactly it offers and why I should use it.

Devil's Advocate position here. I don't know much about carpentry, and if I look at a website selling saws, I will struggle to understand the difference between different models. Dumbing down to an extent that I understand (when I probably won't buy the product anyway) risks alienating the target market that will. Due to customer demands, end-user requirements, and device fragmentation, front-end development has genu…

This is a good point if we were selling physical goods and limited by the amount of information we can convey on a screen but we aren't.

I'd honestly include things like the what and why as critical to documentation. Most libraries, tools, and tech in general are bad at documentation. It's an active choice to omit discussing these things when they should obviously be included but writing good copy is hard.

IDK seems like a good thing to invest in especially if you want your tool to become a dominate player instead of an encroaching tangent.

While there are separate pages for the why and comparisons for vite (but it's only comparing itself to other bleeding edge tools rather than popular ones like webpack, browserify, gulp, grunt) they should be snippets of these sections on the front page. Right now there are 6 title cards of with wasted space with very little information. Compare this with playwright's home page you and immediately know why you want to use the tool:

https://playwright.dev/

For a personal taste thing, I'm not really a fan of these open source tools creating homepages similar to as you would see for various startups/products. My mind immediately goes "oh paid tool, oh well." They do say it's free in a lovely medium size text that doesn't standout much and is beyond the fold.

Re: Vite – Next Generation Front End Tooling

#88

Post by jollybean »

exhaze wrote: post #48
omarhaneef wrote: post #35

Almost all the comments are from those who have tried it. (And most people apparently love it). Why? Because it never tells you what it does. It’s “front end tooling” which could be anything from a new JS target language to a framework to something else. The features don’t help: it’s fast. That could apply to anything. It’s only when they talk about the alternatives like ESBuild and webpack that I get a sense of what…

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…

?? 'fast' and 'fully typed APIs' do not explain anything at all.

Those are completely generic descriptors.

Those are arguably 'differentiators' to the problem they are solving, but they don't first explain the problem they are solving.

Re: Vite – Next Generation Front End Tooling

#89

Post by jollybean »

Rapzid wrote: post #66
quest88 wrote: post #62

Earlier quoted context omitted.

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?

Why Vite explains this all https://vitejs.dev/guide/why.html

Why would anyone read a long-winded technical article before they even know what they are about read about?

"We have some amazing fast tech, that will make your life better -> read our white paper! We have good APIs"

Tell people what it is first, roughly what it's for, then the benefits. Then the article.

Re: Vite – Next Generation Front End Tooling

#90

Post by Rapzid »

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 convinced this style of tooling is the future however here are some issues we are running into:

* 4s full page refreshes

Much slower that when Webpack finally gets going. If I'm working on something that may require lots full-page loads I'll opt for CRA.

This is in part to do with the sheer number of source files. Part AFAIK they aren't using a strategy such as a Merkel tree to keep track of which import chains are actually invalid and instead re-request every file every reload.

Part is SCSS which is a super, major PITA performance wise on a project of this size. Vite doesn't yet support embedded SCSS, and embedded SCSS doesn't support process reuse so it may not even work well with this dev server strategy.

* HMR objects

Editing certain(mostly non-component) code will cause duplicate class names to be created: MyClass2, MyClass3, and etc. Vite seems to use a different strategy than Webpack which, I believe, use proxy objects.. In any case these can cause "instance of" and other failures that trip people up and send them on wild bug chases.

* Weird optimization requirements

In your project's src importing from folder index files is considered harmful to Vite performance.

When importing from node_modules NOT IMPORTING from the base index is considered harmful to performance!? It will not optimize deep import deps automatically(pre-bundle and browser cache them).

=========

Even though I'm convinced this is the direction of dev tooling I'm not sure Vite will be the winner here. I can't help but feel entire server should be written in a language such as Go, and a better incremental build and delivery strategy needs to be in place. A strategy so that the browser only needs to request the files that have changed while going to cache directly for everything else. Otherwise very large projects will continue to be problematic.

Yeah, lazy loading components but that's not always desirable particularly in single page "apps".

Post reply on HN