> Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
Hey don't drag Node into this, you aren't forced to do any of that.
React to me feels like SPA developers discovering the idea of PHP and thinking they invented it. This shouldn't be surprising, since React came from Facebook, and Facebook historically is a PHP shop.
Mixing your business logic and presentation is a bad idea, but it's very attractive when you don't have the informative scars
You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail.
PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
> You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail.
This is accurate, and I never thought of it that way.
> PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
I did laugh out loud because I did not know WHAT to make of the comment. As someone who buttered my bread on PHP when everyone hated it, it was a sign of how times have changed!
It works great, it's fast and you don't have to learn a new templating language or dialect every 2-3 years. Or try to figure out how to do trivial things like loops in loops.
I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
Templating systems produce output based on a template and a set of data. PHP produces output based on imperative code that can do anything. While you can certainly adhere to your templates only consuming data (ie some kind of view model), it's actually awkward to do, as PHP files don't take parameters, so you need to use a convention of having your "template" files provide functions and call them, but functions are global so you now need to name them uniquely to avoid collisions. If templates are meant to be pluggable, this is much more difficult because you have two templates that are supposed to be interchangeable, with identifiers for calling them that are different[1]. There are a lot of properties of template systems that PHP does not actually have.
[1] It's so much worse than this... You can use some horrible hacks like undefining a well-known function that each template implements, but this would only work one level deep without also adding a mechanism for "calling" a template, and at that point you are making a template system on top of PHP.
The rest is not the PHP3 I recognize to be honest, let alone the modern stuff. Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
function render($data) {
switch ($data['foo']) {
case 'bar': include('bar.inc'); break;
case 'baz': include('baz.inc'); break;
}
}
That's your template router with all the template's data pre-loaded in the template's scope, be it ever so filthy.
All of those variables are global, there's no way to establish an interface between the caller and the callee without using functions. You could certainly have a shared understanding of what variables have been injected into a global, but this is awkward, and requires you to do cleanup after each template instantiation to avoid leaking values between templates, which can cause subtle bugs.
> Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
I've talked about this approach elsewhere in thread, it is not nestable without building a way to "call" templates on top of require/include, and when you do that you'll need to undefined the render function to do it as well, which creates additional complexity. At that point, the original premise of just using raw PHP isn't very true, because you are now building a framework or templating system around it.
Also, you have to contend with the magic "render" function not being globally defined by something. It's messy.
> Um. Can you give me an example to pad that out a bit?
Your example of using a render() function is already an example of this. You can parameterize render() to provide data to the template from the caller without utilizing untyped globals, and without having to clean the globals up after the template has rendered.
> Wait, you're only talking about the superglobals, right?
Yes. Globals are globals. PHP's super global distinction isn't really relevant to whether you are tainting the execution environment when you pass data to a script.
The point is, as I elaborate elsewhere, PHP is very awkward to use as a proper templating system.
The discussion thread here may underrepresent OOP PHP.
Large software in PHP usually uses namespaces instead of declaring functions at the top-level scope.
And most projects except for legacy ones lean towards objects and classes over plain functions.
Namespaces allow non-global functions without a wrapping class already, IIRC.
Looking up though, there seem to be special cases (legacy behavior, making everything at the top level global) when using namespaced files with include() statemtents, if I read the docs correctly.
Dumping pure functions as static members into wrapper classes was not uncommon when I used PHP.
But primarily, a lot of code was heavy on dependency injection and inversion of control, Symfony being the leader of this coding style maybe.
TFA also seems to be about class-oriented programming, but not the heavy design-pattern style mentioned above.
The linked TUI CLI parser looks like a nice and lean PHP OOP example.
1. It's a loaded foot gun. PHP was notorious for 1000 line files with HTML and SQL all mixed together. (I speak from personal experiences on this)
2. Templating languages are "portable" (In theory). Have a mixed env of PHP and Java... there were templating languages that would work for both teams, it took a step out of scalability.... XML and XSLT were the promise land on this one, but we fucked all that up. Portability is a big deal. We're still slinging CSV files for a good reason.
1. I've seen enough terrible things in my time, but you can make a mess in any language using any number of frameworks. And it's been a hot minute since I've seen one of those 1000+ line PHP+SQL+HTML+JS+CSS monstrosities in any serious environment.
Improper use of templating engines or trying to use templating engines that aren't up to the task can give you headaches just as well. Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, in the end we're craftsmen who need to learn how to use our tools.
2. This could be a valid use case, but a rather rare one. XML+XSLT is something that sounds fantastic on paper, but as anyone who actually worked with it knows it ranges from a big disappointment to an absolute nightmare.
If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about. And if anything people are cutting corners on SOC in the M and C part of MVC, not the V part.
Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
> If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about.
Those problems are called "junior developers", and I think we'd all like to avoid them, but that's not very sustainable.
Perhaps we can fix the education problem, but given that folks just do a boot camp and head into the market, prospects aren't looking good.
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
The problem is convention, or lack thereof. Without convention, who's to say where that database call should live? Frameworks, which tend to use templating languages for this reason, tend to make that convention clear to all teammates.
I want to mention that this doesn't mean you can't use PHP as the programming language for your templates as long as the conventions are clear, but PHP is poorly suited to being a template language for reasons I've posted elsewhere in this thread.
>>> If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about.
Its a one off... Its just an internal tool... This is a prototype... It's a hot fix...
I know better, I have done it. It is only with dumb luck that they didn't end up as products. Some people dont know that they should not or that it isnt a place they should try to "get away" with it. These things grow and then turn into products and someone has to clean them up.
Source: I made a lot of money turning PHP "projects" into "software".
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine
One of these things is Turing complete. The other is not.
Templating languages have their own laments: see yaml configs used to create "workflows", "environments" and "servers" via templating.
I've seen Python that was almost as bad as PHP. At one company, a guy actually complained that he didn't want to use multiple files, third-party packages, or anything outside of the stdlib. He'd write everything inside of a single "main.py" that ran as an AWS Lambda, which he often edited live in the console. When I first saw this, I thought I had landed on another planet.
At another job, another guy built some massive abstract-factory-factory-layer in Python, a class hierarchy 4 or 5 layers deep. 5000+ lines in a single file. It was almost impossible to debug.
Both of these are better than some C++ code I once saw. 10,000+ lines in a single file. In that file, there was a function with a 3000+ line case statement, which was mostly copy-pasta'd from other parts of the code (not in that 10K line file.)
I have seen plenty of PHP code that smelled like a nuclear dumpster fire, but you can write trash in any language.
In PHP, “HTML" is string concatenation; in React, “HTML" is an HTML-flavoured bit of syntax sugar over HTML-generating functions (and you are still welcome to call the functions yourself, if you want your HTML-generation code to avoid looking like HTML). Aside from looking kind-of similar if you squint, I’d say the differences and pros and cons are fairly significant (For example the IMO worst thing about the PHP approach, the ease of shooting yourself in the foot with XSS holes, is a non-issue in JSX).
I built the Swytch Framework to exactly hit these spots. As far as I know, it’s the only templating system out there with contextual escaping (you write html, it parses the html using a streaming parser, escapes output, then writes it out).
I use it exactly for rapid dev of stupid ideas. I’m not sure if I’d use it in a production environment because it is quite slow.
It did make total sense at the time. Consider we are talking a time where you had static html.
It is obviously good to be able to automate generating web pages based on say the state of a database. As this gives you up-to-date pages without someone having to manually build them.
And if that - automatically build web-pages from a database - is your goal and your current state of the art is static pages, then creating a language you can interject into your static pages, to build the page dynamically is a no brainer.
In defense of the PHP community, things like Symfony attempt to create some sanity when it comes to separation of concerns. Unfortunately, when people talk about PHP they inevitably talk about raw, framework less PHP and act like it's as sensible as something structured and disciplined like Ruby on Rails or ASP.NET MVC.
> PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
So what, JSPs are just the same. In the end what matters is the speed to Get Things Done, and there's utterly nothing competing with PHP, closely followed by Tomcat+JSP as you can use the insane amount of interfaces with just about everything that the Java world has.
> PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
If you think of PHP as prototype-only, mixing tags and HTML is very convenient, like it is with the other thousand templating tools. And obviously it's more a problem of XSS through badly sanitized inputs more than the mix in itself, blah blah blah
It's PHP in production a bad practice that got out of hand.
You're getting downvotes, but that genuinely puzzled me the first time I saw JSX. ("This looks a lot like 'include("form.php")' in old-school PHP. What am I missing?")
Turns out I wasn't missing much. I've mentally pegged it as an example of "the pendulum swings" - thin client vs thick client, centre vs edge, tight coupling vs loose coupling, etc.
Discerning developers avoid PHP for the reasons you mention, and yet it powers a frightening percentage of the Web.
React is popular for the same reason as PHP. I can only hope the industry corrects for this soon, because I challenge you to find a startup building raw PHP in 2024, yet nearly all of them build with React.
