Comment by ikurei

Comment by ikurei 4 days ago

78 replies

View on Hacker News

I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...

> The issue is that these huge frameworks have made the web a horrible slow mess.

I don't think this is accurate. Most bloat in the web is caused by:

a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)

b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible

(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)

React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.

If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.

As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?

mpweiher 3 days ago

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)

Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.

Reply View 14 replies
  • branko_d 3 days ago

    > Networks are fast.

    Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.

    Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).

    Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.

    Reply View 0 replies
  • nicce 3 days ago

    > Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

    Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.

    Reply View 0 replies
  • tmpz22 3 days ago

    Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.

    Check out google maps there’s more to the world than your open office.

    Reply View 11 replies
    • HappMacDonald 3 days ago

      His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.

      Reply View 0 replies
    • [removed] 3 days ago
      [deleted]
      Reply View 0 replies
    • mpweiher 3 days ago

      How would you spec such a "lower powered" Android device?

      Reply View 7 replies
      • panstromek a day ago

        Alex Russel did a lot of writing on this and posts yearly updates based on the state of the phone market. You can pick median, P75 or P95 device based on the analysis and set up targets based on that.

        https://infrequently.org/2024/01/performance-inequality-gap-...

        I did it the simple way and bought a first item in "sort by cheapest" smartphone list. That's Alcatel 1, and it's extremely underpowered. It's maybe a bit overkill, but if something runs on that device, it will run amazing on anything else.

        Reply View 6 replies
regularfry 4 days ago

> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.

Characterising it as "if the developer cares" puts the blame in entirely the wrong place.

Reply View 28 replies
  • soulofmischief 3 days ago

    It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.

    I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.

    Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

    Reply View 13 replies
    • johnisgood 3 days ago

      > The majority of web developers today suck

      Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.

      I do not even know if they would classify as "junior" devs.

      This does not apply to ALL web developers, but many.

      Reply View 1 reply
      • maccard 3 days ago

        They still existed and wrote shitty code 20 years ago, or 30 years ago.

        Reply View 0 replies
    • injidup 3 days ago

      > React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year

      proceeds to shame and suggests changing to the new paragdigm of the year.

      > For a framework meant for serious adults

      Reply View 2 replies
      • soulofmischief 3 days ago

        I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time.

        And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.

        Nice try, though!

        Reply View 0 replies
    • branko_d 3 days ago

      > Also, React is a nightmare.

      I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.

      However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.

      Reply View 0 replies
    • lexlash 3 days ago

      I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.

      React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.

      https://mithril.js.org/

      Reply View 0 replies
    • bryanrasmussen 3 days ago

      I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.

      Reply View 5 replies
      • soulofmischief 3 days ago

        Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?

        Reply View 4 replies
  • cbm-vic-20 3 days ago

    I've seen this happen many times:

    Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.

    PM: Looks great! Okay, the next thing is...

    Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.

    PM: This looks fine. Let's move on to the next thing..

    Reply View 9 replies
    • mattgreenrocks 3 days ago

      If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.

      But the system persists because both people are complicit.

      Reply View 0 replies
    • tonyedgecombe 3 days ago

      Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page.

      https://balsamiq.com/product/

      Reply View 6 replies
      • pmontra 3 days ago

        When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.

        Reply View 5 replies
  • friendzis 3 days ago

    How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?

    Why don't those developers that care put important things the AC/DoD?

    Reply View 1 reply
  • ikurei 2 days ago

    That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.

    The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.

    Reply View 0 replies
  • maccard 3 days ago

    I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.

    Reply View 0 replies
brundolf 4 days ago

I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up

It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code

Reply View 0 replies
cowsandmilk 4 days ago

> developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.

Reply View 2 replies
  • jack_riminton 4 days ago

    Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument

    Reply View 0 replies
  • branko_d 3 days ago

    We built a document management system as React SPA which is very performant.

    Key: when user clicks on something, this causes 0 to 1 HTTP requests.

    We didn’t do lazy loading or caching either.

    Reply View 0 replies
ben_w 4 days ago

> the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Just the other day I was appalled by a new record, 1604.

I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.

Reply View 5 replies
  • pavlov 4 days ago

    EU has laws that give back control to users.

    But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)

    Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.

    Reply View 2 replies
    • CodesInChaos 3 days ago

      > the browser should be cooperating and working on the user’s behalf to limit tracking

      I hear Microsoft is working on a new browser that gives the user more control over cookies:

      1. It shows a confirmation dialog before setting a cookie

      2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.

      They plan to call it "Internet Explorer" or something.

      Reply View 1 reply
      • [removed] 3 days ago
        [deleted]
        Reply View 0 replies
  • spockz 3 days ago

    Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?

    I didn’t even know there were 1600 different distinct trackers around.

    Reply View 1 reply
    • whstl 3 days ago

      Did the page have any ads? Because ads themselves often also contain lots of third-party tools, for fraud detection, the bidding part, tracking, retargetting...

      Reply View 0 replies
ksec 3 days ago

>the 300 tracking scripts every site has to try to squeeze as much revenue as possible

Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.

Reply View 5 replies
  • whstl 3 days ago

    The reason we still have 300 scripts is that ad-tech companies want direct control over their tracking rather than relying on an intermediary.

    So they make it harder or more limited to integrate with tools like Segment.

    Reply View 0 replies
  • ivan_gammel 3 days ago

    > why cant we have ONE scripts to rule them all

    Because those tracking scripts are provided by competing advertising platforms and they want to own the data.

    Reply View 3 replies
    • PaulHoule 3 days ago

      Nobody trusts anybody else. The site wants to over estimate clicks, the advertiser wants to under estimate. Of course the numbers won’t match up because you lose people along the way. If you have 300 trackers they can’t all be lying to you.

      Reply View 2 replies
      • ivan_gammel 3 days ago

        >The site wants to over estimate clicks, the advertiser wants to under estimate

        Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.

        Reply View 0 replies
      • ksec 3 days ago

        Arh! That makes a lot more sense. Thank You. Sometimes I do wish I could learn a lot more about online advertising. But it is mostly a forbidden topic on HN.

        Reply View 0 replies
andrewingram 4 days ago

Yeah, I think both these are true:

1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.

Reply View 17 replies
  • MartijnHols 4 days ago

    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.

    Reply View 16 replies
    • whstl 3 days ago

      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.

      Reply View 2 replies
      • MartijnHols 3 days ago

        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.

        Reply View 1 reply
        • whstl 3 days ago

          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.

          Reply View 0 replies
    • tipiirai 3 days ago

      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.

      Reply View 3 replies
      • dhruvrajvanshi 3 days ago

        > 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.

        Reply View 0 replies
      • ipsento606 3 days ago

        > 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.

        Reply View 0 replies
      • ikurei 3 days ago

        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 ;)

        Reply View 0 replies
    • afavour 3 days ago

      Compare React and Preact:

      https://preactjs.com/

      I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.

      Reply View 8 replies
      • PaulHoule 3 days ago

        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.

        Reply View 2 replies
      • MartijnHols 3 days ago

        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.

        Reply View 4 replies