Did RSCs Really Turn React Into PHP?

[@jherr]

It is important to note that my jQuery code and vanilla JS code are performing what amounts to dangerouslySetInnerHTML operations (in React terms). In the case where you don't know the provenance of the data, or you have not properly sanitized it, this can lead to an XSS vulnerability, though the code shown here does not have an XSS vulnerability because the user input is not reflected. Please take care if you choose to use the JavaScript in the PHP or Rust examples (which is not recommended) to sanitize the code, or to create DOM elements programmatically and only set their innerText to avoid potential for XSS attacks.

[@VincentUchennaOk]

Not a fair comarison at all. Far from it. PHP is a bare server language. RSC+React is a library on top of "Javascript" which is a client language. Use laravel-breeze+alpinejs as a library ontop of PHP and see the difference. Thats what will be a fair comparison, not this..

[@jherr]

@@VincentUchennaOk Question for you, if I put both of these sites side by side and you were not able to bring up the inspector or view source, if you were able to only interact with it as a regular customer would, could you tell which was which? Would you know which was React and which was PHP? Would just a regular customer using the site care if it was created using React or PHP? From the customer perspective the two apps are the same. Thus, it is a fair comparison. Not all sites are huge mega-complex monstrosities. Not all sites need a framework to build them.

[@VincentUchennaOk]

@@jherr That's not my point. I get the fact that they both look alike from a customer point of view. But in terms of technical comparison, it's far from fair. And I feel the pain from most PHP devs right now. Thank God for Laravel, etc.. and all those building tools to make the language most accessible like what nextjs is doing with React. And to look at it more critically, data is every company's business and power, so every Ceo would trust a safe and full featured backend server over a new tech like RSC, than compare frontend technologies. My point is this, every CEO will safely add new frontend tech to their reliable backend, than add new backend tech to their reliable frontend, always... It's inside out, not outside in.. That's why is think this RSC might struggle to take root for long..

[@wizamit]

Exactly what I was thinking. Why are we comparing a meta framework with simple PHP and jQuery 😅 Just use laravel + livewire.

[@ricardodasilva9241]

I think would be cooler to compare nextjs to laravel

[@nimmneun]

Yup, Laravel adds quite the overhead. And maybe use php-fpm with e.g. nginx, since PHPs built-in Webserver is only meant for debugging etc. It's rather slow.

[@king-manu2758]

I would love to see this too

[@elamandeep]

I agree

[@SpaghettiRealm]

@Shadow how about using fetch

[@rajfekar4839]

@Shadow use livewire component

[@mahmoudmousa2405]

Thanks for making this video. It must have taken a lot of time. I still thinks React is going the wrong way. What NextJS is achieving now can be done with simpler code like you showed here. This can still be much better by using AlpineJS or Tubro

[@ing.jdplee]

The content of the table can be put in a and work with that so the headings dont need to be put each time.

[@jitxhere]

At the end Jack simply brought the absolute boss Rust lmao

[@tariksadiku4723]

I'm just a junior developer, but I also agree with the "we still don't know the best practices for the relationships between RSC and RCC". I believe, without clear instructions on how to handle these two, it might get messy really quick.

[@marcuss.abildskov7175]

React in a nutshell. Garbage library m

[@najlepszyinformatyk1661]

@@marcuss.abildskov7175 BS

[@edhahaz]

Some other framework will figure it out eventually and react will clone it within 1year

[@ouss]

Tom uses PHP

[@wp_panther]

yay I'm just glad people are talking about Php again. I love it and I think it's one of the easiest languages to pick up if you want to start wrapping your mind around server-side!

[@thesunabsolute]

The RSC patterns completely break down when you start to scale up an application. It becomes very difficult to remain consistent in how you use them. We ran into issues where we were just declaring "use client" on most components and only using the RSC as a data fetching layer. This led to issues with prop drilling from the top data component down to child client components. At that point, we just ditched the re-write project for 3 of our big Next apps. People hate getServerSideProps, and I get it, but I'd rather have that implementation over RSCs, as it sets a boundary, and the component receiving those props is just a client component. It just makes way more sense to me. I would look to something like Remix with its action/loader paradigm if I wanted to move away from NextJs, should they sunset pages and gSSP().

[@jherr]

Yeah the loader paradigm is sweet.

[@regibyte]

