zlacker

[return to "RCE Vulnerability in React and Next.js"]
1. halfli+yO[view] [source] 2025-12-03 19:52:44
>>rayhaa+(OP)
Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve?

What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering?

Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compiler, but instead of going the svelte route of handling the entire state, it only adds memoization?

If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic.

sorry for the rant.

◧◩
2. apathe+2J1[view] [source] 2025-12-04 01:24:02
>>halfli+yO
I agree. Incoming hot take.

IMO, a big part of it is the lack of competition (in approach) exacerbated by the inability to provide alternatives due to technical/syntactical limitations of JavaScript itself.

Vue, Svelte, Angular, Ripple - anything other than React-y JSX based frameworks require custom compilers, custom file-types and custom LSPs/extensions to work with.

React/JSX frameworks have preferential treatment with pre-processors essentially baking in a crude compile time macro for JSX transformations.

Rust solved this by having a macro system that facilitated language expansion without external pre-processors - e.g. Yew and Leptos implement Vue-like and React-like patterns, including support for JSX and HTML templating natively inside standard .rs files, with standard testing tools and standard LSP support;

https://github.com/leptos-rs/leptos/blob/main/examples/count...

https://github.com/yewstack/yew/blob/master/examples/counter...

So either the ECMAScript folks figure out a way to have standardized runtime & compilable userland language extensions (e.g. macros) or WASM paves the way for languages better suited to the task to take over.

Neither of these cases are likely, however, so the web world is likely destined to remain unergonomic, overly complex and slow - at least for the next 5 - 10 years.

◧◩◪
3. morshu+GP1[view] [source] 2025-12-04 02:26:24
>>apathe+2J1
Does transpilation not cover this? That's how they did JSX.
◧◩◪◨
4. apathe+tW1[view] [source] 2025-12-04 03:30:23
>>morshu+GP1
Transpilation of anything other than jsx requires a complex toolchain with layers of things like LSPs, compilers, IDE plugins, bundler plugins, etc.

Frameworks that go that route typically activate this toolchain by defining a dedicated file extension (.vue, .svelte).

This custom toolchain (LSP, IDE plugins) presents a lot of overhead to project maintainers and makes it difficult to actually create a viable alternative to the JSX based ecosystem.

For instance both Vue and Svelte took years to support TypeScript, and their integrations were brittle and often incompatible with test tooling.

Angular used decorators in a very similar way to what I am describing here. It's a source code annotation in "valid" ecmascript that is compiled away by their custom compiler. Though decorators are now abandoned and Angular still requires a lot of custom tooling to work (e.g, try to build an Angular project with a custom rspack configuration).

JSX/TSX has preferential treatment in this regard as it's a macro that's built into tsc - no other framework has this advantage.

◧◩◪◨⬒
5. halapr+FF2[view] [source] 2025-12-04 11:18:29
>>apathe+tW1
Chicken and egg problem. JSX is supported because it's popular. If React decides to push a new syntax I don't see why everyone wouldn't reasonably quickly adapt and support it.
[go to top]