Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

PHP uses an imperative programming model and has a very clear URL->source file mapping. This means you can look at the URL, find the source file, start at the top and trace your way to the problem.

Node (and Rails, and Java and lots of others) use a declarative router. The app boots. Shit happens. Routes exist. Middleware is involved. There's no way to know what code is implicated in a given URL.

If you're a pro and you can afford to spend a year or so learning framework internals while not getting much done, you develop a sixth sense for where in the codebase an error is likely to be, but you need to spend many weeks and months scratching your head to get there.

PHP is much more beginner friendly in this way.

View on HN

When's the last time PHP has been used in this way? Don't people use frameworks these days such as symfony, silex and laravel etc? And then point the web server to the entry point like with any other language?

>Don't people use frameworks these days such as symfony, silex and laravel etc

People should, Composer (with PSR autoloading) and nikic's FastRoute get you most of the way to a really nice, lightweight meta-framework barring anything else, for practically nothing. There really is no excuse for the "URL points to a file" model to be a thing anymore.

But a lot of legacy PHP code doesn't do that, and likely a lot of newbie code doesn't, because they follow old tutorials, and that model is faster and simpler.

Not even Wordpress uses routing AFAIK.

Honest/naive question: why not? Plenty of mvp or weekend projects can get by easily with url=page. If it's faster and simpler, what's wrong with doing it? Surely there's room for both on the intetnet.

Having a router allows you to not have all of your files be web accessible, by using a single point of entry and a whitelist for all possible paths. Most projects which map PHP files to URLs have everything in the web root.

If it's just a small brochure site with a few pages then it's no problem, but forums and larger projects built like this can leak information and expose vulnerabilities when PHP files which weren't meant to be directly accessed are, such as pages that perform SQL queries expecting variables in context that don't exist when accessed directly, or old config files, text files, open directories, etc.

But "url=page" is still basically routing using the query string, and IMHO so is access control using .htaccess. Any system where URLs are validated and where they don't directly point to files on the server counts.

>> not have all of your files be web accessible

cough wp-config.php cough

> Having a router allows you to not have all of your files be web accessible

Having a router may make it easier, but it's not the only way.

You can just put your libraries, passwords, etc., in some directory outside the document root.

    /var/www/example.com/public
    /var/www/example.com/lib

Then you use "include" to get them.

Having worked on projects with includes within includes within includes, and dealing with global variables defined in one file, used in another and reused elsewhere, it's definitely not the best way and it seems to destroy encapsulation.

If you can keep it under control, though, of course it's no different than includes in C/C++ (it probably literally is a wrapper around the macros.) But modern PHP prefers using autoloaders, so you never actually have to use include statements to begin with. You could just as well define those directories and include them through a Composer setting.

> includes within includes . . . global variables

Yeah, that's a pain. You have to exercise a little discipline. Of course none of my code has that ;)

With hand-typed routing, can't you accidentally define two routes that overlap, so some URLs could match both? The only reason it goes to one and not the other is something random like the order the routes are defined in the file? Like if you defined this route:

  /a/b/c

Then you slept, added a bunch of code, came back in three months and put this in:

  /a/*/c

Now you have two routes that match the same URL. And maybe they're separated by several lines of code, so that the mistake is hard to spot.

You can't do that with a filesystem, put two files in the same place.

> The only reason it goes to one and not the other is something random like the order the routes are defined in the file?

To be fair, that's not random, that's pretty explicit. And if you're optimizing for speed, short circuiting at the first match is a good idea.

But if you're using a router, chances are you're passing the segments as arguments to some function or method anyway, so route /a/*/c and /a/b/c should both wind up returning the same content if the second segment in both cases is 'b'.

How exactly is it either faster or simpler...? Especially when any of the frameworks just come with it configured out of the box?

sure, if you're writing "Hello world", /index.php is great. For everything else? Not so much.

This reminds me of people saying "version control, that's too hard, I'll just make backups of the src dir regularly".

krapp said so in the comment I replied to, I was roundabout quoting that.

Ive read somewhere interview with original author of PHP and he was very strongly against routers and one point of entry index.php . Saying that they are doing webservers job again. Router makes php slower.

I think while it is easier to use files as routing first time you use php.. once you start learn how to program, simple router is much much easier to reason about. Simple router is not the problem when learning php. Problem is clunky language with lot of legacy stuff and that people start with something like laravel that has so much stuff in it that you have to learn 20 concepts at once.

Even if you're not using a full-fledged framework, a router is a must these days. Anyone dropping a dozen or more .php files in the webroot that all include the same dependencies or header/footer is not following modern practices. And by "modern", I don't mean the newest fad from the past 1-5 years. We're talking about a standard way of doing things that is 10-15 years old.

WordPress is a perfect example of extremely poor code. Worth vomiting every time you think about it. No seasoned developer would put together a project the way they still have it. It has nothing to do with "backwards compatibility", or "easy to host with free/cheap hosts". It's not just "not modern", it's actually straight-up unacceptable. WordPress looks like it's put together by a group of php3 juniors writing their first script, having never held a professional job. That's not so much an opinion, as it is a factual assessment that any honest professional developer would give.

I believe WordPress and Drupal still work this way by default? I'm not a PHP dev anymore.

Yep. It's just easier to start a basic site in PHP when you're new. The typical tutorial is "write these four lines in a file and upload it to any host." You're good to go.

Now they shouldn't, but people jumping on JS often spin their wheels until they get pointed to a boilerplate project. It doesn't make for a fair comparison, but it doesn't matter.

Now they're trying to wrap their heads around six major libs with loosely overlapping concepts, four build and orchestration tools, and ten-plus scattered files... for "hello world." Then comes the generally miserable process of figuring out how to put it online.

Throughout this process the reference material is all at least three weeks old, making it hopelessly out-of-date.

I mean, this stuff is often referred to (even here) as a kind of dumpster fire. I can't imagine what a truly new person would think. So while I'm not starting any new PHP projects these days, it isn't hard to see the general appeal.

A very interesting... observation! I've never heard about it before... Thank you for sharing your professional expertise with us

Reply on news.ycombinator.com