[HN Gopher] Write PHP Code Within Next.js Components
___________________________________________________________________
Write PHP Code Within Next.js Components
Author : 0natcer
Score : 66 points
Date : 2023-11-02 21:29 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| _chimmy_chonga_ wrote:
| They only ever asked themselves if they could, never if they
| should.
| jalino23 wrote:
| haha
| some_furry wrote:
| Thanks for this, I'm deploying it to production, stat
| timack wrote:
| Every day we stray further from God's light.
| mrspence wrote:
| And closer to temptation
| timack wrote:
| Deliver us from evil.
| dimmke wrote:
| I literally opened this thread thinking "I want to write this,
| but I can't, I'll get flagged"
| timack wrote:
| That did go through my mind too, but I think for this it's
| warranted.
| mrspence wrote:
| "Yes this actually works. Trust me I wish it wouldn't too."
| garymoon wrote:
| why?
| teaearlgraycold wrote:
| 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.
| mattwad wrote:
| The Next team's core use case is a serverless framework for
| Vercel. Anyone looking to use it as a long-running server is
| just a second-class citizen.
| qudat wrote:
| 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.
| mirkodrummer wrote:
| meh not my cup of tea. Please let me know when "use gpt" will be
| generally available
| loloquwowndueo wrote:
| Good lord. Why.
| rob wrote:
| As someone who loves PHP/Laravel/WordPress, don't tempt me.
|
| My WordPress plugin built with Next.js, integrated with Laravel,
| coming soon.
| 0natcer wrote:
| Laravel dev here too
| CafeRacer wrote:
| This is exactly what I wanted but newer knew existed!
| rpmisms wrote:
| I may actually have a practical purpose for this. Yes, I could do
| the same thing with a simple API, but this is way funnier.
| CSSer wrote:
| 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_.
| theturtletalks wrote:
| 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.
| qudat wrote:
| I would argue that unless your need SEO there is no reason to
| reach for Next.js or any other react framework.
|
| The default should be vite and client only. Everything else
| only serves corporate interests.
| theturtletalks wrote:
| 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.
| qudat wrote:
| 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.
| bottlepalm wrote:
| 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
| typically a backend SSR framework, while Next seamlessly
| transfers the components/code/state to the client so you can
| continue re-rendering with the same framework 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 as most PHP apps just use standard
| JS libraries for interfacing with the server.
| rpmisms wrote:
| They're really cool, and act like the best parts of PHP. I
| actually miss the simply powerful aspect of the paradigm.
| bottlepalm wrote:
| What part of php? php doesnt render on the client, and most
| php apps except for livewire don't integrate call backs to
| the server.
| 0natcer wrote:
| 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.
| bottlepalm wrote:
| I could take this php example or raw sql code and put it in
| the body of an API call from the client.
|
| Are API calls bad now? Same thing. A misunderstood example.
| dgorges wrote:
| > 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.
| NorwegianDude wrote:
| I know. The Next.js part should definitely be removed first. /s
| cynicalsecurity wrote:
| No sarcasm.
| pulse7 wrote:
| The JS part should be removed first. No sarcasm... :)
| moralestapia wrote:
| Who would win?
|
| A literal trillion dollar ecosystem ...
|
| vs.
|
| ... le edgy joke.
| NorwegianDude wrote:
| Any way I can remove the Next.js part? That would be perfect!
| Haha.
| ilrwbwrkhv wrote:
| Yes it's called Livewire Volt.
|
| https://livewire.laravel.com/docs/volt
| hyggetrold wrote:
| Looks nice but what would _really_ take it to the next level is
| the ability to run Java but just JNI (everybody knows that 's the
| only useful part).
| ulrischa wrote:
| Not only HTML in JS, now also PHP in it. How about also adding
| CSS?
| droptablemain wrote:
| "Your [engineers] were so preoccupied with whether or not they
| could that they didn't stop to think if they should." - Ian
| Malcolm
| byhemechi wrote:
| I am extremely tempted to write a vscode mode for this. I'll let
| you all know if I survive
| cantSpellSober wrote:
| I'm trying to think of an argument _for_ this, just for fun. The
| author says the preprocessor converts the PHP to server actions.
|
| May be useful for pulling in a chunk of PHP from a codebase
| without refactoring it?
| nperez wrote:
| 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,
| https://twitter.com/peer_rich/status/1717609270475194466
|
| This is presumably inspired by all of the people saying Next is
| turning into PHP.
___________________________________________________________________
(page generated 2023-11-02 23:00 UTC)