Hacker News Reader

Comment by krapp | Hacker News Reader

Well, this is disappointing. I really like Hack and I was hoping it would take off, but judging from this thread it seems unlikely the language is going anywhere worth following. I guess it's lucky that I only have one project written in it...that I now have to convert back to PHP.

I'm really going to miss XHP. Native XML support has ruined me for templating frameworks. I never want to write HTML as concatenated strings ever again.

View on HN

For completeness: Sara Golemon started porting Facebook's old PHP5 implementation of XHP to PHP7 - you can find it here: https://github.com/phplang/xhp + https://github.com/phplang/xhp-lib

There are a lot of choices to not write HTML by concatenating strings though.

Are there in PHP, though?

PHP does have a history of making this more explicit, given its origins as a templating language. If you go down far enough, isn't all HTML rendering string concatenation? There are plenty of libraries that handle this in many languages, including PHP.

I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. Not having to quote HTML as strings or switch into and out the rendering context with PHP tags makes templates a lot easier to reason about and cleaner. With that, you can natively get features like auto-escaping, HTML tag validation, extending or creating custom tags, template inheretance, all of which you can do in PHP but only if you include the overhead of a framework.

> I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities.

I'm interested in things like this as well. Can you provide an example of what you're thinking of? Something like JSX? Other data structures that are transformed into HTML by a library? The latter seems to be counter to your argument about requiring the use of some framework or library, but I can't think of any alternatives off the top of my head.

XHP templates in Hack do wind up looking a lot like JSX (which is probably not coincidental).. Each tag is a class with a render function that returns an XML node. Here is an example base document template[0] showing what that looks like. Obviously, PHP templates can accomplish the same thing, it just takes more work and more dependencies to magic away the noise.

But with XML as a native data structure you can do things like typehint a tag:

    public function setTitle(:document:base $base, string $title): void 
    {
        $base->setAttribute("pagetitle", $title);
    }

[0]https://pastebin.com/m54VDwNY

Thanks for the example!

I've used Twig, which seems pretty comparable to similar products in other ecosystems, but there are several alternatives. So, to answer your question, yes.

Just use a templating system like Twig

Twig, Smarty, Blade

All of which just wind up building and echoing strings in the end.

I mean, OK, but that's how any templating system works. I assumed the issue was not having to write string-munging code yourself.

No, my only issue is that PHP doesn't let you just echo the HTML directly, because despite being designed for generating HTML, the language doesn't actually know what it is.

Raw PHP is far from its roots as a templating tool and is a full featured programming language. I don't really see any reason why you'd want to use it for templates.

It's not that far. PHP is much better as a language than it used to be, but it's still a hypertext preprocessor (they can retcon the acronym but the language is still designed around taking requests and sending responses), and templating is still almost exclusively what it's used for, because that's what it's best at.

If nobody is doing general-purpose programming (or at least Web programming) with PHP why are there three popular templating libraries?

That's... what I just said almost everyone is doing with PHP, that and not much else. Those templates are what the "Hypertext Preprocessor" part of PHP is about.

OK, let me be clearer then. If PHP itself is just being used as a templating language, where does the demand for multiple templating engines implemented in PHP, and intended for use in PHP projects, with their own non-PHP syntax, such as Twig, come from?

Those engines provide features that PHP natively lacks, or doesn't support well. With raw PHP, you have to manually escape every variable with htmlspecialchars, or mix HTML and PHP contexts in a way that can make it difficult to reason about complex templates, (see: Wordpress) or separate concerns (anyone editing templates now has to know how to write PHP, because templates are just PHP.)

A template engine can give you context-sensitive escaping, template caching and inheritance, macros, and other features that increasingly become necessary for modern web development, and many of which you would probably wind up implementing anyway, once a project reaches sufficient scale and complexity. While raw PHP is arguably faster, it's also more difficult to do properly.

Also, culturally, the PHP community isn't as centralized as other web development language communities seem to be. It doesn't have one 'correct' framework or one 'correct' templating language you're expected to use, so there is competition between multiple engines.

But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.

Well, yes, exactly, that's why I recommended them, and then I get the objection that they eventually are generating strings. I don't really get it.

> But the end result is still the same in either case, basic CRUD - taking an HTTP request, getting some data, pushing it into a template, and sending a response back.

Sure, that's what most PHP apps do... but it's also what most Rails, ASP.NET MVC/WebAPI, Spring, etc. apps do too. And it involves a fair bit more than templating -- database access, data validation, security, etc.

It's true that PHP is rarely used off the Web (although it's possible), but I can't see how what you're describing makes PHP different from any other technology commonly used for Web dev.

PHP is designed around handling HTTP requests and responses, so it already comes with a lot of the functionality you would need to import into other languages. Whether or not that's an advantage or a hindrance is in the eye of the beholder.

I don't think I would want to use just plain PHP and it seems like the frameworks that are popular nowadays kind of abstract over all that stuff anyway. In practice I don't think it makes much of a difference.

Reply on news.ycombinator.com