It’s using a frontend libraries that don’t make your head hurt. Try Solidjs. Super close to plain JS but with great developer experience and performance
@@PraiseYeezus is love. is life. No, but centering stuff is honestly too complicated even as someone who knows how to do it. There are loads of various ways to do it, which is fine since there are many different ways we need to center them. However, there are also many cases where you'd think something should work but it doesn't. Then there's also stuff like heights, you want something to fill 100% of the area and center the contents? There's a lot of complexity to it that backend devs just don't want to deal with. Therefore margin: auto is one of the most common solutions.
@@CottidaeSEA Huh? Centering isn't hard. 1. margin: 0 auto; to center horizontally 2. display: flex; justify-content: center; align-items: center; to center both ways 3. Can also use grid and set its position within the grid 4. Transforms are also an option.
After using and working with server components for almost 2 years now, I'm still not sold on the idea. It adds an incredible amount of complexity and limitations, while the gains in most cases are little to none. I'm a lot more happy with classic SSR + prepass. Sure, I'll still have waterfall, but on the backend, where I can control the requests, requests are faster, I can add caching, etc, and have an instantly loading app without JS, no requests on client side upon initial render.
Im still not sure what complexity it adds. I hear alot of people talking about complexity, but not one have actually given any examples other than "it is just harder". It smells like skill issues
@@48265868this is disingenous. For one, the possibility of dealing with two paradigms at the same time. Harder debugging too. But it's easier to think "haha skill issue" isnt it?
Can I just say for the record - and as a 25 year veteran of web dev, not a new kid - that the fact that there is constant fighting about how to do React correctly suggests that there is an underlying issue in React itself. Best practice is not intuitive, ubiquitous, or emergent. Also I’ve TRIED to use suspense query and it absolutely shat itself.
I do not like react what so ever and have since moved away from most of these frontend libraries. In case I need a very interactive experience svelte does a great job
@@roccociccone597 I like Svelte. It feels simple and elegant. I haven’t used it for a long time, though I’d like to go back and try it again for a more complete project. When I was using it more it was in a dumb SvelteKit / Sapper limbo.
JS was created as a bit of an afterthought to begin with, wasn't it? The fervor last decade to port anything and everything to js or nodejs has entrenched a veritable plethora of Rube Goldberg anti-patterns for "extrapolating" things the original developers of JS never intended: "concurrency", "static linking", "type constraints" - hell, "variable types". Engineering promises out of callbacks in order to use fewer callbacks. You know, sane shit.
We are living in a loop. To wrong way today is the right way tomorrow. Fist we want to load on clint, now on server, now on both, now on client but "stream blocking" the UI
This reminds me of when everyone thought they'd write all their code as multi-threaded once multicore processors came out. Most code is naturally sequential. Dynamic react UIs are much more like algorithms than a single, declarative statement. I don't see most people doing the very hard work to convert their code over to this new "parallelism" paradigm for some (probably) unnoticeable performance gains. So I don't see this becoming the dominant pattern.
Also the example of cascading renders isn’t really bc “fetch on render”, it’s just the current api design. You have to fetch the list of friend ids first before fetching each friend details by id. Alternatively BE could return the details in one call. Or FE could fetch all details in parallel before rendering them. Personally I find nothing inherently wrong with fetching on render. It makes components easily movable/ reusable as you mentioned bc they’re self contained.
“Most frontend devs are strapping together 15 apis…” your teams not communicating Is the problem creating waterfall fetching not a react pattern, you still have to do that waterfall fetch with any pattern if you don’t have an api that gets what you want. The render as you fetch and fetch as you render diagram showed different serverside apis that made it look like one is substantially worse. If all you control is the front end then you don’t get to do the latter, these two pattern overlap really hard. Render as you fetch is better, but you aren’t locked into one or the other and the apis available can heavily dictate when you benefit. So arguing that client side waterfalls (with fetch as you render) are unavoidable because teams don’t talk, and then render as you fetch is what you should do but also you need a better api (that I thought we couldn’t change because our teams don’t talk)
Traditional React single page apps are absolutely fine. Just focus on delivering what the PM wants and make happy customers. RUclips channels like this make frontend development seem so much more complicated that it really is.
This is software engineering, the field of trade offs. SPAs come with trade offs, just like SSR, SSG, any every other design decision. SPAs are "fine" if they suit your use case but they don't always.
I like how the "wrong" fetch-as-you-render code can be explained clearly and anyone can imagine how to write it. But the video end without showing concrete example of how to do the "correct" render-as-you-fetch.
Honestly this data colocation thing is fine as long as the component is rendered lazily, like a modal. Doing it for all components is shooting yourself in the foot. If react starts to get in the way and hoist calls, and now your calls do not happen when you think they should happen but the happen somewhere else, i don't know if this will create quirks/things to keep in mind to avoid issues. Also who said that i want to hoist everything, maybe i want some calls to happen lazily because they perform poorly and i prefer to render the page first. The load function approach of Remix/SvelteKit is much better because it's predictable and you have total control over how data is fatched.
Yup, the opposite is a real issue too. So you have full backend team supporting you and create UI-purpose-build-API where you don't have to chase down 50 different endpoints, then what do you get? An API specific UI where any attempt to move parts out or move additional parts in becomes 10x harder. Even just splitting part of your UI-purpose-build API out becomes 10x times harder because the first question is why do you want to do that when nothing is broken?
I agree with the similarities with object orientation, and see more into it: the problems we see in react apps architecture is that (as shown in the video) we're mixing data with UI component state. What I do is revive an old pattern: MVC. React is really good for the V, but not so much for the C, so I write a controller (C) class in plain javascript and put it up in a context. This controller offers event streams. The UI, on the other side, is made of React components that can take either a stream prop, a controller prop or just get the controller from the context itself and nab the stream from the controller, depending on if you want the component to render from many different data sources (a "friend" component) or a single one (a "shopping cart" component). This lets me do the fetch in the controller, so I could get a bunch of data from the server and publish to each relevant stream individually from the controller without having to swim through the tree to deliver to each component, they can be anywhere and the controller doesn't care where they are (or if they are even visible). Publishing updates components. No parallel graphs, no gorilla context, it's all lightweight, very very flexible and easy to debug (plus I get to build/debug UI and controller separately!, even in parallel which is great for teamwork!). Code is greatly simplified as it's just instancing a class in the controller and then using a hook in the UI side. The downside is, of course, no SSR as it's all dynamic, but streams do have a startup value and you could use that (I haven't tried using it that way yet). As for loading? well, components using data will usually expect a loading flag in the stream (as I started doing this before suspense). No suspense needed and now you can easily debug the loading view. I do this with a very lightweight library: react-state-events. I can't even see it in the bundle size graph, it's very tiny.
I didn't know the name for it, but have been doing render while fetch by accident, wherever possible (probably around 80% of the time) for some years now. What can really help is using a BFF pattern. It's not always possible though, depending on how friendly your API team is, or if you are the API team as well ;)
I think the loader/action pattern can solve a lot of issue and can be a good compromise, not difficult to implement and bring more clarity to the code. It can remove a lot of local useState, speed up the loading page using streaming. Not fan of SSR ? Loader/Action in client side only can be use. I dramaticly seen an upgrate of our application when we moved from a classic architecture using useQuery and 10 000 useState to a loader/action using mainly useMemo to handle the change. At the end, everything is drive by the loading data. And the heavy computation has been move to a dedicate route with action, which can be run outside of the react rendering.
Most of these problems are negligible even on massive apps. They can be solved with simpler UI designs. BFF design for apis Graphql and relay I don't see the point of tearing everything down just to scratch a technical itch
Correct me if I'm wrong, but specific to web apps, doesn't React-Router-Dom offer a solutions to the render-as--fetch vs. fetch-as-render conversation? You can include any fetch/async/promise you want prior to mounting/rendering anything.
I think it doesn’t suck. In the same way that you fetch data in a mobile app, I don’t see much reason to implement it differently for the web. It will only make everything more complicated. KISS always! :)
I honestly don't get what the problem React is trying to resolve lately. If the fetch triggers render require us to hoist the data fetching to the top level. Then why not go back to the original idea of the getServerSideProps() from next.js, or just PHP server-side render. And if you absolutely want to fetch thing earlier before the component, you can do something like useReactQuery(, { cache: something like 1s or 5s }) in the root component or parent component. Then the sub component useReactQuery will just grab the data directly if it's within the cache time span.
welcome onload much faster . normal js problem is routing . So they create routing problem and renderer component / html tag . But r render tag quite expensive and old computer had big problem white page re render issue like browser loading . Normal inner html dont have much white issue either normal js or just put html tag except we cant call js method / function. In our code , we still to old style .Normal js code and less problematic re render
Agreed. It's absurd how much apparent free time people have to labor over these kind of "problems". Just build the dang web app and move on. Every possible FE challenge already has a solution.
Because none of the things you're describing address the issue: relying on a render cycle to fetch data. That means that: - If you refresh, gotta fetch it again. - If your user is on mobile with spotty connection, I hope they enjoy long running spinners - You can never deploy static assets (eg minimal JS) because you have to wait for the JS to parse before it can fetch anything - SSR takes a step forward but still ties your response times to the server, there's a reason why SSR isn't the greatest for client interactivity - Being able to deploy a built app of static, pre-fetched data means your server's load is reduced; it can sent plain HTML to the user for static parts and use SSR when it's dynamic data
Been using relay for the last 6 years in prod. Hated it initially, started understanding the benefits it provided, and I feel like I can say people don’t know how nice their lives can be. Also how frustrating at times haha. But it’s pretty neat
UI = f(data, state) is just the state Monad -- a better type definition is `component :: State Data UI`, where `State` represents the state monad. The real benefit here is that your components can use hook and context like datafetching, without being coupled to a specific context or hook. the state monad provides the interface, but anything that can provide `get :: State Data Data` and `set :: Data -> State Data ()` can be used
As time goes on I've just become more solidified in the idea that state and business logic should not be in the react context and that actually the model and view should be loosely coupled. In order to do that you don't need a state management system, providers etc, just basic language tools. Doesn't matter if the model is on the server or on the client but having it in the react context is the problem I believe.
Testing, and especially unit testing, becomes simple again once you realize this. Your frontend needs a data layer that is not hardwired into react state management.
@@anciequeI totally agree with this, if you have a table then you just need an array of data in the state. The react context shouldn't contain all the logic and actual application state. Rendering and your business problem are 2 different concerns. As for people suggesting libraries, sure everyone has their favourite but honestly I don't think you need a lib for this, if you want, you could just create a custom hook that sends the setState function elsewhere. You can then manage that however you want outside of react. Not saying you should but it's possible. The advantage of having your model outside of the react context are unstated, imagine being able to simulate your app in any way you want in any environment you want because there's not all that overhead and complexity of the react context. Which is a huge pain for testing Anyway I could go on but well, good luck out there.
I wonder how this can be applied to a dashboards page, where dashboards are rendered via tabs, dashboard has to load its layout and widgets configs and then each widget loads its data (from multiple services without graphql)
wouldn't the clearest decision be that, when rendering data based on route navigation is best for server side fetching, and when needing real time data fetching, like a search bar or comment posts, you use a library like React Query to do so?
So with "fetch triggers render,", i need two routers, mostly, i am doing FE in react and BE in something else, so i need two separate routers at client, one is rendering and other will preprare batch of fetching, i dont wat to have one router in clicnt and one in backend, ther are too far one form another, and it makes hard to maintain both.
As far as I know, while HTMX itself does not use components, the HTMX-based stacks in wide use I know of are pretty evenly split between templates and components. BHANO (Bun, Htmx, Alpine, hONO) literally uses JSX components. AHA (Astro, HTMX, Alpine) uses Astro components along with partials and API routes. On the other hand, GOTTH (Go, Templ, Tailwind, HTMX) and Django-based stacks use templates. It would be interesting data to do a comprehensive survey of all HTMX-based stacks currently in use.
Based on this example, the ‘render-while-fetch’ approach will need to include one more step, but I agree it’s still fewer steps than ‘fetch-on-render’.
What happens when you need to friends list on 1 page, but not on another, and the friends list takes a huge amount of data? Do you have to write a whole separate query on the backend to handle that? That is the part of render-on-fetch that doesn't make sense to me as one of the most productive full stack devs (React on C#) on my team. I don't want to write special queries on the backend for every different page I render. I want to pick and choose the data I need on from the frontend and don't want data I don't need. And don't say GraphQL because that doesn't provide the granularity of auth that we need.
The gist of the problem seems to be a badly designed back-end API, isn't it? Sometimes those new "concepts" and "paradigms" begin to look like workarounds for bad engineering.
23:00: I've actually achieved this in wordpress/PHP apps by using a tool called r2wc (React to Web Component). I can make each part of my app that needs a complicated JS UI just simply use the web-component it generates and feed it data with regular string params (these have settings you can configure to transform them into the data types required obviously). It's made working inside systems that AREN'T JS backends stupid simple, even simpler than calling `createRoot` on some ID as each component can have it's own or global state.. If I need global state I use zustand and call it a day. Not SPA BS, no Next.js being setup for an entire client side... Just get the data in a form it can be passed to the markup, parse the markup into a JS readable type and call it a day.
And I here exporting everything in a file, and preparing to put it in a WordPress html component, or for compatibility reasons by deploying the component in vercel and calling it from an , because sometimes the hosting does not allow you to put it inside the WordPress files. Come to think of it, this may also be a useful alternative to use react components in projects with other technologies, and that are not using astro, thanks
Sooo I've watch the video and I still didn't get it. How to optimize the fetching and avoid the waterfall? Any simple answer would help, since I am building an app with exactly the same problems... Back-end don't care about front-end. Even if they do, they have their concerns, different teams, different cloud structures, God, even third parties that are not in your organization. So backend can not be changed. How to optimize my fetching? React-query? or something else? Next.JS is out of the question for now. It will double the work just for some optimizations.. not the best solution.
I'm still building apps on Next.js pages router with no problem. I feel like all this drama happens for 1% of the developer community 😂 and while all of this useless drama is going on, AI developers will take over, receive spec and spit out vanilla HTML, CSS and JS for both client and the server. Even though it will be my demise as a developer, I certainly look forward to it!
No, AI will consume crap code, integrate it into its model, output crap code - and reconsume it into its model. Over time, the models will rot away - and those with any skills will become very valuable because they can actually write code.
@@naughtiousmaximus7853 you couldn’t be more wrong sir/madam. I’ve been involved in this mess for 14 years now. And what do you mean by static? Asking because I’ve mentioned Next.js, not to mention we are in a comment section about React. I probably shouldn’t even answer to a comment that starts with “people like you…”
How do you deal with the situation when your App is using APIs across multiple different systems to build its data? How do you even with this? This assumes that your site and data APIs are on the same system. Whilst the current "traditional" pattern is that your React JS is on a CDN, and your API service is behind load balancing etc. Doesn't this also cause coupling between your server-side and your UI that's undesirable? Now some smart UI person can't go build a different experience based on the same back-ends - because the back-end is now responsible. You also can't now build a UI without also deploying a server that acts as at least an aggregator service. It also means that in a complex enterprise that's less disciplined where you have a mismash of back-end API systems and front-end technologies - where I work as an example there's some Angular, Some React, some plain JS, plus a pile of .NET code, some Node, some other 3P weird stuff and even some Java. A successful system has to interact with all of these to get its job done. Whilst I suppose I'm already essentially writing an aggregator layer in NodeJS using NestJS, I'm not I then want to conflate SSR into that code that's handling Data stuff and shove all of that into NextJS - it feels like mixing concerns in a bad way. With all that said - what IS a good pattern to accomplish this if it's not just "traditional" REST APIs plus an SPA on a CDN. Is that pattern dead or even an anti-pattern now? Is it SSR that's an aggregator over REST/GraphQL APIs? I'm so confused.
Fetch on render is nice when you have small standalone components that do not need to be present when loading the page. It's absolutely awful when you're sitting there waiting for the JS to be fetched, rendered, authenticated, fetch again, render a few components and then fetch some more data, just to render and fetch a bit more.
Fetch-on-render also implies many other problems like nullability that you need to handle by your own because in such case it is not an invalid state, it's regular state which in many cases you don't need.
So basically we are moving back to ssr? I mean it will definitely put more load on server, completely opposite to why client side rendering came to existence in the first place.
It would be more exciting if you attach an example centric article citation rather than just citing the articles. What we are doing and what actually is a good practice for developers like us to learn more.
The problem with the parallel approach is that you now have to keep track of two states and if you remove a component, you're still fetching data that nobody is using
Honestly why make a massive react change when realistically the API should have an extra route to return all the data in put network call instead of 2+ . You still are going to do a fetch after render however why not create a special type of component like suspense but unlike suspense would prefetch the data before the render?
so not only the synchronization of states between business logic (SS) and UI logic (CS) but also the binding of the server to the UI itself (the server knows that the screen will need this and that) .... madness
i think this is a bad example. can't you just allow a single api endpoint to handle all the data? there is no need to go back and forth among "fetch user info", "fetch friends list", "fetch friend" . so it's just as simple as hydrate html/js and call that single api endpoint and that's it! i dont know how much better it is comparing this and the render while fetch loading (the difference must be so minimal there)
He mentioned that passing props down through too many levels of components is expensive. You can throw the giant response in a context, but then need to build out hooks to get to slices of that response (`useSelector`, etc.), so you end up with something like prefetch + React Query's cache.
Technology is always the same. We create it, click rocks with it, make it bigger, make it faster, then start realizing all the fat we can trim, and we start slimming down, removing unnecessary features, or outright replacing features with better ones. Vanilla JS was a CRT TV, and React was the flatscreen, now React can either change its approach to being a flatscreen or fall behind the devs making slimmer, faster, nicer flatscreens like Svelte 5 and HTMX. Probably a bad analogy, but the best I had.
The idea of suspense has always been nice, but in practice, fetch as you render is hard to apply if you're not facebook. I wish Theo would've spent more time showing how annoying it is to implement infinite scrolling purely with RSC versus how easy it is to do it with something like react query. IMO The DX/simplicity that react-query brings still overweighs the performance gains that you can >potentially< get with fetch as you render IF you do everything correctly. I don't disagree with Theo that fetch as you render is the better approach, it just seems that the environment has not developed enough to make this a viable option for everyone, which is a bit sad
ten years ago, We( old school devs ) said - "it is wrong way", what are you doing.... after few years we give up, and say - ok now we accept your( younger devs ) rules. And what - after that you trying to say it is you idea an you get it your selfs.... Holly Turing......
The solutions that try to fix the fetch-as-you-render are only partially solving it, the waterfall is inevitable, render-as-you-fetch is the best but the mindset is hard for current devs to change
The scenario presented is highly hypothetical, imo. I'd expect one to create a hook to pull all items for the list, even though there would be muliple api calls, making FriendItem a dumb component. I've never seen a single item API being used to fetch an item from the list. So, no, it's not a realistic scenario. Besides that, fetch as render does have a benefit of delaying fetching data that might not even be used by a user anyway. Basically, all this falls as a website performance optimisation exercise, and a moat appropriate technique/pattern should be used for the specific problem on question. Tldr: there is no silver bullet solution.
not one mention of Zustand. Definitely the best way handle state in a react app nowadays. I still am not convinced that React Sercer (Components) is a good solution, although is it has a good objective. Next is just bad nowadays. SSR with zustand with a global state that can fetch data completely apart from the components works great. Only thing better is Solid.js. Better yet is htmx with minimal js.
The right way to use react is not to use react. Render-while-fetch is basically signals with a ton of extra steps. Use Solidjs instead and stop looking for answers for the wrong question: how to work around react’s fundamental flaws
@@janisozols5255 this problem isn’t about performance, it’s about delaying fetching using patterns. It’s not a react problem, you can use both of these patterns in solid or angular or pick your component based framework. It’s really just should a component request it’s own data or not. He just has react brain and explains it as a react problem. Signals don’t solve render as you fetch, you’re concentrating on “render” when the problem is all about component mounting which happens regardless to your state and dom updating system.
@@Diamonddrake Signals do solve render-while-fetch because you can use a complex context data structure without rerenders or even immutability rules. Signals link these data updates to fine-grained DOM changes
@@Diamonddrake Render on fetch is bad BECAUSE React's render methodology can allow a single fetch to trigger a cascade of rerenders and therefore more fetches. With signals perhaps first page load could take a performance hit, but after mounting stateful UI actions wouldn't cause that cascade. At least, not nearly as often. Render on fetch is bad but React is a footgun that makes it something you have to think about. With fine-grained reactivity it's a lot harder to shoot yourself in the foot using a bad pattern.
@@LeFlamel You can easily write the same pattern with the same results in both solid and react. The cascade is a side effect of components requesting their own data, has nothing to do with level of reactivity or how much of a component gets rerendered. That’s an illusion. React absolutely does more work than it needs to, has nothing to do with this issue.
Reacts biggest issue is just how entrenched it is in market. Literally so many better options to build apps but you gotta learn React anyways. Its like learning to ride a horse carrier when you have a car available right next to you. Its insane.
are you actually a dev? the amount of .NET, Java, Django, Laravel etc. projects out there is pretty significant, you don't 'need' a single one of these advanced fancy new(tm) shiny React patterns to get a job.
@@ingvarr6235no, there are also situations where a tool is strictly speaking worse than other tools. This is one of them. Everything react is trying to do there's another framework that does it better
This video is the best case for HTMX I've ever seen. I kind of mean that to troll, but also, doing all of the data gathering and sending it at once seems so much easier.
And asynchronously. I've fired off multiple LOB'd divs using hx-trigger="load" and all return within a reasonable amount of time, letting me focus on writing SQL.
The example you wrote in he video to illustrate "the problem" has nothing to do with the problem actually. Just fetch the data from a sane endpoint and render the list -> now the "fetching in the render" is slowing down the first fetch call what? 5ms? 10ms? 40ms? Most of the problems come from really bad architecture. Why on earth would someone fetch each item from a list separately when in fact they are all needed? Even if you need to load them while scrolling or w/e you can still obtain multiple results at once (paging).
Your example server side dependencies is way too simple. Waterfall-dependendencies are costly, even sever side! Imagine multiple collections within your resource then each of these collections also have a couple shared collections dependency of their own. The API will take double digits seconds to return. That's not fun.
"We're all here because we love React" I'm a backend guy who despises anything frontend that's not hand-written HTML/CSS/JS, so I guess I'm mostly here for the schadenfreude?
I feel like the solution to frontend is to become a backend dev.
It’s using a frontend libraries that don’t make your head hurt. Try Solidjs. Super close to plain JS but with great developer experience and performance
Have you ever seen a backend dev center a div? There's a reason why every documentation site for Python libraries look and read like shit
@@PraiseYeezus java and python lib websites are like things from 1994 web
@@PraiseYeezus is love. is life. No, but centering stuff is honestly too complicated even as someone who knows how to do it. There are loads of various ways to do it, which is fine since there are many different ways we need to center them. However, there are also many cases where you'd think something should work but it doesn't. Then there's also stuff like heights, you want something to fill 100% of the area and center the contents?
There's a lot of complexity to it that backend devs just don't want to deal with. Therefore margin: auto is one of the most common solutions.
@@CottidaeSEA Huh? Centering isn't hard.
1. margin: 0 auto; to center horizontally
2. display: flex; justify-content: center; align-items: center; to center both ways
3. Can also use grid and set its position within the grid
4. Transforms are also an option.
This video has definitely been fetched on render
Edit: finished watching, the excalidraw part was rendered as you fetch
LOL
After using and working with server components for almost 2 years now, I'm still not sold on the idea. It adds an incredible amount of complexity and limitations, while the gains in most cases are little to none. I'm a lot more happy with classic SSR + prepass. Sure, I'll still have waterfall, but on the backend, where I can control the requests, requests are faster, I can add caching, etc, and have an instantly loading app without JS, no requests on client side upon initial render.
Im still not sure what complexity it adds. I hear alot of people talking about complexity, but not one have actually given any examples other than "it is just harder". It smells like skill issues
@@48265868 nowadays whenever someone wants you to be convinced with his opinion he adds that “skill issue” on the end lol.
What is complex about it? If you need more than a server component, mark it a client component. I literally don't get it
SSR is not server only code though. It's equivalent to use client. Prepass is what?
@@48265868this is disingenous. For one, the possibility of dealing with two paradigms at the same time. Harder debugging too.
But it's easier to think "haha skill issue" isnt it?
Can I just say for the record - and as a 25 year veteran of web dev, not a new kid - that the fact that there is constant fighting about how to do React correctly suggests that there is an underlying issue in React itself.
Best practice is not intuitive, ubiquitous, or emergent.
Also I’ve TRIED to use suspense query and it absolutely shat itself.
I do not like react what so ever and have since moved away from most of these frontend libraries. In case I need a very interactive experience svelte does a great job
@@roccociccone597 I like Svelte. It feels simple and elegant. I haven’t used it for a long time, though I’d like to go back and try it again for a more complete project. When I was using it more it was in a dumb SvelteKit / Sapper limbo.
JS was created as a bit of an afterthought to begin with, wasn't it? The fervor last decade to port anything and everything to js or nodejs has entrenched a veritable plethora of Rube Goldberg anti-patterns for "extrapolating" things the original developers of JS never intended: "concurrency", "static linking", "type constraints" - hell, "variable types". Engineering promises out of callbacks in order to use fewer callbacks. You know, sane shit.
We are living in a loop. To wrong way today is the right way tomorrow. Fist we want to load on clint, now on server, now on both, now on client but "stream blocking" the UI
And all along people act like each approach doesn't have downsides and upsides.
Can we go back to PHP already?
Never.
Who is stopping you?
@@nilskaspersson Big Wordpress! :3
Do whatever you want
You can if you want. More speed for me! :3
This reminds me of when everyone thought they'd write all their code as multi-threaded once multicore processors came out. Most code is naturally sequential. Dynamic react UIs are much more like algorithms than a single, declarative statement. I don't see most people doing the very hard work to convert their code over to this new "parallelism" paradigm for some (probably) unnoticeable performance gains. So I don't see this becoming the dominant pattern.
Also the example of cascading renders isn’t really bc “fetch on render”, it’s just the current api design. You have to fetch the list of friend ids first before fetching each friend details by id.
Alternatively BE could return the details in one call.
Or FE could fetch all details in parallel before rendering them.
Personally I find nothing inherently wrong with fetching on render. It makes components easily movable/ reusable as you mentioned bc they’re self contained.
When do the user info provider services call galactus?
It's just an optimization that we probably don't need, the end user won't feel and that will introduce complexity and worsen the DX.
New to this channel and liking these takes on blogs. Great vid. Thanks!
“Most frontend devs are strapping together 15 apis…” your teams not communicating Is the problem creating waterfall fetching not a react pattern, you still have to do that waterfall fetch with any pattern if you don’t have an api that gets what you want. The render as you fetch and fetch as you render diagram showed different serverside apis that made it look like one is substantially worse. If all you control is the front end then you don’t get to do the latter, these two pattern overlap really hard. Render as you fetch is better, but you aren’t locked into one or the other and the apis available can heavily dictate when you benefit. So arguing that client side waterfalls (with fetch as you render) are unavoidable because teams don’t talk, and then render as you fetch is what you should do but also you need a better api (that I thought we couldn’t change because our teams don’t talk)
Traditional React single page apps are absolutely fine. Just focus on delivering what the PM wants and make happy customers.
RUclips channels like this make frontend development seem so much more complicated that it really is.
“Frameworks” make it more complicated.
This is software engineering, the field of trade offs. SPAs come with trade offs, just like SSR, SSG, any every other design decision. SPAs are "fine" if they suit your use case but they don't always.
Frontend is already overcomplicated and liberal crap, u just need CQRS on the frontend. fetching inside routes it's pretty decent.
@@MrEnsiferum77 "front end is liberal crap" lmao
@@PraiseYeezus Software developers are liberals by nature, so it's liberal crap.
I like how the "wrong" fetch-as-you-render code can be explained clearly and anyone can imagine how to write it. But the video end without showing concrete example of how to do the "correct" render-as-you-fetch.
Yeah there are no real common standards for react
Honestly this data colocation thing is fine as long as the component is rendered lazily, like a modal. Doing it for all components is shooting yourself in the foot. If react starts to get in the way and hoist calls, and now your calls do not happen when you think they should happen but the happen somewhere else, i don't know if this will create quirks/things to keep in mind to avoid issues. Also who said that i want to hoist everything, maybe i want some calls to happen lazily because they perform poorly and i prefer to render the page first.
The load function approach of Remix/SvelteKit is much better because it's predictable and you have total control over how data is fatched.
Yup, the opposite is a real issue too. So you have full backend team supporting you and create UI-purpose-build-API where you don't have to chase down 50 different endpoints, then what do you get? An API specific UI where any attempt to move parts out or move additional parts in becomes 10x harder. Even just splitting part of your UI-purpose-build API out becomes 10x times harder because the first question is why do you want to do that when nothing is broken?
I agree with the similarities with object orientation, and see more into it: the problems we see in react apps architecture is that (as shown in the video) we're mixing data with UI component state.
What I do is revive an old pattern: MVC. React is really good for the V, but not so much for the C, so I write a controller (C) class in plain javascript and put it up in a context. This controller offers event streams. The UI, on the other side, is made of React components that can take either a stream prop, a controller prop or just get the controller from the context itself and nab the stream from the controller, depending on if you want the component to render from many different data sources (a "friend" component) or a single one (a "shopping cart" component).
This lets me do the fetch in the controller, so I could get a bunch of data from the server and publish to each relevant stream individually from the controller without having to swim through the tree to deliver to each component, they can be anywhere and the controller doesn't care where they are (or if they are even visible). Publishing updates components. No parallel graphs, no gorilla context, it's all lightweight, very very flexible and easy to debug (plus I get to build/debug UI and controller separately!, even in parallel which is great for teamwork!). Code is greatly simplified as it's just instancing a class in the controller and then using a hook in the UI side.
The downside is, of course, no SSR as it's all dynamic, but streams do have a startup value and you could use that (I haven't tried using it that way yet).
As for loading? well, components using data will usually expect a loading flag in the stream (as I started doing this before suspense). No suspense needed and now you can easily debug the loading view.
I do this with a very lightweight library: react-state-events. I can't even see it in the bundle size graph, it's very tiny.
9:30 build a BFF/experience API which aggregates the results so frontend gets exactly what it needs.
IMO that’s the only real benefit of next. Easy to make a BFF.
This. REST is not great when used directly from the front end, but a BFF bridges the gap excellently.
This is awesome! This will clearify alot for beginners and even intermediate react programmers.
Good job, Theo!
Watching 40 minutes of this and going back to fetching with use effect at the end🤣
I haven't watch the video... is that true? or just a jokeee
@@leisiyox no . just use normal php / c# /jsp .. more faster hahah.. no need 2 server
yep, at the end we just watch it, and cant implemented it since we working on the project which has lived for a few years.
I didn't know the name for it, but have been doing render while fetch by accident, wherever possible (probably around 80% of the time) for some years now. What can really help is using a BFF pattern. It's not always possible though, depending on how friendly your API team is, or if you are the API team as well ;)
Cant wait to see what Tanner will come up with Tanstack Start
I feel this is going to hurt my feelings…
Most of my apps were written the wrong way too 🙃
So once you update user info it’s gonna re-render three levels of components instead of one?
It would be great to have an example of open source best practices so that you can learn the best overall ideas.
I think the loader/action pattern can solve a lot of issue and can be a good compromise, not difficult to implement and bring more clarity to the code. It can remove a lot of local useState, speed up the loading page using streaming. Not fan of SSR ? Loader/Action in client side only can be use. I dramaticly seen an upgrate of our application when we moved from a classic architecture using useQuery and 10 000 useState to a loader/action using mainly useMemo to handle the change. At the end, everything is drive by the loading data. And the heavy computation has been move to a dedicate route with action, which can be run outside of the react rendering.
So early the porn bots haven't been banned yet
i'm 1 minute late
Most of these problems are negligible even on massive apps.
They can be solved with simpler UI designs.
BFF design for apis
Graphql and relay
I don't see the point of tearing everything down just to scratch a technical itch
Correct me if I'm wrong, but specific to web apps, doesn't React-Router-Dom offer a solutions to the render-as--fetch vs. fetch-as-render conversation? You can include any fetch/async/promise you want prior to mounting/rendering anything.
Well solidjs does not have the main problem discussed in the article - performance problems when using and frequently updating data context
What is this microphone stand's model name? I really want this thing.
I think it doesn’t suck. In the same way that you fetch data in a mobile app, I don’t see much reason to implement it differently for the web. It will only make everything more complicated. KISS always! :)
I honestly don't get what the problem React is trying to resolve lately. If the fetch triggers render require us to hoist the data fetching to the top level. Then why not go back to the original idea of the getServerSideProps() from next.js, or just PHP server-side render. And if you absolutely want to fetch thing earlier before the component, you can do something like useReactQuery(, { cache: something like 1s or 5s }) in the root component or parent component. Then the sub component useReactQuery will just grab the data directly if it's within the cache time span.
welcome onload much faster . normal js problem is routing . So they create routing problem and renderer component / html tag . But r render tag quite expensive and old computer had big problem white page re render issue like browser loading . Normal inner html dont have much white issue either normal js or just put html tag except we cant call js method / function. In our code , we still to old style .Normal js code and less problematic re render
Agreed. It's absurd how much apparent free time people have to labor over these kind of "problems". Just build the dang web app and move on. Every possible FE challenge already has a solution.
Just move on to Signals
Because none of the things you're describing address the issue: relying on a render cycle to fetch data. That means that:
- If you refresh, gotta fetch it again.
- If your user is on mobile with spotty connection, I hope they enjoy long running spinners
- You can never deploy static assets (eg minimal JS) because you have to wait for the JS to parse before it can fetch anything
- SSR takes a step forward but still ties your response times to the server, there's a reason why SSR isn't the greatest for client interactivity
- Being able to deploy a built app of static, pre-fetched data means your server's load is reduced; it can sent plain HTML to the user for static parts and use SSR when it's dynamic data
@@PraiseYeezus you can cache your ssr rendered page and then response times are not depended on the server location anymore
Been using relay for the last 6 years in prod. Hated it initially, started understanding the benefits it provided, and I feel like I can say people don’t know how nice their lives can be. Also how frustrating at times haha. But it’s pretty neat
How do you guys draw some much stuff on excalidraw without getting tendonitis? I gave up after 10 minutes and just learned to use mermaid insteas
Is everything now back to BE?
does it still matter if we have React.Context? we call the API ourselves together in root components and hence no waterfall
UI = f(data, state) is just the state Monad -- a better type definition is `component :: State Data UI`, where `State` represents the state monad. The real benefit here is that your components can use hook and context like datafetching, without being coupled to a specific context or hook. the state monad provides the interface, but anything that can provide `get :: State Data Data` and `set :: Data -> State Data ()` can be used
As time goes on I've just become more solidified in the idea that state and business logic should not be in the react context and that actually the model and view should be loosely coupled. In order to do that you don't need a state management system, providers etc, just basic language tools. Doesn't matter if the model is on the server or on the client but having it in the react context is the problem I believe.
The "model on the client" is state management libraries like valtio or zustand. You can easily create fine-grained reactivity with most of them.
I agree. React state should contain render state, not app state.
Testing, and especially unit testing, becomes simple again once you realize this. Your frontend needs a data layer that is not hardwired into react state management.
I think the idea is fine but problem is react. Try solidjs where you can use this approach without any problems
@@anciequeI totally agree with this, if you have a table then you just need an array of data in the state. The react context shouldn't contain all the logic and actual application state.
Rendering and your business problem are 2 different concerns.
As for people suggesting libraries, sure everyone has their favourite but honestly I don't think you need a lib for this, if you want, you could just create a custom hook that sends the setState function elsewhere. You can then manage that however you want outside of react. Not saying you should but it's possible. The advantage of having your model outside of the react context are unstated, imagine being able to simulate your app in any way you want in any environment you want because there's not all that overhead and complexity of the react context. Which is a huge pain for testing
Anyway I could go on but well, good luck out there.
I wonder how this can be applied to a dashboards page, where dashboards are rendered via tabs, dashboard has to load its layout and widgets configs and then each widget loads its data (from multiple services without graphql)
wouldn't the clearest decision be that, when rendering data based on route navigation is best for server side fetching, and when needing real time data fetching, like a search bar or comment posts, you use a library like React Query to do so?
Love the chapter names here
That's why I'm already familiar with this stuff. I also watched your video on the Suspense thing. Was surprised to see Tanner's tweet was "so" old
So with "fetch triggers render,", i need two routers, mostly, i am doing FE in react and BE in something else, so i need two separate routers at client, one is rendering and other will preprare batch of fetching, i dont wat to have one router in clicnt and one in backend, ther are too far one form another, and it makes hard to maintain both.
i think i will stay with render triggers fetch, i dont do so much big thing i need to do it oposite way.
As far as I know, while HTMX itself does not use components, the HTMX-based stacks in wide use I know of are pretty evenly split between templates and components. BHANO (Bun, Htmx, Alpine, hONO) literally uses JSX components. AHA (Astro, HTMX, Alpine) uses Astro components along with partials and API routes. On the other hand, GOTTH (Go, Templ, Tailwind, HTMX) and Django-based stacks use templates. It would be interesting data to do a comprehensive survey of all HTMX-based stacks currently in use.
Does someone have the name of the original video where Theo made this flowchart?
Based on this example, the ‘render-while-fetch’ approach will need to include one more step, but I agree it’s still fewer steps than ‘fetch-on-render’.
What happens when you need to friends list on 1 page, but not on another, and the friends list takes a huge amount of data? Do you have to write a whole separate query on the backend to handle that? That is the part of render-on-fetch that doesn't make sense to me as one of the most productive full stack devs (React on C#) on my team. I don't want to write special queries on the backend for every different page I render. I want to pick and choose the data I need on from the frontend and don't want data I don't need. And don't say GraphQL because that doesn't provide the granularity of auth that we need.
The gist of the problem seems to be a badly designed back-end API, isn't it? Sometimes those new "concepts" and "paradigms" begin to look like workarounds for bad engineering.
23:00: I've actually achieved this in wordpress/PHP apps by using a tool called r2wc (React to Web Component). I can make each part of my app that needs a complicated JS UI just simply use the web-component it generates and feed it data with regular string params (these have settings you can configure to transform them into the data types required obviously). It's made working inside systems that AREN'T JS backends stupid simple, even simpler than calling `createRoot` on some ID as each component can have it's own or global state.. If I need global state I use zustand and call it a day. Not SPA BS, no Next.js being setup for an entire client side... Just get the data in a form it can be passed to the markup, parse the markup into a JS readable type and call it a day.
And I here exporting everything in a file, and preparing to put it in a WordPress html component, or for compatibility reasons by deploying the component in vercel and calling it from an , because sometimes the hosting does not allow you to put it inside the WordPress files. Come to think of it, this may also be a useful alternative to use react components in projects with other technologies, and that are not using astro, thanks
what site does theo use to draw those diagrams?
Excalidraw
excalidraw
Excalidraw
Sooo I've watch the video and I still didn't get it. How to optimize the fetching and avoid the waterfall? Any simple answer would help, since I am building an app with exactly the same problems... Back-end don't care about front-end. Even if they do, they have their concerns, different teams, different cloud structures, God, even third parties that are not in your organization. So backend can not be changed. How to optimize my fetching? React-query? or something else? Next.JS is out of the question for now. It will double the work just for some optimizations.. not the best solution.
Also, when you visit the page again, you’ll get a quicker response because you’ll be fetching only the JSON data, not any HTML.
I'm still building apps on Next.js pages router with no problem. I feel like all this drama happens for 1% of the developer community 😂 and while all of this useless drama is going on, AI developers will take over, receive spec and spit out vanilla HTML, CSS and JS for both client and the server. Even though it will be my demise as a developer, I certainly look forward to it!
No, AI will consume crap code, integrate it into its model, output crap code - and reconsume it into its model. Over time, the models will rot away - and those with any skills will become very valuable because they can actually write code.
I feel people like you who say this stuff about AI havent built a single remotely interactive app ever, just static site after static site.
@@redneckcoder I hope that’s true! But you are talking about AI in its infancy..
@@naughtiousmaximus7853 you couldn’t be more wrong sir/madam. I’ve been involved in this mess for 14 years now. And what do you mean by static? Asking because I’ve mentioned Next.js, not to mention we are in a comment section about React.
I probably shouldn’t even answer to a comment that starts with “people like you…”
How do you deal with the situation when your App is using APIs across multiple different systems to build its data? How do you even with this? This assumes that your site and data APIs are on the same system. Whilst the current "traditional" pattern is that your React JS is on a CDN, and your API service is behind load balancing etc. Doesn't this also cause coupling between your server-side and your UI that's undesirable? Now some smart UI person can't go build a different experience based on the same back-ends - because the back-end is now responsible. You also can't now build a UI without also deploying a server that acts as at least an aggregator service. It also means that in a complex enterprise that's less disciplined where you have a mismash of back-end API systems and front-end technologies - where I work as an example there's some Angular, Some React, some plain JS, plus a pile of .NET code, some Node, some other 3P weird stuff and even some Java. A successful system has to interact with all of these to get its job done. Whilst I suppose I'm already essentially writing an aggregator layer in NodeJS using NestJS, I'm not I then want to conflate SSR into that code that's handling Data stuff and shove all of that into NextJS - it feels like mixing concerns in a bad way. With all that said - what IS a good pattern to accomplish this if it's not just "traditional" REST APIs plus an SPA on a CDN. Is that pattern dead or even an anti-pattern now? Is it SSR that's an aggregator over REST/GraphQL APIs? I'm so confused.
Fetch on render is nice when you have small standalone components that do not need to be present when loading the page. It's absolutely awful when you're sitting there waiting for the JS to be fetched, rendered, authenticated, fetch again, render a few components and then fetch some more data, just to render and fetch a bit more.
i really wanna know what u have to say about react native!
Fetch-on-render also implies many other problems like nullability that you need to handle by your own because in such case it is not an invalid state, it's regular state which in many cases you don't need.
So basically we are moving back to ssr?
I mean it will definitely put more load on server, completely opposite to why client side rendering came to existence in the first place.
balls
This, I agree with this...
bro's talking the truth
Waiting for the REACT NATIVE VIDEO
It would be more exciting if you attach an example centric article citation rather than just citing the articles. What we are doing and what actually is a good practice for developers like us to learn more.
16:43 "So we now have arrived at the jungle. ~ contexts as well as other dependencies." part repeats?
Nope , it's all in your head.
The problem with the parallel approach is that you now have to keep track of two states and if you remove a component, you're still fetching data that nobody is using
why not just use xstate?
Y'all need Svelte. 😂
Honestly why make a massive react change when realistically the API should have an extra route to return all the data in put network call instead of 2+ . You still are going to do a fetch after render however why not create a special type of component like suspense but unlike suspense would prefetch the data before the render?
so not only the synchronization of states between business logic (SS) and UI logic (CS) but also the binding of the server to the UI itself (the server knows that the screen will need this and that) .... madness
this is the hard part and hard decision you need to consider when using reactjs, that is why I still love jquery over reactjs
i think this is a bad example. can't you just allow a single api endpoint to handle all the data? there is no need to go back and forth among "fetch user info", "fetch friends list", "fetch friend" . so it's just as simple as hydrate html/js and call that single api endpoint and that's it! i dont know how much better it is comparing this and the render while fetch loading (the difference must be so minimal there)
Separation of concerns.
Also that would be one massive query that will hammer the db if you get even 10000 CUs
He mentioned that passing props down through too many levels of components is expensive. You can throw the giant response in a context, but then need to build out hooks to get to slices of that response (`useSelector`, etc.), so you end up with something like prefetch + React Query's cache.
Technology is always the same. We create it, click rocks with it, make it bigger, make it faster, then start realizing all the fat we can trim, and we start slimming down, removing unnecessary features, or outright replacing features with better ones. Vanilla JS was a CRT TV, and React was the flatscreen, now React can either change its approach to being a flatscreen or fall behind the devs making slimmer, faster, nicer flatscreens like Svelte 5 and HTMX. Probably a bad analogy, but the best I had.
The idea of suspense has always been nice, but in practice, fetch as you render is hard to apply if you're not facebook. I wish Theo would've spent more time showing how annoying it is to implement infinite scrolling purely with RSC versus how easy it is to do it with something like react query.
IMO The DX/simplicity that react-query brings still overweighs the performance gains that you can >potentially< get with fetch as you render IF you do everything correctly. I don't disagree with Theo that fetch as you render is the better approach, it just seems that the environment has not developed enough to make this a viable option for everyone, which is a bit sad
ten years ago, We( old school devs ) said - "it is wrong way", what are you doing.... after few years we give up, and say - ok now we accept your( younger devs ) rules. And what - after that you trying to say it is you idea an you get it your selfs.... Holly Turing......
The solutions that try to fix the fetch-as-you-render are only partially solving it, the waterfall is inevitable, render-as-you-fetch is the best but the mindset is hard for current devs to change
The scenario presented is highly hypothetical, imo. I'd expect one to create a hook to pull all items for the list, even though there would be muliple api calls, making FriendItem a dumb component. I've never seen a single item API being used to fetch an item from the list. So, no, it's not a realistic scenario.
Besides that, fetch as render does have a benefit of delaying fetching data that might not even be used by a user anyway. Basically, all this falls as a website performance optimisation exercise, and a moat appropriate technique/pattern should be used for the specific problem on question.
Tldr: there is no silver bullet solution.
21:26 "all components in solid melt into air" - just acknowledging the excellent sneaky Marx reference
not one mention of Zustand. Definitely the best way handle state in a react app nowadays. I still am not convinced that React Sercer (Components) is a good solution, although is it has a good objective. Next is just bad nowadays. SSR with zustand with a global state that can fetch data completely apart from the components works great.
Only thing better is Solid.js.
Better yet is htmx with minimal js.
The right way to use react is not to use react. Render-while-fetch is basically signals with a ton of extra steps. Use Solidjs instead and stop looking for answers for the wrong question: how to work around react’s fundamental flaws
I swear to god, this. The performance hit wouldn't be as bad if virtual dom and useState did not exist.
@@janisozols5255 this problem isn’t about performance, it’s about delaying fetching using patterns. It’s not a react problem, you can use both of these patterns in solid or angular or pick your component based framework. It’s really just should a component request it’s own data or not. He just has react brain and explains it as a react problem. Signals don’t solve render as you fetch, you’re concentrating on “render” when the problem is all about component mounting which happens regardless to your state and dom updating system.
@@Diamonddrake Signals do solve render-while-fetch because you can use a complex context data structure without rerenders or even immutability rules. Signals link these data updates to fine-grained DOM changes
@@Diamonddrake Render on fetch is bad BECAUSE React's render methodology can allow a single fetch to trigger a cascade of rerenders and therefore more fetches. With signals perhaps first page load could take a performance hit, but after mounting stateful UI actions wouldn't cause that cascade. At least, not nearly as often. Render on fetch is bad but React is a footgun that makes it something you have to think about. With fine-grained reactivity it's a lot harder to shoot yourself in the foot using a bad pattern.
@@LeFlamel You can easily write the same pattern with the same results in both solid and react. The cascade is a side effect of components requesting their own data, has nothing to do with level of reactivity or how much of a component gets rerendered. That’s an illusion. React absolutely does more work than it needs to, has nothing to do with this issue.
Why would someone let their server execute react code while you can just let user's device do it for you for free?
Reacts biggest issue is just how entrenched it is in market. Literally so many better options to build apps but you gotta learn React anyways. Its like learning to ride a horse carrier when you have a car available right next to you. Its insane.
are you actually a dev? the amount of .NET, Java, Django, Laravel etc. projects out there is pretty significant, you don't 'need' a single one of these advanced fancy new(tm) shiny React patterns to get a job.
What alternatives do you mean? I think that every solution comes with its own limitations and is suitable for certain task and situation.
@@ingvarr6235no, there are also situations where a tool is strictly speaking worse than other tools. This is one of them. Everything react is trying to do there's another framework that does it better
@@ingvarr6235and I think that was the point - even though there are better solutions to solve the problem, react is used by default
The wrong way to use React: using React
I'm deeply interested in how this could be replicated in React Native
@@TechStache i hate that thing , very unstable
This video is the best case for HTMX I've ever seen.
I kind of mean that to troll, but also, doing all of the data gathering and sending it at once seems so much easier.
And asynchronously. I've fired off multiple LOB'd divs using hx-trigger="load" and all return within a reasonable amount of time, letting me focus on writing SQL.
Check out Solidjs first. Solidjs looks similar to react but has no problems with data changes in context
The example you wrote in he video to illustrate "the problem" has nothing to do with the problem actually. Just fetch the data from a sane endpoint and render the list -> now the "fetching in the render" is slowing down the first fetch call what? 5ms? 10ms? 40ms? Most of the problems come from really bad architecture. Why on earth would someone fetch each item from a list separately when in fact they are all needed? Even if you need to load them while scrolling or w/e you can still obtain multiple results at once (paging).
With react-query you can prefetch data elsewhere
Your example server side dependencies is way too simple. Waterfall-dependendencies are costly, even sever side! Imagine multiple collections within your resource then each of these collections also have a couple shared collections dependency of their own. The API will take double digits seconds to return. That's not fun.
7:27 Theo sounds like he's in "interview with senior js" video.
The react community is the most insufferable community i have been in contact with, i miss ROR already
Aw, did someone steal your sweetroll?
I like the python machine learning AI community... its just wait for it to end, collect data, analysis and rerun 3h
Did he just ended the video with "Please watch this video"?
Dan trying so hard to use maths. Which shouldve contain proof instead of a one hit wonder one liner
Thanks theo for explanation
"We are all here because we love react" I mean it's good. But I'm here for your stash.
why were they complaining; Suspense was experimental...
After the rust cult, we have the react cult 😂
agree if you working on new project, disagree if you working on existing project which has live for few years. simple as that.
Not excalidraw... excalidraw
so basically htmlx/Marko.js with extra complexity.
So, basically, read the manual?
Remix fixed all this for me thankfully
"We're all here because we love React" I'm a backend guy who despises anything frontend that's not hand-written HTML/CSS/JS, so I guess I'm mostly here for the schadenfreude?
If you dont want to waterfall and load the js first, why not use php? Front end devs are the craziest evil devs doing premature optimizations