It's funny, but all you see here and on Twitter are cheap shot one liners, many of these people have never even used Next.js.
I find server actions combined with RSC to be incredibly useful and powerful. Easily define and call a type safe function from client to server with zero overhead. No API boilerplate, fetch, tRPC anything.. You just define a function and call it, very nice. Type safety, code completion, refactoring works across client/server, all that.
Of course the examples of server side code in client side function handlers are just that, examples, not the suggested way to use server actions. You can write super hacky 'bad' code in every language. Server actions are best defined in their own file of course.
Not sure why it's being compared to PHP so hard as PHP is a backend only SSR framework, while Next seamlessly transfers the components/code/state to the client so you can continue re-rendering with the same framework and language client side as you used server side for SSR. PHP could never do that.
The closest thing to server actions in PHP is Livewire, which was never a standard part of PHP and not unique to PHP either. Most PHP apps just use normal JS libraries for interfacing with the server.
I'm entertained by the trolling, it reminds me of when React first launched, to see who was yelling the loudest about React violating separations of concerns, and totally missing the point, just jumping on the bandwagon. It feels like a similar thing this time around. It's fun to keep tabs on who misses the point.
probably just because PHP is now recognized widely as fundamentally bad design. Its just that many people who came late to the party never really knew why, so they think to themselves, no this is actually great "no API boilerplate, fetch, tRPC anything.. You just define a function and call it, very nice.".
First php doesn't have that ability, except for Livewire which not many people use. Second php has come a long way, is type safe now, very fast, battle tested, easy to host and a perfectly fine option for building websites with. It's why it remains today the most popular framework used to build websites with.
I'm still yet to see something as productive as PHP for web apps, ecommerce etc.
You ask for a customised e-commerce shop with many standard features out of the box. How long will the Java or Rust engineers quote you? A year? Php? A week?
I've been working exclusively in javascript/node since 2015 and nothing in the JS ecosystem has ever felt as productive as rails or django or laravel. Maybe it's rose tinted glasses when working on those select few projects but compared to the node ecosystem I'm bashing my head against the wall updating libraries that provide no migration docs seeing alternative solutions saying "we don't support X, sorry."
It's just all so frustrating, and I'm not even refactoring old code! It's two years old and already so brittle.
I feel like you need to have extreme patience and foresight to correctly build maintainable JS apps. Libraries people recommend today will die out very quickly. It never really felt like this in python or ruby, but I could be having a selective memory.
This has been exactly my experience as well. There were things I really liked about JavaScript and node, but in the end the lack of framework and the ridiculously fast rate of change that can bit rot a code base in six months, was enough to drive me back.
I found elixir and Phoenix to be exactly what I needed. I use it exclusively now, except for legacy apps. Phoenix is the full framework, comprehensive in what you need. Compared to rails, I like it a bit better. It fixed some of the things I didn't like about rails, such as the extreme levels of magic. Phoenix is a lot more explicit. Performance is incredible, and you get some amazing features like live view, and many others just from being on the beam VM. Definitely worth a look if you're feeling like this.
Dang I didn't mean to turn this into a sales pitch for Phoenix! NextJS has also been quite enjoyable for me. I use it for static sites, or really anything that doesn't require a database. The ability to SSG everything and just serve it with nginx is a killer feature in my opinion.
Have you used Next? I’ve found it more productive than anything because I can reuse the same code, DTOs, components, rendering, etc.. across server and client. It feels like I’m building a single app instead of dealing with using one code base to build the page and another to update it on the client. No extra JS frameworks needed. Plus TypeScript/ES6 is crazy productive - destructuring, structural typing, super expressive while being type safe as well. This server action stuff has made communicating with the server as easy as calling a function. So much overhead gone.
I used Next a few years ago, I'm extremely weary of proprietary frameworks. Especially those with VC funds. I've been around long enough to knows what eventually happens to those tools (the company goes bust, no one wants to maintain it, and people move to new things).
I'd be more of a fan of Vercel if they moved ownership of Next.js to the OpenJS Foundation and gave monetary support through that org instead. Obviously this would require movements to have react there as well; but if you cared about nurturing an open ecosystem it seems like the altruistic move.
I'm exploring HTMX for certain use cases at work. That library feels like the only new innovation happening in the web dev world. All the other frameworks are way too "same-y." Angular, react, svelte, solid, vue; they're all riffing off each other which is fine, but none of them really offer something completely substantial from one another. Just different syntax, with different bundle sizes, with different performance.
I think you are confusing a productive language with a productive ecosystem.
Using typescript and next maybe you are super productive writing code, but in the big scheme of things you are not productive if you have to reinvent the wheel and write your own framework.
Neither Next nor typescript will give you an integrated solution for translations, background jobs, schedules, validation, ORM, queues, file uploads, authentication, authorization, etc.
Granted, you’re super fast writing typescript but we are not talking about the same kind of productivity I think.
“I installed some third-party PHP software and didn’t turn on auto-updates for that software, and then my server got hacked” is a hit on your server admin skills, not PHP.
The attack vector was directly through php. Everything was upgraded to the latest. It was the theme that was hacked. How that is related to admin skills makes no sense.
If it was the theme that was hacked then it wasn't PHP it was the design of wordpress and the theme specifically. Almost all hacks of wordpress are not due to workpress itself but due to the themes and extentions.
If it was written in another language you'd have the same problems with the same architecture.
Wordpress gets exploited because it's popular, not because it's written in PHP
i just wanna add here on a serious note that i also see a use cases for "server actions", but i do not primarily write next.js or react so i didn't have an opportunity to try them out yet.
I think it's important to know what you would use them for. I don't think core business logic should be there, but I see why you would use them for f.e. signing something that would require a secret you don't want to have on the client side.
I do however think that it's not a good idea to show the inline code example in a presentation. fortunately none of those examples exist in the documentation. having a seperate file with server actions that can be imported is a good way to handle it i think.
> You just define a function and call it, very nice.
What do you do when you change the action API (arguments / return type) and deploy? What happens with browsers still having the old code that assumes the old contract?
Pretty much the same as dealing with traditional API versioning. You can version the functions themselves, or put a version in they payload and return an error telling the user to refresh.
How do you version the functions? How does the server determine which function to call? Does it use the name of the function, or its source code file, or something else? If I rename the old version and call it `actionOld` while the new version is `action` will it know how to call the old one, or do I need to do the opposite (call it `actionNew`)? What if I move the old one to a different file?
You can use a v1 folder for your v1 functions. The server identifies functions by path and name of the action. Similar to a url. So like a url if you want a new one, you'd create actionNew, and if you move the location of the function it would break old versions without a redirect.
I find server actions combined with RSC to be incredibly useful and powerful. Easily define and call a type safe function from client to server with zero overhead. No API boilerplate, fetch, tRPC anything.. You just define a function and call it, very nice. Type safety, code completion, refactoring works across client/server, all that.
Of course the examples of server side code in client side function handlers are just that, examples, not the suggested way to use server actions. You can write super hacky 'bad' code in every language. Server actions are best defined in their own file of course.
Not sure why it's being compared to PHP so hard as PHP is a backend only SSR framework, while Next seamlessly transfers the components/code/state to the client so you can continue re-rendering with the same framework and language client side as you used server side for SSR. PHP could never do that.
The closest thing to server actions in PHP is Livewire, which was never a standard part of PHP and not unique to PHP either. Most PHP apps just use normal JS libraries for interfacing with the server.