Fantastic video Jack! Thanks a lot for taking your time to do this comparison. On a side-note, for heavy PHP users these days there is another library that really shines and it's alpinejs, it's lightweight, fast and integrates easily with php.

[@jherr]

I will check that out! Thank you!

[@waleedmasoom6326]

@@jherr on that note, the TALL stack is being implemented in my team (tailwind, alpine, laravel and livewire) and I'd be curious to hear about how livewire and alpine look/feel to someone so familiar with the React world such as yourself.

[@elamandeep]

​@@jherrplease compare laraval vs next js

[@marcuss.abildskov7175]

They got nothing to do with each other lol

[@regibyte]

​@@marcuss.abildskov7175 you are right but at the same time, in this video Jack used NextJS and compared it to raw PHP, it doesn't make sense either to compare an SSR framework to a full language, but here we are anyway. NextJS offers so little to the development experience in comparison to everything laravel has to offer, it would indeed not be fair to compare both.

[@sammckay]

Laravel with Livewire would have been a nice comparison for the PHP side. Nice video though

[@lutfiikbalmajid]

Livewire is always send request for every states action.

[@skapator]

Sad but true, the decision for all is based purely on job market. Not tech. Unless PHP starts to get more views on youtube.

[@yashkhd1100]

Excellent video Jack..!! I think there needs to be rethought in direction major JS frameworks are going. With cut throat competition in JS frameworks space they are just coming up with features which are not well thought out and more of a patchwork. Just look at syntaxes like "use client" and than there are special folders in NextJS with '(' syntax, all this I consider not very mature design. It works but it's not clean. Putting server functionality in client side frameworks is not adding much of a value. The whole JS full stack thing started with developers able to share models and some common functionality between both client and server so both always remain in sync and JS is the only option which is widely supported in both client and server. However, doesn't matter how much optimized JS runtime engines are at the end of the day JS is a "scripting language" and all variables/functions in JS is merely an "associative array". There is nothing much compiler/interpreter can do to get more performance. Just look at perf numbers...languages like PHP which is not known for performance are easily beating JS by miles. Matured systems like Java or .net core will easily beat JS and PHP by miles. In my opinion rather than overengineering this JS frameworks React should continue to improvise on client side and let server side systems handle their things for the better.

[@2gbeh]

Agreed

[@BeyondLegendary]

Impressive, very nice. Let's see Paul Allen's performance comparison.

[@jherr]

So the Microsoft Paul Allen? Or some other guy?

[@BeyondLegendary]

A movie character played by the B-lister Jared Leto.

[@nathanpointer7844]

Love that meme

[@codedusting]

Lmao 🤣🤣🤣 you're commenting this in every one of Jack's videos.

[@artuchka-profi]

​@@jherr american physco movie starring Christian Bale

[@codernerd7076]

2 things you left out, general hosting cost and hard disk space needed... there is a massive difference right there spoiler PHP wins both!

[@CFXTBogard]

The idea is to compare performance, not costs.

[@nightshade427]

Not sure about php, but it is very similar to asp webforms and postback, if you want async components it looks very similar to asp webforms with updatepanel postback, from 2005. The code and approach of react server components and server actions seems very similar.

[@boot-strapper]

YOU DID IT, YOU TOOK MY RECOMMENDATION TO DO SOME RUST!!!!!!!!!!! wooooooooooooooooooo

[@TariqSajid]

php save people life. so hate if you want to hate php. but i will use php no matter what.

[@Flash136]

The component model and state management of React is hard to beat. I'm still sticking w/ React, but for now I will have to use the pages dir because the app router is still too slow.

[@johnychinese]

Yep, I still use pages for any project and will continue to use. It just makes sense

[@nightshade427]

I think people were saying it's similar to modern php with Laravel and htmx/livewire. Not similar to old school php with jQuery.

[@kevanschwitzer8585]

Great content, easy to listen to, and highly informative. One thing possibly worth emphasizing further -- Response times or throughput for hello world style cases shouldn't carry too much weight. In many (most?) apps, most of the heavily lifting will be dominated by things outside app code, the database being the most common. So unless maximum performance at pretty much any cost is your goal, something that emphasizes developer productivity for web apps often hits the sweet spot. (i.e., something like PHP for a web app vs. Rust, C, C++). Even from a perspective of placing a high value on performance (see judyrecords for example) it wouldn't be a good choice to write/re-write it in a lower level language to eek out 10ms.

