Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.
I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?
Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
> a single component outweighing an entire app feels fundamentally broken.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
> a single component outweighing an entire app feels fundamentally broken
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.
A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.
If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.
> If Preact truly was as feature complete as React, it would be used by everyone by now
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.
There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:
- accessibility
- amount of libraries with plug-and-play solutions to common problems
- security
- scalability
- rendering performance
- maintainability
- browser support
- browser extension interference
- hundreds of other niche edge-cases that someone will eventually run into but are non-obvious until it's widely used
React is really well-thought out and well made by hundreds of professional contributors that have worked on it for years. The premise that hobbyists can make a better overall solution in less than 8 months is strange. At best they can make a smaller solution, but it will have to sacrifice in other areas.
React and the react ecosystem fail at many of the criteria you’ve listed. You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react. Lots of sites have massive issues with rendering performance, scalability and maintainability even with react.
What react does do is give you a clean separation of concerns across team boundaries and allow for reusable components . But the cost you pay for that is a boat load of overhead, complexity, maintainability concerns, and react specific edge cases
A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
It’s not just about the size of the payload, it’s about the stuff happening in the background and the constant diffing of the various DOMs that react has. I can tell I’m on a react site by how laggy it is. Some devs manage to do better but I can still tell.
Another wonderful feature of react is it will fully render the page on my iPad and then quickly replace it with an error message. Absolute brilliance.
> You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react.
> A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
Perfectly proving my point.
It's not react-the-framework's fault, yet those sites are always react sites.
This is the "everyone who drinks water dies, therefore drinking water is deadly" argument. I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent. You're also forgetting about the trillions of wordpress (and similar) websites that exist.
It’s much more of a “everyone who chooses this flavor of soda dies”. Maybe it’s the soda, maybe it’s the people it attracts.
> I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent.
And this is the “you’re holding it wrong” argument.
Facebook and Airbnb are the poster children for react (one of them wrote react). They are both perfect examples of absolutely disastrously monsters of websites plagued with issues related to all of the problems react supposedly solved.
Depends on the project. For websites I like to use a statically generated Nextjs site served by nginx[1] and for SPAs Nginx that serves a Vite-built static bundle with a backend that’s in whatever language the backend team chose.
You didn't ask me, but I have what seems like an esoteric use for React: I only use React for the components, because vanilla/native web components are a major pain in the ass to work with.
You don’t need to wrestle with React’s state management monster unless you’re into that sort of thing.
While Google Translate's interference sucks, with current browser tools, I don't think they can really operate any other way.
This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.
There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.
Unfortunately browsers don't really provide good solutions for extensions that need to inject or change sites. Look at Google's owner in-browser translate extension, its DOM manipulation breaks many interactive apps as well. There are no tools available in browsers for it to not need to do that.
It's not just noise though; clients are actually experiencing crashes and other issues because of it. I wrote an in-depth article on the Google Translate extension's interference of React (and other webapps): https://martijnhols.nl/blog/everything-about-google-translat...
It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.
Makes me wonder if you can use this to hijack their plugin. At the very least you should be able to inject text into it, but you can probably render a pretty little login form as well, abusing the trust the user has in their extension. Is injecting elements into a document controlled by others really safe?
How would this work? They are injecting CSS into your page, but you can't inject anything into the extension UI from a website. The only thing you could do would be to emulate the extension UI in your website, but for that you don't need to inject anything. You can just copy the design.
The article mentions they inject a web component. I imagine a bad actor could add something to that. In this case at the very least the author could add a "I hacked your Grammarly extension" text just via CSS, but I'm sure you can go much further, even more so with other extensions (eg password managers).
But you could also just add you own lookalike web component to you page that looks like the grammarly one. If people enter credentials there, it's user error.
At no point would I say web development is super simple. It's hard to get started, it's hard when something gets larger/more used, and it's hard when things are massive.
There are so many things to consider, as the original post shows. On top of that is:
- accessibility
- screen reader support
- testing
- usability
- animations/transitions can help and are another can of worms
- SEO
- consistent user elements -> interface components
- responsiveness
- performance
- minification
- lazy loading images
- optimizing images (eg serving a 200 kB webp/avif instead of a 5MB JPG)
- caching/scaling so your server doesn't go down when Hacker News/Reddit links to it
- hosting cost
- security
- CORS
- CSP
- forms
- validation
- feedback
- helping users fill it in correctly with as little friction as possible
- user content sanitization
- rate limiting
- licensing
- of the content you make
- images you use
- libraries you use
Your toolset might work for a simple website that nobody will visit, but if you actually care about providing the best experience you might want something more.
Half of these are literally an import and 2-5 lines away in .NET, Rails, Spring, etc.
Most of the others are a 2-3 npm installs away in the frontend, and a few are not used by extremely popular sites like archive.org, Wikipedia nor this very site.
So long as your article has a decent enough structure – which this article makes it seem is the only thing that matters – I reckon there are two ways to make blog posts that developers read and share;
1. make so many of them, you'll repeatedly hit gold eventually
2. go the extra yard with research and/or effort
The intro's "The developer had interesting insights" makes it sound like they failed blog was full of opinion pieces. Very few opinion pieces succeed, but they're the easiest to write (i.e. the first category). It might work for some people, but for us unknowns, nobody really cares. Go the extra yard and make it interesting by doing a deep dive of the subject.
I've fully focussed on the second approach. As a consequence, each article takes a lot of time to complete, so I generally don't finish more than one per month. I try to make them all something I can actually be proud of (which is quite a challenge), and then I spend a lot of time tweaking the structure, making things less verbose, and improving scanability – I rely on making sentences bold a lot for that. I try to use relevant images, but I find actually helpful ones are hard to make for developer content. While hiring illustrators is a good idea, I doubt many writers are willing to pay for that.
To make my articles more interesting, I try to make a custom component for each article to spice it up and slowly grow the component library I have available for my blog. It doesn't always work though – for my last article I spent several hours building an easter egg that only 22 people (<0.1%) interacted with it.
I would absolutely not go the extra yard with research/effort until you have an audience for your blog. I've seen plenty of well thought out, in depth posts get zero traction because the blog wasn't established, and plenty of off the cuff short brain dump posts from established blogs get front page HN traction.
This wasn't my experience. Hacker News felt surprisingly welcoming as soon as I upped the depth and reduced the opinion.
There are some areas I noticed Hacker News isn't very interested in, such as web accessibility (other platforms picked that up much better), but I think that has more to do with the not-as-exciting subject than the writer/blog.
> I've fully focussed on the second approach. As a consequence, each article takes a lot of time to complete, so I generally don't finish more than one per month.
This is what I've been running into. My approach comes out of writing a bunch of code or re-writing the same sort of code across multiple projects and realizing it would be useful to share. Next I'll dump all the code into a blog post and have to start formulating what the structure of the post will be. What content do I need to add to support my claims that this code is correct (or correct enough to use)? Add in time to research alternative approaches to the code, research and write about the alternatives.
I've found that I'm proud of my finished articles but it takes awhile to get them written. I'm in the midst of one that I've kind of hit a writers block on because I have a fair bit of research left to do. I haven't been motivated to do the research and write up the findings. However, I feel like thats normal and I'll get back to it at some point.
>So long as your article has a decent enough structure – which this article makes it seem is the only thing that matters.
Author here.
I hope I didn't give the impression that structure is all that matters, as that's not what I believe.
I think all the usual advice about choosing an interesting topic and writing well apply too, but I tried to focus in this article on blogging advice I don't see people discuss.
Even on European servers, it’s still controlled by a US organisation, so if Bitwarden is required to shut down access, they will. For an example where this happens, this court verdict from The Netherlands shows Microsoft's Dutch branch refusing to grant access to data (on its EU servers) of a Dutch company, to a Dutch curator who by law must be given access, because of trade sanctions on the majority owner: https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBAMS:2...
I expected it to be much harder to move away from these services I heavily relied on like Microsoft 365. Before I started migrating it figured I was so entangled in their web, that switching to an alternative would be a tremendous task. After actually migrating these services, I managed to migrate 90% within a few hours per service. This is nowhere near the amount of effort I expected it needed. Because of that, I'm also optimistic about migrating Git and NPM. While I don't think NPM will be any different, I suppose my optimism about Git might be misguided because of the amount of customization that goes into setting up CI/CD. Still, since only one out of all of the services might be hard - one that doesn't handle any PII - I stand by saying the overall effort was easier than expected.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.