[junon]

TL:DR it's a meme.

The context here (as I understand it) is that Next.js, a popular React-like framework that allows (in a way) coding both the server and browser portions of a web app in one codebase, such that each portion is extracted at runtime and automatically wired up via API calls. This is a simplification but it's how you can think of it.

They've now introduced an even tighter way of introducing server code into what are otherwise frontend React components by piggie backing off the old "use strict" directive syntax, called "use server", allowing you to interleave - directly and inline - the client and browser code.

Many a meme have been created, half-jokingly comparing it to PHP, ranging from the supportive jest, to the very seriously critical, as one would expect the internet to do.

Some of those memes have been in the form of "use ___", such as "use binary", "use php", etc.

I don't use frontend frameworks much these days so maybe someone can correct me on some of this, but hopefully this helps explain it a bit.

https://nextjs.org/docs/app/api-reference/functions/server-a...

[sebastianconcpt]

Rauch made a meme generator now

https://samgen.vercel.app/GYVwdgxgLglg9mABAITnA1gWwIYCd0AUA3...

[junon]

That tracks. Rauch is a funny guy. We would blast funny songs in the office during the ZEIT days. It doesn't surprise me in the least that he's embracing the meme.

[cal85]

This kind of explanation is why I come here.

[actionfromafar]

Me too, but I still don't understand. This must be what it feels like to not know how computers work. I recognize some of the words in the explanation.

[sophiebits]

One clarification: client and server code are never mixed within the same file. "use server" can only be used in server files and marks code that the client can call back into.

[ipsum2]

This is incorrect (outdated). In the NextJS conference, they demoed interleaved client and server code.

[crucialfelix]

It's caused confusion, but that is a server side component. Dan Abramov confirms that here:

https://twitter.com/dan_abramov/status/1717648341234778376

The html for the button gets SSR and sent to the client. The button click handler is an RPC that runs the actual sql statement on the server.

[sophiebits]

I can assure you I’m correct.

[DoesntMatter22]

Solidstart had this at least a year ago

[_lvbh]

I think they introduced some weird mixing in the NextJS conference that just occurred recently. I don’t understand it enough to be sure though.

[cal85]

Yes, they demo'd a component with an onClick callback that contained a 'use server' directive followed by serverside SQL query, right there in the onClick. So presumably that callback is automatically replaced at build time with some generated clientside code that posts to a dynamic endpoint generated from just that function, or something. Seems like a strange idea with lots of ways to go wrong, but I don't know enough about it to judge.

[mlfreeman]

Hmm, server-side onClick event...did they just reinvent ASP.NET Web Forms?

[ryoshu]

Yes. That's one of the jokes.

[williamcotton]

These conditional checks are an obvious sign that they’ve cleaved the rock in the wrong location.

These conditional checks on server state exist because they didn’t create the shared environment between web server and web browser at deep enough of a level.

The key is to replicate the server-side pattern of “user actions cause HTTP request”. That is, you make a version of express that runs in the browser. Then you make parallel middleware that runs in both the browser and the server. Then you make your React components fire off mock HTTP requests that are handled by the browser express router.

So you write the same route handlers and components for the browser and server to run but then you write environment specific middleware.

Browser middleware:

https://github.com/williamcotton/williamcotton.com/tree/mast...

Server middleware:

https://github.com/williamcotton/williamcotton.com/tree/mast...

I’ve expanded beyond express in the above application to add controllers, a routes file, and views, all code that has no conditionals and runs in both the browser and server environment.

What NextJS demoed is poorly conceived. There’s no need to autogenerate a link to an API.

Instead, your frontend middleware has req.update() defined to make an API request and the server middleware has req.update() defined to make the SQL update. GraphQL pairs well with this approach, but so does something like Graphiti/Spraypaint for a more traditional ORM-like model.

And there you go, sane server and client side rendering.

[sophiebits]

In most cases, you don’t want to treat server and client code the same from the perspective of I/O since the performance characteristics are dramatically different.

[sophiebits]

What I said is still true.

[boringuser2]

>API and frontend in the same code base

Well, it takes very little knowledge to know this isn't a good design paradigm.

[8n4vidtmkvmk]

Wat? Of course front and back should be in same codebase. Why on earth would you need them to be in different repos? Put them in different folders if it makes you happy but there's no need to toss stuff all over the place. They're friends. They need to talk to each other. Let them live together

[gedy]

Though, isn't this what full-stack/server side UI folks favor? Rails, etc.

[nsonha]

it's not that conclusive, there are many other aspects in which it can be bad (security, team's workflow etc). There is however no design principle ever dictates how components should/should not be stored in the same code repo.

[elnardu]

Pretty much this!