[@kirillvoloshin2065]

anyone else having Vietnam flashbacks from seeing jQuery?

[@parlor3115]

Thank you for this. I will refer our PM and techlead to this video once I propose rewriting everything in Rust!

[@MMH94MMH]

Nowadays it is no longer necessary to use jQuery, javascript has been greatly improved, I always prefer to write vanilla javascript than to include a lot of code that is not fully used.

[@jherr]

If you watched all the way to the end I use vanilla JS instead of jQuery. And I updated the code on the github repository to do it without using innerHTML and it's still really small.

[@CFXTBogard]

1. Thanks for adding my comment in your video. that make my morning 2. at the end of the video, where you show the charts it would be nice that it indicates what result is better (Page Size (Kb) Lower is better), Response Time(s) Lower is better, Request Per second Higher is better) In that way it is clear what is the optimal value on the chart. Thanks!

[@jherr]

Fair.

[@luizgrocco]

Although it was a really nice comparison and a wonderful job at it as always from you Jack. I find it hard to really trust any of the data we got simply because a more complex app is needed to accurately measure many of the benchmarks performed in this video. If a base case App is all we care about, then framework builders should make their framework as simplistic as possible, since their out of the box "create--app" will probably be the most performant in that scenario. But then, in a large project, that will no longer be true because of all the extra stuff needed to make a good App. All in all, what I'm trying to say is that this video is likely a "micro-benchmark" scenario that should be taken with a grain of salt. Either way, great job! The video still highlights many ways of accomplishing the task and is a valuable source of information like always from you Jack, keep up the good work!

[@garrickcrouch4530]

Hey Jack thanks for all the vids. Super cool to see. One kind of weird comparison is using php dev server. Do you think it would be a much fairer comparison for all to use a proxy server like nginx and runtime/process manager more typical to how node and php are deployed in production services? NGINX -> PHP FPM -> some php stuffs NGINX -> node upstream server via PM2-> some node stuffs You could try an Open Swoole for PHPs server and probably got nearly the same speed of the Rust server form testing I've seen with it. THanks for the vids!

[@jherr]

Hmmm, good to know! I'll check that out.

[@vipinchaudhary7915]

I would still prefer NextJS. Though, Rust looks fine, I am not a big fan of blowers.

[@jherr]

Blowers?

[@adfasdfasdf643]

PHP is honestly better than RSC/Nextjs for the mental model they are going for. I feel like React/Nextjs strengths are still for creating a minimally hydrated SPA with fast interactions. If we were to compare interaction speeds with a json api call, it should be better than PHP or RSC. RSC are currently the worst of both worlds. If I want fast interactions I would go for a SPA. If I want fast page loads I would go for static/PHP/Rust

[@oscarljimenez5717]

If you want highly dynamic site? Then you have to go with RSC, even if SSR is slower right now, you have more things like Streaming, Static etc

[@MobiusCoin]

Really wish you used Alpine instead of jQuery. The comparison would've been a lot more analagous. Also... maybe even Laravel Livewire?

[@jherr]

Yeah, livewire is hella cool.

[@MrEnsiferum77]

RSC and RQ next video?

[@codokit]

PHP is great

[@saintgalgo]

What would be the bundle size if instead of using a client component with a server action you just used a server component and filtered the json response using query params?

[@jherr]

I think I did a bundle size check pre-client component and the numbers were really close to with the client component. Not using client components does not mean a zero sized bundle. Not even close. It still includes React, and still does hydration. It just hydrates from the JSON payload instead of re-running the client components.

[@runonce]

Great vid! I was expecting to see "components" being listed as a huge advangtage to PHP, for me that is the killer feature of React. Also I wonder how would affect the results if you used a PHP framework like Laravel or Symfony.

[@jherr]

Yeah, that's true. You are correct. That would be the first and primary benefit. I guess I skipped over that to isomorphic rendering of said components.

[@mengfandy7365]

Nice Jack, i love your channel :)

[@cloudkungfu]

I love that the investigation gets wayyyyyyy more in depth as the video progresses 😂 good stuff!

[@deimiosxxx]

Dev speed is usually worth more money than performance. Once performance begins to be an issue you are making enough money with your app to hire primeagen to rewrite it for you in rust.

[@Asis2036]

Toms a genius

[@davvidess]

you mean you can hire Tom to rewrite in JDSL

