Hacker News Reader

Comment by anonyfox | Hacker News Reader

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks!

Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness.

Or go best-of-all-worlds if you happen to know Elixir/Phoenix.

But don’t continue the descent into RSCs, now matter how many people tweet about it. These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead!

Stay sane instead, ship actual products quickly, and earn that lambo!

View on HN

Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never really caught on. (Hint: hidden component boundaries mean hidden complexity!)

Meanwhile, the "server-rendered HTML" and "client-rendered HTML" camps are both doing quite well. I consider myself quite lucky to have both options at my disposal for every web project. I hope the work on RSC doesn't muddy React's support for pure client-rendered apps.

1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

CORBA is one of the few technologies purposefully designed to violate both the entirety of the Fallacies of Distributed Computing and the CAP theorem. It's a case study in awful ideas, week long troubleshooting nightmares, and angry customers.

You don't hear about it for the same reason it's impolite to talk about your top 10 favorite snuff films with customers. There is no situation where it's appropriate and anyone flirting with the notion needs to be dismissed before they doom your company.

CORBA is pure evil and you should not speak its name so lightly.

Preach it.

> So why doesn't everyone use it?

Not to detract from your point, but nobody uses it because when network administrators everywhere started closing all the ports except for 80 (for "security!"), everybody moved to SOAP, that uses the port 80. And then, since the SOAP consortium doesn't have enough competency to create a full data transfer format, starting from XML and contained in a couple thousands pages of docs, in about a decade people said "enough!" and moved into what is commonly called REST.

The problem with component boundaries is there, but it's not really what CORBA did.

CORBA was a total piece of shit back in the day. Nobody in their right mind would chose it for anything today except as example of "don't do this when you're designing and implementing something."

It's an over engineered overly complicated design that leaves a lot of crucial stuff undefined, which made interoperability impossible. From a performance perspective it was crap. And debugging an implementation was almost impossible.

It's a great example of how architects can destroy a good idea by layering ridiculous amounts of abstraction into an incomprehensible pile of software.

And it shows that architecture without implementation experience should never happen.

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix.

THIS... unless you're building something that absolutely requires a full blown progressive rich frontend app, (95% of you don't), liveview will do all the thins using serverside components with minimal jaavscript.

Not just that, you'll have a serverside thread dedicated to that user which allows you to actively push changes to the user's frontend without you having to write explicit javascript handlers.

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead!

So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is always there, but if that's your concern just build a traditional server templated site. The vast majority of SPAs have zero need for SSR and the complexity that it introduces.

"very, very good reasons" bullshit, you do not need to turn landing pages into 30MB react bundles with 20 morbillion node modules

That's more an indictment of node's ecosystem and package management than anything else. Having helper libs for almost everything along with multiple versions of the same modules bundled is just a bit ridiculous. With functional deduplication across versions and a more robust standard library so people didn't need to add 50 NPM modules to do anything that would drop by an order of magnitude.

Beyond that, bundle splitting with lazy loading is very helpful, but it requires knowing that you can do it and some additional work on top of baseline bundling. Then you're nearly at parity with static sites in terms of individual page download requirements for the first view (assuming react/etc are cached CDN libs rather than bundled) but each subsequent view of that page is much smaller, faster and more responsive than static html.

There are definitely use cases where you want a render loop in web, pioneered by React, instead of traditional approaches for a web application. I think the pendulum swung too far and too many sites are being built as a SPA, but there are absolutely some "very good reasons" to build a SPA with React. As always, it depends on the use case.

The flip side is that most sites, and even "apps", don't need to be SPAs.

> We moved away from server rendered UI for very, very good reasons.

In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.

You can have a "static" site that renders react components to non-root nodes in order to provide interactivity if needed.

That is literally what RSCs are, so unlike most of this thread, I am glad to start using them instead of using some template language like in PHP or Python.

Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.

Citation needed.

99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat.

No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.

I didn't make any statement about what an application is, or isn't, or what percentage of the internet is in fact applications. That being said, things like Figma exist and wouldn't if the web was only static pages, so there's a compelling argument to be made for the existence of SPAs.

> 99% of apps are basic CRUD apps

Citation needed.

>99% of apps are basic CRUD apps

You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.

So because a few forms need validations you turn your whole application into a JS hellhole?

That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app.

Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything.

Now, new JS frameworks send small JS bundles as you open each page, lol.

Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction?

Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works.

I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.

You can absolutely render react components into non-root nodes to inject interactivity into static sites. It's a good approach if you're serving a bunch of static content and you want a calculator or interactive visualization, for example.

The point at which you should consider a SPA is when you are sharing data between most of the "pages" in your app, and there are multiple data sources surfaced in any given "page." In this case, you're going to have to jump through indexdb/localstorage hoops just to avoid losing that data on every page transition, dehydrating/rehydrating multiple types of records then passing them around via a context or somesuch. In that case you're on the hook for complexity either way, but the SPA version performs better at the cost of some SEO.

> We moved away from server rendered UI for very, very good reasons

Can you please list your reasons?

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix.

Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dashboard, that latter situation quickly became basically our entire dashboard and it simply made sense to move to a full SPA taking advantage of the API we were exposing to customers anyway. This was 2016, so LiveView didn't exist at the time, but I'm still not sure I'd make a different decision for that product today.

The blog post is talking about the application that powers our public marketing site, which has a pretty different set of needs, but figured I'd throw it out there that we use and love Elixir/Phoenix! :)

Thanks for sharing the Elixir love!

More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

You forgot to also say Rust is faster.. if all languages were very similar there's not much point in having those.

That's fine, that's why I continue to use Rust and not Elixir.

There are a small handful of statically typed languages on BEAM, gleam is the only one I've played around with but it's pretty neat

Yeah I've used Gleam but unfortunately using a language for production apps that is not well supported as Rust and even Elixir is is a dealbreaker for me. Gleam is fun to play around with though.

Reply on news.ycombinator.com