I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
I'd be interested in adopting a sole-purpose framework like that.
Denial of service and source code exposure in React Server Components
21–30 of 232 posts
Re: Denial of service and source code exposure in React Server Components
#22Earlier quoted context omitted.
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
Re: Denial of service and source code exposure in React Server Components
#23It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
Also kind of funny that they're comparing it to Log2Shell. Maybe not the best sort of company to be keeping...
Re: Denial of service and source code exposure in React Server Components
#24I wonder what does these vulnerabilities mean for Facebook. As per my knowledge, Facebook's the biggest web app written in React.
Does Facebook actually use RSC? I thought it was mainly pushed by the Nextjs/Vercel side of the React team.
No they don't. I think Meta is just big enough that they don't really care what is happening with React anymore haha.
Re: Denial of service and source code exposure in React Server Components
#25So we have a new React CVE and tomorrow is Friday, so please be prepared for a new outage brought to you by the super-engineers at Cloudflare.
Look on the bright side: maybe GitHub will be down first, so nobody can upload any vulnerable code right before the weekend.
Re: Denial of service and source code exposure in React Server Components
#26React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we…
I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusion whats running where.
Re: Denial of service and source code exposure in React Server Components
#27It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.
It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.
Re: Denial of service and source code exposure in React Server Components
#28Oh boy, I somehow missed that React was offering these.
Google has a similar technology in-house, and it was a bit of a nightmare a few years back; the necessary steps to get it working correctly required some very delicate dancing.
I assume it's gotten better given time.
Re: Denial of service and source code exposure in React Server Components
#29It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
Perception management
Re: Denial of service and source code exposure in React Server Components
#30React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we…
I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusio…
I pretty much dumped a side project that was using next over the new router. It's so much more convoluted, way too many limitations. Who even really wants to make database queries in front end code? That's sketchy as heck.