PHP Framework Benchmark

As I wanted to set up a system to benchmark PHPixie I decided I might as well benchmark other frameworks too. Performance comparison done by Yii developers is laughable at best, because they benchmarked the “Hello World” scenario which tells nothing about database access speed, ORM performance or view rendering. This is really biased towards frameworks that lazy load classes and modules on first request to them. If the framework initializes slower it doesn’t mean it works slower too. Thats why:

We will benchmark a complete scenario that includes parsing URL parameters, getting data from the database and rendering a view.

Also I will not be testing this on a dedicated machine but on a VPS with limited resources. Why? Because that’s where a lot of website end up. So here is the setup:

  • 1  GHZ CPU
  • 256 MB RAM
  • XCache Enabled
  • 100 concurrent connections
  • 30s test time

Framework versions benchmarked:

  • PHPixie 1.45
  • Yii 1.1.13
  • Kohana 3.3.0
  • FuelPHP 1.4
  • CodeIgniter 2.1.3
  • Laravel 3.2.1 and 4 Beta (very slight performance difference so I included only 3.2.1 in graphs)
  • CakePHP 2.2.4
  • Symfony 2.1.6
  • Zend 2.0.6

We will run a test application that will have to take a parameter from the URL and output the record from the database. We will have a Fairy table with two columns: id and name. The URL will be http://test/fairies/get/1 and we expect to get the name of the first fairy from the database. This way we can test routing speed and database access. Here we go:

PHP Framework Benchmark

PHP Framework Performance with XCache

Well it seems that Yiis’ claims are a bit overhyped, it is indeed faster then most frameworks, but the difference is not as drastic now. I’ve been hearing a lot about Laravel 4 lately, but the results that I came up with Laravel 3 were mostly the same.

So now let’s try without the XCache:

PHP Framework Benchmark without opcache

PHP Framework Benchmark without opcache

As you can see the difference is quite larger this time. PHPixie is approximately twice as fast as Zend. Why so? Mostly because we update the code all the time to tweek little things that hog miliseconds of performance, for example trying to use str_replace instead of preg_replace where possible, etc.

Let me say a few words about my personal thoughts.

CakePHP has very good documentation, I’ve created few sites with it some time in the past, and it seems a decent system, but it does kick you in soft places a few times, mostly because you can find a lot of tutorials on the internet that are in fact for its older version and don’t work with the new release. Their database abstraction feels a bit dated and doesn’t really provide a convenient way of querying the database, especially when passing params to find() as array. You don’t get any hints when doing that (like code completion when using query builders in other frameworks) and have to remember those parameters which means consulting the API a lot, which doesn’t seem developer friendly.

Yii was annoying for me to code in. Mostly because i hate code generation. Even today when i tried to do this simple application to benchmark I got this pregenerated website with contact form and about page etc, and had to spend time to actually not use it, it felt like I was modding a CMS rather than coding my own code. On the other hand generated models do seem to be a workable idea so I can’t hold this against Yii. Another thing that bugs me about it is naming things like Gii etc. The name doesn’t describe at all what it does. Also it is really hard to find a tutorial that actually tells you which code to write rather they tell you which buttons to press to generate the code, and leave you wondering how to actually do the customization part.

Codeigniter was super awesome back in the day, it was simple, elegant, everything. It’s still pretty good now but some developers complain about it moving slowly with PHP focusing on backwards compatibility. IMHO apart from the namespaces there’s little reason for a framework to force PHP 5.3 on you and there is nothing really groundbreaking in PHP 5.4, except for maybe traits. But Codeigniter still feels dated though, especially its ActiveRecord implementation. PHPixie follows a lot of Kohana practices which follows CodeIgniter, so you might say that CI is PHPixies’ grandad.

Kohana is something that I like and have used a lot. The tutorials are for the most part non-existent, but it’s  rather intuitive to write in. What I really liked is the lack of master page layout by default, like those that CakePHP and Yii have, which is good because you usually define it yourself by extending a Controller, so you have more control over it.

