141–150 of 232 posts
Earlier quoted context omitted.
? afaik react server components made it to core
They shouldn't be loaded in a React SPA at least, e.g. `react-dom` and `react` packages should be unaffected.
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."
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
Earlier quoted context omitted.
This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
> This isn't a Javascript problem, this is a React problem. It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106 > Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript. Yes. And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and fronten…
Did you even bother to read my comment? Try again, please. Next time don't skip over parts.
Earlier quoted context omitted.
I had this issue with a React app I inherited, there was a .env with credentials, and I couldn't figure out whether it was being read from the frontend or the backend. So I ran a static analysis (grep) on the apk generated and points light at face dramatically the credentials were inside the frontend!
Why would you have anything for the backend in an APK? Wouldnt that be an app, that by definition runs on the client? Most frameworks also by default block ALL environment variables on the client side unless the name is preceded by something specific, like NEXT_PUBLIC_*
These kind of node + Mobile apps typically use an embedded browser like electron or a builtin browser, it's not much different than a web app.
Earlier quoted context omitted.
Very standard in security, announcements always always always try to downplay their severity.
fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.
It'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.
The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/
Earlier quoted context omitted.
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
Isn’t that what Phoenix (Elixir) is? All server side, small js lib for partial loads, each individual website user gets their own thread on the backend with its own state and everything is tied together with websockets. Basically you write only backend code, with all the tools available there, and a thin library makes sure to stich the user input to your backend functions and output to the front end code. Honestly it…
It's extremely nice! Coming from the React and Next.js world there is very little that I miss. I prefer to obsess over tests, business logic, scale and maintainability, but the price I pay is that I am no longer able to obsess over frontend micro-interactions.
Not the right platform for every product obviously, but I am starting to believe it is a very good choice for most.
React 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…
React team reinvent the wheel again and again and now we back to laravel
Earlier quoted context omitted.
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 think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…
Align early on wrt values of a framework and take a closer look at the funder's incentives.