For those not in on the origin of the joke, Next.js introduced "server actions" which became a huge meme / debate topic on Twitter - for example, <a href="https://twitter.com/peer_rich/status/1717609270475194466" rel="nofollow noreferrer">https://twitter.com/peer_rich/status/1717609270475194466</a><p>This is presumably inspired by all of the people saying Next is turning into PHP.
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.<p>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.<p>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.<p>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.<p>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 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 <i>wrong</i>.
I hope with enough joking around the Next.js team realizes they've made a horrible mistake.<p>What they <i>should</i> 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.
Moving past the <i>excellent</i> joke.<p>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.<p>What <i>is</i> 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.<p>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.<p>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.<p>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.<p>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.<p>We parody “enterprise” software, where vendors convince large companies to invest in over-engineered garbage.<p>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.<p>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.<p>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.
Looks nice but what would <i>really</i> take it to the next level is the ability to run Java but just JNI (everybody knows that's the only useful part).
You think this is a joke but Meta/Facebook has something similar for interop between XHP (<a href="https://github.com/hhvm/xhp-lib">https://github.com/hhvm/xhp-lib</a>) and React.
As someone who loves PHP/Laravel/WordPress, don't tempt me.<p>My WordPress plugin built with Next.js, integrated with Laravel, coming soon.