Laravel I didn’t like, there’s just no edge to it apart from branding. They seem so consumed by branding and naming everything those strange names, e.g. Eloquent and Blade. They keep on telling you that their bundle system is the best and their ActiveRecord implementation is the best when it’s more or less same thing as you would expect from any framework, e.g. eager loading is a cool idea but it has been in Kohana since a long time and Yii too. I can’t smile enough when I see the “A Framework For Web Artisans” and “All the cool kids are doing it” punchlines. I assume the idea is to use coolness as a factor e.g. like Apple does. What is really good about Laravel is detailed configuration files which other frameworks lack in comparison.

Zend is still being Zend. It is slow but has extensive libraries, large community and a lot of good documentation. I don’t think anyone uses it for small to medium projects though.

Symfony is still slow, though it targets the same enterprise niche as Zend does. I never used Twig, as PHP is a very good templating language on its own, the idea of declaring templates is rather useful though, and looks much better then using includes inside PHP. Using Doctrine was also a choice of sacrificing speed for stability. If I had to choose between it and Zend though I would pick Symfony because it seems a bit more straightforward for the developer (e.g. me).

Now where does PHPixie fit in? If you know that your application will have no use for the complex stacks of frameworks like Zend, that all you actually will use is mostly database access and showing pages and making AJAX calls you need something that does just that, something that let’s you built upon what you decide is best and let’s you deploy applications fast. If further down the line you come across that you actually need an additional feature you can easily add a library to PHPixie with no hustle at all. On the other hand large projects usually tend to have their own implementation of virtually everything and PHPixie can provide a very strong foundation for that.

