Today is a good day to stop using react
>>109045961I never started.
>>109045974If you use the web - you use react.
>>109045961retvrn to server side rendering
SolidJS is better. It uses JSX too, but instead of autistically constructing a virtual DOM so that you can re-run 500 component functions every time the user clicks on a checkbox, it runs each component function only once and just observes whatever state variables were used, immediately updating specific properties of the element in response to changes. It feels a bit closer to vanilla HTML+JS reactivity, just more automatic.React is such a slow and clunky piece of shit compared to every other framework, people just fall back to it because it's easy, but I'm hoping Solid can change that.
TRD >>109047832just stop using this nonsense entirely
React is better for vibecoding so it's my choice
>>109047989stage 5 cancer
>>109048018Yeah instead of vibecoding something that can I can put online in 45min I'm gonna spend 2 months building shit on solidjsAnd the end user can't even tell the difference
>>109048167nobody's using your slop anyways lol
>>109048167use html
>>109048167Stage 10 cancer.
>>109045961at this point in time, there is literally no true discernible difference between any of the major frameworks apart from the syntax you write. they all do the same shit, and they all get vibecoded to hell and back.
>>109048174I have a job, if you had one you wouldn't be disagreeing with me
>>109047832Pure React on its own is fine. I implemented full webgl rendering engines using react update cycles for rendering loop and didnt see any performance issues. But that was pure React with hooks.What is horrible is that abyssal retarded slow crap NextJS. I have no idea how anyone can take this ultra slow, pointless piece of shit seriously, or any similar crappy overhead frameworks.
>>109048284>i- i have le job!!imagine being proud about working at a jeet sweatshop
>>109045961I don’t care about those frameworksI just ask Claude to build whatever I want and I ignore everything elseAny other workflow is transgender and luddite
>>109045961I know a website is using react if it shows me several spinners for 10 seconds instead of content immediately.I know a website is using react if in the middle of reading an article, text suddenly disappears because the component it is on was automatically unloaded due to some irrelevant javascript error.
>>109045961CSS is just as complex as JS nowdays
>>109048545>I just ask Claude to build whatever I want and I ignore everything elseYou sound very replaceable.
>>109045961at my job, we currently fight a huge performance problem with react. What's amazing is that yes, react is already quite slow by itself, but there are libraries that really turn it up exponentially, making the site pretty much unusable, with clicks registering after a few seconds.Personally, I always use vanilla and I love it
>>109048856You dont work in tech, trans
Yes. Please give some love to the no-npm, no-deps, no-build frontend framework I wrote: https://qitejs.qount25.devIf anything, just get inspired that it's possible to write a full-featured frontend framework without all this React-and-friend insanity.
>>109051150dude. if someone is abandoning the use of the most popular frameworks, he probably isn't looking to use another framework and is going vanilla.
>>109051210Yeah, I know. I've primarily built it for myself and I use it actively. It's fully SSR compatiblw and it fits my projects. No expectations here, but it's worth saying it's unlike any other js framework, yet somehow feels a lot more sane.
Use case for (((frameworks)))? Retarded fucking imbeciles think that just because a big company uses it then it they use it as well they be as successful. Fucking fucking retards>it le makes things easier>le this>le thatNo you fucking baboon just use vanilla JS you incompetent fucking subhuman
>>109051690>Use case for (((frameworks)))?trying to grab a piece of the "industry standard" pie and lord over it.
>>109046365I have been doing web dev for 20 years and have never used react because I am not retarded and understand how things work on a fundamental level. React is a fractal of retardations and all the so called "developers" that fell for it outed themselves as double digit iq retards.
bros I hate "reactive" so much.Maybe it's because I have only seen shitty implementations of it.But if every developer has issues with "reactive", maybe it's not on the developers...
>>109052067You hate spreadsheets?
>>109052024so you using html/css/js for front end?
>>109052081Yes and it's great.
>>109046365>If you use the web - you use react.wrong and Mozilla proved it when they moved from React to Web Components on their MDN
What's the point of even using React now when there is already support for native web components?
>>109047832this, plus Solid's state is way simpler and easier to usemany React libraries use Solid under the hood (e.g. Tanstack)>>109047921you'll keep saying this until you actually have to do something for once in your life. Then you'll realise how abysmally dogshit the web is and why React was created
>>109052362MDN is 99% static shit, they have no excuse to be using whatever they're using right now, and Lit is the shittiest middle ground of all.
>>109046613retvrn to static sitesif it must be dynamic, astro islands + laravel backend api
>>109045961No.React works, makes SSR trivial, has tons of libraries and tools. It's the best framework for making WebApps as of now.>>109046613You can have both, React makes it trivial to add SSR.My websites use React and also support SSR and also support browsers without JS by fallbacking to HTML forms and cookies.
>>109052363Web components suck and do not solve anything.
>>109051690If you write website sufficiently complex, you either use a framework or end up developing a de facto framework yourself.
>>109053290conversely, if your website is not sufficiently complex (99% aren't), and you use a framework, you are wasting everyone's resources for no good reason.
>>109053290Yes, but React (other major frameworks like Vue and Svelte too) and they way it does things is just wrong.
>>109048744>I know a website is using react if it shows me several spinners for 10 seconds instead of content immediately.Holy shit why is /g/ so full of retards and nocoders?If you see a spinner then it means the server is lagging, not front end. It literally doesn't matter if your front end is in react or vue of vanilla, if your server is not responding and you have to wait. If it was react lagging, then your entire browser (tab) would be lagging, with no spinner animations whatsoever.
>>109053305Agreed >>109053309Works on my machine
>>109053290it honestly massively depends on the specific use casemost people aren't developing the next figma...
>>109053305>>109053314B-but I LOVE to waste other people's resources!
>>109053317Figma is not a good use case for a dom framework. It's a wasm territory.JS frameworks are good fit for complex apps where you have multiple subpages, content is dynamic, there are regular XHR, many callbacks/event listeners, popups etc.
>>109053314On your machine, sure. But when I visit websites that you created on your machine from my tablet or phone, the melt, I wonder why. Also the build step is fucking ridiculous, writing compilers to compile a language into an interpreted language should be illegal.
>>109053325That's why my websites function with react for normal people, and if someone disables JS they get fast but feature poor version for luddites.
>>109053332See >>109053334
>>109053311you would be correct in theory, but in practice somehow every slow ass website turns out to be react shit.you only need to look at twitter and then nitter.
>>109053334Yeah, if you do that, you're excused, but I do not believe for a second that even 1% of Reat websites can do that. Furthermore, it's simply more complex to achieve that kind of shit with React.
>>109053260Photoshop Web version is built with web componentsSalesforce Lightning is web components
>>109053340This. I remember 7 years ago Twitter was super snappy, thank God I'm no longer in it. Whenever I open it, it's extremely slow and retarded. And it happens to literally every React website I visit. And people can generally see it for what it is now.
>>109053331>Figma is not a good use case for a dom framework. It's a wasm territoryYou are correct>complex apps where you have multiple subpages, content is dynamic, there are regular XHR, many callbacks/event listeners, popups etc.Yeah and still I don't believe most projects need those features
>>109053311Thanks for proving you are a nocoder retard. t webshitter 15 yoe
>>109053331>>109053385> complex apps where you have multiple subpagesSSR is fine for those, I think the biggest problem with React and friends is that they reinvented resource routing on the frontend instead of making it possible to build mini-SPAs on any page with heavy logic, while leaving the rest of the pages out of it. But ofc then React wouldn't be so popular for webshitters, they'd have to learn backend too.
>>109053340>>109053362You absolute retards. JS is single threaded. If the JS code was the bottleneck then your entire browser (tab) would be unresponsive. The only reason you see spinners in react websites is because majority of web is written in React and websites that aren't, offload that latency to the main fetch which means that instead if seeing a spinner you just see blank page until it loads fully, and rinse and repeat every time you click any link there.
>>109053261Laravel is the most retarded shit I've ever had the displeasure of trying to use. You have to have profound brain damage to even consider it. I'd rather manually operate the website by handwriting the response to the client everytime a request comes in than use laravel.
>>109053348>Furthermore, it's simply more complex to achieve that kind of shit with React.Wrong. I wrote plenty of complex WebApps and every time I didn't used a framework, I eventually had to replicate framework functionality, except in less flexible way that took significantly more time to develop.
>>109053385>I don't believe most projects need those featuresMy projects need these features.
>>109053411Not an argument
>>109053422lol what? open network tab and see how many unnecessary requests an average React app makes, how many delays it introduces etc. This doesn't require browser to freeze up and isn't a performance issue, it's a literal skill issue incentized incentivized be the retarded React framework devs who conceived the monstrosity.
>>109053419oh is that why API access is so rare these days? I don't get it honestly why not more websites just expose nice APIs that I can consume and integrate whichever way I want. Hell rate limit me to death I'm probably not sending many calls anyways I just wanna make a nice CLI so I don't have to suffer through your abominable webui just because I like your business logic. Blergh
React sounded cool to me in practice, it was easy using prior one way binding web frameworks, but the heavy reliance on fake html DSLs always felt off to me and everyone always starts top-toeing around mutable state. I think something like react would work very well in a language like Rust, where you have real (mutable) reference types with borrow checking, but on the web, I'm not so sure what can be done.
>>109053430I like it. It has sovl.
>>109053419React is not in opposition to SSR.Actually, it makes SSR very simple.Dividing your codebase into react and non react makes no sense and solves no problem
>>109053311>If you see a spinner then it means the server is lagging, not front end.That's what a beginner might think. There's plenty of cases where the server is responding decently fast but the page is still slow as shit (should be instant).It's often because they are using something like react that encourages bloated pages and it's making tons of requests (often to different servers) to actually build the page, sometimes even sequentially.
>>109053430This.I have every single second I wasted on this shit at work.
>>109045961I'm too deep into it, it is over for me.
>>109053475React is in literal opposition to SSR. Before React I didn't even know the term SSR. I remember first time seeing the term and wondering if it's some fancy new thing. You motherfuckers make me so angry. Nothing makes me as angry as retarded React lovers.
>>109053445React is a DOM frameworks. It makes no requests that the same vanilla JS website would do.Again, if the react is the bottleneck then it means your browser uses 100% CPU and your tab is unresponsive with no spinner animations whatsoever. You see spinners because the backend is slow, not because client is slow.
>>109053500You are absolutely retarded, as expected from a React monkey, You've been replied two twice on the matter of> but muh frontend isn't the reason for le browser being le slowRead this: >>109053445>>109053476
>>109053460If you made a SPA website then it means you already have some API available. If anything, it is easier to add public API to an SPA app than make one from scratch.
>>109053476JS is single threaded. If your client is the bottleneck, then your browser would be not responsive. You wouldn't see any spinner animations whatsoever.No amount of mental gymnastics will change that simple fact.
>>109053500Also React isn't a DOM "frameworkS", it specifically abstracts the DOM away and re-renders it with JavaScript. React is a twisted joke that only became popular because of the retardation of Facebook devs.
>>109053498>React is in literal opposition to SSR.False. All my react websites use SSR. React, actually makes it simple to add SSR.
>>109053530No amount of name-calling will change the fact that JS is single threaded. If your client is the bottleneck, then your browser would be not responsive. You wouldn't see any spinner animations whatsoever.
>>109053546>JS is single threadedhe doesn't know about web workers
>>109053552You motherfucker, you keep saying that, well please go ahead and explain to us how your React websites use SSR and how they work perfectly fine without JavaScript enabled, please show some code as well.
>>109053560> make 100 requests to the backend> browser not lagging, very responsive > spinners spinmany such cases
>>109053550React is a dom framework because it generated DOM, as opposed to generating CSS or rendering on canvas.
>>109053560The js itself is, but the underlying event loop can dispatch multiple things at once and you're also ignoring WebWorkers or iframes, even.
who came up with the idea of basing a whole website around js? and why?I have a theory this is one of the major reasons why the internet is so shitty nowadays.I don't want a reactive website. Stop changing website aaargh!!
>>109053563React doesn't use web workers in a typical workflow.
>>109053601Probably braindead phone users who like the flashing lights and gizmos
>>109053601> be "talented" Facebook dev in 2010s> be paid a lot of money to do any sick shit you want> have "ideas"
>>109053601The same people who wanted to port applications to the web. To claim the idea is insane, is frankly, retarded. How much JS is too much anyway?
>>109053612Yeah a lot of software is just justifying your role and your pay. What happens when things are mostly solved? You come up with new "solutions". Everything got bloated because people couldn't just stop and focus on the core functionality, refine things, they had to invent more, and a lot of it wasn't useful.
>>109053582Making 100 requests to a laggy server will take same amount of time bo matter if you use react or not. It has nothing to do with ajax.
>>109053619I guess webapps are an okay idea but genuinely most 'webapps' don't need to be webapps at all - and besides everything is a webapp nowadays.I'm always looking for good old desktop programs cause they just feel better. Unfortunately the space is dead.But webapps always feel the same, always look the same it's always so clunky... :(
>>109053596It literally can't dispatch multiple things at once. If your JS function blocks and doesn't return to event loop, your the entire tab or browser hangs. JS can only process one thing at once.>WebWorkersReact doesn't work in a web worker.>iframesI'm pretty sure iframes run on the same thread as the tab/browser. But I am not sure because no one uses iframes in 2026
>>109053644Yes, only you don't normally make 100 requests to the server normally. You make exactly one (funf) request with SSR and that's about it.
>>109053664>you don't normally make 100 requests to the server normallyI might not, but most people do, normally
>>109053659You can literally run multiple fetches in parallel, you can see this with the network tab and the waterfall. Any call that dispatches to webidl can be parallelized. Yes, handling the result is not. It's strictly cooperative concurrency.
Using React since 2015, never stopping.
>>109052363React components are for organizing codeWeb components are for delivering custom elementshttps://mayank.co/blog/web-components-considered-harmful/>Components compose>I can create an <Input> primitive component that wraps an <input> element. And I can create a <ThemedInput> component that wraps the primitive <Input>. Then someone else can take my <ThemedInput> and create a <PasswordInput> on top of it. After all of these components are resolved and initialized, the final DOM tree should really only contain a single <input> element.>The intermediate components are not (always) relevant for the DOM tree. The browser doesn’t care how the code on my website is organized. In other words, components are totally made up. That doesn’t mean components are not useful; just that they exist in a different plane. This is what makes it possible to compose all the way up to a <Page> componenthttps://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/
>>109053664That or you look at your ~10 second page load and 6 gorillian API calles and start thinking about cache-control, etags, localStorage, sync engines or literally just doing SSR with rehydration. Problems suck and obviously the right answers aren't always possible.
>>109053676Fetches are not handled by react. If your react code is lagging then your entire browser will be lagging.
>>109053702You don't need to do API call to access localStorage.React supports SSR and rehydration.
>>109053716Accessing localStorage is a blocking API call in the browser.
>>109053290the question is: why does a website need to be complex? it should be as simple as a word document.
>>109053567Okhttps://github.com/funmaker/webapp-boilerplateHere is the base boilerplate code I use to develop most of my webapps. All the SSR magic happens here: https://github.com/funmaker/webapp-boilerplate/blob/master/server/middlewares/reactMiddleware.tsxBasically, react-dom/server allows you to take your client code and render it into dom. Then it gets put into basic handlebars template that adds everything else, including the initialData JSON which gets used to rehydrate and restore state on client.In my apps you basically have 2 ways of passing data to client, there is typical REST API which gets triggered on async actions/forms and such and there is "page data" which is data bound to specific route. If you fetch data on browser that Accepts html, it gets SSR'd and the data is embedded in HTML as initialData. However if you fetch these routes as XHR, you get JSON, that's how SPA is archived.You might also be interested in webpackMiddleware file next to it, it handles Hot Module Replacement. This boilerplate can hot replace both client and server code.Now for no-JS part, this of course requires some workarounds. Of course not every website can function without JS, porting a client side game would be completely infeasible. But sometimes you can make a simple subset of functionality that will just work. For example:https://github.com/funmaker/hybooruYou can check the demo using link in the repo.It's just a booru it can function without JS, it just fallbacks to using forms. Of course then you won't get mobile friendly gallery, autocomplete and various customization functions. But I even managed to make themes work without JS. The bulb button is actually an input type="image" which is wrapped in a thin form. It executes request that changes a cookie that then sets theme during SSR.
I much prefer Angular. I'm not sure how React even became the dominant library. It has the same spaghetti code hell, bespoke solution issues that JQuery did. No two React solutions look remotely the same and it's a big issue in terms of maintainability, and they engage in some of the worst dependency hell imaginable because it isn't a real full fledged framework so you have to frankenstein together your dependencies. Do React devs actually like it or is it forced on you? You don't have another preference?
>>109053902>I much prefer AngularStopped reading there. Nocoder confirmed.
>>109053902>I'm not sure how React even became the dominant libraryReact is less opinionated and more like functional programming. This makes it much more flexible, allowing you to adopt it to various programming styles, improving the developer experience significantly. Angular that forces you into pseudo enterprise single way of doing everything just feels like a slog. It's like going back from Rust to Java again.>Do React devs actually like it or is it forced on you?The opposite. React is much more flexible and doesn't force anything onto you.
>For a public deployment of your [REDACTED] app, I would use:>FastAPI>Jinja2>SQLite>OpenAI>python-docx>A few lines of vanilla JavaScript>and nothing else until there is a clear need for additional complexity. That's probably less than 10% of the technology stack that a typical SaaS startup would use, while still being fully capable of serving real users.is this enough /g/ or is it still too bloat?
>>109047832solid.js still has a runtime, just use svelte (just ships vanilla js) or roll your own manually using something like alien-signals
>>109054102Fuck-massive bloat. Worse than a classical react/express/mongo stack.
>>109053659>I'm pretty sure iframes run on the same thread as the tab/browser.Only if they cannot safely assume direct access of each other's window contexts.That means cross-origin iframes may process in parallel.And iframes where policies have been used to disable direct access may as well.That's not to say they WILL - but they MAY.
>>109054102go/sqlite/vanilla javascriptyou can serve tens of thousands real world users on a $5 vps without optimisations
>>109054101>React is less opinionated and more like functional programming.React hooks and functional components, which promote side-effect free programming making them somewhat smell like functional programming, didn't come into being until React v16. Long, LONG after React had started dominating the framework space.
>>109054199Even OOP React was more flexible and less opinionated than angular.
>>109054197Yes and, btw, you can do the same with Rails or PHP on the same $5 vps, which is a bit slower and less performant, but eeasier to write. React devs are delusional.
>>109054197>>109054212If you want to save as much money on server as possible, then using react without SSR will put less strain on your server resources.
>>109054248btw, that's also questionable with those 100 requests a typical react app makes
My website uses react and nextjs, can you guys tell me what you think? https://umigalaxy.com
>>109054276React has nothing to do with async requests though. React just renders DOM and binds callbacks, it's your app logic that does requests, indifferent to where you get that data from.
>>109054311sure, bur how come we only see this shit with React apps?
>>109053659>>109053560>if the react is the bottleneck then it means your browser uses 100% CPU and your tab is unresponsive>JS is single threaded. If your client is the bottleneck, then your browser would be not responsive. >If your react code is lagging then your entire browser will be lagging.All wrong.There's worker threads.function calls implemented by the runtime can be threaded.There is Async.The only situation where you would block is a loop or a string of synchronous functions, without yielding. Which almost never happens because doing a lot of stuff you'll probably call an async function just by happenstance.React internally is not that either, it yields. >>109053704see >>109053445 >>109053476
>>109054322The truth is that although react itself doesn't do this, it is the natural way to organize programs written in the react framework. So it's a bad excuse to pretend it is not react-related.
>>109053854Even word documents aren't simple. wtf? Microshart can't even get "pixel-perfect" behavior between Office365 and old versions of Word. The real world demands features and functionality.
>>109054358>can't even get "pixel-perfect"If only that was the problem, the documents will often be completely fucked. And not some old unsupported version either. Between current web and desktop.
>>109054376Irony is PDF is equally cursed. Adobe and M$ keep shitting it up with insane garbage. 3D PDF is basically just an inferior mhtml (literally uses chromium for js and webgl as well). They keep adding document protection garbage too. I'm sick of it. It's pathetic I have to kneel to web browsers as the only sane, portable document viewer in 2026. Sadly I don't even think browsers open mime encoded web pages anymore either...
>>109054322Because 99% of webapps complex enough to require many async requests are written in React.
>>109054341How? You'd still have back-and-forth with two-way binding MVC-esque UIs as well. The whole point of react is just forcing functional immutability to prevent inconsistency. Anything else is basically added on after. Hell, people use to need redux because of how fucking small react really is.
>>109054331>There's worker threads.React doesn't work on web workers.>function calls implemented by the runtime can be threaded.If your JS code calls any such function, it will block your browser/tab thread until it returns.>There is Async.Async does not wait for React computation, it waits for server or a timer 99% of time.>The only situation where you would block is a loop or a string of synchronous functions, without yielding.React is synchronous. If your react is lagging then your entire tab will be lagging. A spinner is not an indication of a client side lag, it means your server is lagging.>Which almost never happensThat's exactly my point.
>>109054448>Async does not wait for React computation, it waits for server or a timer 99% of time.It doesn't matter what it waits for. What matters is that it yeilds. Whenever you await, you yeild.So if you have a un-yeilding JS sync renderer (so not react) rendering the page for 2 seconds, that would not be a hang if you have 10 fetches with json interspersed in it because it would yeild every ~100ms.>React is synchronous.No, but doesn't matter, what matters is that it yeilds. It uses a system of scheduled callbacks to do this. Heck you can even ask for a framerate so it yeilds in time for the next frame.>lagging>client side lagJust say you're new to coding
>>109053311lmao vibegrammers
>>109045961my work is going to start using react from using no js framework. But at home I refuse to do web dev
>>109053876>wipes the entire screen when crashing
>>109054592>Whenever you await, you yeild.You can't await for React. It works synchronically in the main(dom) thread.>So if you have a un-yeilding JS sync renderer (so not react)We are talking about React.>No, but doesn't matter, what matters is that it yeildsIf your app is so complex that react adds significant amount of overhead it will not yield. It only yields after it is done rendering the dom.>Heck you can even ask for a framerate so it yeilds in time for the next frame.Exactly. If you see a spinner then it is not react lagging. It means it is waiting for server.>Just say you're new to codingI have been programming for nearly 20 years.>>109054595What does that mean?
>>109054666What do you mean by wipe and crash? As in browser crashing?
>>109054670>We are talking about React.It was a steelman of your argument yet you cannot reply.>if your app is so complex that react adds significant amount of overhead it will not yield. It only yields after it is done rendering the dom.This is just wrong. Go look at the source code yourself: https://github.com/react/react/blob/main/packages/scheduler/src/forks/Scheduler.js#L570
>>109054874>It was a steelman of your argument yet you cannot reply.The entire argument started from a claim that React displays loaders because it is so slow which makes absolutely no sense because if you see a spinner it means it is waiting for some request or something and not for React itself to do its job.>This is just wrong. Go look at the source code yourself: https://github.com/react/react/blob/main/packages/scheduler/src/forks/Scheduler.js#L570Nothing in this code will display a spinner while React is doing its work.
>>109052133you should kill yourself, you are the reason javascript is everywhere, look at all the malware everywhere, its all on you nigger
>>109054934>The entire argument started fromAnd then you made statements like:>if the react is the bottleneck then it means your browser uses 100% CPU and your tab is unresponsiveWhich are wrong and I explained to you how they are wrong even if react doesn't yield (it does)>Nothing in this code will display a spinner while React is doing its work.No one said it does. Im showing you where it yields.
>>109054129svelte also has a small runtime, just like solidJust use either, but I prefer svelte because it's elegant and kinda fun to use.
>>109053902React was made for jeets
>>109053902Angular is fucking bloat dude, yeah it's a framework and enterprises love the code architecture, but it fucking sucks
>>109055015>Which are wrong and I explained to you how they are wrong even if react doesn't yield (it does)Even if react yields because of effects or suspense or whatever, as long as it has some work to do it will take 100% of the core. React does not dispatch any webworkers or inherently waits for any async operation.The point is that you can't reliably display a spinner to wait for some supposed react overhead. That's not what spinners are for, that's not something that happens, there is no semantics to express something like that. You can't tell React to "display this DOM while you are busy rendering the real content" or whatever happens during this supposed React overhead. The closest is suspending with a placeholders while you are waiting for the server.
>>109055116can you normies stop arguing irrelevant stuff, it's empirical truth that spa is garbage, normies call it "javascript" because they barely know how to use a pc, I call it "raping the user pc instead of paying bigger servers" basically late stage capitalism
>>109055033>sveltedon't get me wrong, I love svelte but holy shit this runes concept is so retarded. oh you want actual reactive variables? better $state or $derive those fuckers then! if I wante explicit over implicit handling, I'd be writing my frontend with fucking python.
just use Preact?it has the power of React but is much smaller
>>109054408>webapps complex enough to require many async requests are written in ReactMuh CRUD so complex, must async
>>109053876Ngl your booru example is so fucking stupid. It's a single POST form to a search API end point. You could probably setup a cloudflare worker connected to an external search provider api connected a cached db and host this thing statically.>no responsivitygrid? flex box? media queries?responsivity should be handled by CSS exclusively and if not, you can always do such a simple route, again, with a cached cloudflare worker. No explicit server/backend needed.Also much better SEO this way, integrated CDN, just snappier in general>dark modeLol, Nobody needs dark mode. Nobody needs a fucking custom SSR react framework to do this.
>>109055910>Ngl your booru example is so fucking stupid. It's a single POST form to a search API end point.What do you want from me? You asked me how to write a React SSR app that also works without JS on client side and I have shown you a simple example of exactly that. Are you expecting me to show you a large webapp just to demonstrate this simple idea?>You could probably setup a cloudflare worker connected to an external search provider api connected a cached db and host this thing statically.Users wouldn't like that. They are self-host type people who rather spin a simple service like this one on their home server than to pay for a cloud solution. And so do I.>>no responsivity>grid? flex box? media queries?>responsivity should be handled by CSS exclusively and if not, you can always do such a simple route, again, with a cached cloudflare worker. No explicit server/backend needed.>Also much better SEO this way, integrated CDN, just snappier in generalWhat are you talking about? JS is not used for responsivity. It's for stuff like SPA, endless scroll, autocomplete, mobile gallery, ruffle flash player, etc.>>dark mode>Lol, Nobody needs dark mode.I like dark mode.
Also I just realized light mode throws 500 for some reason. I wonder when that happened and why no one reported it yet. Maybe because no sane person uses light mode lmao.
>>109053244>you'll keep saying this until you actually have to do something for once in your life. Then you'll realise how abysmally dogshit the web is and why React was creatednope>>109053290nope
>>109054429> You'd still have back-and-forth with two-way binding MVC-esque UIs as well.There are many ways to organize. For example even MVC is not the only way to do presentation, MVVM is another common pattern if we are stuck adhering to named patterns. Writing callbacks at the function level instead of as the action level is another key difference.Hint: react is not the first UI framework ever made. Most desktop frameworks did not have these problems.
>>109055252>just use Pajeet react?>it has the shitting power of React but is much more indianThanks ranjesh, very cool
>>109053854>why does a website need to be complex?Stupid people make complex things.
I use flutter
>>109057647Exactly idiots admirer complexity while smart people admirer simplicity.>>109058656Bless your heart Pic related, left peak are React users
>>109060376Left side of left peak is flutter users though
>>109060387Shots fired
