Next has always been inspired by PHP. in his keynote Rauchg even spent like a moment of silence dedicated to the PHP Lambo, completely out of context. it must have been confusing to others not in on the joke but for those of us in the audience it was great
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 hope I don't have to say this but: If you even in the slightest consider to use this in any application at all you are an absolute madman and and should be locked out of the internet for the rest of your life, I hope you find some other fun activity, maybe gardening or woodwork.
I think part of what makes these recent gags so funny to me is that it illustrates how perilous mixing RSC with client code feels in practice. Worrying about teammates accidentally exposing environment variables was already bad enough. Debugging is now even more troublesome, and for what? So we can use some XML-like syntax everywhere? React serves a purpose but this doesn't feel like it. All these directives, the lookalike tree complexity, and overloading fetch just feels wrong.
I get what you’re saying, but you can use React without RSC just fine. Next.js might be pushing RSC, but using Vite and normal React is fine. Hell, even the pages directory still works in Next.js and it has no RSC.
From my experience, Next isn't great for SEO either.
Try setting up a redirect that preserves query params with server components.
Server components do allow redirects on the server-side, but they do not expose query params.
It's technically possible with middleware (single root file that runs for every request), or by setting up a client-side redirect, but that's not ideal.
Very true, but React is extensively used for landing pages and e-commerce where SEO is vital. If you’re using Next for those sort of apps in your company, why not use it for the dashboard? It’s seems like the natural progression instead of running Vite on internal apps and Next on external ones.
Yea I disagree. You’ll be fighting nextjs the entire time. It’s a tool for e-commerce sites. And honestly at this point you’d be better served with Astro.
Can you elaborate on why Astro is better or what type of fight with Next? Your type of post with strong opinions but none of the underlying _reasons_ are one of the reasons why JS framework wars are tiring. I'm really interested in alternatives to Next, but it's difficult to good, non-vitriolic, shop talk.
We bolted Next onto the React/Python application at work for SEO stuff. There's a number of self-inflicted problems with our integration but Next seems serviceable. Vercel's direction as a whole is not aligned with our needs though. The framework and paradigm churn is a huge time suck.
I don't really have a strong opinion. Vercel is a really loud voice in the React world, so I guess I'd like them to survive a post-zero interest rate policy world (many growth companies have struggled). Or at least, not push paradigms and features specific to their needs on the React world, then run low on cash, leaving those paradigms functionally unsupported and half adopted by other React libraries.
My needs that Next solved mid-2021 when I picked it: framework that can build on existing React code with strong SSR/ISR primitives + tools for bundle size control for SEO. Nice DX with hot reload was a big plus. My backend is Python and that's pretty set in stone.
Vercel seems to be very focused on solving full stack problems, with the app vs pages routing changes, RSC, server actions. It's clear they're listening to paying customers and I wouldn't tell them to stop. It's just not the problem I have.
The default should be SSR / SSG. Client only is a recipe for a slow web. Client loading is mainly appropriate for long running apps, like GMail, where users tolerate a slow initial load because they're keeping the tab open for a long time. There's a reason the Jamstack mascot is a loading spinner.
Maybe for public facing sites with minimal interactivity. But at that point just use something more basic. For web apps, client only is the way to go and way simpler to maintain. It’s not even close.
I agree, client only is choosing DX over UX. Slow loads, bad for mobile, loading spinners, flashing content. Which is why Next.js is awesome, it abstracts all of that away for you, so you still get fast sites without sacrificing DX.
I build web apps without loaders. There’s maybe a brief flash before content loads but it’s less than 1s ttl. People just want to slap loaders in front of everything because they have been duped into believing react-query is the state mgmt solution for react. It isn’t, it’s lazy programming.
I haven’t touched php in ages but that actually looks surprisingly nice. Pretty much every language has one of live view type libraries these nowadays, but this looks quite robust.
I hope with enough joking around the Next.js team realizes they've made a horrible mistake.
What they should have done was include a convenient RPC framework in Next - not magic code-splitting and magic RPC code-gen built specifically for people that are too lazy to write two files for code ran in completely different environments.
If you aren’t deploying to vercel for the duration of the project, use something other than next.js. It has become a vercel only product at this point.
The problem I see with Next has nothing to do with re-visiting these concepts, and almost everything to do with the examples. Flipping your mindset from “react is a framework for client side rendering” to “react is a dsl for building HTMl on the server” is a leap and it brings all this junk with it. I think thats how we get these parodies, and the “sql in a component” nonsense.
What is missing though is guidance on how to clearly separate these things. How do you do permissions, security model, clear separation of concerns, etc within nextjs in this new world? This is not new ground so the patterns should be pretty easy to describe. But thats missing and as a result, we do have people saying “no no. The process.exec call was a demo” without realizing that people are going to refer to that as a best practice.
My favorite part about this debate is that this is how Rails works, but Rails is worse. You intersperse raw database calls with your template code (`user.first_name`), and your templates kick off an untrackable amount of queries, and when you start nesting templates, you've lost all hope of app optimization.
RSC looks like it has some great potential. I really enjoy seeing these miss-the-point trolls that overlook existing technology issues.
As much as I like PHP and JavaScript, as the README in this repo alludes to, this is cool concept but its not a good idea to actually use this.
Some of the worst code I've had to maintain are weird mixtures of PHP/JS all in the one view file including where you have PHP generating JS/interpolating in variables.
PHP as a templating language alone is actually pretty decent, but you need to keep the JavaScript separate to keep things clean.
Ironically, these days PHP has its act together - look at Laravel - better than most of the JS ecosystem does.
I don’t mind JS as a core language. Web Browser APIs are pretty awesome (with a few notable exceptions like IndexedDB). But the Node and SPA ecosystem is, speaking objectively, a dumpster fire.
We parody “enterprise” software, where vendors convince large companies to invest in over-engineered garbage.
Node, Express, React, Vue, etc. used to be for hipsters who wanted to cobble something together with maximum velocity and flexibility. But with them now in the big leagues, we’re seeing the same “enterprise” patterns emerge.
This is not an inevitable part of “growing up”; Python/Django and Ruby/Rails have been around for two decades, powered various unicorns, and are used at old-school multinational corporations as well as tech behemoths. But they have not fallen victim to the nonsense that plagues the JS ecosystem.
In fact, a lot of the JS ecosystem is now the worst of both worlds; you have over-engineered “solutions” combined with outrageous churn and zero sense of direction.
This is presumably inspired by all of the people saying Next is turning into PHP.