[@kohelet910]

Really cool video ! I love those stats comparisons ! Rust is really impressive. And I do agree, the more i use the app router, the more i feel frustrated by having small tiny bugs, and I don't always get why is that happening.

[@Flash136]

5:46 TIL you can await and receive data from a server action.

[@johiny]

there are lots of ways of do somenthing in web development or in software in general, I guess you have to put in a weighing what you need, what you want, ex: performance, friendliness development, eco system, all that dependent on you and your team, and it can change overtime, I'm sure there is a good reason of why multiple companies started its projects with ruby on rails regardless it wasn't super popular, like everything in the life it depends.

[@_y7ya]

Using JQuery created a bit of an unfair comparison. AlpineJS would've made more sense here.

[@jherr]

I did go with vanilla JS later on and that's 0.4Kb. But ok, I'll redo with Alpine and post a short with an update.

[@vitorgouveia5378]

it did because react team is dumb and somehow hasn't made async client-side components yet, so if you want to await promises on the client you need to do all kind of shenanigans

[@neociber24]

Isn't suspense for that?

[@machinedo]

Great opportunity to contribute to the React OSS?

[@dealloc]

There are many reasons why they haven't introduced async/await for client components. They have tried; Dan Abramov and Sebastian Markbåge has already talked on the subject many times before. The gist of it is React has its own scheduler for handling priorities (e.g. UI events have higher priority than updating state) that users can control through Transition API (useTransition, startTransition). There's no good and consistent way to manually manage priority of micro and macro tasks within the event loop as it's handled by the runtime (i.e. browser).

[@fcnealvillangca7943]

I actually plan to refactor my apps to HTMX and alphine, django and just make overkill todo app list with authentication in each front end framework with nextJS, Nuxt, Sveltekit, Etc Etc. incase future job applications wants a sample of those lol. the only constant in JS eco is the changes monthly. instead of correcting some lapses from previous push I ended up updating new version and breaking changes in frontend I'm so tired 😢

[@neociber24]

I like Rust but we don't have the DX of Javascript and React, I try using Yew and Leptos for SSR and reloading during development is too slow because we need to compile each time.

[@WesleyHandy]

Rust and Vanilla JS seems like a killer combo, of course, if you know Rust

[@jherr]

FWIW, I really don't know Rust, I used a combination of ChatGPT, Stack overflow, API documentation and... engineering skill. To just kinda wing it. Turns out it wasn't entirely terrible. On the plus side that experience gave me a lot of confidence that AI is still just a tool and not a replacement. There is no way I could have done that without being an engineer with previous experience in C/C++, Go, Rust (a little), Java, etc.

[@bideshbanerjee5506]

Jack it's a request if possible can u make a video about making our own server component setup..and also explaining how RSC is working....🙏🙏🙏🙏

[@cariyaputta]

The "use client" and "use server" are ugly, it's like C++'s "pragma once"

[@gencomer]

React, i choose you! :D

[@yaanno]

Thank you for including Rust (again)!

[@TheGiliwawa]

well you're not comparing the same thing if you're comparing php to nextjs one is a language the other is a framework.

[@xanthe7045]

Wow! I guess it's about time i migrate my NextJs app to PHP :)

[@adaliszk]

While the PHP example is fine, I feel like we would need an actual real-world example using a framework to make it apples to apples. As for Rust, rocket is great, although if your really want performance then actix is something mindblowing :)

[@jherr]

A viewer added an axum version and it's apparently 3X faster than rocket.

[@alfieqashwa5257]

Axum ❤

[@mr7clay]

JSX is just unrivaled tech for HTML construction: (1) XSS-safe by default and ensures proper construction of (2) attributes and (3) tags. A huge part of what makes PHP annoying is needing a template language for 1 and you can still mess up 2 and 3.

[@Manoj-lg2xq]

I prefer Go comparison than rust cz Golang is lot easier than rust.

[@abhishekbu1087]

Instead of Jquery, can't we just use Solidjs or React with PHP.

[@YusufSalahAdDin]

Rust/Rocket >= Python/Django? Look same approaching.

[@tech3425]

Really well made video!

[@ZakiWasik]

I think the ending of this video is a perfect segue into the video Theo did over on his channel: kzbin.info/www/bejne/aIuXl42qiLCfmac

[@jonathangamble]

Golang please!

