Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise of Hybrid PHP: Blending PHP with Go and Rust

yekdeveloper.com

Post reply on HN
Print view View original

151–158 of 158 posts

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#151

Post by zelphirkalt »

reactordev wrote: post #63
zelphirkalt wrote: post #50

Earlier quoted context omitted.

How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.

The issue is, if I’m using JS, why on earth would I ever use PHP? I can just await file('index.html') or return The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.

So if returning a component is the same, how would one (PHP) be more painting oneself into the corner than the other (JS)?

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#152

Post by zelphirkalt »

sublinear wrote: post #55
zelphirkalt wrote: post #50

Earlier quoted context omitted.

How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.

I'm coming from the perspective of real world business concerns, not hobby projects. It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break for reasons out of their control. They should be able to develop…

I find it quite presumptious to assume, that backend developers do not care about this or that, or that they "drag ass about it".

To me it rather sounds like what you describe are code monkeys that give zero pushback on back engineering decisions, and will jump at anything that marketing throws in front of them. We have way too many of that kind already, making the web a dystopian version of what it should be.

And let me tell you, I am mostly doing backend things, as all the hype in the frontend world is offputting, but when I do frontend things, I don't do half-assed things. I make websites more responsive than 95% of "responsive" websites that we find these days as passing for that, most of which are developed by frontend developers, unsurprisingly. This is because I don't subscribe to the hype and solve responsiveness issues using web standards and CSS.

Just the other day I enhanced a couple of pages in a platform I am building, so that they can be used entirely without JS, while they are polling the backend API. Nothing too complicated, simply taking precautions on the backend side for enabling those pages to be reloaded and rendering updated state, and avoiding reloading them triggering new unwanted duplicate actions in the backend. How rare it is, that I see frontends going to that length of putting in some minimal effort, to make their websites more accessible and privacy friendly. Where are all those great web developers?

As I see it, a good developer with good knowledge about the basics of web development, most importantly HTML and CSS, only secondarily JS, can build better sites than most of what we see on the web today. The current mainstream is clearly not working all that well.

Why one would go for SSR? Because it doesn't require ones users to run untrusted JS. Because it doesn't require every single client to rerender the same things over and over again. Because it is lighter on the client. Because often it needs less data transferred, because there is no frontend framework whose code needs to be sent. Because it does not require repairing browser functionality after breaking it. There are many reasons to choose SSR. Also I will note, that you can do SSR and separate the logic for rendering your pages from your other code, so that the SSR accesses only API routes. Then others can build alternative frontends for that API.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#153

Post by liampulles »

evantbyrne wrote: post #147
liampulles wrote: post #128

Earlier quoted context omitted.

I think the Java stream API is amazing, and I do like that. Not having the equivalent of hibernate level ORMs is not a disadvantage for me personally, just because I don't like ORMs - Asking chatgpt to spit out some SQL and mapping code for me and being able to tweak the actual SQL over time is preferable (but again that is just my preference). I don't really agree with the idea that Go has an underdeveloped type sys…

Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily…

The "Go-ithic" way to write a library is to be strict with its API and place the onus on the consumer to do the work to map to and from it. So if I understand your example correctly (I might not), then it would be totally acceptable and in fact preferable for a Go codebase to map between the validator, then the query builder, and then the http response. Its preferable because I want libraries to have a thin API and be focused on doing one thing well, and I also want to have it clearly presented to me how I am mapping to and from an external dependency.

Another way of putting is that the Go philosophy is not to abstract details away or try and hide them, its to make the actual control flow of the program as plain and obvious as possible.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#154

Post by evantbyrne »

liampulles wrote: post #153
evantbyrne wrote: post #147

Earlier quoted context omitted.

Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily…

The "Go-ithic" way to write a library is to be strict with its API and place the onus on the consumer to do the work to map to and from it. So if I understand your example correctly (I might not), then it would be totally acceptable and in fact preferable for a Go codebase to map between the validator, then the query builder, and then the http response. Its preferable because I want libraries to have a thin API and b…

I understand that is the Go philosophy. I care more about what is practical than dogmatic. It seems clear to me as a complex library author that the type system leads to way too much glue code, which is expensive to write and maintain.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#155

Post by liampulles »

evantbyrne wrote: post #154
liampulles wrote: post #153

Earlier quoted context omitted.

The "Go-ithic" way to write a library is to be strict with its API and place the onus on the consumer to do the work to map to and from it. So if I understand your example correctly (I might not), then it would be totally acceptable and in fact preferable for a Go codebase to map between the validator, then the query builder, and then the http response. Its preferable because I want libraries to have a thin API and b…

I understand that is the Go philosophy. I care more about what is practical than dogmatic. It seems clear to me as a complex library author that the type system leads to way too much glue code, which is expensive to write and maintain.

As a Go developer of a few years now, I don't find it that way. I've found it to be very easy to write the glue code, because its largely the same as other glue code, and I find it easy to maintain because the plain control flow makes finding bugs easy. But perhaps the takeaway here is that, because Go certainly is opinionated, its a way of doing business that works for some and not others. And that's cool.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#156

Post by phplovesong »

forgotmypw17 wrote: post #97
phplovesong wrote: post #62

Earlier quoted context omitted.

How is php easy to setup?

Step 1: Copy the files. Step 2: (There is no step 2.)

This is not realistic. I have not seen that since little league soccer homepage back in the late 90s.

For "simple" deployment you need a binary that you ship. Anything else requires more steps, php included.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#157

Post by N2yhWNXQN3k9 »

yurishimo wrote: post #119
therealpygon wrote: post #115

Earlier quoted context omitted.

Never really understood using a template language when PHP is first and foremost its own template language. I also don’t understand developers making decisions now about things that might one day have to be replaced. It’s like building a bridge, but letting the plan to maybe have to tear down the bridge 50 years later dictate all the design decisions. The fact this happens to lead to more organized and testable code…

Templating languages in PHP are largely about better ergonomics. Sure, you can have your own helper functions that do the html escaping or an abstraction layer to pass variables into includes without polluting global variable scope, but that’s all boilerplate. Twig and Blade are both fine templating engines with their own quirks and features but they’re also battle tested and have proven their use over the past decad…

Laravel uses stupid tricks to make templates easy. If you are using heavy modularization with blade templates in production for views, you are paying a lot because the framework developers are lazy and don't want to actually memoize requires.

Re: The Rise of Hybrid PHP: Blending PHP with Go and Rust

#158

Post by forgotmypw17 »

phplovesong wrote: post #156
forgotmypw17 wrote: post #97

Earlier quoted context omitted.

Step 1: Copy the files. Step 2: (There is no step 2.)

This is not realistic. I have not seen that since little league soccer homepage back in the late 90s. For "simple" deployment you need a binary that you ship. Anything else requires more steps, php included.

I don't understand the difference between one binary and several files, except that the files are easier to version...
Post reply on HN