Laravel Trends

I’ve been following the Laravel trends for more than a year now, frequently reading on the Laravel forums/blogs/developer documentation etc., comparing Design patterns and other Geek stuff , searching for things like “laravel sucks”, “why choose laravel” etc., you’ve probably done the same in order to get the full gist on the alternative technology you are hoping to adopt. I ultimately could not resist to pull up Composer and get my own Laravel installation.

My initial opinion of Laravel was good

  •  Installation was really easy, and you’ll have a full working copy in about 3 minutes.
  •  The developer documentation is good and to-the-point, but lacks a bit on high-level implementation examples.
  •  The community is quite big and helpful, although I’ve seen some flame wars in the discussion forums

After my localhost installation and some further delving into the official documentation, I started investigating the structure/architecture and built some Controllers and Models etc… it was really easy, party because of the good documentation and also because of some “common magic” in the Laravel framework.

Over the hype and under the hood

  1. Laravel is too dependant on the Symfony framework, one gets the impression of a hybrid framework leeching off the success of another framework.
  2. Laravel feels like a chaos of mix-and-match – Laravel originally filled the gap between Micro and Full-stack frameworks, but looking at the current version it looks more like its trying to be a Full-stack framework, via Symfony.
    In order to use Laravel well, you are forced to learn other 3rd party products as well.
  3. The Blade templating engine which comes built-in with Laravel reminds me of way back when templating engines were popular, in the past decade most developers haven’t had a need for them.
    The Blade templating just adds another learning curve, frustration and runtime overhead – majority of frontend developers can read PHP anyway, so why do we need to be bothered with all these handlebars and freaky Blade markup.
  4. Laravel’s database abstraction is called Eloquent. At first glance it appears to be quite helpful and doing basic CRUD stuff seams like a breeze. That is until you need to do some real enterprise-level database work, with things like compound keys, multiple joins within join select lookups etc., in an enterprise environment Eloquent lacks quite a bit.
  5. Configuration, routing, helpers etc. looks naive and cannot be fully extended (without major changes), Laravel assumes too much, it assumes how a web application might work, unless of coarse you use the Symfony components which again raises the question, why not just use Symfony.
  6. The Facades problem, there are many heated debates about this ..more

 If you don’t care about semantics, then Laravel is a good framework for building small-medium web applications fast.

Why I prefer Zend Framework 2 and Symfony

  1. Both are professional high-level enterprise-ready frameworks with OOP done right, and taken seriously by major companies
    At any given time there is a significant amount of international jobs advertised for Zend Framework and Symfony developers,
  2. ZF1 was a bad dog and not the easiest framework, but ZF2 is light years ahead and completely different from ZF1, it is modular, service driven and extremely powerful, it scales beautifully with virtually any type of application and performance tuning is great.
  3. ZF2 and Symfony’s code base is clean and concise, not to mention the design patterns which are extremely powerful. built by some of the best software engineers and endorsed by many reputable companies.
     Enterprise support is vital for the longevity of the framework (remember what happened to Codeigniter).
  4. ZF2 and Symfony might not appeal to novice developers because of the high-level design patterns and implementations – you will also find less high-level seasoned developers working with frameworks like Codeigniter, Laravel, CakePHP – food for thought

Leave a Reply

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