[@mgs_4k198]

The shortcomings of JQuery are not inherent to PHP. The shortfalls of jQuery as compared to React, have nothing to do with php

[@jherr]

Fair.

[@ricardomonge2769]

I would use the one that makes me more money

[@bigmistqke]

looking forward to the interview with ryan!

[@Svish_]

You there's a `` tag for tables, right? 😛

[@hakim_jazuli]

"which one I use?" custom mvc php, that sends cached single line html(no whitespace), and custom mini js reactivity library(standard async operation on client side that used html as template for looping component and other standard function)... at this point both client and server expected to work in conjuction... php sends single line template, and js is assuming php to sends correct template... the main problems is that I used b**tstrapst*dio for my views build tools and it ships bootstrap 5 css and js to client, which is notoriously taxing in the first load🤣🤣.... I could have manually make html and handle css using smaller library, but I'm not planning to manually handle all my markup and style design any time soon😅😅...

[@rumble1925]

React actually did always look like PHP but it was client side. The re-render of the page when you POST new data is what the virtual dom emulates but in a better and more efficient way. PHP isn't bad because of how you could render templates, it was bad because of PHP the language and finicky environment it ran on.

[@jediampm]

However in case of PHP as language, the fault is on Developer for not separating business logic from presentation layer. Where in case of React is a choice of the creator since the release of functional components with state you have that look of mix . It easy to point out the fault to the language instead of the dev choices. LOL

[@rumble1925]

@@jediampm I'm thinking more about how PHP was a language that had no real design direction and was just a haphazard pile of awkwardly implemented functions around C code. It's better now though but hard to get away from legacy code.

[@other_perfection]

thank you! great video as always

[@zakir.nuriiev]

Thanks a lot for an interesting comparison!

[@bessimboujebli1076]

shoud've just learned php it's easy and better

[@orbitory7936]

Am I wrong in saying that you are comparing a full frontend framework with jquery which has no data binding? Like mentioned by others use alpine, htmx or at least some jquery plugin for data binding. But yes hard to beat RSC in react

[@hacktor_92]

so.... everyone is bashing on php with various stuff, yet it's faster than nextjs? wow

[@devjcarrillo]

I love the examples but is this comparison fair? PHP's built-in server is way slower than using nginx or even apache. I think the metrics will be a 🤏 different if used with nginx. Of couse, rust is still going to dominate.

[@Santon-Motho]

Developers fixate on the weirdest things.

[@deathdefier45]

I worked with PHP once for a project in December, figured out how to use it within a day or two just basic crud didn't know it was this performant.

[@АлександрГерасимов-с3щ]

Perhaps filtering is not the best use case to illustrate server actions. I believe filtering, at least at low-medium scale, should be done fully on client. If we send all initial data on first request and keep it on client, there is no need to make additional requests and make server do extra work. And, depending on scale of our data, multiple searches could result in much bigger data transferred than full data set on initial load. For performance I can suggest looking into bun runtime. It can be used to make fast api server, but it is still in development, so it cannot run entire frameworks in its own runtime yet.

[@grinsk3ks]

In general the PHP approach is pretty slick and simple. The problem I have with it is DX and docs. They are highly inferior to JS frameworks. Furthermore the frontend feels "decoupled" in a bad way, since you have your code spread across many places. Template file, js, CSS, PHP controller, ... And then there's the highly discussed scaling issue. On every request, everything is bootstrapped and run. Sounds like a ton of overhead to me. In the plus side your server is basically idle when there is no request. I can confirm the large Drupal apps slow. That's why these projects tend to have a lot of caching. Laravel Livewire might be a solution to this. I didn't try it, but I doubt that it handles reactive rendering as well as a js framework

[@pEeLL00]

I would not use jquery for such small examples. and I would expect Content-Encoding with gzip and compare gzipped size

[@gordonfreimann]

i would LOVE to see same metrics with solidjs too with signals😢

[@jherr]

IMHO, probably going to end up somewhere between NextJS pages and PHP. There is an upward bound on the amount of speed you can get out of a Node server.

[@mrgerbeck]

RSC's are kind of a mess. Server Actions also feel pretty half baked. Let's see how they evolve.

[@mehrdad-ai]

love your honesty!

[@antonychiramel80]

Why do I feel the NextJS team made a mistake by bringing App Router😅

[@arjobansingh1940]

