Hacker News new | ask | show | jobs
by afavour 633 days ago
While this is true I think the multiple libraries problem is a rounding error when you look at the majority of web apps created today. React and react-dom combined are over 100KB. Svelte and Lit are in the single digits. So you could embed a lot of frameworks before you get close to the bloat people use every single day without even thinking about it.
2 comments

As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
> You can't judge frontend by React and the way it's badly used.

IMO you can because it’s the vast majority of webapp usage today. I’m also a heavy Svelte user and I love it but front end web dev is practically a React monoculture so it makes sense to think about it when evaluating options.

I’m not saying it isn’t a problem inherent in web components, it is. But using it as a reason to not adopt web components runs contrary to the logic the vast majority of the industry currently uses. Perfect as the enemy of good and all that.

React is irrelevant for me and my users. This is not an argument in favor of web components over Svelte. Adopting web components would mean an objectively worse UX for my users - for example requiring them to enable JS.

You won't get a Svelte to look past the flaws of web components by saying "React is bad".

Yes, you’re talking about you and your users. I’m talking about the industry at large. Those two perspectives don’t have to line up.

The article we’re discussing is titled “Web Components are okay”, not “Web Components are better than Svelte for webdevladder and their users”.

Look at the thread you've created here - I'm arguing that the article minimizes the antipattern cost they impose, and your response brings up React as if it somehow changes that.
Yes, I previously mentioned the “perfect as the enemy of good” argument.

Like I already said, I use and like Svelte. But the vast majority of the web dev ecosystem uses React. Web components would be better than everyone using React. Arguably everyone using Svelte could be better still but that’s a separate debate.

> your response brings up React as if it somehow changes that.

It does. Because the industry clearly has no problem with a large upfront cost, given that it imposes one today. Web components would be better than what we have today even if it isn’t the ideal.

You absolutely can judge tools by how they are used, especially if said tool encourages poor usage.
Except, any beginner can make a mess with anything. Methodologies and frameworks evolve, but not all create any for beginners.
You can judge React, but like I said, not frontend. You're responding to an argument I didn't make.
React has one up-front size for rendering code whether you use 1 component or 10,000 components.

Svelte and Lit rendering code size just keeps going up, and up, and up....

You can argue about which is better, but this kind of naive size comparison is disingenuous.

While it’s true that Svelte and Lit can grow in size dependent on project there’s no world in which even large projects get close to the base level of the React runtime.
Reddit rewrote a small part of their website with web components using lit. 100+ requests and over a megabyte of Javascript to render a side menu.

Because they probably did the "several runtimes don't matter" thing, and every tiny component loads the full lit runtime

I have no idea about that but if the figures you’re providing are correct it’s pretty obvious the answer is that they did it wrong. There is nothing in the web component API that would require 100+ requests nor several MB of JS, especially when you’re in control of every step in the process!
> every tiny component loads the full lit runtime

This is just not true.

Why does it need 100+ requests and over a megabyte of JS then?

Edit: when it was "unveiled" the sum total of JS was 178 requests totaling 1.37 MB: https://x.com/dmitriid/status/1777404560316707052

I don't know, but it only loads one copy of Lit.
Only if you are doing it wrong. https://lit.dev/docs/tools/publishing/