Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Denial of service and source code exposure in React Server Components

react.dev

Post reply on HN
Print view View original

201–210 of 232 posts

Re: Denial of service and source code exposure in React Server Components

#201

Post by chuckadams »

ricardobeat wrote: post #99
acdha wrote: post #74

Earlier quoted context omitted.

> If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion. This is interesting because every Next/React project I see has a slower velocity than the median Rails/Django product 15 years ago. They’re just as busy, but pushing so much complexity around means any productivity savings is cancell…

+1 to this. I seriously believe frontend was more productive in the 2010-2015 era than now, despite the flaws in legacy tech. Projects today have longer timelines, are more complex, slower, harder to deploy, and a maintenance nightmare.

I remember maintaining webpack-based projects, and those were not exactly a model of simplicity. Nor was managing a fleet of pet dev instances with Puppet.

Re: Denial of service and source code exposure in React Server Components

#202

Post by yawaramin »

stack_framer wrote: post #121
Uehreka wrote: post #55

Earlier quoted context omitted.

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…

I find myself just wanting to go all the way back to SPAs—no more server-side rendering at all. The arguments about performance, time to first paint, and whatever else we're supposed to care about just don't seem to matter on any projects I've worked on. Vercel has become a merchant of complexity, as DHH likes to say.

Htmx does full server rendering and it works beautifully. Everything is RESTful–endpoints are resources, you GET (HTML) and POST (HTTP forms) on well-defined routes, and it works with any backend. Performance, including time to interactive and user device battery life, are great.

Re: Denial of service and source code exposure in React Server Components

#203

Post by yawaramin »

hbbio wrote: post #86

We pioneered a lot of things with Opa, 15 years ago now. Opa featured automatic code "splitting" between client and server, introduced the JSX syntax although it wasn't called that way (Jordan at Facebook used Opa before creating React, but the discussions around the syntax happened at W3C notably with another Facebook employee, Tobie). Since the Opa compiler was implemented in OCaml (we were looking more like Svelte…

Ocsigen Eliom did it before Opa, no?

Re: Denial of service and source code exposure in React Server Components

#204

Post by yawaramin »

delifue wrote: post #98

React server component is frontend's attempt of "eating" backend. On the contrary, HTMX is the attempt of backend "eating" frontend. HTMX preserves the boundary between client and server so it's more safe in backend, but less safe in frontend (risk of XSS).

Htmx doesn't really have an XSS problem, this was solved by templating language long ago. See https://htmx.org/essays/web-security-basics-with-htmx/#alway...

Re: Denial of service and source code exposure in React Server Components

#205

Post by c-hendricks »

kyleee wrote: post #133
c-hendricks wrote: post #96

Earlier quoted context omitted.

Some of the anti-next might be from things like solid-start and tanstack-start existing, which can do similar things but without the whole "you've used state without marking as a client component thus I will stop everything" factor of nextjs. Not to mention the whole middleware and being able to access the incoming request wherever you like.

And vercel

That's true, can't blame people for having a bad taste of VC funded companies taking the reigns on open source projects.

Re: Denial of service and source code exposure in React Server Components

#206

Post by tracker1 »

_jzlw wrote: post #81
chuckadams wrote: post #2

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."

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.

Yeah, I kind of hate it... Blazor has a massive payload and/or you're waiting seconds to see a response to a click event. I'm not fond of RSC either... and I say this as someone absolutely and more than happy with React, Redux and MUI for a long while at this point.

I've been loosely following the Rust equivalents (Leptos, Yew, Dioxux) for a while in the hopes that one of them would see a component library near the level of Mantine or MUI (Leptos + Thaw is pretty close). It feels a little safer in the longer term than Blazor IMO and again, RSC for react feels icky at best.

Re: Denial of service and source code exposure in React Server Components

#207

Post by reactordev »

nawgz wrote: post #132
skydhash wrote: post #89

Earlier quoted context omitted.

The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.

Not to defend the practice, I’ve never partaken, but I think there’s some legit timing arguments that a server renderer can integrate more requests faster thanks to being collocated with services and dbs.

which brings me back to my main point of the web 1.0 architecture. Serving pages from the server-side, where the data lives, and we've come full circle.

Re: Denial of service and source code exposure in React Server Components

#208

Post by christophilus »

array_key_first wrote: post #191
_jzlw wrote: post #81

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.

This is how client-server applications have been done for decades, it's basically only the browser that does the whole "big ole requests" thing. The problem with API + frontend is: 1. You have two applications you have to ensure are always in sync and consistent. 2. Code is duplicated. 3. Velocity decreases because in order to implement almost anything, you need buy-in from the backend AND frontend team(s). The idea…

No, it's not. I've built native Windows client-server applications, and many old-school web applications. I never once sent data to the server on every click, keydown, keyup, etc. That's the sort of thing that happens with a naive "livewire-like" approach. Most of the new tools do ship a little JavaScript, and make it slightly less chatty, but it's still not a great way to do it.

A web application should either be server-generated HTML with a little JS sprinkled in, or a client-side application with traditional RPC-like calls when necessary.

Blazor (and old-school .NET Web Forms) do a lot more back-and-forth than either of those two approaches.

Re: Denial of service and source code exposure in React Server Components

#209

Post by joshdavham »

rk06 wrote: post #187
rk06 wrote: post #128

Earlier quoted context omitted.

nuxt, sveltekit etc don't have RSC equivalent. and won't have in future either. Vue has discussed it and explicitly rejected it. also RSC was proposed to sveltekit, they also rejected it citing public endpoint should not be hidden they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there

please forgive typos in above comment. i can no longer edit them

Haha don’t sweat it dude. Happens to literally everyone on HN.

Re: Denial of service and source code exposure in React Server Components

#210

Post by KronisLV »

nathants wrote: post #162

Just exchange json. Backend in python/ruby/go/rust. Frontend in javascript/typescript. Scripts in bash/zsh/nushell. One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.

I really like having a good old RESTful API (well maybe kinda faking the name because don't need HATEOAS usually)!

Except I find most front end stacks to lead to either endless configuration (e.g. Vue with Pinia, router, translation, Tailwind, maybe PrimeVue and a bunch of logic for handling sessions and redirects and toast messages and whatnot) and I feel the pull to just go and use Django or Laravel or Ruby on Rails mostly with server side templates - I much prefer that simplicity, even if it feels a bit icky to couple your front end and back end like that.

Post reply on HN