> The ability to interleave code and HTML was also tacky and never taken seriously

And yet people would take a bullet for React and the JSX templates.

Funny how "server side rendering" became a hot new thing too.

I was so confused when I heard that, "like... a HTML file?".

Keep going at this rate and we'll be using frames again.

> using frames again.

That’s pretty much what htmx is…

> "like... a HTML file?"

Serving a static HTML file is not server-side rendering.

It's much dumber than that. The people advocating for SSR want the server to respond with HTML generated based on whatever is in the request.

So like PHP?

This thread is so cope.

I too find this hilarious. Not because I want to defend PHP, but moreso that I personally sort of despise react and it's whole ecosystem. I've never liked writing code less than when dealing with a spaghetti monster react app.

Well React was born in Facebook which was famously PHP codebase. It makes sense.

JSX and PHP are actually seriously different. When you break out of PHP, you're just outputting text to standard output. When you're using JSX syntax, you're constructing Javascript objects that can be manipulated using standard javascript techniques. Anyone who believes they're comparable seriously doesn't understand the task that is before them.

Oh please, I professionally use both daily, JSX is just PHP with more steps.

Though not JSX, with TSX you get type checking with your markup.

My reading of this thread is that people are comparing JSX as a templating language to PHP as a templating language, splicing PHP <? ... ?> into HTML like how we have { ... } in JSX. At the end of the day React lets you write a function that returns HTML just like a PHP file.

"The ability to interleave code and HTML was also tacky and never taken seriously" - That was the whole point of it! The day I found PHP and could leave behind the cgi-bin and SSI it became my favourite thing - and has paid me well for the last 20+ years :)

Putting HTML inside of scripted code blocks was legendary back in the day and every web-oriented language did it. I guess people have already forgotten about ASP and ColdFusion. Being able to for each an array into table rows? Game changing.

I have been coding in coldfusion (openbluedragon) on 2012. Still lurks in my dreams. I refactored to components (objects) some functionalities as a POC, it did not fit well with the main programmer.

> The language is very unplanned, go look at an equality chart for PHP, it makes JavaScript blush as well.

This has been fixed in PHP 8. https://wiki.php.net/rfc/string_to_number_comparison

> make non-strict comparisons more useful and less error prone, by using a number comparison only if the string is actually numeric. Otherwise the number is converted into a string, and a string comparison is performed.

That… makes it even worse.

why?

Because now the behavior of comparison depends on whether the string looks like a number.

Arguably 48 == "48" should be true. If this doesn't work for you, stick to ===.

Thank you, I'll stick to languages where you can't just compare numbers and strings without an explicit conversion.

Also, should 48 == "48.0" be true? How about "048", "48.", "0x30", " 48 ", "48foo", "3*16", "XLVIII", "forty-eight"?

Once again: just use ===

If you decide languages based on minutiae like this, I can only pity you.

=== works for equality (if you actually remember to use it), but how about comparison? There's no strict version of <.

strcmp

I'd love to see a modern PHP without the language quirks and with a decent standard library.

> The ability to interleave code and HTML was also tacky and never taken seriously but I think touted highly by some as a killer feature.

And yet people seem to keep inventing variations of this as "templating" languages.

That presumably take care of the escaping rules and grammar of the output language, unlike the giant string concatenator that is PHP.

Yeah, a big problem with the traditional PHP-in-HTML approach to generating web sites is that it's one of the areas where PHP hasn't dramatically improved since the early days. Later templating engines learned from the problems people encountered with PHP and were built to be aware of the output format, and PHP never did that. A lot of work was put into writing templating engines in PHP that in retrospect really should have instead been a language mode for PHP itself.

We would have seen dramatically fewer bugs and injection attacks over the years if PHP had made <input value="<?=$value?>"> a perfectly safe and normal thing to write back in 2005.

There are actually shockingly few context-sensitive templating languages for php and those that exist don't seem that popular (Latte is the main one I'm aware of). Most of them are more of the giant string concatenation type, maybe with escape by default semantics (e.g. Smarty, Mustache).

The bad original library, the original lack of features that help against bad coding practices and the fact that it is so accessible to beginner programmers that you’ll find a lot of beginner code.

The ability to mix html and code means it’s extremely easy to get started which is the big strength.