Question about React's future
Posted by HolyPommeDeTerre@reddit | ExperiencedDevs | View on Reddit | 111 comments
Reading this: https://opencollective.com/styled-components/updates/thank-you
It's not about css in js. It's been a while now that React is moving to SSR. A move I have a hard time understanding. With the depreciation of the context API, I am starting to think that I may have to switch from react to something else (vue, preact and co).
How do you prepare for this move? Are you even preparing?
PotentialCopy56@reddit
The problem in the past few years is the core react developers have slowly left and verxel a for profit company has slowly picked up the pieces. Verxel has pushed hard to be the sole maintainers of react and permanently integrate it into next.js. this is all so they can push their cloud services that integrate with next.js.
I believe vercel will be the death of react. SSR is such a small part of react usage yet thats all you hear about and all they seem to work on now because it fits the next js narrative.
HolyPommeDeTerre@reddit (OP)
Thanks for sharing your concerns (or pov). How would you handle having this app in react and now you know that in a few years, you need to switch either to SSR or to pin your version or to switch to something different?
I guess I am asking too much, with little context as mentioned by others.
Main-Drag-4975@reddit
As a backend-leaning sort I’ll be starting future projects with html5 web components instead of something like react components, htmx as the provider of simple frontend behaviors, and as little npm-related tooling as possible.
Jeep_finance@reddit
Use lit.dev. Used it at last 3 companies and we have many apps and component libraries in production right now using it.
It writes web components usable in all modern browsers. I work for a company you have heard of
Darkehuman@reddit
Been using Lit for a while now and love it. Being able to use it for a standalone frontend or exporting a web component library that can be served via SSR is great.
Jeep_finance@reddit
I haven’t used their SSR support. Will have to look into it. Didn’t know that support had actually landed
Darkehuman@reddit
By SSR support all I mean is bundling your Lit web component library into a .js file that gets served on page load so that the browser is aware of the web components you've defined.
Any HTML served after that (like with HTMX) can use those components too.
nobuhok@reddit
This. Lit and Stencil are both good.
MrCreamsicle@reddit
I think you meant to post a video URL behind your second link, but they're both linking to the MDN docs
Main-Drag-4975@reddit
Thanks! I’ve fixed the link.
ottieisbluenow@reddit
For the last two years or so I have been working on a now fairly large Go (chi/templ/bob) and HTMX app. It's great. Extremely efficient and easy to maintain. Overall complexity is massively less than the react version. Losing all of the tooling has been massive.
HolyPommeDeTerre@reddit (OP)
Yeah for new projects I am leaning towards such solutions too
Akkuma@reddit
This seems to be a misunderstanding. Why do you need to use SSR? You can continue using React as a SPA without issues even with the latest React. If you're familiar with React you know how slowly it moves. The idea that it won't continue working into the future as a SPA isn't well supported. They certainly want React to be a full stack framework powered by some meta framework like next, but that doesn't mean that reality will play out.
Now personally I won't choose React for personal stuff and I wouldn't push for it at work, but I doubt they'll shoot themselves in the foot completely.
PotentialCopy56@reddit
Vercel almost made a breaking change on lazy loading to appease their stupid services. The only reason it didn't get merged was because of a huge backlash. That was like last year.
PotentialCopy56@reddit
All apps turn into legacy apps eventually.
HolyPommeDeTerre@reddit (OP)
Yeah true
PotentialCopy56@reddit
I would just go to the highest version before shit hits the fan. Nothing wrong with not using the latest and greatest. By the time it's considered a legacy app it'll probably need to be rewritten anyways. That's if you aren't long gone by then
UntestedMethod@reddit
Bingo. I've delivered many projects over the years and this has ultimately been what I've experienced. Rewriting is sort of inevitable if an app is still viable and needs a major update to the framework it's built on. Data on the other hand tends to stick around much longer as front ends come and go.
Lyelinn@reddit
Yeah even react website now states that “best way” to start react app is to use nextjs. I’m so tired of their shilling and absurdly stupid ideas like yeah let’s put sql query into button onclick
No_Shine1476@reddit
Microsoft is probably doing a double-take like "Really? We did this TWO DECADES ago."
U4-EA@reddit
nextjs is a mess. It had 1,670 open bugs right now. Remix has 6.
That is not a dev team I have faith in.
MasSunarto@reddit
Brother, this is what I understand after skimming some blogs. So I agree with you completely in this particular matter.
lifeslippingaway@reddit
Context API has been deprecated?
Yweain@reddit
No
lturtsamuel@reddit
Wait. Contaxt is deprecated? Since when? I did some quick googling but didn't see such info. The document of useContext is still there: https://react.dev/reference/react/useContext
HolyPommeDeTerre@reddit (OP)
According to the other comment, I misunderstood and exaggerated the impact. Context API doesn't seem to be deprecated as of now.
jakechance@reddit
I’d argue that React is an anti pattern nowadays.
React was originally built to do two things well in its time; SPAs in the Wild West of web standards and support IE6. The latter is gone and not only do we have standards, but their consistency has allowed the web to become a necessity. That means we have a whole host of universal best practices as security, performance, and usability must be taken seriously.
HTML and CSS have more features and they’ve gotten easier to conceptualize and more expressive. JavaScript is still necessary for some interactivity but you’d be astonished what just the DOM API can do on its own. It has never been easier to build a modern application that does little more than render these and send these over HTTP as we’ve been doing since the beginning of the web.
In the decade+ since React has come out there has been an incredible amount of JS churn. Not just the libraries but concepts like CSS in JS (abandoned by their creators) or state management (HTML and the browser already store state). The more traditional web technologies have had less or no churn. E.g. Relational DBs are better with more features running on faster hardware, all the middleware in the world understands what to do depending on the HTTP status code or various headers, etc. Their simplicity and longevity also make them easier to learn and debug as there are multiple decades worth of still relevant resources (which will also help LLMs).
Try a SSR web framework (over 5-10 years old is best) and the newer super simple SPA view layer add-ons like HTMX, Hotwire (Turbo + Stimulus), LiveView, etc. Excluding Type/JavaScript on the backend, you want to aim to write the least in it for 99.99999% of web apps.
propostor@reddit
When SPAs first came around I thought they were a god-send. The clean separation between back-end and front-end architecture was amazing, and I felt like I was writing proper software applications for the web.
The return to SSR screams of failure to me, not in a dev/tech sense, but in a horrible desperate kowtowing to the Search Index overloads. We're forcing ourselves to stick with SSR simply because "we need as much as possible present on first load so that web scrapers can web-scrape". It's nothing to do with user experience or the quality of a website, and everything to do with the most basic and archaic need to have all the html available immediately for a tiny handful of search engine bots to read. It feels like an insane bottleneck to the progress of web development.
We're now stuck with over-engineered hybrid efforts via things like 'page hydration' in React, or 'interactive auto' mode in Blazor. It adds excess complexity purely to appease the archaic search engine gods.
What can be done? Not much but learn the new way of doing things, I suppose!
bdougherty@reddit
It’s just a return to monke. Sending full HTML over the wire has always been the best way to build nearly every site. There’s nothing “archaic” about that. You really cannot beat the performance of that, no matter how hard you try. The user experience of that is almost always better, too.
card-board-board@reddit
But it's not the best thing for every single company. Having a single REST API that returns json can that can easily be used by your native mobile apps and your web app and your public API is such a simpler way of developing software. Needing a back end that can return HTML was a massive pain in the ass and that's why we stopped doing it. Having all clients use the same API data layer makes things simple and clean. I've done both and I don't want to go back.
But say for the sake of argument you want to have your back end return ad hoc HTML pages and/or snippets. What the hell is react for then? Answer: people who went to code boot camp and literally only know react.
bdougherty@reddit
I guess we will just have to agree to disagree. What you describe has, in my experience, been a much bigger pain in the ass than the traditional way of just rendering HTML from the server. Specifically, combining the public API with private APIs has been a disaster everywhere I've seen it because the two things have vastly different requirements. It all just results in everything taking longer to do because of all the coordination required, and reduces the performance of everything across the board.
propostor@reddit
Hard disagree.
A basic webpage built with only HTML has not been a thing for many years already. There is already a bunch of JS that has to be sent over for a modern reactive page to work.
The only difference now with SPAs is that the JS provides the rendering processes so the HTML is empty on first load until the JS is ready. You still need to wait the same amount of time for the page to be ready. The only reason SSR is being considered is because it needs to prepare something for bots to read in millisecond time.
bdougherty@reddit
This is not even remotely true. Browsers are extremely good at parsing and displaying HTML delivered in the HTTP request. You are vastly exaggerating the need for JavaScript interactivity for most sites.
propostor@reddit
Yeah, parsing and displaying HTML is exactly what the SEO bots are looking for.
But opening and closing that hamburger menu? All in the JS.
yawaramin@reddit
Opening and closing a menu without JS is pretty easy with a
<details>tag.bdougherty@reddit
A hamburger menu is a failure from the start, but we'll have a way to do it without JS in a year or two. Switching everything to JavaScript is not the best strategy to handle it.
Displaying HTML is the entire thing, it is not something unique to search engine bots. Developers love this "modern" way because it makes some things easier for us, but ultimately it makes things worse for everybody else. The people running React have finally realized this after years spent destroying the web.
propostor@reddit
Sorry that's another hard disagree from me.
Consider any mobile device. Every other screen has a menu button somewhere and more often than not it takes some sort of "hamburger" form with a slide-out drawer or overlay when clicked. It's the optimum use of space on a small device screen.
How can the same be achieved on a website on a mobile screen? The answer is the same. Raw HTML is literally impossible when you want to add event listeners to DOM elements... Unless you remember JD in the html attributes, but then we're back to the problem of needing to do full JS download for the page to be ready.
kcrwfrd@reddit
I mean initial page load isn’t just about bots, it’s a significant factor in user experience too. It has a massive impact on conversion for e-commerce, for example.
propostor@reddit
Every SPA framework is around 200kb for initial load, which is pifflingly small by modern internet speed standards. The only outlier is Blazor which is 1-2Mb and even that is fine for most cases.
Most e-commerce platforms have so much going on that SPA download speed is the least of their worries.
I work for an e-commerce platform and I am quite sure we would in fact improve download times if we switched to a modern framework, but alas we are old and corporate and stuck in our dotnet framework 4.8 ways... but we are still a £5B/yr platform, so clearly initial download time is only one part of the equation.
kcrwfrd@reddit
I’ve known the argument about first load performance for SSR vs static SPA CSR for quite a while but I couldn’t find any specific examples to point you to, so I took it as an exercise to try generating something with Cursor + Claude this morning to be able to demo the differences in performance characteristics.
I had it generate an API with fastify, an SSR app with next.js, and a static SPA with TanStack start.
Using network throttling to test revealed a pretty massive difference in initial page load between the SSR and CSR front ends.
On the other hand once the client side bundle was already downloaded, navigating routes in the static SPA felt way nicer and more immediately responsive.
What’s best for you will come down entirely to your use case.
But fwiw in e-commerce initial page load has a huge impact on conversion rates. This is very well studied and substantiated.
Sunstorm84@reddit
200kb is still slow when you’re limited to 2G/3G speeds. If many people leave when they have to wait more than 2 seconds, you’re going to lose potential customers.
propostor@reddit
lol all those potential customers connecting to your company website from a remote mountain top. The loss of revenue from such a thing is most certainly going to be so small that it is insignificant.
I mean, I do agree in principle that it's better to have a site loading as fast as possible, but I wouldn't say a 200kb SPA download is ever going to be a dealbreaker. Otherwise no major platforms would ever use them.
Also as an aside, this has some interesting info: Web Performance of the World’s Top 100 E-Commerce Sites in 2018
Sunstorm84@reddit
Let’s be real here; we’re not talking about using your site from a mountain top. Mobile networks are sporadic and centralised around major cities.
As soon as you start to move away from the most populated areas, performance diminishes, or becomes non existent.
Not everything is e-commerce, either; take a sports betting site for example. As a casino you’d want to make it as quick and easy as possible for anyone to place bets, even with a terrible connection.
propostor@reddit
I think we're talking real edge case users here but I would still argue that an SPA in the long run presents far less bandwidth/data requirements. Browser caching means the SPA is fetched once and then it's tiny API calls for everything else on repeat visits to the site. This is far more efficient than having to grab a ton of html on each navigation.
Customers who truly need to have optimal data transfer would be given a proper mobile app so the whole UI is installed already and then the only network requirement is API calls sending barely a few kb at a time.
Sunstorm84@reddit
Your expectation that the user would wait for the first load is unrealistic. If they never sign up in the first place because it took too long to open the page, they aren’t going to download that app either/
propostor@reddit
No, unrealistic is the increasingly outlandish requirements your painting for this scenario. First it's a spotty internet connection to use a gambling website. Now the user is assumed to have not signed up yet.
I don't disagree that fast page load is important but the difference of a few hundred kb is utterly negligible in 99.99% of scenarios.
Sunstorm84@reddit
The requirements aren’t outlandish in the slightest; they’re real world requirements from part of my experience and are based on user data, analytics, etc.
As you point out, 200kb isn’t really an issue if the user has previously downloaded and cached that data, but the issue with 200kb is only about losing potential customers because they don’t make it through the first step in the funnel - the first time they access the site, sign up and make their first deposit.
The amount of people that don’t want to wait even 5 seconds is extremely high in some parts of the world, much higher than the statistics in the article you shared.
My point is only that it depends on your audience as to what is acceptable; in many cases you don’t need to care at all. In others it’s crucial enough to define the success and failure of the business.
PragmaticBoredom@reddit
Search discoverability is a huge thing for any business with public facing (not login gated) content.
Honestly I’m really tired of the subset of FE devs who try to treat it like some minor detail or inconvenience. Making a website that can be indexed by search engines is a headline part of the job.
Yes it would be easier if we could write whatever we wanted and not worry about search engine indexing, but that’s life. You build the product to satisfy the goals, not build it how you want to build and then pretend that the product requirements are wrong.
card-board-board@reddit
I've built apps that care about SEO and apps that don't. If you aren't in e-commerce or marketing then you probably don't care about SEO and therefore probably don't care about crawlers, and in those scenarios frameworks like next are pointless and bloated.
Beyond that if SEO is such a big deal to you then React just isn't the tool for the job. You're literally just sending strings to the client and that isn't some difficult unsolved problem. Template strings. Cache. Done.
Server-side react has no reactivity, so to quote office space "what exactly is it you do here?"
Shinma_@reddit
Completely valid and true. I would say that the frustration of having to find all kinds of workarounds to handle hydration, serving crawlers with edge functions of different content and handling mixed scenarios is a fair criticism of react.
PotentialCopy56@reddit
Most large scale applications I've worked on are not public facing. Couldn't give a rats ass about search ranking and will never be interested going down that hell hole.
PragmaticBoredom@reddit
Right, that’s why I said it doesn’t matter for apps that aren’t public facing.
The problem is when people are doing public facing websites and trying to pretend that it doesn’t matter.
last-cupcake-is-mine@reddit
A massive amount of websites are public applications behind logins, or private internal applications. These don’t require any SEO at all. If you’re building something public where search matters, yeah go nuts.
dbbk@reddit
SPAs didn’t go anywhere… you can still make them…
U4-EA@reddit
The problem I have with SPAs is protection of views. There are times you really don't want people to be able to infer from the bundle what views contain, even if it doesn't contain the data.
MoreRopePlease@reddit
SSR is like what we used to do back in 1996: run perl on the server to build the web pages overnight and deploy as static files (except for the bit of code that would serve ad tiles).
What's old is new again.
saposapot@reddit
That’s the sign of experience. All tech seems to be cyclical. Of course I’m exaggerating as each time it goes back it’s a bit improved from before but it’s quite amusing to see how tech moves from one side to the other.
Fat clients then thin clients then fat again. Microservices can be traced back maybe 1 decade ago but with a different name. Heard just days ago some tech being explained to me and I just thought: oh, it’s RPC again?
Just to be clear: yes, it’s an exaggeration but almost all architectures have been invented. Since all have pros and cons, it’s quite normal that at some point in time we value some things and then it shifts back to others. If you consider the very “high level” architectures/concepts, they can probably be traced even back further, almost to punchcards :p
Code-Katana@reddit
Perl::CGI apps FTW! /s
saposapot@reddit
I won’t make up percentages because I don’t know them but non-SSRs will still be a big piece of the pie. All “business” apps that are behind a login have little reason to move to SSR (I know there are some, but hard to make it compensate the negatives).
SPAs were always a problem for search engines. At some point in time, people decided it was OK and search engines can now run JS so it’s fine, until a few years later people decided maybe not?
I think it’s exactly like all web dev: a lot of noise caused by people that want to sell books, courses, YouTube views or whatever. They can’t do that if they just say “use the same old thing” so they permanently need to hype the next big thing.
Akkuma@reddit
SSR isn't solely about search engines it is about improving page load by not having a shell that has to turn back around and hit the server again to start rendering. This doesn't matter for many B2B apps, so SSR has a smaller target than has been pushed. There are some nice side effects though like SSG, which is nice for another niche.
bdougherty@reddit
It always matters, just to slightly varying degrees.
Akkuma@reddit
B2B can be but with login walls they usually matter less. You also can do local first on a client anyway, which avoids part of the SSR benefit. Nonetheless, I agree with you that there is still merit to it.
My personal site is ran on SolidStart, is completely SSG, but could be SSR if I wanted it with minimal work.
Inevitable_Abroad284@reddit
Frontend has always been complicated by externalities like that. SPAs do feel like what frontend should be, but I suppose we have to build for what is required, not just what is elegant.
PotentialCopy56@reddit
It's all for Vercel. Next.js is Vercel's pet project and it's all about SSR. All Vercel has to make money is their cloud services for 'full stack frontend" so they greatly benefit from pushing SSR hard.
double_en10dre@reddit
This is what irks me as well, and I have a feeling that within 5-10 years we’ll have a new “Search Index” paradigm anyway. The current methodology is clearly flawed, and traditional search engines are becoming less and less useful
If/when that day comes, all this unnecessary complexity and vendor lock-in is going to look quite foolish. Just imagine if all these brains had been working on something genuinely useful
HolyPommeDeTerre@reddit (OP)
Thanks for putting those words. I feel less alone to think this way :)
shootersf@reddit
Can you link more around context API deprecation? I'm seeing the legacy API is being removed. We use Context quite a lot and I'd be shocked to be seeing it go away so silently as I can't find any stories about it
HolyPommeDeTerre@reddit (OP)
I totally align with that. I was also hoping for people to clarify a bit more about the depreciation since the move from the styled component owner feels pretty big (at least bug enough)
shawntco@reddit
Btw it's deprecation, not depreciation. I only point it out because I see you saying it repeatedly. :)
Alkyen@reddit
The guy moved away from styled because they don't get used anymore in comparison to tailwind. Which is totally understandable. That has nothing to do with context API which is here to stay. Also client components are here to stay too we just gave server ones now. No need to prepare for anything right now, server components will be used in some projects but not at all in others. It totally depends on the type of project you are building.
sedatesnail@reddit
The post says that it is "defacto" depreciated because it isn't in react server components. But as far as I know server components only run once for each request so I don't understand why context would be useful for rsc?
Blecki@reddit
It's a circle.
Right now it's back to server side rendering. So 2000.
Don't worry about what's hot or what's going to exist in 10 years. People are still writing websites in php, for fucks sake.
Just use whatever someone is willing to pay you to use.
Mysterious_Mood9343@reddit
SSR of a SPA is a lot different from classic server-side. Frontend devs conflating any code running on a web server that returns a processed response is like a backend dev saying jQuery is the same as React.
Blecki@reddit
Call it a spiral then. We'll be back to rendering entirely on the client soon enough.
saposapot@reddit
Just because something isn’t introducing new features every month, it isn’t dead. If it’s maintained and doesn’t have security vulns, keep on going.
Just remember all long living companies have very old software running everywhere… if it works, it’s hard to change it
mechkbfan@reddit
No.
Been around long enough that some new sexy thing comes out that everyone gets hyped about, until the next sexy thing.
Task runners -> Grunt, Gulp, Webpack, etc. Frontend -> Knockout, Backbone, Angular, React, Vue, etc. CSS -> Not even sure where to begin here as there's so many categories SCSS/SASS, BEM/OOCSS/SMACSS, Bootstrap, etc.
Don't change horses midrace.
Learn good habits.
Accept each application has a lifetime.
IAmTrulyConfused42@reddit
What’s funny is even with 15 YOE you didn’t go back far enough to say how jQuery is one of the forgotten bits.
I bet you used it too. 😀
WillCode4Cats@reddit
I still use JQuery lol. Though honestly, my usage has declined quite a bit since plain JS has gotten so much better of the years.
WizardSleeveLoverr@reddit
Same. We have a legacy codebase that has tons of jQuery that isn’t going away anytime soon.
Groove-Theory@reddit
Was working in a dyno tech job that, even up to COVID, was still just using vanilla javascript on the front end. Not even jQuery, no frameworks, just pure ass javascript (not even able to use ES6)
Happy to not be working there anymore.
amejin@reddit
Sounds like heaven to me... ES6 is a weird restriction.. but vanilla everything is my jam
mechkbfan@reddit
Oh jQuery...
Absolutely loved it at the time, then it turned into "no, this auto complete box uses it, find another one"
Lyelinn@reddit
On a side note happy that BEM thing died. Really ugly concept.
saposapot@reddit
BEM has definitely not died… it’s just a naming convention so everytime you still have to create classes, it’s still a good thing. Unless you use tailwind.
But nothing really replaced BEM, just made it smaller and not “the only” CSS thing you have in your project.
mechkbfan@reddit
I sound like an old man but I still have zero issues with Bootstrap 4 combined with a living style guide and enforcing consistency in the UI/UX.
But my bread and butter is line of business applications where KISS matters, not making it sexy.
When I saw Tailwind demo, it just seemed like an improved version of Bootstrap helper classes but maybe I'm missing something.
sole-it@reddit
Grunt, Gulp are two things i always wanted to learn...guess i am lucky i didn't spend time on them.
thelochteedge@reddit
Holy shit I feel like I never see Knockout referenced. I actually worked in this framework for years haha. One of my old jobs still uses it for their frontend.
leeharrison1984@reddit
Team Knockout. It was ahead of its time in a lot of ways, but file sprawl was very very real. I still think of it anytime I hear people talking about "signals" as if they're some brand new concept.
baxxos@reddit
I think the MS Azure ecosystem runs on it, or it at least it still did a couple of years ago.
Kennen_Rudd@reddit
Magento/Adobe Commerce uses it too.
HolyPommeDeTerre@reddit (OP)
I get that over the 15 years I've been here. I am not afraid for my "skill" in react. I don't care, I have other skills.
React (in this example) is widely used in production envs and is a customer faced lib. You could switch it for any other lib that changes drastically its core ideology (imo).
What about the big apps out there using it, trying to keep it updated? Would you switch, implying a refactoring? Or would you just pin the version and stay on this one, accepting you won't update?
G3NG1S_tron@reddit
I’m using React in a mature project and updating hasn’t been an issue. It’s got great backwards compatibility.
HolyPommeDeTerre@reddit (OP)
Yeah same, for now.
mechkbfan@reddit
It's too much of a 'how long is a piecee of string' type question with so much missing context.
Worked at one site that just everything was pinned, brought in the different framework, matched the styles, and just wrote everything new way with minimising changes to the old one. Was fine and they planned for a v2 of whole site in several years with new UX, etc.
Recently we're doing similar but strangler pattern. Don't want to do the big budget for a new site, so just picking off one page at a time.
I'd have zero issue pinning in this stage. Have to ask what value it brings.
HolyPommeDeTerre@reddit (OP)
No problem, my question was weirdly framed. I understood that with your answer.
Thanks you for your answer :)
BoysenberryLanky6112@reddit
Reading threads like these makes me so happy I've stayed in back-end development my entire career. I've dabbled in a bunch of the different packages referenced here for personal projects and seen them in the front-end repos I've worked at, but they seem like such a nightmare to use and the fact that they shift so quickly is kinda insane.
britishunicorn@reddit
To me the biggest difficulty about being a FE developer is that we really have to stay up to date on the 1,000s of new frameworks/libraries/breaking changes that keep coming up, and that's basically hours & hours & hours you have to spend doing that and if you stay behind you're basically dead. FE is really becoming unnecessarily complex for no reason. I have many colleagues who are "full stack" devs but do not want to touch the front-end with a 10ft pole 😂
BoysenberryLanky6112@reddit
The latest "full stack" app I built the frontend was static HTML/CSS with a bit of vanilla js to make api calls hosted in an s3 bucket. I definitely try to do that if I can. I've built react apps in the past and they can just get super complicated even for some of the simplest things and debugging them can be a bitch.
LeadingFarmer3923@reddit
The shift toward SSR with React can feel like it sidelines long-time SPA strategies. But it's less about abandoning client-side and more about improving performance and SEO where it matters. If your app doesn’t benefit from SSR, you don’t have to follow the trend blindly
Gwolf4@reddit
Wait holy fuck excuse me? Deprecate context? I swear I haven't really learned how to use it, it felt always cumbersome and redundant and now people tell me that it is going to be deprecated? Another moment of flabbergastedness inside the react ecosystem.
del_rio@reddit
It's not being deprecated lol. Recent releases of React have improved the API for it, there is no equivalent lol
johanneswelsch@reddit
One styled component, completely empty, adds something like 1KB to your bundle size. You just should not be using it since Tailwind V2 came out.
jnhwdwd343@reddit
It’s not moving to SSR, it just supports it from now on
30thnight@reddit
Why?
React has gone nearly 10 years without breaking changes that’d affect an app engineer. Its biggest criticism is that it hasn’t adopted change fast enough.
The context api isn’t deprecated & wont be removed.
The linked post refers to react’s server side templating apis not having access to client-side specific apis (context, hooks, state)
ValentineBlacker@reddit
Damn, I felt a little bad not keeping up with React but if it's gonna be SSR I might as well stick with Phoenix Liveview.
Alkyen@reddit
Context API isn't being deprecated. And just because there are server components doesn't mean you will only write server components. The point of server components is that some things are better suited on the server.
But client components are still a must in many cases and will be required forever as instant interactivity is a requirement in modern apps, that can't happen with server components. Also React isn't going anywhere anytime soon.
ButWhatIfPotato@reddit
Frameworks and libraries come and go. The worst thing you can do in your career is limit yourself to one of them. There is a small chance that you can land a job making crazy money trying to tame unwieldy old tech, but I would strongly advise going against that path.
beth_maloney@reddit
Will continue to use csr as before. SSR is a useful tech that react has historically not supported well. It's good to see the react team invest in this but I won't be using these new features.
Anyone who is surprised by reacts focus on SSR hasn't been paying attention to what Facebook has been doing.
PragmaticBoredom@reddit
Thank you for saying it. I’m getting tired of arguments that SSR is a bad thing to put energy into or that making a site easily accessible to search engines is a flawed goal. These are hard requirements for real-world products. There are too many debates going on right now that start by assuming they shouldn’t be factors.
HolyPommeDeTerre@reddit (OP)
And, historically react was built to help change the fact that client side JS apps were hard to build. But we had SSR systems at first. I think changing this core ideology is weird, to compete on other libs features that already handle SSR in a good enough way. That's not that I don't get it, it's more that I don't think it's really interesting. I use a screwdriver for screwing drives, I don't want my screwdriver to start pumping water or force me to screw only in certain angles.
Now maybe I am exaggerating this :)
beth_maloney@reddit
Facebook has been using SSR with react for a long time. If this is a change in core ideology then it happened a long time ago.