How Next.js is delivering React’s vision for the future (Sam Selikoff)

[@voinbobar]

Sam delivering the best presentation as usual!

[@jordantan888]

this is the best argument so far

[@dawid_dahl]

Loved this presentation; just what I needed amidst all these new and shiny updates to build a mental model.

[@zalodias]

Love the new paradigm.
But would really prefer defining server/client components at the filename level: e.g. Modal.client.tsx, NewsStory.server.tsx.
"use" string directives just feel out of sync on how we write JavaScript

[@viniciusataidedealbuquerqu2837]

it doesn't make it totally server because you can attach js events on the components that makes them "universal" so there should be signals to make it fn level. but I agree that sensible defaults are the way to go

[@bosung90]

Love your talk.
We used to have allergic reactions from people seeing html inside js, and css inside js, not anymore.
I always tell people stop breaking code up by their types, but their functionality.
Nobody writes button without styles, and nobody writes button without its corresponding js or form actions.
If then, why are we breaking up the code into different files? That is a code smell and its called fragmentation.
If we have a button that adds todo list (handled on the server), this button is useless without server action, then why not put them together in the same component? The only reason why we didn't do it before was because there just wasn't a good way to do it.

[@rockNbrain]

great talk!!

[@yipansong2688]

PHP is best language in the word

[@dinuka]

Nice presentation

[@benme1386]

Can you unit test React Server Components, or would they only be tested via E2E tests? It's easy to test client components based on useSWR, because I can mount the component and mock out its network API calls to create any scenario my test needs.

[@janstrnadek1441]

Looks like "good" old PHP :) let's mix SQL and HTML together... The presentation looks good, and the new tutorial too... But my feelings are quite contradictory until I've tested that by myself. Especially I am curious about some complex applications and how this thing will be tested.

[@DivjotSingh]

I wonder about security implications of third party packages. What if a from npm has a formAction in it that steals my server creds/data. How would I even track it and stop such an attack?

[@VercelHQ]

nextjs.org/blog/security-nextjs-server-components-actions

[@DivjotSingh]

@@VercelHQ thanks. However this only let's you protect your own server actions and components. How can I stop a random from npm performing certain server actions?

[@viniciusataidedealbuquerqu2837]

@@DivjotSingh I think if you taint your creds it shouldn't creep out but no one's stopping from leaking non tainted data

[@grunklejp]

What is preventing you from downloading a normal NPM package that steals your creds today? I dont think server actions leave you anymore exposed to supply chain attacks.

[@DivjotSingh]

​​@@grunklejp I completely agree. Even today I can import a design system component and SSR it and end up running third party code during the server pass.
I guess I'm feeling bit nervous/lack of control over what a third party component can end up doing without my knowledge. If components can contain both server and client code, it makes them even more powerful than before for attacks as well
Maybe Next can add an opt-in system where we can allow formAction or action on form components only for selected npm packages.

[@blankcheckguy69]

can we get the github repo link?

[@alansaldivares]

They guy at the bottom right was watching memes 👀

[@ikusoru]

Loves the new Next.ja features. However the example on server actions is a bit off and I don't really see the benefit of it other than Next.js keeping you locked in using Next.js actions.
So I would take Sam's words with a grain of salt, especially as he was paid to deliver this talk and basically sell it. 😉

[@hamzadata]

here comes the meme attack

[@viniciusataidedealbuquerqu2837]

I understand the sentiment but couldnt we make formAction "use server" by default? seems like too much to write again "use server" inside a server component

[@TheTmLev]

Form action doesn't have to be inside a server component, it could be in client too

[@maccodifavole]

it's literally 2 words lmao

[@MahmutGundogdu]

Yes , after I saw the server component, i though , react is a lego. I feel like a lego owner who press a lego in night. Thanks you killed SoC.

[@codefinity]

15:44 🤯 I have 🫘 using SERVER ACTIONS, but I have 💭 that there 😯 only for from submissions. That is, a ‘’ with a ‘“submit”’ button.

[@catalinim4227]

that's a lot of technology and innovation for a basic to-do spa 😂

[@pbritotube]

A glimpse into React's origins:
It wasn't designed for data handling or retrieval.
Instead, React aimed to refine UI creation with one-way data binding, ensuring a seamless rendering flow.
Overengineering is the bane of elegant programming.

[@JakeLuden]

It’s not over-engineering, it’s just 2023. React’s origins solved 2013 problems. Next is helping solve 2023 problems.

[@pbritotube]

​@@JakeLuden
React was created to simplify UI development. Adding other concerns doesn't improve it, it makes things worse by introducing a bunch of decisions and compromises. The result is easy to predict

[@youreale]

@@JakeLudenThose 'problems' already existed before 2023 but were (intentionally or not) unreachable by the React ecosystem.

[@solarspear27]

First commit -m