Write PHP Code Within Next.js Components(github.com) |
Write PHP Code Within Next.js Components(github.com) |
This is presumably inspired by all of the people saying Next is turning into PHP.
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.
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.".
And so the cycle continues...
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 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.
Are API calls bad now? Same thing. A misunderstood example.
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?
The default should be vite and client only. Everything else only serves corporate interests.
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.
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.
Whats quite amusing to me in the context of this joke, is back in the late 2010s we actually used React this way in PHP via the V8JS PHP extension lol
In production, too.
RSC looks like it has some great potential. I really enjoy seeing these miss-the-point trolls that overlook existing technology issues.
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.
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.
My WordPress plugin built with Next.js, integrated with Laravel, coming soon.
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.
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.
Not a single one of those provide even a way to do translations, run a background job and most don’t even provide an ORM or a way to validate input.
It’s a freaking joke.
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.
HTMX is just wildly different in that regard.
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.
A literal trillion dollar ecosystem ...
vs.
... le edgy joke.
https://github.com/vercel/next.js/blob/ffdfd33251165d8b2f092...
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
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.
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.
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.
A feature nobody needed that breaks the ecosystem and introduces huge amounts of complexity.
It hurts to see.