[HN Gopher] React 19 almost made the internet slower
___________________________________________________________________
React 19 almost made the internet slower
Author : henriqueinonhe
Score : 129 points
Date : 2024-06-17 14:14 UTC (8 hours ago)
(HTM) web link (blog.codeminer42.com)
(TXT) w3m dump (blog.codeminer42.com)
| 0xblinq wrote:
| I'm so done with React. Since Vercel kidnapped it everything is
| done for/because of their platform and their interests. Most evil
| company I've seen in a long time.
| hipadev23 wrote:
| An innocent dev was just overcharged $5k by Vercel while
| reading your comment.
| STRiDEX wrote:
| driven by facebook in this case
| https://x.com/sophiebits/status/1800966114048147495
| realusername wrote:
| The whole js ecosystem is insanity, React isn't even the worst
| offender, it's a machine to generate complexity.
|
| My controversial opinion is still the same, the less front-end
| you have in your stack, the easiest you'll be able to scale.
| rglover wrote:
| Yargh, there still be some sanity left on these seas [1].
|
| [1] https://github.com/cheatcode/joystick
| whoknowsidont wrote:
| >The whole js ecosystem is insanity
|
| This is such a lazy, grandstandy, unoriginal take.
|
| >My controversial opinion is still the same
|
| It's not controversial it's just tired and ignorant.
| realusername wrote:
| > It's not controversial it's just tired and ignorant
|
| Tired maybe but not ignorant since I helped to maintain two
| React SPAs for 6 years now so I'm pretty aware how bad it
| is.
| theultdev wrote:
| Well, still a subjective take.
|
| Heavy use of interactivity is hard. React makes it
| maintainable. It was hell before.
|
| I've been working with React (and RN) since it came out
| and I've had nothing but good experiences, especially
| compared to the previous decade before React.
|
| My motto is local-first, the more stuff the client does,
| the cheaper it is to scale and less bridging between the
| server you have to do.
|
| Move everything to the client, especially the database.
| Let the database do the syncing. Plus you get offline and
| undo/redo basically for free. Pagination? Fuggetaboutit.
| MBCook wrote:
| (Not a GP). Yeah. I use and like React. I don't have an
| issue with it. It's not tiny but it does a lot of work
| and makes my life easy.
|
| My general complaint is the JS ecosystem in general and
| its tooling.
| apsurd wrote:
| > Heavy use of interactivity is hard. React makes it
| maintainable. It was hell before.
|
| Agree, React is great for UI interactivity.
|
| > ...the more stuff the client does, the cheaper it is to
| scale and less bridging between the server you have to
| do.
|
| Disagree. The most costly form of scaling is people. UI +
| business-logic + data-modeling + data access (ACL) all
| held in async client concepts is a complexity nightmare
| in my experience. Even for my team-of-one side-projects.
|
| Server <-> client bridge is a feature for managing
| complexity over time. I may agree that added ceremony
| could make 95% tile app experiences default harder. But
| for anything that's not a toy, the #1 risk is always
| team/people/communication complexity.
| realusername wrote:
| The more stuff the client does, the higher the payload is
| going to be and the more complex the bundling and tooling
| will be.
|
| I'm in a company with around 100 devs now and I can
| certify you that front-end SPA do not scale at all unless
| you throw a insane amount of devs hours in the tooling,
| even then it barely does.
|
| That's not mentioning the insane npm churn that you have
| to maintain, the testing story which is pretty abysmal
| outside of a few top libraries, the typescript tooling
| which is eating so much ram that I'm changing my laptop.
|
| And I'm not sure why you mention the pagination as a plus
| where it's one of the big downsides of the front-end
| stack, there's a lot of hacks to make it behave okay in
| most situations.
| ivan_gammel wrote:
| > I'm in a company with around 100 devs now and I can
| certify you that front-end SPA do not scale at all
|
| What is the difference between SPAs and other monolithic
| architectures, e.g. on desktop, that makes it so? Why
| can't you go with OSGI-style plugins, for example? Loose
| coupling, separate SDLC and deployments etc?
| Capricorn2481 wrote:
| > My controversial opinion is still the same
|
| This is the most popular opinion on HN. If anything, it's
| controversial to say React isn't a dumpster fire
| nine_k wrote:
| In general, the less code you have, the better.
|
| Sadly, many products require sophisticated frontends, the FE
| is often a core part of the value proposition. React may be
| overkill in smaller cases, but it's a good tool in these
| cases of complex dynamic UIs.
| freedomben wrote:
| Exactly. Things like LiveView (Phoenix) are changing the
| game somewhat, but if you need a sophisticated frontend,
| React is still a good way to go. PWAs in particular I think
| still have a lot of promise, even if they are being
| (intentionally) stifled by tech companies that have
| competing interests and want web apps to be as impotent as
| possible.
|
| For simple frontends that don't need to be complex UIs, I
| definitely don't turn to React (I love simple tried-and-
| true templating systems like ERB and/or EEX), but I
| definitely think React has it's place. Not everything
| should be SPA, but that doesn't mean nothing should.
| hnthrowaway6543 wrote:
| average HN commenter: React is artificial complexity, you
| should be able to make any website using jQuery and plain
| HTML, because that's what I did when I last did front-end
| development in 2007.
|
| also average HN commenter: If you use Python for your backend
| you're a moron, you need to use Rust so the API calls for
| your 0.5 requests/sec web app finish in 100ms instead of
| 125ms (note: 99ms is waiting for the database).
| realusername wrote:
| I've been maintaining React SPAs for 6 years now so I
| absolutely know what I'm taking about when I say that it
| doesn't scale. I experienced all the pains of the js
| ecosystem.
| bushbaba wrote:
| JS Ecosystem just has too much churn. Every 5 years there's
| some new better way of doing things.
| Capricorn2481 wrote:
| What's a negative development in React that was only for
| Vercel?
| johnfn wrote:
| The article says that React was about to make a change, the
| community pointed out it had bad trade-offs, and React backed
| off. What does that have to do with Vercel? Where's the problem
| with React here?
| tmpz22 wrote:
| Vercel is a (more?) opinionated ecosystem that influences
| higher adoption of Server-Side-Rendering and other features.
| This encourages projects to use more niche APIs like
| Suspense, and due to the capital, marketing, and bearish
| adoption of Vercel products by vocal parties (startups) -
| will influence React's developers to cater to them.
|
| I'm agnostic because I quit full stack web development ~6
| months ago. I think the product development story sucks and
| combined with the market economics of the current tech
| industry is just not fun or profitable to invest my career
| in.
|
| It's -probably- a good thing that stuff like SSR becomes
| mainstream/required. But I really don't like that one of the
| main entities behind it, Vercel, has raised $563M as of their
| latest Series E as they steam towards an IPO of their
| Framework/Cloud offerings.
| mglikesbikes wrote:
| What are you doing after quitting full stack web dev?
| epolanski wrote:
| I don't mind writing react but Vue and Nuxt are saner choices
| if you want great out of the box performance.
| sesm wrote:
| Which Next are you talking about here?
| epolanski wrote:
| Edited, meant Nuxt
| madeofpalk wrote:
| " Most evil company " is quite the statement about some silly
| javascript library.
| sergiotapia wrote:
| This is precisely what happened and is still happening today.
| And remember, this company pays a lot of money for tech
| influencers as well.
| vlaaad wrote:
| Ugh, this post is so much drama, while the actual events are
| pretty boring and happen all the time. React team changes
| something, there are unintended consequences, the change is
| reverted.
| Capricorn2481 wrote:
| There will never be more FUD on HN than a React article
| dylan604 wrote:
| I think you're entirely forgetting about Rust, AI/ML/whatevs,
| or any of the other myriad topics delivered daily. It's what
| happens when you open up comments from anyone anywhere at
| anytime.
| Capricorn2481 wrote:
| ? I have never seen a bad comment about Rust on here. Seems
| like there's lots of certainty about it.
| randomdata wrote:
| It was time for the regularly scheduled Rust
| advertisement again.
| Capricorn2481 wrote:
| That's not an advertisement from me, but pointing out
| that people hype Rust on here.
| lucsky wrote:
| Try to mention Electron and see what happens... :>
| baobun wrote:
| Show HN: I ported MetaMask to Electron [flagged]
| intelVISA wrote:
| [dead]
| TiredOfLife wrote:
| You haven't seen threads about Microsoft.
| meiraleal wrote:
| To call it unintended consequences you didn't understand the
| post.
| crubier wrote:
| Yes, it was very much intended consequences, based on their
| perception of usage and what usage should be like, which was
| biased. They admitted it and plan on reverting though.
| terandle wrote:
| "This gives us the best performance characteristics when you're
| following best practices (i.e. hoist data fetches to Server
| Components or route loaders), at the expense of making an already
| bad pattern a bit worse." [1]
|
| Their rational was pretty solid in the PR, but seems they
| overestimated how ready the community is to embrace newer best
| practices and they are back tracking.
|
| [1] https://github.com/facebook/react/pull/26380
| fabian2k wrote:
| My impression from the later responses was that they
| underestimated how often this particular pattern for parallel
| loading with React Suspense is used. The people that are slow
| to embrace the newer patterns would likely not have used
| Suspense at all, so nothing would have changed for them. This
| would have affected a specific subset of people that used
| Suspense for parallel loading, but didn't switch to route
| loaders.
| diob wrote:
| I hadn't heard of route loaders till all this.
|
| What are they, in plain terms? Is it just manually hoisting
| what you know a route needs all the way to the top of the
| tree? Or is it some compile time magic that analyzes your
| components used, making the decision for you on what to fetch
| for a route?
| fabian2k wrote:
| Haven't used them myself yet. As far as I understand it's
| essentially moving the data loading into the router. The
| router has an API for the loaders so the rest will work
| automatically like loading states. So yes, this means you
| have to define what to load at the top where you define the
| routes. Though I think this also works with nested routes,
| but I don't have any experience with them.
| svieira wrote:
| It's either/both - the "simple" method is to manually host.
| The more complex methods use runtime or compile-time
| reflection on the code to determine what gets loaded when
| (a la https://engineering.fb.com/2020/05/08/web/facebook-
| redesign/...)
| eddd-ddde wrote:
| I'm familiar with route loaders from Qwik, I imagine they
| are similar.
|
| Essentially data fetching starts as soon as possible. Right
| after routing, right before rendering.
| Zenzero wrote:
| It feels like the react team has decoupled from the best
| interests of the community. Much of the appeal of react was in
| building the SPA. There are so many web apps that are best
| built in react on the frontend. Instead we now get this Vercel-
| driven RSC use-client mess which is of little benefit to the
| SPA crowd.
|
| The fact that the suspense change made it this far shows how
| the react team has lost focus. Now more than ever, the
| ecosystem is really primed for a competing framework to
| dethrone react. I say this as someone that has invested a lot
| into using react.
| pkilgore wrote:
| Preact is a delight an contains non of this nonsense (yet).
| hoten wrote:
| This seems unfair given how the team reverted the change. You
| can argue they messed up and maybe aren't as in tune to some
| segment of their user base as they should be, but not that
| they aren't interested in making the best software they can
| for everyone.
| ssahoo wrote:
| Shutout for Svelte. It took the best of VUE and react. It's fast
| and very lightweight when compared to Vue, which has a largish
| ecosystem.
|
| https://svelte.dev/
| sertraline wrote:
| I come to think that corporate people love React because if you
| stop following the news and not be constantly reminded about
| the direction React is currently heading, you will fall out of
| the loop and your projects will stop working in 1 year or so.
| Which is beneficial for the employees, as they will never run
| out of work to do, maintaining the framework itself rather than
| their actual project. And the framework gets more complex with
| each year, too, so you can pretend that you are doing some
| complex work without actually doing it.
| buremba wrote:
| ^ Exactly my feelings about React. The sad truth is that
| React is still viable for startups as the ecosystem has the
| most extensive librarie.
| _puk wrote:
| I love svelte, and is what I reach for personally, but it's
| still early enough in its lifecycle that there's constant
| changes / new paradigms being introduced, especially if you
| include svelte-kit (originally it used sapper).
|
| If I had a team that had gone all in on Svelte I'd be bemoaning
| the need to upgrade recent code already.
| Capricorn2481 wrote:
| There's literally more churn in Svelte than there is in the
| React library
| moffkalast wrote:
| Hot take time: React is the most corporate framework to have
| ever corporated in the history of corporate, designed for one
| thing first and foremost: To make high turnover easier so they
| can fire you at any time and replace you with the next guy in
| line who'll already know how the entire thing works... because
| there is only one stupid way to do things in React. You either
| like it or it feels like pulling teeth.
|
| I'm up for cheering for literally any alternative. Any.
| lominming wrote:
| I did an evaluation on the various frameworks 2 years ago, and it
| largely came down to only these 2 choices:
|
| - React (if you want the largest support, packages, community,
| but sacrifice on performance) - SolidJS [1] (best performance,
| composability, low-level primitives, but sacrifice on
| packages/community)
|
| Every other choice like Angular, Vue, Svelte are just somewhere
| in between these 2 spectrums which I felt was not worth it.
| Either choose the one with the largest ecosystem or one which has
| the best primitives & performance.
|
| - React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than
| react) (large community) - Svelte (fine-grain, faster) (best dx
| pre-v5) (composability is still not as flexible in v5 compared to
| SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most
| consistent) (dx similar to react) (small ecosystem)
|
| [1] https://www.solidjs.com/
| Etheryte wrote:
| In all honesty, I think neither one of those are the main
| measurement you should be using from a business point of view.
| React has a huge ecosystem, but many packages are out of date
| or poorly maintained. This means you either still roll your own
| or you take on the pain of working with the bugs or compat
| mismatches you inevitably get (looking at you, React 18). On
| the other end, I would say for the majority of modern web apps,
| performance doesn't matter too much, so long as it isn't
| absolutely abysmal. So what are the right metrics, in my
| subjective opinion? Readability, and by extension
| refactorability, and ease of iteration. In other words,
| developer experience, because that will literally save your
| business actual time and money.
| otabdeveloper4 wrote:
| Never met a corporate SPA that didn't have abysmal
| performance.
|
| That said, framework choice isn't the problem, frontend devs
| having no clue how to design and use API's is.
| zdragnar wrote:
| Corporations fill their ranks with junior developers, more
| breaking news at 11.
|
| I remember plenty of multi page applications from big corp
| that ran like a dead dog too, back in the day. Or ASP sites
| that wrapped the ENTIRE page in a form, with all of the
| frustrating complications that entailed.
| tracker1 wrote:
| Hated ASP.Net WebForms over dialup for sure... massive
| view state, it was a mess.
| tracker1 wrote:
| I think bringing in component libraries that include the
| kitchen sink, the farmhouse and the farm... as well as the
| neighbors farm are a big issue too.
| resoluteteeth wrote:
| If you really think the performance of the framework is
| something you need to optimize but want to keep the react
| ecosystem, you could also use react (or preact) with preact
| signals which I think should make react perform more like
| newer frameworks like solidjs in terms of not rerendering
| entire trees of components unnecessarily.
|
| I'm not sure this is really the first thing that needs to be
| optimized for most people though, despite there being a lot
| of frameworks whose sole reason for existence seems to be
| fixing this aspect of react's performance.
| user3939382 wrote:
| The value proposition of Vue to me is, "We looked hard at all
| tools out there, especially react, and iterated on it to make
| it nicer to use."
| onion2k wrote:
| Any slow app would be just as slow if the team had built it
| using different tech, because it's the design of the software
| that makes it slow, not the framework.
|
| There is no framework that has a "pit of success" that makes it
| inherently easy to build a fast app, so any team that uses a
| framework poorly is just as likely to use a different framework
| poorly. If they switch and things improve it's probably because
| the new framework happens to fit their mental model rather than
| any inherent function of the framework itself.
|
| A good team that designs their code to make the most of a
| framework could write a good, fast app using any particular
| tech.
| WorldMaker wrote:
| I've spent a lot of time thinking about what the "pit of
| success" looks like for a framework to make it inherently
| easy to build a well performing app ("fast" is a different
| subjective matter), even in some of the worst cases of a
| naive developer doing naive things. (I think I got really
| close to a "pit of success" with Butterfloat if you enjoy
| working with RxJS. Its defaults are tuned for smooth
| performance even if you are doing too much work in a
| component.)
|
| There's no framework that has a "pit of success" on every
| subjective performance quality metric, but I do think some
| frameworks more than others have larger "pits of failure"
| that make it too easy to get bad performance even doing what
| you think is supposed to be the right thing. Because I've
| vocally picked on it many times at this point, an easy
| example to mind is Angular's Zone.js is a big opaque library
| that can accidentally drop you into a "pit of failure"
| without you realizing how you got there. I'm glad a couple
| years after I raised some warning flags about Zone.js that
| Angular is finally addressing that elephant in the room and
| removing Zone.js as the suggested option and are close to
| removing it as the default option.
|
| (I'm less glad that the reason that finally pushed them to do
| that is adding Signals. It seems wild to me to have proper
| Observables and also Signals and that just seems like another
| potential pit full of accidentally doing the wrong thing
| because it looks easy but the interactions between imperative
| code, Signals, and Observables is going to necessarily be
| complex and fraught with scheduling problems. I can't say
| that I'm surprised that Angular development is again moving
| one step forward while also two steps back at the same time.)
|
| I know others with similar rants about React Hooks and how
| easy it is to miss needed dependencies in the dependency list
| of a Hook and too easily fall into a pit of failure.
|
| It is useful to evaluate frameworks with some small eye to
| "how hard does this make it to do performance right if we
| follow its 'best practices', even in the case of simple
| mistakes?"
| norman784 wrote:
| Well TBH svelte works just fine with vanilla javascript
| libraries, so you could argue that the ecosystem is not as
| small as you think. Almost every other library/framework in
| this space requires a wrapper around the vanilla javascript
| library.
| mightyham wrote:
| You can make the same argument then for SolidJS. Almost every
| vanilla JS library works fine with it without a need for
| wrappers.
| steve_adams_86 wrote:
| People who love Angular really love it, so I trust that there's
| a legitimate place for it. I think one of the main things
| people love is that the convention and tooling eliminates a ton
| of the noise and redundancy that the other tools tend to lead
| to as teams slap applications together without sufficient guard
| rails.
|
| Essentially a lot of the tools we use are only meant to be view
| layers, and we constantly cobble together supporting layers
| (models and controllers for example) ad-hoc. Angular handles
| that off the shelf. I suspect a lot of people are put off by
| this because it feels imposing and they might not realize
| they're implementing the same stuff manually, and likely doing
| it worse.
|
| I used to think it's plain old garbage but realized that's
| ridiculous. There are reasons people prefer it in some
| scenarios.
|
| SolidJS is my favourite by a long shot, but I find myself using
| React because I know so many people I write for and work with
| are more comfortable with it. I'd be glad to use it more often
| if it made sense.
| dottjt wrote:
| I'm currently learning Angular and it's an absolute dumpster
| fire of a framework in the sense that it offers no clear
| philosophy. It's just a jumbled mess of concepts and syntax.
|
| I think where it shines though is that it's completely
| batteries included, which I can see being useful for large
| enterprises where it's near impossible to change things.
|
| Having recently worked on a very legacy React app, it became
| apparent to me the value of frameworks like Angular. If you
| can maintain it and upgrade it gradually, React is arguably
| the better choice. But if you're leaving it to stagnate,
| Angular is a far better proposition.
| WorldMaker wrote:
| So much of Angular versus React is "No one got fired for
| picking Google tech" versus "No one got fired for picking
| Meta tech" with some of the obvious problems of their
| "parent" organizations' approaches visible in the
| maintenance efforts.
| pie_flavor wrote:
| This seems to completely throw out DX. Svelte is an enormous
| productivity increase from SolidJS, trading microseconds of
| performance for that (Svelte is still _very_ fast) does not
| seem worth it at all. That 's like saying your two choices are
| Python and C, Rust not being worth it.
| ComputerGuru wrote:
| > That's like saying your two choices are Python and C, Rust
| not being worth it.
|
| Not a great example since that's actually why all the other
| propositioned system language replacements never took off in
| the way rust did. Rust is (or can be, but importantly, when
| used idiomatically and not just "in some form") as fast as C.
|
| There were lots of other languages that tried to replace C
| with better DX but failed because they weren't Pareto
| optimal. So I kind of get GP's point: DX alone won't cut it.
| jonahx wrote:
| > best dx pre-v5
|
| Did something bad happen to dx in svelte in v5?
| afavour wrote:
| One of my criteria these days is portability... web components
| are a frustrating API to use directly but one of the reasons I
| develop with Svelte is that it can produce web components that,
| should we pivot frameworks some day in the future, will be able
| to live inside another framework.
|
| React absolutely fails in that regard. I try not to be a
| conspiracy theorist but I think React actively avoids web
| component compatibility as a form of vendor lock in.
| jmull wrote:
| I wouldn't call the ecosystem of svelte small. Since it adheres
| to HTML and javascript so closely, the effective ecosystem is
| pretty much the things supporting plain javascript and plain
| HTML, which is a lot of things.
|
| (Though two years ago I think sveltekit -- the app framework
| for svelte, without which svelte is incomplete for many cases
| -- may not have been quite ready for production, so it was
| probably fair at the time.)
| windowshopping wrote:
| I feel like the percent of people using suspend is a tiny tiny
| fraction of the percent of people using react. I think this title
| is massively sensationalized.
| remixff2400 wrote:
| The unfortunate part of this is that a large percentage of that
| small percentage is library maintainers, so it matters a lot
| more overall because of their role in the React space, even if
| users aren't necessarily using those features.
| crubier wrote:
| I think you're wrong, without knowing it. And in a way this
| kind of subjective judgment call "people must be using react
| like me I guess" is the entire cause of this misshap.
|
| Don't assume usage patterns. Measure them, or you know nothing.
| Capricorn2481 wrote:
| But you just did the same thing by saying they were wrong.
| Did you measure it?
| refulgentis wrote:
| The change occurred in [March
| 2023](https://github.com/facebook/react/pull/26380) [^1^], and it
| became a hot topic 15 months later? [^2^]
|
| Are React release cycles that long? What's up with the title that
| it "almost" was slower if it was released? I assume I'm missing
| some context here.
|
| [^1^]: grep "This happens because of the following PR:"
|
| [^2^]: article publication date is June 17, 2024, tweet
| screenshots are dated between June 10th and that date
| Uvix wrote:
| Yes, the release cycles between major versions are that long;
| v18 was released March 2022.
| refulgentis wrote:
| Wow. 2y3m and counting (presumably, given article title).
|
| It's very straightforward, yet a complete surprise to me. I
| guess I'm just replying to invite someone else to give me a
| long-winded explanation of how the JS ecosystem works.
|
| ex. now I'm flummoxed as to how Vercel/next.js
| exists/releases new features, if they're based on React.
| Seems you'd either get stuck living on React top of tree,
| unreleased, or have an unholy merge to do.
| Uvix wrote:
| React in particular puts out a point release with breaking
| change warnings, along with an upgrade guide, several
| months before the next major version so that developers
| have plenty of time to prepare for any required changes.
| (For React 19, this was the 18.3 release at the end of
| April 2024.) They also try to provide scripted code updates
| ("codemods") to ease the upgrade process.
|
| This is admittedly rare in the JS ecosystem.
| SahAssar wrote:
| > now I'm flummoxed as to how Vercel/next.js
| exists/releases new features
|
| They run on canary react releases. It's a not that hidden
| dirty "secret".
| norman784 wrote:
| AFAIK React 19 was tagged as RC recently, so that could be the
| issue, people where not using React 19 in the frontend because
| of not being ready
| breadwinner wrote:
| The first problem here is putting a UI widget in charge of
| fetching data. React was originally designed to be the V in MVC.
| Had we left it as the V in MVC we'd be loading data in
| controllers, like we do in every other framework. Having a React
| component be the model, view and controller is a mistake, and we
| can still reverse course.
| 0xblinq wrote:
| That's why I think the most sane way to use React (or Vue)
| nowadays is through Inertia.js.
|
| Have a proper backend doing all the backend stuff and just
| render page components as if they where just the views of the
| framework.
|
| All this server components nonsense is solving a problem that
| maybe Facebook has but almost no one else does. But people
| think they do, so a lot of complexity is added for no real
| reason.
| diob wrote:
| I've never seen a MVC codebase that wasn't a nightmare to work
| in.
| sky2224 wrote:
| Yeah, MVC (and MVVM for that matter), seem like architectural
| approaches that are great in theory, but with the reality of
| constraints, requirements, timelines, and ultimately many
| engineers' misunderstanding of things (frankly I'm probably
| included in that group as well), it just leads to a mess of
| interdependency and tight coupling among functionalities.
|
| Now granted, this is pretty much a given for any architecture
| (nothing is perfect): so maybe my expectations of what things
| _should_ be needs to be reeled in a bit.
| breadwinner wrote:
| > _it just leads to a mess of interdependency and tight
| coupling among functionalities_
|
| Disagree with that. Most UI frameworks, including ASP.NET
| Core, JSP and JSF (Java based frameworks), Ruby on Rails,
| and Django (Python) are all based on MVC. That's no
| accident. MVC works very well.
| perrylaj wrote:
| Going to assume you're talking frontend? Otherwise you'd be
| claiming most Spring, Django, Rails, Angular, <enter common
| backend framework> codebases are a nightmare to work in.
| While there are many good application architectures that
| don't fit into the MVC pattern (or introduce additional
| layers, e.g. - auth), separating DB ops (M) from business
| logic (C) and endpoint handlers (V) has always been rather
| maintainable/testable in my experience.
| randomdata wrote:
| _> React was originally designed to be the V in MVC._
|
| React wasn't designed to fit in the MVC model. However, if we
| are trying to draw an analogy, as far as I can see it most
| closely resembles the controller. It is where the events are
| handled to update the "model" (state), which are propagated to
| the "view" (DOM element). What makes you say V?
| breadwinner wrote:
| "Just the UI: Lots of people use React as the V in MVC. Since
| React makes no assumptions about the rest of your technology
| stack, it's easy to try it out on a small feature in an
| existing project."
|
| Source: https://github.com/facebook/react/tree/015833e5942ce5
| 5cf31ae...
|
| React is good at V, it is not good at M or C.
| randomdata wrote:
| _> React is good at V_
|
| How so? Under MVC, V is the visual representation of the
| model. React does not exist there at all. It relies on the
| DOM and associated technologies to provide that.
|
| React does give a mechanism to keep the visual
| representation in sync with the data and it provides a
| place to handle events that update the data. While it is
| not designed for the MVC model, so we cannot truly speak to
| it in MVC terms, the closest analog to those seem to be the
| M and C.
|
| I'm assuming you had to go back to a commit from 8 years
| ago because all future commits realized that whoever wrote
| that React is the V in MVC was confused?
| breadwinner wrote:
| > _V is the visual representation of the model. React
| does not exist there at all._
|
| Disagree. That's where React exists. Whether you specify
| V using turtle graphics style API, or DOM style markup,
| it is all still V.
| randomdata wrote:
| Consider the React function: function
| Hello() { return <div>Hello</div> }
|
| The div object is where the visual representation is
| handled. React in this case is only concerned with
| passing data to it, which is explicitly the model's
| concern under MVC. Although I suggest that event handling
| is really why people choose React, and that is the
| controller's concern according to MVC.
|
| Again, React isn't designed for the MVC model, so we have
| to really stretch ourselves to find any kind of
| similarities. But if React was only the V to the greatest
| extent that we can pervert the meaning of V, what value
| does it add?
| breadwinner wrote:
| > _what value does it add?_
|
| Efficient updates.
| randomdata wrote:
| Updates are the job of the model under MVC. Are you
| trying to imply that React is meant to serve the M, or
| are you trying to avoid the question?
| BalinKing wrote:
| I think they meant "efficient updates [of the DOM]".
| lcnPylGDnU4H9OF wrote:
| I think what OP and others are talking about when they
| refer to React as being the view part of model-view-
| controller is that a server might render a React
| component in the view layer after the controller has
| decided what data to collect and which layout to use.
|
| I think something other people sometimes talk about are
| single-page applications, in which case it's not a single
| component being rendered but an entire application. At
| that point MVC was simply disregarded by the developers
| because React is really just trying to be the V in MVC.
| randomdata wrote:
| That would be what is known as the template layer, not
| the view layer. If we're just randomly making up
| definitions for MVC, then sure, anything goes. But as
| nobody has provided the the arbitrary definition they
| just came up with off the top of their head, surely we're
| sticking with the standard Smalltalk usage?
| andrewflnr wrote:
| This is much like saying the DOM is not truly part of the
| view because it doesn't directly represent the pixels
| that the user sees. Both the vDOM and actual DOM exist
| entirely to facilitate a particular kind of presentation,
| and can be logically separated from the model which could
| in principle be presented in purely audio format or
| something. If that's not a "view", then what is?
| goatlover wrote:
| I think the point is React does not provide the DOM, the
| browser does. Unlike MVC frameworks in languages that do
| provide their own UI. Smalltalk being the grandfather of
| that.
| Spivak wrote:
| Yes but the DOM is the render target for React and hence
| the V. Just because it's a complicated way to talk to the
| screen doesn't mean it's not doing that.
| williamcotton wrote:
| I use React like the V in MVC for my homemade framework:
|
| https://github.com/williamcotton/williamcotton.com/blob/3
| 719...
|
| That's a link to a route handler (controller) that makes
| a graphql call (model) and then explicitly updates the
| DOM with renderComponent (view).
|
| FWIW, that code runs both client-side and server-side and
| it is written in F# that compiles to both environments.
| randomdata wrote:
| _> That's a link to a route handler (controller) that
| makes a graphql call (model) and then explicitly updates
| the DOM with renderComponent (view)._
|
| See, we're already not talking about MVC. Under MVC, the
| model updates the view. But, as you say, in your code the
| "controller" does the updating. _Maybe_ you could argue
| that React is serving the role of the model here by
| actually being the place where the DOM gets updated, but,
| ultimately, we 're always going to struggle with finding
| such analogies when React isn't designed for the MVC
| model.
| breadwinner wrote:
| > _Under MVC, the model updates the view._
|
| Nope. Under MVC, models knows nothing about view.
| randomdata wrote:
| Right, but the model does know everything about
| signalling change. Under MVC, the model is responsible
| for updating the view through the passage of messages.
|
| Which is essentially one major part of what React tries
| to offer. Granted, in an ugly way as it has to deal with
| the harsh limitations of Javascript instead of having the
| power of Smalltalk to work with, but such is life.
| agumonkey wrote:
| Some argue that React is the R in MVC
| notpachet wrote:
| Some of us are still shipping Redux apps with React as the V
| and life is good.
| gr__or wrote:
| _Caleesi voice:_ React wasn't invented to stop the wheel of
| MVC, it was invented to break the wheel
|
| And I think life is better without the V-C distinction. Models
| ofc still exist but the field has gotten more fine grained for
| the term to still cary meaning
| maliker wrote:
| "almost made the internet slower"... uh, pretty sure it's been
| making things slower since inception when it replaced html + a
| few ajax requests. I know, I know, I'm old. Get off my lawn.
| WolfOliver wrote:
| HN should have a like button for comments
| wizzwizz4 wrote:
| It does: the favourite feature.
| thanatos519 wrote:
| Turing-complete content is an abomination.
| vundercind wrote:
| I remember when AJAX made things _faster_.
|
| Then we stopped sending html to insert into the DOM, and
| started sending JSON with a bunch of extra steps in between.
|
| The fastest sites I see these days usually just reload the
| whole page pretty often.
| tracker1 wrote:
| HTMX for the win!
| INGSOCIALITE wrote:
| htmx is an answer to a question no one asked
| afavour wrote:
| I remember when React first came out... it was actually a dream
| for performance initially. The VDOM diffing made complex, fast
| moving UIs way easier to run performantly.
|
| I lost track of it around maybe version 0.6, by the time I
| picked it up again we were in Redux land and the framework was
| five layers of crap deep. Sigh.
| Waterluvian wrote:
| I'd love to see these narratives actually demonstrated in
| tests via blog posts. I suspect it's more a demonstration of
| human memory and perception than it is of reality.
| plorkyeran wrote:
| Well, you can go back and look at the original blog posts
| announcing React? I assume they're still on the internet
| somewhere. React was a pretty massive speedup over the
| portions of Facebook and Instagram's frontends that it
| replaced and they showed off their benchmarks a lot early
| on. That library had very little in common with the thing
| now known as React, though.
| brazzy wrote:
| Frontend development is the most quickly revolving cycle
| of enshittification I know of.
| theturtletalks wrote:
| Enshittification is when a company offers an amazing
| product, but once they have a hold over the market, they
| make it worse and squeeze customers. It works because
| customers are so locked in and there are market forces
| stopping them from switching to a competitor.
|
| Frontend development is not being enshittified. We have
| so many frameworks that you can switch to if React isn't
| your cup of tea. Hell, you can use Astro and use React,
| Vue, Svlete, etc and it renders to HTML. HTMX is a new
| framework and easy to pivot too since React devs know
| JSX.
|
| React is also silently borrowing ideas from Svelte and
| Solid.js (and those were inspired from React) so all
| these frameworks are improving each other without even
| knowing it.
| Waterluvian wrote:
| This is what I don't really understand when people are
| airing their grievances. What exactly _is_ the problem?
| You can absolutely write webpages and software the same
| way you could 5, 10, 20, etc. years ago. There 's
| absolutely nothing stopping you from making a VanillaJS
| website or JQuery or whatever. Nothing went away. There's
| just more choices.
| theturtletalks wrote:
| Their grip is not with React per se, it's with the
| pressure to use new, updated features. Hooks was like
| this when they were introduced. People were so used to
| using lifecycle functions and then hooks became the
| "official" way. Users could still use classes and
| lifecycle functions, but since it was not the new
| "preferred" way, devs had the pressure to update old
| perfectly working code.
|
| We're seeing the same with RSC. Many Next.js users are
| updating their apps to use the new App Router, but I've
| seen many just stick to the Pages Router since it just
| fucking works for their app and RSC has improvements, but
| none they care about.
| Waterluvian wrote:
| I've got applications that are years behind in React. I
| actually felt the opposite was true: I could upgrade
| React without having to change my code at all. And even
| more awesome: I could gradually use new features without
| touching any existing code.
| jmull wrote:
| > The VDOM diffing made complex, fast moving UIs way easier
| to run performantly.
|
| That was marketing more than reality.
|
| VDOM diffing isn't the slowest way to update complex UIs but
| it isn't the fastest either. In practice your app often ends
| up generating a lot of VDOM which then gets diffed away... a
| bunch of work and then a bunch more work to determine the
| first bunch can be thrown away. The app developer needs to
| step in to manage and optimize the process.
| afavour wrote:
| Believe me, I know. We were manually diffing in a previous
| version before React came along and it was a shitshow.
|
| The primary initial benefit with React was an improvement
| in reliability. Our previous implementation (in Backbone
| IIRC) wasn't doing it quite right. Having it built into
| React was a gamechanger. Then with judicious use of
| shouldComponentUpdate you could minimize the amount of VDOM
| thrashing required.
|
| I know at one point we explored immutable.js to make the
| diffing super efficient but the DX was pretty bad. I'm
| excited for JS to get records and tuples at some point and
| make that all way simpler. But for now it feels like
| shouldComponentUpdate and PureComponent are a lost art of
| React, few do it.
| agumonkey wrote:
| yeah early releases made intermediate stuff very lean and
| fast (as a user), more so than ad-hoc event based
| vanilla/jquery logic spread around (good luck tracking
| dependencies).
|
| but I admit something is off with react somehow (and i'm
| pretty favorable to it usually).
| theturtletalks wrote:
| Something seems off because marrying HTML, CSS, and JS is a
| complex abstraction and with trade-offs. Then you throw in
| SEO, so hydration gets created. Then JS can be used in the
| server too so you have to manage both states. Then, users
| don't want a blank screen, but a loading screen so they
| know the website is working.
|
| Before you know it, you've created a whole new paradigm
| that has it's own sets of new problems, even those solved
| by the original HTML/CSS/JS model.
| prisenco wrote:
| I loved React when it first came out. I never got into MVC
| frameworks like Backbone or Angular because they felt too
| heavy, but React came as a promise that it was only the
| View layer and that provided a lot cohesion, as you say,
| compared to too much jQuery.
|
| But now it just feels so heavy and that the initial
| elegance has been lost to history entirely.
| goostavos wrote:
| >something is off with react
|
| The amount of rope it gave to hang yourself. Hooks were the
| harbinger of the sad state that what was to come.
|
| The OG React was a breath of fresh air because it
| introduced the world to immutable data flow. The component
| model was dead simple. You had a fat (for better or worse)
| class that served as a management point for your side-
| effects and IO, then a bunch of stateless transformation
| functions / components.
|
| The old class + lifecycle methods imposed a much needed
| friction on the development process. Their clunkiness was a
| feature (imo). It raised the cost of creating stateful
| components / performing side-effects wherever you wanted.
|
| Then hooks showed up. In a lot of ways, it feels like React
| is now rediscovering the bad parts of OOP: uncontrolled
| mutation and side-effects. "Immutable data flow" means very
| little when everything is launching side-effects, updating
| some global store, modifying 12 layers of caches, writing
| to local storage, etc. etc. etc. etc.
|
| It became a complete nightmare to reason about what an
| application was actually doing. Most of my experience with
| React (at least as of a year ago) was debugging performance
| issues, or UI quirks from component A clobbering updates
| from component B, because some special GraphQL caching
| magic modifies some global cache somewhere in some
| provider, which is 37 layers removed from the code you're
| actually looking at.
| zogrodea wrote:
| The last paragraph hits close because I've experienced a
| similar issue recently. It turns out some component
| library was responsible for excessive rerenders even when
| idle (eating up the daily quota of read operations on
| some database for a small project).
|
| As a stopgap, I just made a completely unstyled
| alternative to that internal admin dashboard that uses
| Handlebars HTML templating (no Javascript) on the server.
| Inclined me towards dependency rejection (which is an
| approach I was already taking for some side projects).
| the__alchemist wrote:
| When I first learned react and web programming, I was very
| confused about this! React was advertised as fast! From reading
| react docs, articles, tutorials etc. There was a concept called
| "fiber" that was around the corner that would make websites
| even faster; it had demos where pixels would dance around the
| screen. I didn't grasp what made it faster, but assumed it was
| doing some binary magic in the web browser!
|
| I learned more, and ended up writing my own react-like
| framework in Rust/WASM. (Seed).
|
| Now, I program in HTML, CSS, and JS. If the project triggers a
| certain complexity threshold, I'll bring in TS.
|
| React advertising itself as fast was a lie.
| meiraleal wrote:
| It was fast! Now it's legacy tech.
| DangitBobby wrote:
| Unfortunately what the headline means is "even slower than
| that", though you probably knew that already.
| scoot wrote:
| Since the author doesn't appear to understand the difference
| between the Internet and the Web, and thinks that React handles
| internet traffic, I think it's fair to assume that the rest of
| the article is going to be a hot mess.
| verbalstoner wrote:
| JS frameworks were a terrible mistake
| voat wrote:
| You're either using a framework, or unintentionally writing
| your own
| rglover wrote:
| The frameworks aren't the problem, it's their authors. There's
| a virus in the JavaScript world that makes people think ever-
| more complex solutions make tools better. After years asking
| "why is it like this" (I'm a JS dev/framework author), I
| realized this is likely due to an inferiority complex because
| hearing "real programmers don't use JavaScript" makes people
| feel bad so they try to compensate with complexity and end up
| creating messes. That and complexity pays well.
| jmeyer2k wrote:
| React server actions also have this limitation. No way to call
| two server actions in parallel.
| throw_that_away wrote:
| React is the UI Java
| ravetcofx wrote:
| I've noticed the internet becoming generally slow and laggy over
| the last few years for older computers and devices. Things from
| around and before 2015 to 2017 are becoming pretty unusable for
| doing basic web app tasks.
| zogrodea wrote:
| Unrelated, but I'm impressed by how fast browsers can be in some
| cases.
|
| I once created a HTML file with just a start/end HTML tag and 50k
| (unstyled) button elements in between, curious to see how it
| performs. I tried the same in Flutter on a release build (using
| Material widgets so they are styled) and the HTML was much
| faster.
|
| I was able to tab through (changing focus by holding tab) the
| buttons in both Chrome and Firefox at a consistent frame rate
| with no signs of any lag, while FLutter struggled and lagged
| quite a bit with the same.
|
| Would anyone know why that is? Are web browsers hyper-optimised
| for static documents (beating a "native" GUI toolkit for static
| documents)? Is Flutter just comparatively slow compared to Qt,
| GTK and so on? Does the styling have that much of an impact on
| performance?
|
| I am aware that updating DOM elements is uniquely slow for
| browsers but this experiment was a surprise for me and I'm
| curious for an explanation.
| l5870uoo9y wrote:
| If you want performant styling stick to CSS.
| ComputerGuru wrote:
| CSS can certainly be performant but you need to be aware of
| what can trigger reflows, which will absolutely destroy your
| performance. Cascading reflows are horrible.
| Jabbles wrote:
| Can you share your code?
| zogrodea wrote:
| I will in a bit hopefully. It was a few months ago and I
| don't have Flutter installed on this computer but I'm doing
| it now.
|
| Edit: I was coding it up now, but my storage is full (having
| trouble copying text to my clipboard and unable to save
| files) so I don't think I will be able to deliver on what I
| intended. Sorry about that.
|
| On the HTML side, I had a code generator (in Javascript) that
| output `<html> <button /> <15000 more buttons.../> </html>`
| and wrote it to a file.
|
| On the Flutter side, I used the default Flutter sample app
| (`flutter create .`) and I just used a similar code generator
| to put 15000 buttons in a Column widget.
|
| I don't think I'll be able to do much else to help with
| reproducibility sadly.
|
| If others try the same, I would be interested in if their
| results are any better than mine (with Chrome/Firefox being
| faster).
| Jabbles wrote:
| I think if you use ListView.builder() in Flutter instead of
| a Column you will see much better results - it ensures that
| Flutter does not have to layout 15k buttons all the time,
| just those that are visible.
|
| Of course, it's unfair to allow Flutter to have
| optimizations but not the raw HTML, but disallowing well-
| known, real-world optimizations is also an unfair test IMO.
|
| https://api.flutter.dev/flutter/widgets/ListView-class.html
| cal85 wrote:
| > Are web browsers hyper-optimised for static documents
| (beating a "native" GUI toolkit for static documents)?
|
| Yes. The browser is the world's most widely deployed and used
| runtime. I would assume Blink, WebKit and Gecko are the three
| most carefully optimised pieces of software ever.
| d0100 wrote:
| Shoutout to the devs from pmndrs reminding the react core team
| that not all async is fetching crud data
| bob1029 wrote:
| I knew we were going off a cliff the moment GitHub did their big
| client-side rendering rework and made it effectively impossible
| to review large PRs in the web UI.
|
| This has all become too complicated as is traditional. Every JS
| framework I have ever used ultimately suffered the same fate. The
| only web framework that works long-term is whatever is documented
| on MDN.
|
| Something approximating PHP + AJAX has always been the correct
| path. If you are doing things like shipping DOM across
| websockets, I think you may have missed an important step
| somewhere along the way.
| lovethevoid wrote:
| React, vue, and svelte all have MDN docs. So not sure that's
| the best way of determining a better route for JS frameworks.
| 38 wrote:
| no, they dont.
| graypegg wrote:
| I would like to see a "framework of opinions" somewhere. 0
| actual software, just documentation for standard JS and browser
| APIs organized in a way resembling framework documentation.
|
| The current style of web platform documentation tends to
| resemble a big list of objets, or the most basic and slowest
| introduction to web development possible.
|
| Something in-between, with chapters like "templating" or "data
| fetching" that focused on some opinionated but framework less
| structure, would be nice.
| voat wrote:
| TLDR: Don't do data fetching in your components if your care
| about performance. Hoist it up to the route, so you don't have to
| wait for deeply nested components to render serially.
___________________________________________________________________
(page generated 2024-06-17 23:00 UTC)