Hacker News new | ask | show | jobs
by HelloNurse 1110 days ago
If I understand correctly, this server side component technology is strictly JavaScript (or maybe Typescript etc.), so how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services?

Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deployment and management difficulties, that fatally bad downsides like the likelihood of crucifying the masochist hipster's application or site to specific cloud services seems a minor detail.

Is it simply a perversion that has been designed to appeal to exclusively JavaScript project of exclusively JavaScript programmers who have some hope of salvaging and porting already JavaScript business logic?

2 comments

I don't understand your argument at all. Why would a TS backend be inferior to a PHP backend, for example?

Because for many people, that's the tradeoff.

Think of a new project.

You'll still have "OOP" PHP + some random templating language + the infamously hard to do "sprinkles" of JS.

In the end lots of people start to shoehorn their PHP or Django CMS into REST API parts anyway, reinventing the wheel over and over again, for every new requirement.

I have nothing against PHP or Django or other server technologies with corresponding templating languages.

But to churn on the "old and proven" point in 2023 seems odd to me.

It's tradeoffs all the way down.

A TS backend is inferior to a PHP backend merely due to available frameworks being night and day in favor of PHP.
A TS backend is going to have a SPA frontend, reducing the complexity of the backend significantly.

Use Koa and a database client and you're good.

PHP isn't "complex", it's nearly identical with minor variations.
My point is that the need for a backend "framework" decreases significantly if you take that burden on the frontend.

And anyone writing a JS/TS backend is likely doing that. So I would expect fewer "frameworks."

What kind of operations do you imagine an application is used for?
> how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services?

With RSP you can implement a server function and (relatively) directly call it on the server, type-safely. Try doing that another back-end (I have and mostly failed).

Sounds like a potential foot-gun for input validation by the backend getting missed. :(
Isn't that the purpose of tRPC?