64 thoughts on “PHP Framework Benchmark

    1. admin Post author

      Yup. A couple of people I worked with quite like it. Laravel suffers from deep design flaws. Let me show you how it handles eager loading for example:
      SELECT * FROM "books"
      SELECT * FROM "authors" WHERE "id" IN (1, 2, 3, 4, 5, ...)

      Consider now that you have 2000 books in your database
      This is flawed because:

      • You have to iterate over the result set to get all those ids, 2000 cycles
      • There is a limit on the size of the IN condition, so most likely eager loading will crash here. E.g. oracle allows only up to 1000 items inside IN
      • Because you already had to iterate over all rows you don’t work with a database cursor anymore, so all those 2000 rows are now in your memory

      Such an ORM is neither state of the art, nor classy nor beautiful. All it has is a strange name.

      1. Aldo Utrera

        I’m sorry but this is not true. Just read this in there you’ll find an explanation using the same example you used, and they are just using two queries.

        1. admin Post author

          I didn’t say they weren’t using 2 queries. Please reread my post more closely. The problem is not the number of queries it is that in order for it to work they have to iterate over the result of the first result to get all the ids. Then iterate the second result to asign objects and then they give you the combined result so that you can iterate over it. Does that sound effcient to you? Bare in mind that you have to hold the whole result set in memory to do so. A much smarter system would utilize database cursors and read rows one by one while returning you results in a efficient way. To prove me wrong please try eager loading a 2000 row set with its relationship and tell me how fast it is. this problem has been solved years before by other systems. Take a look at Kohana with() source code:
          do you see an IN condition there? Benchmarks those and see my point. Laravel does it wrong. Period.

          1. Quike Morales

            You’re right.
            Just imagine a CMS or Blog with more than 2,000 posts, with 30Kb average each. Loading those into memory will surely crash your script and it will be veeeryyy slow.

          2. John Cole

            I never used the Laravel DB Class. Except… I use it to get my connection and thats all. Then you can do everything you want with raw queries (of course with full controler).

            I created a test table with 5.000 users and selected them all with the following query. I also showed them on my screen with print_r.

            $sth = DB::connection()->pdo->query(‘SELECT * FROM users’);

            The execution time was between 0.05 second and 0.09 second. So that is pretty fast for a query that should never be used.

            But yeah, not everything is good in Laravel. But it has good sides and bad ones. Otherwhise everybody would use the same framework.

          3. admin Post author

            Well if you run raw queries you just benchmark mysql, not the framework. It will be roughly the same for any framework.

          4. John Cole

            Yeah, I know that. But I never likes ORMs anyway. Why should you use them? I have at this moment no reason to use them as I find that raw SQL queries are easier to understand and to switch between frameworks whenever needed.

            But as I said all the frameworks has good and bad sides.

          5. mootch

            It seems to me, that the link about Kohana’s with() code you posted is just about binding eagerly loaded models to one-to-one relations. Of course this can easiely be done with a JOIN, because you only need to match two single values, and that’s why it makes no sense to use an IN clause here. But joining 1:m or m:m relations, that should support limit, offset and grouping features in your query don’t work with JOINs. So i think it’s a common way to use the IN operator to select some relations. But it’s a good hint that IN is limit in some db engines, thanks for that.
            Using the DB cursor would be nice, but at least if you try to dump the whole result as array, you need to keep it all in memory, anyways.

          6. admin Post author

            As for dumping the array with print_r() phpixie has the ->as_array() method to do this.
            As for 1:m relationships, yes those are pretty hard to do in one query, but I still wouldn’t go with IN. What I would do is: select all Categories, then select all posts that have categories that satisfy the conditions (without the IN) and then use PHP to combine those together: 2 queries without the ugly IN

          7. mootch

            Well i think phpixie does a good job, but i just like to find out why you are against an IN operator.
            Imagine you have a news portal with 10.000 articles and 500 authors. Now find all articles written by the 10 newest, still active authors on your platform. I would first query the authors, and then use their IDs to find their related news.. usually with select * from news where authod_id IN (476,497,451,...) and merge the results with the author set. I believe that is much faster then fetching all 10k news items and match them in php instead… well, maybe as long as the IN values are not too big.

          8. admin Post author

            If you use an IN statement you would still be matching news items with authors with PHP.
            The IN vs Join approach differs only in the query that is being executed.
            E.g. a join query would look like: Select * from news LEFT JOIN authors ON where = ‘PHPixie’;

            Doing so you save the time and memory that would be required to build the IN query ( to build an array of IDs you would have to iterate all authors and make a comma separated list of IDs)
            Using a JOIN is just that much more efficient

          9. mootch

            You are missing the point i mentioned. Now try to limit your join’ed result to 10 authors. If you just add limit 10, you only get 10 news,… maybe 6 from author-1 and 4 from author-2, but that’s not what you wanted. That’s why most other ORMs use multiple queries and IN. I read an article about Yii that still relies on the JOIN but uses another query before to find the exact number to use in the JOIN LIMIT parameter. But as far as i can see, they dropped this behaviour in the newest version,… so maybe that was not optimal at all.
            I think a lot of other people already thought about the same problems. There might always be room for improvements but i guess they all know what and why they did it their way.

          10. admin Post author

            Well you can always do something lke this:
            SELECT news.* from news RIGHT JOIN ( SELECT * from authors where’PHPixie’ LIMIT 10 ) a ON news.author_id =

            Wouldn’t this work jsut as fine, resulting ina much smaller, much more readable query and without all the limitations of IN ?

          11. mootch

            Ah yeah a right join. Yes indeed that would work in most cases… at least when no lazy loading is used. But querying large data would return a huge amount of redundancy data. I’m not sure what is faster.. 2 queries that return less data or 1 big query that could contain redundand data each row.. i have to fit here. nevertheless, i think i’m getting too much off-topic here. thanks for your attention.

  1. Phil Sturgeon

    1. Which versions are you using.
    2. Put 0.1 WHAT on the graph, metrics are important here.
    3. Are you using the Query Builders, ORMs or raw SQL queries here?
    4. Why did you add your opinion on marketing to a benchmark article?

    This is an amature post and I’m not at all impressed. You’ve done this to fling mud at the competition and to make your own look the best. Yii did this a while back and lost a lot of respect from a lot of developers.. Stick to the facts.

    1. admin Post author

      The metrics are either obvious of being seconds. In all the benchmarks I ran i used the shipped ORM or whichever datatase abstraction was present. Lastly, writing a blog is all about opinions. I must say I didn’t fling mud at anything, just stating my mind. Of course I couldn’t be 100% satisfied with any other framework, otherwise I wouldn’t write this one.

      1. Phil Sturgeon

        Adding labels to charts is something you’re taught in secondary school as a kid. Trivial point, but something worth doing.

        In all the benchmarks I ran i used the shipped ORM or whichever datatase abstraction was present.

        Well this is the problem. Kohana and Laravel all have Query Builders obviously ORM’s while CodeIgniter only has a Query Builder. You cannot run a benchmark that is ORM’s v Query Builders or you’re obviously going to get different results.

        And again, you’ve not listed version numbers. Is this Laravel 3 or 4? Or 2? How would we know now? How will people know in the future?

        Lastly, writing a blog is all about opinions.

        When it’s a personal blog I absolutely agree. When it’s on a project you need to maintain a little professionalism, otherwise people will very quickly loose respect for you and your project. This discredits your framework – which may well be very good.

        1. admin Post author

          If you read my post carefully you would notice that I did list the versions, and I also specified that results for laravel 4 and 3 perform roughly the same. I don’tknow how did your knowledge of ORM system is, but fetching a single row from a database without the relations in an efficient ORM should be roughly the same as doing it with a query builder over which the ORM is built. I’m quite aware that comparing programatical relationship resolution opposed to query builder would be somewhat unfair thats why I didnt include those into the test. On the other hand when people choose which framework to write in and take a look at benchmarks they don’t really care about fareness. If I would take your point to an extreme I could compare nothing to Yii since it doesnt have an ORM at all and instead relies on pregenerated classes. You also may argue that we can compare nothing to Zend because Zend has such an extensive library etc. The benchmarks alone don’t matter by themselves at all because at the end of the day you can always write pretty efficient stuff in C and ditch the PHP idea as a whole. What matters is the tradoff between speed and ease, and that’s where PHPixie stands. It seems to me you are quite a laravel fan, so if you have some time i would be glad to see a callgrind of a full-featured laravel project just for comparison

  2. dev_to

    Yii was annoying for me to code in[..]

    Laravel I didn’t like, there’s just no edge to it apart from branding. They seem so consumed by branding and naming everything those strange names[..]

    Wow, that makes your results so much more believable. Whats the code you used for “benchmarking”?

    1. admin Post author

      Unfortunately it has been quite a while snce I did those and didn’t keep the code. If you disagree with them feel free to make some of your own.

    2. admin Post author

      In case you haven’t noticed Yii is quite fast in my benchmark. So your point of me cheating the system in order to merit frameworks i like is invalid

      1. dev_to

        No, my point is that you are biased which makes your “benchmark” invalid without providing any further information on how your testing was done and what code you used. It can’t be much longer than 2 weeks since you made these benchmarks and i don’t believe you would delete any sample code you may want to use for future benchmarking or to redo the exact same test at a later stage but with imporvements to PHPixie or whatever.

        In my opinion these results can’t be representative at all. Either you do a proper benchmark or you don’t do it in the first place. Since i don’t have my own framework i would like to push and because i’m quite lazy i wont build something for all frameworks now to proove that a non valid benchmark is wrong. Maybe i’ll do a benchmark with some of them when i feel like it.

        1. admin Post author

          Id din’t keep the code because it was really simple (2 lines in a controller, a model and a view of 1 line). Why would I keep that? If you do not trust these benchmarks look around for more and you will find they are more or less showing similar results. If I were at any time to redo those benchmarks I would still have to rewrite must of my test scripts because the frameworks would change with time too. If you ever do a benchmark feel free to tell me of the results =)

        2. Simon

          You don’t have a point, everyone has programming preferences, so will naturally prefer some frameworks style of doing things over others, it doesn’t follow they are then going to sabotage those frameworks they don’t like, the mere fact he went beyond the useless “hello world” benchmark is a big plus.

  3. Rasmus Schultz

    I’m afraid your maths (or your logic) is flawed.

    The contrast between the fastest and slowest benchmark is going to be drastically dependent on the database roundtrip time – without knowing what that is, this doesn’t really show anything, because the database overhead is present in every test, and it could be either really high or really low, and you would get a completely different result.

    In order to complete your benchmark, you need to use e.g. cachegrind (or another profiling tool) to establish the database roundtrip overhead as a baseline – a horizontal line could be drawn across your diagrams to show where the baseline is, or you could subtract the baseline from the response times before rendering your diagrams.

    Because the database overhead baseline is entirely system-dependent, your diagrams don’t really tell me anything.

    1. admin Post author

      I ran all benchmarks on the same system and witht he same database, so the roundtrip time would be roughly the same for same queries. As for the database having its up and downs it would be a somewhat evenly spread statistics and Zend being twice as slow as PHPixie can hardly be attributed to it having a streak of bad luck with the datatabse during the test. As for a callgrind if you check out the latest blog topic you’ll see some pretty interesting callgrind with a much more reliable usleep used as a reference point. If you like any particular framework I could whip out the same callgrind for it too.

  4. Dex Barrett

    So you’re saying (or at least implying) that we should use your unknown framework instead of let’s say CI, Kohana, Laravel, because yours is faster (supposing it is since your data lacks more information about the benchmarking) and thus it is better.

    Honestly, I don’t see anything special about your framework and how it can improve my development. What if I want validation or authentication? I guess I can just drop a Composer package… whoops! seems like your great framework doesn’t use PSR-0 let alone Composer; instead you use that ugly underscore name conventions.

    This is just a pathetic attempt to praise your work by trying to bash other projects. Good luck, man.

    1. admin Post author

      Your point about autoloaders is invalid as they stack, you can use PSR-0 with PHPixie without any problems. I guess today is the day when php illiterate people try teaching me stuff

      1. Dex Barrett

        I know how autoloaders work. Very clever attempt to change the subject since my point wasn’t about the autoloader. What I said is your classes still follow that ugly_oldschool_namespace_emulation_filename_convention, which is only used for libraries/frameworks that started being developed a long time ago and want to offer backwards compatibility or don’t want/plan to rewrite their projects so that they use namespaces. Yours is a new one, so why using underscores? So that it is compatible with PHP 5.2? That will be your little creation’s death kiss.

        And supposing that your framework runs 0.x seconds faster doesn’t make it better. There’s a lot of things to consider if you want to compare frameworks. Don’t try to reinvent the wheel, dude, that’s been done many times before and it gets boring.

        1. admin Post author

          The naming convention that you hate so much is actually quite more usable then namespaces when combined with a cascading file system. that’s the reason why Kohana didn’t switch to namespaces, there is actually a pretty long topic on their forums with lots of people arguing and lots of good points in support for either side. In the end they stayed with the current system. Until PHP has an option to import classes using a wildcard the whole namespacing idea is simpy extra typing. FuelPHP went the namespace way and overloading classes there requires you to do stuff to config files etc. I am not actively opposing namespaces, i just think that in their current state their usability is quite well unusable. As for it being the death of the project all I can do is lol, because I can bet I could redo the whole system (under 15 classes) to use namespaces in like 20 minutes?

          1. Dex Barrett

            You know what else you could do? You could build this site with PHPixie so that we could witness how fast it is. I mean, I’ve seen that some framework’s websites are built with the framework itself (Kohana, CodeIgniter, Laravel). That really would enhance your framework’s credibility. Because, well, all I can do is lol when instead I read it is “Proudly powered by WordPress”.

          2. admin Post author

            MAking a full blown CMS system that would work like wordpress would take too much time. I’d rather concentrate on the framework itself

    2. Simon

      He sounds like he hit a nerve, if you don’t like his benchmarks do some yourself, Yii also had benchmarks when they launched, the difference is he had the good grace to go beyond “hello world” something which favours certain frameworks over others.

      The truth is there is nothing special about any PHP framework, the differences are either minor or simply down to personal taste (e.g – do you want something minimal, do you like or dislike code genberation, etc), if you actually want something signifcantly different or want signifcantly different performance then you have to go to another language. And of course the fact there are so many PHP frameworks (with none doing anything special enough to come out the clear winner) somewhat destroys the point of a framework in the first place, a standard that everyone knows, which saves time / training and increases the pool of developers.

      Quite why you have taken such offensive over someone running benchmarks (and doing a better job than 90% of those you find on the web who use “hello world”), is a mystery, some frameworks are faster than others, fo rmany people it is a factor in which framework they use (no doubt after having been scarred for life by using CakePHP or even worse trying out Drupal).

      There is plenty of room for another framework, becasue as of yet the PHP community has not come up with a killer framework like RoR or Django which becomes a standard, indeed many of the PHP frameworks including those you mention have pretty laughable levels of use or demand, go to a couple of job sites and see how many of the employers are asking for Laravel or Kohana.

      1. Bill

        Since you last commented do you now think that Php has a killer framework? Or are they still much of a muchness in your eyes.

        To me the biggest bottleneck with Php was the lack of a good library management system, and this in part has been helped with Composer. If we had had better libraries, then perhaps we wouldn’t have such a fragmented eco-system. On top of that, we have a very similar situation regarding CMSs and their associated plugins. Perhaps it has felt easier in the past to load a plugin, rather than integrate a library.

  5. Ivan

    > I can’t smile enough when I see the “A Framework For Web Artisans”

    Yeah. PHPixie branding is much better: “Framework for schoolgirls”
    Or something like “PHPixie – framework for kids”


  6. Ronald Castillo

    So at the end of the day, all it matters it’s really how fast a framework is? I thought a framework was about taking the hassle out of repetitive tasks so that you can focus on your application rather than configuration issues.

    If all that really matters is speed, why not use YAF which is built as a PHP extension using C? I bet that it’s super fast.

    Benchmarks prove nothing, what really makes a framework GOOD is what it has to offer.
    IMHO apart from the namespaces there’s little reason for a framework to force PHP 5.3 on you and there is nothing really groundbreaking in PHP 5.4, except for maybe traits.
    Little reason ? You sure have overlooked PHP 5.3 new features. Maybe you should have a look at anonymous functions and late static binding. jQuery already proved why lambdas are so damn useful. And PHP 5.4, traits are REALLY REALLY REALLY useful. When you really get the hang of it they’ll become really useful (you could use them the same way CakePHP uses behaviors).

    I’ve used many PHP frameworks during my career (Zend, CI, CakePHP, Laravel, etc), and so far the one that’s more suited to my needs is Laravel. Forget the “all the cool kids are doing it” stuff and give it a try.

  7. Glen

    Excellent Article! (Despite the jealous comments from your competition.) Speed and ease of use are the 2 most important factors for me. (If a framework is missing some function, I can always later add some code for that.) I’ll have to try out PHPixe. I have been playing around with the Silverstripe combo CMS/Framework. What do you think of it? Add it to your benchmark with your thoughts? Please?
    Also maybe benchmark some mini frameworks like ‘Flourish’, Obullo, or ‘Fat-Free’ Thanks much!

    1. admin Post author

      I haven’t actually seen it. But how would I benchmark a single database call etc if it’s a CMS, it’s a much more complicated system

  8. Michel Acosta

    Please it would be good to know the name of the author these useful page in order to reference it.
    Best Regards

      1. MIchel Acosta

        Thanks Mr. Tsiupa. I´m making a document for graduating as an engineer in IT and I used the information of these page.
        Best Regards

  9. CommonSense

    If you have time to write your shitty little opinions, I’m sure you have time to fire up a benchmark test comparing pixie here and state your claims with proof ;)

    All these suckers who have negative opinions are butt hurt coz they wanna stick their dicks in everything… (Just like i’m doing :P ) LOL
    Take a moment, relax, punch yourself in the face! and move on… if you don’t like competition.

  10. Spabby

    Using a framework is always a balance between performance and maintainability, and I like to dial my framework right up to maintainability because for me, cpu cycles are cheap, my time is expensive.

  11. Lectus

    I love CakePHP, but those results are quite interesting.

    I also tried Yii and I liked your comments. It was my exact experience. Yii is VERY hyped but the tutorials are lacking. They teach Gii to generate code and then you’re lost. This is why I jumped in CakePHP. It also has a code generator (saves tons of time), but I can actually code WITHOUT it too if I want. CakePHP is very easy once you understand the magic behind it.

    I’ll take a look at PHPixie. It doesn’t hurt to try different frameworks anyway.
    Thanks for charts and this constructive post.

  12. Rohit

    It will be very good if you can test the Cygnite PHP Framework.

    Since it is new framework I would like to know Cygnite Framework performance against others. :)

    1. admin Post author

      I’d recommend submitting a request to Techempower’s Framework benchmarks. They do benchmarking of practivally every framework (including Pixie) so it might be quite insightful

  13. mortensens

    This is ( opensource project. May be good or bad. But nobody may not attack like this. if you know better, write your framework and release it. its easy to talk here…
    I do not understand whay those laravel kids attacking others here and there. Laravel is not more than phpixie or other micro frameworks. its top of symfony. Not even a real framework. I do not see any thing more than symfony itself in laravel. Why will I use laravel instead of symfony. symfony is much more stable and professional framework. And laravel is on top of it. So why will I use laravel instead of symfony.
    Second thing about laravel is performance. I do not believe those laravel kids use laravel. Test laravel for generating a page which include above 20 queries. its performance is worse than even symfony. What are you talking about. you must test your framework before attacking others. I really hate laravel communitiy. They think that they know all truths, and others are always wrong!!!. what a funny guys.
    phil s. said “there is no need namespaces on php” on codigniter forums, yesterday. And today he is saying namespaces are a must. mr phil what did changed yesterday to today. your decision changing too fast. you must know something before you write a decision. you are in contradiction with your self usually. I thing you must look at yourself before you teach “what is respect” here. you can say “its black” today, and you may say “no its white” tomorrow.
    I realy hate those larvel kids and community.

  14. Yosef

    I think about idea that MVC framework structure+parts should be part of native PHP language 3.5 years.

    This month when i really far a way from PHP somebody send me link to PHALCON – almost like my idea. I think also python and ruby should have native framework that will run much faster.

    Today steps that PHP have to do to survive node.js/rails/python raise:

    1. Phalcon should be integrated to be part of PHP 5.6 soon as possible – this will awake PHP from loose to ruby.

    2. Also should be in 5.6 create functions instead today functions that will be consistent like in python- all this function should start with s_print, s_split_words() etc…

    3. Add asynchronous native engine to PHP as NODE.JS

    4. Take Facebook HipHop or like that engine and make it part of native PHP. Its big importance for ecommerce systems to compile code before deploy to production for prevent errors/warning/bugs in compile time and fix them before they will naybe discovered by users in run time. (It exist opinion of unit tests that prevent that – they not prevent this issues in views+ in agile project all time demands changes and write all time unit test that big part of him going to garbage make script programming slow vs C#/SCALA)


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>