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

81–90 of 158 posts

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

#81

Post by sneak »

timschmidt wrote: post #78
sneak wrote: post #74

Earlier quoted context omitted.

I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas. Cool that you’re creating an actual desktop-style gl app with it.

I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default. Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to…

I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over.

I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.

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

#82

Post by creatonez »

dakiol wrote: post #15

The one thing I don't like about PHP is that the whole application is bootstraped (and autoloading and the configuration is re-evaluated) in every single http request. Sure thing there's cache and all, but it just doesn't feel right (compared, to, for instance, an http server written in golang)

You're right. It's a completely asinine approach. Especially when PHP itself is used as a templating language.

And solutions that try to fix this (custom templating engines, runtimes that run the whole thing inside a continuous PHP process) are simply putting lipstick on a pig.

The solution is to use a language that wasn't originally called "Personal HomePage"

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

#83

Post by osigurdson »

sneak wrote: post #81
timschmidt wrote: post #78

Earlier quoted context omitted.

I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default. Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to…

I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over. I learned how to build for the web by looking at webpages and seeing how t…

If you look at a typical next.js type app with all of the build steps, minification, post-css, tree-shaking, client side / server side, etc., it isn't exactly optimized for reverse engineering. Maybe that ship has already sailed.

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

#84

Post by timschmidt »

sneak wrote: post #81
timschmidt wrote: post #78

Earlier quoted context omitted.

I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default. Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to…

I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over. I learned how to build for the web by looking at webpages and seeing how t…

I recognize it as a more or less universal optimization process. Everything important ends up in silicon, if it remains important long enough. And there are several stages of that.

Like you, a part of me years for SGML and The Semantic Web, and where it makes sense in Alumina I am using RESTish APIs.

But I do not pine for Javascript. Language or frameworks. 20 years has been enough. And I do not believe that some of the 4mb minified obfuscated js downloads from a CDN I've seen are in any way more accessible than a WASM binary of similar size. At least there is advanced tooling for the WASM representation. Folks who want you to read their code will still make it easy, and folks who don't won't.

To your point about learning, WASM makes some really incredible systems like https://lovr.org/ available in the browser, which I would have loved to have as a kid, but which also aren't javascript. It's related to Turing completeness somehow, once you let a little software into your structured document, it all wants in. Or maybe it's "if you give a mouse a cookie"?

I understand what you're saying about discoverability. But the developer in me really likes having a relatively simple binary interpreter to target for network-delivered cross-platform binary applications. My hope is that offering such a juicy target to the folks who want to develop applications (including myself) gets them out of all the semantic document features, allowing both sets of code to get simpler and more focused. Because I think they're two different, both entirely valid, tasks folks use the web for.

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

#86

Post by [deleted] »

osigurdson wrote: post #29

Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints. It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.

[deleted]

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

#87

Post by [deleted] »

colesantiago wrote: post #3

I bit the bullet rewriting my app from PHP to Go and it paid off for my company, we're talking 20K lines of PHP code, reduced to 4K lines of Go and with the added efficiency gains with it. I think some orgs just need to take the jump and plan a rewrite, add tests (easier with Go) and just do this if they are a PHP shop, I would say it's worth it. Instead of blending Rust/PHP or Go together and having an unmaintainabl…

[deleted]

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

#88

Post by phendrenad2 »

sneak wrote: post #75
phendrenad2 wrote: post #71

Earlier quoted context omitted.

PHP really isn't that different from Ruby or Python these days. But, I can see the perspective where none of those 3 are valid solutions given newer better options like NodeJS and Rust.

Yeah, I use php colab all of the time to run numpy stuff on gpus, I learned about it in my php data science class in university. They’re basically equivalent now.

You're right, there is one area where Python has an advantage over PHP, but it has nothing to do with the language, really, and more to do with tools people have built to transform the language for other purposes. So it's sort of like saying Python and Ruby are completely different because Rails exists for one and not the other.

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

#89

Post by overfeed »

evantbyrne wrote: post #79
liampulles wrote: post #41

I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them. It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing t…

The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being ab…

> The reason Go does not have a grand framework is that the language has a severely underdeveloped type system

Counterpoint: PHP.

PHP 5.3 had an even less capable type system, but developed several usable frameworks.

Post reply on HN