Hacker News Reader

Comment by alib | Hacker News Reader

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool). I’ve been using NextJS 13 and I love how it makes SSR as easily achievable as it always was with PHP and always should have been. I’d recommend it highly.

View on HN

In fairness, PHP prior to v7 was either a dumpster fire or a dirty bomb depending on how far back you go. When folks called it a fractal of bad design, it 100% deserved it, and folks rightly went looking elsewhere to solve their problems.

PHP is a phenomenally better language today, and folks really should take another look, but let's not pretend it was always anywhere near as good as it is today. Not by a long shot.

Also, don't judge NodeJS based on the React ecosystem. The sheer mass of APIs and wrappers needed to get a React-based system running is no one's fault but the React community. Stockholm Syndrome at its finest.

Rails and Django got very popular because of how terrible it was to work with PHP in the mid '00s

Well, PHP has no client-side rendering, so it's a weird comparison

OP said PHP + Javascript. JS is used for client side rendering. Nowhere was implied that PHP does that.

PHP has as much client-side rendering as React SSR does.

I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt description of what is going on)

Where other solutions might have abstracted the frontend part into a thing with a different name (or not bother doing it at all) React chooses in a rather unprecedented move to call it all just... React (well, there's Remix and such, but alas). Which is fine, as long as you understand that this new "React" will now probably lead to "React Frontend Dev" and "React Backend Dev", because the work and the complexities that these rolls entail did not just disappear by rolling it into the same name.

It's not entirely clear if architecturally there are going to be more benefits than footguns, but I think it's cool that they are trying.

React borrowed these concepts from Solid, SvelteKit, and Remix.

Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.)

I sometimes hear snarky comments about the proliferation of all these frameworks. But here is the tangible benefit of that “competition.” (Really more cooperation than competition)

More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases.

The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.

They may succeed, but only due to inertia, not a better/cleaner solution.

> The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.

Not really, the percentage of users for Solid, Svelte, and Remix are vanishingly small. They're essentially testgrounds for React anyway.

I had my own server side component system in PHP, 20 years ago.

And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.

Technically it wasn't client side rendering but it wasn't far from it.

And for actual client side rendering I experimented with compiling my HTML templates into XSLT and sending XML with data instead of HTML to the browser and letting it render it to HTML using provided XSLT. Because it was blazing fast when compared to JS at the time.

So, yeah, I guess thank you industry for coming around to what some twentysomething years old made just to build some websites for his freelancing.

But you weren’t google so by definition your tech is inferior to state of the art. It was you twenty years ago reinventing the wheel we have now.

I'm sure that React is engineered way better than not only what I achieved, but also what I could ever hope to achieve. I'm not against React. I'm just saying that it's an implementation of really natural (good?) old ideas. Just in JS.

> And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.

I did the exact same thing. I made a page with a table that was fully rendered server side. Any change in the display, such as pagination, sorting or filtering would trigger the same PHP code that returned a HTML fragment. The Javascript for that was easy. Just send an AJAX request to the server and replace the <tbody> element with the new content.

The PHP code itself was separated in components which made it easy to share the rendering logic for the initial page and the page used for the AJAX request.

React solves this in a more convenient way, but I am really surprised that we had to wait until 2023 before it happened.

People often ignore that the browsers themselves have also vastly improved. It's what makes a lot of the modern advances possible in the first place.

It's less full-circle, and more a blob that vaguely resembles a circle when you use are fully zoomed out.

I never liked NodeJS; on the one side it was innovative in that its concurrency model allowed for faster back-ends, but a lot of the features of existing back-end languages like Java and PHP were still missing, so a lot of patterns were re-invented, the language itself needed years to get to the 'safety' levels that Java already had and PHP was working towards, and proven and standardized technology like XML and the contractual guarantees it could give were discarded because it was heavy and JSON was better because it was human-read/writeable or something like that.

I feel like we lost a lot of time and effort by ditching XML. I mean documenting a REST/JSON API is still painful. While 20, 25 years ago you could already generate your data models and a parser for your XML payload. I still don't know what was wrong with XML. Yeah it was a bit heavier on the line than JSON, but that's a fixable problem - using compression, or use EXI (https://www.w3.org/TR/exi/) to turn it into a binary protocol. I don't know if EXI ever became a thing, but at the time I was quite exited about it knowing how much XML was passed around.

EDI never became a thing. One of the greatest selling points of HTML/XML/JSON is that they are human-readable. Even if gzip compressed, most tools will decompress automatically and show you the raw text.

So the tooling nor library support never came for EDI (i.e., Chrome, libxml, etc.)

Also, if you really wanna go full-throttle binary for speed, size, etc., you probably don't want something heavy like XML anyway.

https://en.wikipedia.org/wiki/Comparison_of_data-serializati...

I do think a lot of the original reasons why NodeJS was created has been lost, since at that time, non-blocking IO created some great performance gains. In many "modern" developer minds, it's now relegated to a dumb tool to spit out JSON or host a toolchain.

I personally think PHP’s syntax is miles worse and harder to understand.

Reply on news.ycombinator.com