Hey Jack, Great content, you are among the only few content creators who make videos about intermediate to advance topics. Kudos for that. Can I request a video regarding usage of React query in NextJs App directory?

[@therealdevopsintern]

What drives me nut is the cost of hosting a nextjs application. But with php you can host your application on a shared hosting- just copy your files and paste.

[@KyleRonning]

I'm doing a DevShare presentation at work this week on React Server Components. We have a lot of PHP code at my work. This video is great. We should just sit and watch this instead!

[@srinidhihebbar196]

Why isn't qwik used anywhere in the comparisons???

[@jherr]

It has similar performance numbers to pages in terms of raw throughput. Better TTI though than React. Not as good as the vanilla JS version, since even with its aggressive lazy loading it's not going to be lower than 0.4Kb.

[@srinidhihebbar196]

@@jherr Nice work Jack. Appreciate your contents. 🤝

[@hypergraphic]

Great video! It is cool to see PHP again as it's what I cut my teeth on back in '08. At work I'm still just using plain old client side react with Vite for the dev server. Since all our features are behind a login, SEO doesn't really matter to us. Also, as cool as all the SSR stuff is, I struggle to see the advantage of switching. We have a lot of complex UI stuff and I wonder how RSC will change it.

[@jcandeli]

This is a great video but as a side tangent, does it bother anyone else that he doesn't use a semantic Table element instead of Divs?

[@TheVimeo]

wait until you do it via rails with hotwire.

[@walidmkw]

In long term, the state management would exist on rust too no ? A fullstack framework as nextjs is but with rust instead of node ?

[@_ryaaan]

Nothing was said about the composability of React vs PHP. At scale, PHP is a nightmare to manage and maintain. I'll take React any day over PHP

[@jannatulnayeem7289]

You don't even know how to scale a php application and you are choosing react.

[@_ryaaan]

@@jannatulnayeem7289 Please don’t send me back to 2008

[@jannatulnayeem7289]

@@_ryaaan Why you want to go back 2008? Go to 2023.

[@kal9421]

Fantastic video Jack! Thanks a lot for taking your time to do this comparison. I want to ask you if you can can give us an example about how to setup react server component with express or how to integrate react rsc with existing express app thanks !

[@iammahabub]

It was legit & had a great discussion ❤

[@mgs_4k198]

You can still get all of the React (or anyother SPA) library benefits if you create your APIs in PHP and use an SPA library on the front-end.

[@jherr]

Another fair point. You are on a roll!

[@mgs_4k198]

@@jherr I appreciate the distinctions you tried to make in this video, but I think often a times people promote this notion that "JavaScript apps are fast and php is slow" without really making an accurate comparison between the two. I've done a bit of work in both ecosystems. From my point of view the Laravel way offers a lot more than the full JS ecosystems. Also I don't think that the JS ecosystems are just naturally more performant. What is more important is just how you build your app.

[@jherr]

@@mgs_4k198 I think the video shows in all cases PHP being faster.

[@codeitlikemiley]

actix web would yield better results on rust by x1000 times

[@jherr]

I believe you. I just noticed that binserve is based on actix.

[@venomweed]

bro brought a bazooka to a knife fight i was not expecting rust ngl :p

[@2penry2]

Great illustration of why "view as a product of state" is such an attractive offering. Important lesson for new learners about where we came from and why Nextjs/React w server actions is a huge plus in terms of DX.

[@ravenbergdev]

I think when people say "it's just like php" they are really trying to say: the stuff is too tightly coupled and has no clear separation of concerns.

[@jherr]

Yeah. I probably took it a bit more literally than that. :P But because this is such a React channel I did want to show some kind of drastically different alternatives. I see React being misused a reasonable amount. I don't mean bugs, I just mean "I wouldn't have used React for this site." And the alternatives aren't bad. And things like Laravel's Hotwire are, in their own right, very cool and potentially a better fit for a lot of applications.

[@ravenbergdev]

@@jherr haha you showed well! Love it! Undercover PHP developer. 😁

[@jherr]

@@ravenbergdev I'm just a fullstack web developer. Some days that means I'm a React developer, sometimes Solid, sometimes... whatever.

[@TheTmLev]

Rocket web framework is not the best option right now, Axum or Actix Web are more revenant at the moment.

[@erikslorenz]

I dont like any of it these days.

[@nameless4014]

Yes it did