Hacker News Reader

Comment by giusc | Hacker News Reader

My personal opinion is that either no symfony and no pux should exist.

There's no need to reinvent frameworks in PHP as PHP is the framework already. There's no need to reinvent templating in PHP as PHP is the templating already.

If you require different productivity from a language just don't stick on PHP and make the right choice by using the most appropriate language for you. There's plenty out there.

PHP is great, it rocks and is very fast when used in the right way.

View on HN

If you're building a web application in PHP, then symfony is a huge improvement over naked php files or rolling your own bootstrapped system. Right out of the box it addresses concerns of security, user management, routing, persistence, and myriads of the other basic needs of a web system. Packages for many common components are already built, meaning you can get sophisticated functionality working quickly. It is modular enough that you can include only the components you need.

The built-in templating language, twig, actually provides a number of benefits over bare PHP templating. It addresses security concerns, has a concise and clean syntax, and compiles down to optimised PHP template code, minimising the performance hit.

If you are suggesting that PHP shouldn't be used for web applications, and should only be used for basic templating, I would be interested to know what you consider to be an "appropriate language".

Look at the php.net website source code. Another example could be the Wordpress source code. It's not handsome code, but it just works.

Things like fat (either slim) frameworks should be memory resident (java or similar), not reloaded from scratch at each web request, it just won't never perform on big sites. Alternatively, if you need to deal with bigger applications, or massive traffic, you can build some kind of backend memory resident application (c, c++, java, go...) and delegate the hard work to it by using a lightweight rpc protocol (see messagepack, thrift, protobuf), and leave PHP alone to do the job it's born for.

Also, the choice to adopt a framework is serious stuff, it firstly should be well designed and maintained, then it should suit exactly your needs and more importantly you should not just use it, but learn conventions and write your code by sticking on them or else all your code will result in a bad mess.

Wordpress is "not handsome code" and has been the source of massive security holes for a decade.

Symfony has problems, to be sure, but it at least establishes certain levels of sanity that you have to do something stupid to break.

Any "big site" will use an opcode cacher like XCache or APC to avoid reloading .php files from disk on every request.

Honest question: while I know that's true (I was using APC, now using Zend Opcode or whatever the replacement in PHP 5.5 is whose name escapes me at the moment), it seems to me that there's still going to be a performance penalty incurred. The PHP may be all compiled to bytecode at that point and the bytecode may be 100% memory resident, but you're running through all the initialization routines for the framework on each and every page hit.

"Pure" PHP is a pretty fast language when benchmarked, but PHP frameworks tend to benchmark poorly, and I've always assumed that the overhead incurred by PHP's execution model is the culprit -- essentially, PHP was written with assumptions about How Dynamic Web Sites Work that made sense in the late '90s but really suck when every request is hitting a front controller and being dispatched through a router. Is this not the case?

Yes you can use APC, opcache or XCache to load php bytecode in runtime. but you are still calling php functions/methods or creating a lot of objects in runtime. that's the overhead.

Too many people are losing sight of the power of 'pure' PHP and jumping on the framework wagon unnecessarily. That doesn't surprise me, as frameworks provide structure and rules to a language that is very messy.

Exactly. You don't need a 'router' when you have the filesystem and mod_rewrite.

What about when you are deploying with PHP-FPM or HipHopVM? A native routing component separates your application from your application server.

Using mod_rewrite (or the nginx equivalent) with PHP-FPM will work fine. I don't see why it wouldn't work with HipHopVM either.

In over 10+ years of PHP development I have never needed a "native routing component". Call me crazy...

Reply on news.ycombinator.com