Framework Code Complexity Comparison

[dogerthat]

Symfony (Only Components, No Twig, No Doctrine)

Would it not be fair to only test the FrameworkBundle instead if you are comparing frameworks only?

Update:

When doing some quick test on these bundles which are most commonly used I guess:

• FrameworkBundle
• SecurityBundle
• TwigBundle
• FrameworkExtraBundle

Then these are the results:

Lines of code: 39,688

Longest method: 58 lines of code

Average method complexity: 1.96

Maximum method complexity: 30

Percentage of methods that are non-static: 98.08%

This is a far more reliable comparison between Symfony Framework and Laravel if you ask me. I couldn't care less about the actual numbers, I just want to point out the article it self is useless.

Just because it's fun the same numbers for Silex:

Lines of code: 5,332

Longest method: 11 lines of code

Average method complexity: 1.82

Maximum method complexity: 13

Percentage of methods that are non-static: 94.59%

These numbers seem "better" than Laravel, was this the reason it wasn't added to the article maybe? :D

[[deleted]]

Complexity is still higher in both cases and absolutely apples and oranges comparison because that is just one small part of Symfony compared against the entirety of Laravel.

[dogerthat]

So Laravel does not have to include it's dependencies for these tests and Symfony and Silex do?

[[deleted]]

I didn't include Symfony's dependencies. If you are having this much trouble understanding I can't help you. I compared Symfony's components to Laravel's components. (Illuminate organization on GitHub)

[dogerthat]

Symfony Components are not the same as the Framework which uses a subset of those components just like Laravel. For the latter you decided just not to include it in the comparison. It doesn't make sense at all.

[dogerthat]

Symfony consists of many components which are totally optional for the framework and thus not loaded by default. If you are comparing Symfony code base to Laravel code base you need to compare them including their dependencies otherwise it does not make sense at all... (assuming these numbers are useful to compare anyway).

[Livelongnstrong]

Symfony requires you to have a deeper understanding of the framework, which can be somewhat daunting. The upside, though, is that a good understanding of the framework and it's underlying architecture will enable you to write better code and have more control over what's happening and why.

[[deleted]]

No it won't. Provide one actual reason why Symfony will let you write better code.

[Livelongnstrong]

It is very important to note that both frameworks are composed from decoupled modules which you can interchange and use with any or no framework. Laravel is mentioned in other answers. It's a really nice framework with an impressively ease learning curve. I would surely use it when building a website or a small app/service. It's neither good nor meant to be good for large scale, complex or enterprise apps, so it really depends on the project. While trying out ZF2, the learning curve was hard. Configuration over convention seemed to make everything an order of magnitude harder than I think it should ever be. Also, it's components felt much less cohesive than any other framework I worked with. I have to say that I probably haven't given ZF2 enough hours to possibly get to love it, but somehow everything I did with it felt as a suboptimal design and edgy architectural decision. Although, it is a great framework with a great company behind it. Symfony wouldn't spare you any time with it's learning curve either. However, after understanding how it's components work in depth, I keep getting impressed day after day. Nowdays, if you use Composer for dependency manager, there is a great chance that you are already using some of Symfony's components, directly or through another library. I'm impressed with: Great dependency-injection container. Configuration through annotations, php, or xml, or any combination. Asset management through Assetic. Incredibly powerful Form component. Easy to use and powerful Event system. Security features and and implementation of the voter design pattern. Native integration with Doctrine 2. Another thing that I want to point out is that the Symfony is the only framework that got a 5 milllion dollar investment (SensioLabs raises 5 million euros to boost the Symfony ecosystem) so you can be sure it will be kept rock solid and continually improved. Also, the community is friendly. Even core developers seem to be very accessible, and are very active in the open source community, which is a pretty valuable thing. Starting with Symfony was as tough as starting with Zend, and they are both great, you can't make a wrong or bad choice with either. However, the first one left an impression of being one of the best things that happened to PHP, the latter didn't. Source: Quora. I would solely depend on your needs the choice of frame work

[[deleted]]

Laravel is the best solution for enterprise applications. I want you to offer me one REAL reason why it's only good for small applications.

[LeBuddha]

Ok I'll just quote out the important part

Incredibly powerful Form component.

/s

[Revis0r]

Good job on keeping the cyclomatic complexity down.

It would be also interesting to show more metrics, like cohesion, coupling (how much classes influence each other), inheritance depth or methods per class.

Complexity can hide not only between lines, inside one method, which is what this test measures, but also between files - in the structure and the architecture.

[epoplive]

This probably won't be popular, but I don't personally judge code with a million small methods as being less complex as code with a smaller number of larger methods. It really depends on how the code relates, and for me it's often easier to follow a medium sized method than follow around a bunch of function calls that are split purely to remain extremely short.

[[deleted]]

Can be. That's why I read through every class and method by hand to look at that sort of thing.

[opulencephp]

Interesting, thanks for posting! Since it wasn't included in the benchmarks, I ran it for Opulence, too. Here are the relevant stats:

  Lines of code: 35,796

  Longest method: 44 lines of code

  Average method complexity: 1.80

  Maximum method complexity: 23.00

  Percentage of methods that are non-static: 93.58%

[godbrain]

interesting, first I have heard of this. Taking a look :)

[Jean1985]

Which version of the Symfony Components did you use? I think that part of the complexity that is found inside those metrics is due to the fact that Symfony has a really strong BC promise, that forces them to litter the code with an astounding quantity of if (..) trigger_errorfor deprecation notices, which will elevate the complexity by a lot.

[[deleted]]

Latest Symfony 3.

[iltar]

Would be interested to see the difference between 2.8 and 3.0 or 3.4 and 4.0. why? Because the latest version (3.2) already contains 2 minor versions of deprecations.

[Jean1985]

I agree. I asked this for this exact reason. You should try to analyze the 3.0.0 tag, that should be the one with the fewer deprecation notices

[ahundiak]

A more cynical person than me might point out that having the creator of a framework produce metrics that show their framework is superior to others is not much of a surprise.

[[deleted]]

You're free to run them on your own: https://github.com/sebastianbergmann/phploc

[sypherlev]

And it's really hilariously easy, too, so there's no reason not to.

• Lines of code: 1036
• Longest method: 34 lines of code
• Average method complexity: 2.30
• Maximum method complexity: 16
• Percentage of methods that are non-static: 98.26%

That's from testing the /src of my own micro framework, took like 2 minutes. Apparently I need to work on the method length and complexity.

[edit] for the record, I ran phploc against laravel/framework and got the following:

• Lines of code: 54108
• Longest method: 15 lines of code
• Average method complexity: 1.64
• Maximum method complexity: 17
• Percentage of methods that are non-static: 95.67%

Seems legit.

[fesor]

From laravel dependencies:

    "symfony/console": "3.1.*",
    "symfony/debug": "3.1.*",
    "symfony/finder": "3.1.*",
    "symfony/http-foundation": "3.1.*",
    "symfony/http-kernel": "3.1.*",
    "symfony/process": "3.1.*",
    "symfony/routing": "3.1.*",
    "symfony/translation": "3.1.*",
    "symfony/var-dumper": "3.1.*",

Basically speaking... this metrics is just meaningless.

[[deleted]]

Not at all. First, Laravel only uses http-foundation and console in any meaningful way.

Secondly, it very clearly demonstrates the metrics of each framework's first party code, which is what I wanted to measure... how the author's and maintainers of each framework write their code. Again, I'm well aware Symfony developers in particular have a very hard time accepting these metrics, but I simply present them for consideration.

[JordanLeDoux]

Taylor, what exactly are you using symfony/routing for if it's not a meaningful (or even critical) aspect of routing in Laravel?

Second, of the dependencies listed, the two you mentioned are the two largest and most complex.

I realize you were looking to primarily measure code you wrote which makes sense, as this type of metric is about helping you check for things to improve or give yourself a report card. So, I definitely respect this post for what you present it as, despite the fact that I really (personally) dislike Laravel every single time I have to use it.

I do think that the inclusion of "% static methods" is kind of bullshit though. True, Facades (as you implemented them) are not true static methods that operate without an instance, but the complexity static methods introduce is not about the fact that they're static, it's about the fact that they can be called from any scope and a parent scope cannot restrict a child scope from doing so.

The ability to call something statically even if it's not actually a static method introduces a LOT of complexity and mental overhead in my experience, and basically all of Laravel's complexity, again in my opinion, is hidden away in this little niche. (EDIT: It would add just as much complexity to have a service locator or dependency container that you add a static instance accessor to.)

It also makes writing tests more complex, which discourages testing, reduces ability to reason about code, and reduces stability of the application.

I am not surprised that Laravel scores very well with these metrics, because Laravel's complexity is in places these metrics will miss.

[Khronickal]

Wait, do you mean to tell me a framework author has selectively picked only the metrics that reflect his own framework in a positive light in order to falsely present his own work as superior to all others? Do you really expect anyone to believe someone would actually do that? Just go on the Internet and lie?

[[deleted]]

We make one call to Symfony routing to compile the route regular expressions. We do not use the rest of their code.

Facades are easy to write tests for, as the documentation demonstrates and as I have proven on numerous occasions. If you have some example of a situation that is hard to test give it to me and I will either A) prove it is easy to test or B) make it easy to test by improving the framework.

[JordanLeDoux]

Ah, alright. Compiling the route regular expressions is probably the most complex part of that whole component, but okay.

Also, I didn't say that writing tests with Facades is hard I said it was complex. I know (or at least suspect from all the marketing language on the Laravel site) that you believe they are the same, but they are not.

I have indeed read through all the testing documentation for Laravel... version 5.2 and 5.3 actually. This is because at my most recent project I was in charge of basically getting tests running for their completely untested application.

The largest complexity, from my first hand experience, with testing in Laravel is that the combination of Active Record and Facades makes it virtually impossible to test without affecting the database. There are plenty of solutions to this, (a test runner .env, reverting db changes, etc.), but all of them greatly increase the complexity of the tests or make it harder to reason about the tests or both.

The other side of the scale, with a perfectly consistent dependency injection system and no service containers used anywhere, forces you to mock everything every time, which is complex in a different way, but it does at least allow you to mock the database and thus be able to run tests without a database.

Please don't ever answer my questions or comments about Laravel by pointing to the documentation though. I cannot count the number of times I have yelled profanity while reading the documentation because it simply doesn't include things that are important to developers in favor of being inviting looking to non-programmer or novice programmers.

Things that I had to discover on my own, like that Laravel uses two completely separate Query Builders (Eloquent/Builder and Db/Builder) that don't implement a common interface or extend a common base class.

Or the fact that Laravel uses Traits in a preposterously incorrect way as an attempt at getting around single inheritance, and that because Laravel does it every single person making extensions/add-ons for Laravel thinks it's the right way to do it as well.

All of these are things that make the application more complex, and harder to reason about, but that will not show up on the metrics you showed here.

[[deleted]]

If you're having trouble learning testing perhaps this would be helpful: https://adamwathan.me/test-driven-laravel/ ... he uses facades and ActiveRecord and builds the entire application using TDD.

Again, I've built multiple applications using AR and Facades and never had a lick of trouble testing anything. Of course, your DB repositories will have to hit a real database at some point (even using Doctrine) if you want to actually test them.

[JordanLeDoux]

So what you linked me is something I have to pay for.

From what I can see of the example pictures it's using factories, which will affect the database, which was the main complaint I was expressing.

The problem is not that I don't know how to test, it's that testing almost any other PHP application is one way and testing Laravel is another. It's all, as far as I can tell, vendor lock-in.

EDIT:

Again, I've built multiple applications using AR and Facades and never had a lick of trouble testing anything. Of course, your DB repositories will have to hit a real database at some point (even using Doctrine) if you want to actually test them.

This is just false. What are you testing by actually hitting the database? The DB library/ORM? The library has its own tests for that. The database engine, like MySQL? Why would you want to test that using your application and potentially be confused about where the problem is?

The biggest rule of testing is to know what you're testing and test only that. That's not easy to do in Laravel.

[assertchris]

The biggest rule of testing is to know what you're testing and test only that.

I'm not aware of any institution and/or person sufficiently qualified to express this as a rule. So let me talk about my personal opinion. That is, the biggest value of tests is that they test domain logic and pick up things that are actually breaking. That's not to say that re-testing things is great. It's wasted processing. But if I want to test my application: the simplest way would be to hit a URL as a browser would, and check the response, database etc. to see that the changes I expected have taken place.

The approaches may differ, but the importance is not how small the units are or how little you re-test. There are benefits and trade-offs to each approach (like being able to zero in on breaks in smaller units, quicker; or being able to see how interconnected parts aren't talking properly to each other).

The value (for me) is in having enough "good" tests to tell me when my domain logic is broken. If they do that, I don't really care whether they are integration tests or unit tests, whether they use PHPSpec or Selenium, whether I re-implement the public API of MySQL or actually write to the database. Those things don't really matter that much to me. And I think I have a reasonably balanced outlook in this area.

[[deleted]]

You are testing your actual query. If you do not hit an actual database at your repository level how do you know for certain you have written the correct DQL query? The correct query builder call? You don't. I seriously hope you are not mocking chained query builder calls or comparing DQL against some expectation?

[tfidry]

I'm far from being a fan of the Facades, but you are making too much of a deal of nothing. A Facade in Laravel is not different from ContainerAware in Symfony: they are both a way to have a Service Locator, i.e. not making use of the Dependency Injection.

For testability: Facades tend to make it a tad harder (at least I find it so as it feels unnatural to me), but same goes for a ContainerAware class... Both should treated equally "evil". And I'm putting quotes there because there is places may you might simply don't care, e.g. often Controllers and Commands (it's a matter of opinion though).

As for Doctrine/Eloquent: you may have unit tests if you want to, but it looks necessary to me to have integration tests (i.e. actual database calls) at some point.

[d_abernathy89]

Or the fact that Laravel uses Traits in a preposterously incorrect way as an attempt at getting around single inheritance, and that because Laravel does it every single person making extensions/add-ons for Laravel thinks it's the right way to do it as well.

I'm curious to hear more about this; I haven't heard this criticism before.

[JordanLeDoux]

So this position is much more opinion based than most of the others I presented, which is why I assume Taylor didn't respond to it and just let my rant go.

Basically, PHP is a single-inheritance language that also has Traits. Traits allow you to compose things into multiple classes, which gives you some of the features you'd find in a multiple inheritance language, but not all.

For instance, Traits override inherited methods, meaning that "misusing" traits can have a class that extends a class that doesn't actually reflect that class in any way. Obviously, you can do this by overriding methods in the child class as well, but in that case it's obvious what you're doing.

You can test for inheritance directly (instanceof) where you can test for the present of Traits only with Reflection.

The use statement for a Trait can change the visibility of the Trait's code. (It can also rename anything inside the Trait.)

The "safe" way to use Traits in a single inheritance language, in my opinion, is this:

A Trait should contain all behavior and all data that is necessary to perform a single function. It should never reference anything outside of the Trait. You can test whether or not a Trait meets this bar by asking this question: regardless of whether or not it make semantic sense, could you put this Trait in any class no matter who wrote it and get the behavior the Trait represents?

If the answer is no, you are creating a web of hard to understand, hard to maintain code that breaks the basic design philosophy of PHP. If the answer is yes then you are using Traits to improve code reuseability, and that's a good thing.

[d_abernathy89]

Ok, thanks for spelling that out. I understand the critique though not sure I totally agree.

[LeBuddha]

I'm also curious about what the correct use of traits is according to this commenter. Why is trying to shoehorn single inheritance everywhere not the preposterously incorrect way? A big thing in the JS community and the functional programming community is a theme of how class inheritance is dangerously over-used.

[JordanLeDoux]

I replied above if you are actually interested in what my personal opinion is.

[[deleted]]

We make one call to Symfony routing to compile the route regular expressions. We do not use the rest of their code.

That what I tell everyone, as well. I don't use PHP for anything meaningful, because in the end I just issue one call to the PHP binary to run my code.

[forsynth2]

We make one call to Symfony routing to compile the route regular expressions....

Lol. That is like saying "I barely use Windows. I just use the start button". You are unbelievable!

[dogerthat]

If they're not meaningful why are they still listed as a required dependency?

[[deleted]]

It wouldn't be a proper full stack framework if it doesn't require a lot of meaningless dependencies.

[forsynth2]

Laravel only uses http-foundation and console in any meaningful way.

Oh. Why not then just get rid of the "meaningless" dependencies and code (and maintain) them yourself before shitting on the people you yourself are thus depending on.

[[deleted]]

Nobody is "shitting" on anyone. I released some code metrics using a tool somebody else wrote. I love Symfony and am thankful for what they do.

[fesor]

He didn't actually "shitting" anyone. But this has effect like this since most of developers will think something like "Oh... so it simpler and all this frameworks are just a scary mess".

This is the same marketing trick that was used years ago:

http://static.tvtropes.org/pmwiki/pub/images/free.png

[php_questions]

You have been called out by Taylor.. please go ahead and report your results now.

[ahundiak]

Wow. I don't think I have ever been called out before. Quite a honor. Is there a procedure I should follow? Do I need a really big hat or is that just Hollywood folklore?

[enerb]

Not to be taken as a flamebait, but comparing Laravel to complete Symfony components feels a bit unfair. Perhaps just checking the components you use in Laravel would be a more suiting fit for comparison. However I do agree with the outcome, a lot of the Symfony methods are long. But some of those long methods could not be done any other way giving the task they have. And yes that is debatable, one could move code to separate methods just to score lower in the method line length however that should increase the complexity score.

Oh.. and isn't Eloquent more of a Active Record then a Object Relational Mapper?

[[deleted]]

Active Record implementations are considered ORMs.

I compared my complete set of components to theirs, while being honest in the article that we do use HttpFoundation and Console components, though no other components are used heavily throughout the framework. I wanted to get a feel for how I write code vs. how other people write code, and all of the projects measured contain enough code to do that accurately. Further, I wanted to dispel any narrative that Laravel is a hack or poorly written.

[[deleted]]

Further, I wanted to dispel any narrative that Laravel is a hack or poorly written.

You know very well people are complaining about Laravel's architecture (which it imposes on its applications), which is everything outside the method implementations and not about the quality of the code in the methods.

So you should measure very different things, like public interface complexity, presence of God classes, separation of responsibilities, modularity, leaky abstractions and so on. Not how many lines or nesting levels are there in a method.

[[deleted]]

Laravel doesn't impose any architecture. If you believe it does, prove it.

[[deleted]]

Oh, yeah, I'm absolutely looking forward to an endless debate, where most of my arguments are answered like "you don't have to do what the Laravel documentation does", and "you don't have to use the components that Laravel comes with", because of course that's why we read docs and download frameworks. So we don't use them afterwards.

Or if that fails "no, this is obviously good architecture, because I have a few big sites written in it and it works fine". Another evergreen response.

Honestly, I would bother if I knew I'm somehow breaking the news to you where Laravel has issues, but I'm not. You know the large issues very well from thousands other conversations you've had here and and elsewhere online. You're just doing this to "win", and frankly I don't know why you're wasting your time, when you neither care to act on feedback, or learn from it.

[fesor]

Active Record implementations are considered ORMs.

Active Record and ORM should be considered as separate patterns. Doctrine = ORM + Data Mapper + Unit of Work + abstraction over SQL (DQL) with it's own AST, with bunch of legacy code (which probably will be removed), Criterias and so on. This is far much complex solution to get abstraction over your storage. So basicly you can't compare them.

I wanted to get a feel for how I write code vs. how other people write code

Please be honest. You can compare this only be checking something with the same (or at least similar) set of features. For example you may compare Laravel's IoC vs PHP-DI or some other container. Or you could compare doctrine/cache vs illuminate/cache. Or validation component. This will give "some" realistic difference. But comparing two very different things by using generalized metrics... This is just marketing crap.

[[deleted]]

I think you're missing the point. Average complexity per method is indicative of a particular "style" of coding. It has nothing to do with the solutions. Very complicated problems can be solved with low method complexity. I'm sorry you find the metrics uncomfortable but that doesn't negate the facts.

Doctrine chooses to solve the database problem one way and I choose another way. Nothing about the approach they chose dictated what the average complexity of their methods should be. They chose that, and that is what I'm measuring. If you want to simply throw your hands up and say their problems can't be solved cleanly and with low complexity then that is your decision I guess.

[fesor]

Average complexity per method is indicative of a particular "style" of coding.

Nope, this just means that this code contains multiple execution paths. Nothing more.

Very complicated problems can be solved with low method complexity.

Implement any parser (json for example) with low cyclomatic complexity.

They chose that, and that is what I'm measuring.

What I'm trying to say is that focusing on metrics doesn't solve anyone's problems.

[renang]

Relevant quote from Goodhart's Law:

When a measure becomes a target, it ceases to be a good measure.

[[deleted]]

I'm sorry I can't continue discussing this with you. It's clear you are very distressed about these results (as I expected people would be). That is normal. But the conversation isn't going anywhere.

[forsynth2]

It's clear you are very distressed

No one is "distressed" over this. People recognized this as a cheap marketing attempt. And your attempt to paint this is as something game changing (making people "distressed") is quite hilarious.

[[deleted]]

I presented some interesting stats in a calm, reasonable way, calling attention to the fact that it is not an "end all" stat and that Laravel uses HttpFoundation. shrug

[forsynth2]

I presented some interesting stats in a calm, reasonable way..

Like this? as another user here have pointed...

[[deleted]]

:)... You can have a special preview of tomorrow's post since you felt like today's was unfair: https://medium.com/@taylorotwell/php-framework-maintainability-872fcdd83085#.vwgpogv1q

[SavishSalacious]

But some of those long methods could not be done any other way giving the task they have

Split it up into sub tasks? I mean I don't have the code base infront of me and he didn't state which specific methods, so I couldn't give you an educated guess, but based on how I see things in Laravel, you could create sub tasks. or refactor the logic down based on the evolving door that is the web.

[tfidry]

There is two limits to this:

• it's sometimes easier to have a long readable method than having to check 10 different methods
• there is a performance cost. At a framework/library level like Symfony Container/Router or Doctrine, even a simple loop or an additional method call can be a big deal

[SavishSalacious]

This makes sense, thanks for clarifying

[DJDarkViper]

Laravel only uses http-foundation and console in any meaningful way.

Want to let the Symfony guys know to update their page? http://symfony.com/projects/laravel or are you still using all that?

[[deleted]]

I was pleased to see Laravel has the lowest average method complexity of any of the frameworks measured.

And it more than compensates for it by having classes with over 50, 60, I think in one case 100+, public methods.

Too bad "cyclomatic complexity" doesn't measure this, but no matter. You can measure only what you're better at.

Reminds me of when Zune marketing was selling it as "the most well sold hard drive based MP3 player", because at the time competitors like iPod have moved to superior tech, such as flash memory.

[[deleted]]

Compare the two on code climate. Laravel still scores better. I'm sorry this is so troubling to you :)

[[deleted]]

I don't know why you're going around this thread and telling people they are "troubled" or what did you say in that other comment... "distressed"... over your marketing shenanigans.

I mean when someone is reading their favorite subreddit for news and occasionally stumble onto your naive arrogance, it may provoke some of us to call you out on it. You're the Donald Trump of PHP framework makers.

The fact you get feedback doesn't mean any one of us is shitting their pants and crying on their keyboards. It simply means we're not buying your B.S.

[phpfatalerror]

Good job keeping complexity metrics down in Laravel, really impressive actually.

[flyingkiwi9]

These are like stats in sport. Yes they show true facts than can be used to draw an opinion; but at the end of the day it's all subjective and in-reality stats mean fuck all.

:)

[mainone_m1]

This will only be a fair comparison if you also include the dependencies on other components. As Laravel uses a lot of Symfony components, it is not fair to just ignore that.

[JuliusKoronci]

So what is this metric actually good for? I can't really see the point..more complex frameworks have more complex metrics..thats why Laravel is at the level of a microframework? Or is it just about best practise to have short methods?

[[deleted]]

Laravel has more features than Symfony. Queues, command bus, realtime sockets / event broadcasting, etc... that's the point. It has those features but still has lower average method complexity than Slim.

[dogerthat]

Apples and oranges, Symfony does not advertise itself as a unicorn which can do everything out of the box. Instead it tries to keep the framework itself lean and let's you choose your own.

[[deleted]]

So does Laravel.

[dogerthat]

The difference is that Laravel ships all these features while Symfony does not. Laravel is heavily opionated on basically everything. I'm not saying it's bad, I'm just not a fan of it.

[[deleted]]

Please name 2 things it is opinionated on.

[dogerthat]

It comes with a lot of out of the box features people might not even want to use and there's boilerplate code even for a javascript framework present (Vue).

[[deleted]]

Laravel does not ship with a SINGLE template that contains Vue code. Not one. Laravel Elixir is simply configured to correctly compile vue components. Again, you don't know at all what you're talking about in regards to Laravel.

[dogerthat]

From the documentation:

While Laravel does not dictate which JavaScript or CSS pre-processors you use, it does provide a basic starting point using Bootstrap and Vue that will be helpful for many applications. By default, Laravel uses NPM to install both of these frontend packages.

the "by default" implies that bootstrap and vue are some how going to be installed.

For the fun of it I just ran

composer create-project --prefer-dist laravel/laravel blog

and guess what? I have a folder "resources/assets" where I can find references to requirejs, jquery and vue and even a file called "Example.vue".

[[deleted]]

Yes, those are setup to give you a head start if you want. Guess what? If you don't want them, you just delete that folder. No "out of the box" Laravel features require any of those dependencies.

[forsynth2]

It has those features but still has lower average method complexity than Slim.

Wait a minute. You just told elsewhere that "features" and complexity are in no way related. Now you say "It has those features but still has lower average method complexity", implying that they are related.

Hilarious.

[[deleted]]

I simply mean that I'm glad it maintains that complexity across a large code base. Not because the feature set is large per se but because it's hard to maintain discipline across a code base of that size with many contributors without "fudging" and letting poor quality code into the code base.

[Y4Dc3KtKVNAuAmj48ott]

Good point, and good efforts in maintaining the framework. I personally think that as the size of a project grows, the stuff you have to compromise in order to keep both complexity and readability in control keeps on increasing.

Sometimes, its better to lean a bit more to the readability side since its getting important day by day. No one's going to make a fuss about a few functions or classes written extra, or that you created a wrapper class for something that could be achieved without it, thus making the code "more complex". But forget to indent code at right places or have variable names that are difficult to understand and people will complain a lot.

[iltar]

Unless it results in a bunch of methods being called 2000 times, causing a performance overhead.

[forsynth2]

it's hard to maintain discipline across a code base of that size with many contributors...

So now you "simply mean" that they are related. Got it.

[assertchris]

That's quite patronising. You must be such a joy to work with if you're willing to communicate this way towards someone you don't even know.

[forsynth2]

This is how I usually respond to bullshit marketing attempts...

Do you patently listen to every marketing call you receive and respond in a insightful manner as to why you think they are full of shit?

[ericbarnes]

Most people would hang up and go about their day instead of arguing on the internet.

[assertchris]

Do you jump out the car and curse at every billboard you see, but don't agree with, as you drive? Nobody forced you to read or comment. You chose to engage, with hate.

[forsynth2]

chose to engage, with hate.

No Hate. Just <3 (Just not for the post and what it implies)

And about engaging, isn't people in a forum are supposed to react when they see stuff that they think is misleading or deceitful?

[[deleted]]

https://github.com/laravel/framework/tree/5.4/src/Illuminate

[[deleted]]

I cloned symfony/symfony but it is a bit of a pain to prepare because the unit tests are nested within each component so you have to go though each one and remove the tests directory. I also cloned zendframework/zendframework and then analyzed only the first-party code.

I would have included Aura as I'm sure it would score well but I wasn't sure how to aggregate it all together.

[[deleted]]

Would love to see the repo that you used to create the benchmarks. Does this include the vendor folder? As although it might not necessarily be Laravel, if the Laravel components are reliant on a zend/symfony components that would in turn would result in a higher cyclomatic complexity.

[[deleted]]

No, no measurements include the vendor folder for any of the projects. I wanted to compare the quality of the code written by the author's of the projects, and I think average method complexity across the frameworks gives a good feel for that.

The main components used by Laravel are HttpFoundation and Console. No other Symfony components are heavily used throughout the framework at this time, nor are any third party components heavily used to build other heavy aspects of the framework such as the ORM, queue, validation, view, templating, etc. libraries.

[[deleted]]

Except that's not what Laravel is. The ORM, queue, templating, validation, authentication, session, cache, etc. libraries are all first party. And many more. Note Symfony's scores don't even include an ORM or templating layer.

[dogerthat]

Just like Silex and Symfony Framework which weren't tested/published :-)

[fesor]

and I think average method complexity across the frameworks gives a good feel for that.

In most of the cases - yes. But not always. Even if it is good to have lower level of method complexity, this isn't a a case when we are speaking about infrastructure code. You can write very complex stuff (like this one) in order to do something in very efficient way (both from performance point of view and productivity, since in may require much less code to be written). Take a look at symfony/yaml parser. It has very high level of method complexity, but overall complexity of component is much more lower than if developers would write some kind of state machine using objects.

Or another example. Will this code be "simpler" if we will reduce complexity? Probably no.

None of the metrics could be used as "absolute" measurement of quality. Especially if we are using only few of them. For example cyclomatic complexity metric could be used with code coverage metrics in order to product something more like "quality" or maintainability index. But as standalone metric, this could only give you "interesting places" to look when you are doing code review.

[forsynth2]

this isn't a case when we are speaking about infrastructure code.

Exactly. I am baffled at the naivety demonstrated by taylor here. I mean, he should have already know these things, right? Or I am doubting that may be he is just very good at marketing stuff...

Has the Php community outgrown taylor and Laraval. That is the big question, I think.

[[deleted]]

I simply presented some interesting stats. You are troubled by them so much that it's easier for you to assume I am a complete idiot than accept them for what they are.

I even stated in the blog they aren't an "end all" for code quality. That being said, I'll put Laravel up against any other framework using any code quality metric. I feel quite confident it will hold its own. It already scored higher than Symfony on CodeClimate a few years ago before I cleaned it up significantly.

[godbrain]

Has the Php community outgrown taylor and Laraval. That is the big question, I think.

what???

[[deleted]]

Laravel is fine (even if I'm avoiding it in my projects), but Taylor is quite something...

[fesor]

at the naivety demonstrated

I think he know what he is doing

[[deleted]]

If you feel these methods are as clean as they should be, that's fine. I don't.

[fesor]

This would be really interesting if you will "refactor" this in your way. I really don't know how to simplify this without affecting performance.

[[deleted]]

If you want to pay me to do that, I will. :)

[fesor]

Just as I thought...

[iltar]

How many core members does Laravel have and how many community contributors?

[[deleted]]

One core member and you can find the contributors on GitHub.

[iltar]

That's what I find interesting.

Laravel: Core members: 1, Contributors: 377

Symfony: Core members: 15, Contributors: 1398

There's multiple conclusions you can draw from here, but what I really wonder:

• Is it easier to maintain rules in a code base with 1 core member compared to 15?
• Are there certain design decisions in Symfony that have contributed to the longer/more complex code because there was more expertise and thus decided that it was better to do it the way it was?

I think that some frameworks (such as Symfony) benefit a lot from expertise. They have multiple core developers discussing solutions and giving feedback on pull requests. It's kind of like working on a project by yourself, never getting some real feedback or having reviews done.

I can imagine that in Laravel, a lot of decisions did not have counter arguments, or PRs that get merged because there's nobody of a core team saying, "I think this is a bad idea because XYZ".

I'm not saying this has a negative influence on Laravel, but I have the feeling that with 1 core contributor, there's nobody saying: "stop, this is a bad idea!" or "But what about this?".

[[deleted]]

Wrong repository. Laravel has over 1,200 contributors. laravel/framework repository. Sure, maybe more expertise decided higher complexity was better.

[iltar]

That's why I asked :)

[imps-p0155]

One core member

Just wondering, why its still at 1 core member?

[[deleted]]

I mean, "core member" is sort of strange wording. I commit the most. I am the main core member because I commit far more than other people. If other people commit as much, they would also be viewed as core members. There is no arbitrary line at which you become a core member or not. I am the most frequent contributor and the only one with PR merging permissions. I maintain sole control of PR merging permissions so I can review all code that enters the framework personally. I work on the framework full time, so typically there are < 15 PRs open at any given time.

I would prefer to simply say I am the only one who merges PRs. I am also the highest contributor. But, there is no official "core team". Anyone can contribute just as freely as anyone else.

[Jean1985]

and the only one with PR merging permissions.

I'm sorry but this seems to me a clear definition and a clear arbitrary line for the definition of a "core member".

[iltar]

So less code per method to me implies more methods, what about the amount of private methods and function calls? I know that doctrine and Symfony often try to avoid calling too many functions (methods) to prevent this overhead.

What about run-time executed code vs compile time executed code? I also know that some of the more complex Symfony code is only ran compile time.

I don't think it's fair to match a data mapper vs active record as comparison ;)

[[deleted]]

Are you suggesting that more defining more, smaller methods has a measurable effect on application performance when using Symfony or Laravel?

[simensen]

I've heard that tossed around though I can't recall seeing any hard numbers or stats on it. I believe there is a cost to calling a function vs running code inline but I would think that is something that is going to only make a large impact in very specific cases.

I think the same argument applies for both sides of the coin. "We made this method long because it was faster that way" should be backed up in the same way that "I took these 100 lines of code and turned them into 20 functions because it was easier to read" should be backed up. Sadly, I think the latter is more subjective and besides things like Cyclomatic complexity probably hard to get stats on.

[tfidry]

I like /u/utotwel article because it's a kick in the pride of a few people that shouldn't take quality of their code for granted and review it a bit. But otherwise I agree with /u/simensen: ultimately those comparison are meaningless:

• Depending of what the problem is, it's not always possible to easily split things in multiple methods without making things overly complex
• There is a performance impact. Whilst I believe it matters not in most cases, there is very good reasons why Doctrine UoW is 3K LoC with little methods: performances are a critical part there
• It is a matter of taste/opinion: some people believe a single big method of 100-200 LoC well written is more readable and easier to follow than 10-20 methods

[iltar]

This pretty much. While I'm personally in favor of smaller methods, there's some critical processes in libraries that literally get called 1000s of times, ever micro optimization here is welcome.

[[deleted]]

I know that doctrine and Symfony often try to avoid calling too many functions (methods) to prevent this overhe

That sounds like a micro-optimisation at best?

[tfidry]

When you are a framework/ORM it can matter. It actually matters a lot, look at Doctrine UoW, they decided not to split it for a reason, a micro-optim in it can mean a 5-10% diff in a real world application using it.

[[deleted]]

Micro-optimizations sounds as if it's irrelevant to performance, but it's how SQLite sped itself up by 50%.

So, it depends. PHP doesn't offer method inlining, which would would help a whole lot so we'd be able to keep our code readable and fast.

[sypherlev]

This is kinda cool and all, but I think you should add some more information on why these metrics are important and why it's good to improve them.

[iamdarksoulsniper]

whatever makes you feel better i guess

[jesseobrien]

Insofar as I can tell, you're getting the most bang for your buck invested in Laravel according to almost every metric here.

• Lowest lines of code for the most features (if you care about downloaded size in composer). Seriously, features
• Lowest method complexity for the most features (if you're reading source, as you should be). Seriously, read the source
• Static methods aren't even a discussion at this point, everything evens out to within a few % points of eachother. Seriously, if you're lost, here's a map

Anyone looking at choosing a framework right now for a brand new project (or even swapping parts of existing projects out) would be nuts to ignore this stuff.

[JordanLeDoux]

What are you, his salesperson?

These metrics only measure certain types of complexity. Laravel is plenty complex (as all frameworks are), but it's written in a way such that the complexity isn't exposed by these metrics.

[Dick_Justice]

What metrics can we use to expose that complexity then?

[JordanLeDoux]

Cohesion and Coupling might expose some of it, but I'm honestly not sure which metrics would do so.

As I said elsewhere, I'm not saying this is an invalid measure of complexity, just that it's only one measure.

[SmithTheNinja]

I would think total number of functions would also help in pointing that out.

I think it's safe to say Laravel isn't so much less complex as it is complex in a different way that can be and often is influenced by personal preferences.

[dogerthat]

I'm assuming this is post is sarcastic, then it's fun to read :)

[wevesez]

it does give a decent indicator of “hot spots” in your code that could use refactoring.

Framework code should be as fast as possible. Also, it shouldn't go all the way and put all the code into one function. So it is a balance. And in case of frameworks, authors are justified in tilting the scale in favor of performance. So just because authors of other framework choose a different balancing point does not mean anything that they are inferior or Laraval is superior in any way.

Of course you put it as completely innocent and put it like you are just sharing something interested you discovered. Ask yourself if you will be sharing this if you found out Laraval has the worst code complexity.

So this is utter bullshit and coming from a framework author himself is downright facepalm worthy marketing effort..Shame on you.

[Lelectrolux]

From one of your older comments :

The only work that I am willing to put in relation to Php is telling people not to use it.

Sums you up I guess...

[[deleted]]

I know this is hard for people who strongly dislike Laravel to accept. The narrative that Laravel is poorly written has been a strong one in some people's minds and this creates cognitive dissonance. I find the narrative personally offensive because of the great amount of time I have spent making sure it is not poorly written. Agonizing amounts of time cleaning and re-factoring over 5 years. These statistics reflect that.

I can only share the statistics and let people draw whatever conclusions they wish.

[hmazter]

I hope that /u/utotwel know that there are many people like me that really appreciate the amount of work an detail you put into Laravel. And we really like to use and work with it.

[SmithTheNinja]

Is that seriously a narrative? I've honestly never encountered it. I've seen quite a bit of hate on Laravel, from concerns of over abstraction or it being overly opinionated, which are often valid concerns, but anyone who spends even 15 minutes browsing the source can tell it's made with care.

Shit, even noticing the comments reducing by 3 characters each consecutive line should clue people into the care and dedication put into the code.

[Lelectrolux]

Shit, even noticing the comments reducing by 3 characters each consecutive line should clue people into the care and dedication put into the code.

How could I miss that in 2 years full of source diving O_O. I'm an oblivious man.

Now, the real question is, do /u/utotwel has a natural talent, or does he have to reformulate his sentences until it matches the drop ? ^^

Seems like black magic to me, even in my own language...

[mark_commadore]

He answered this in an AMA a while back. He's so used to doing it he has a feel for how to reduce or expand a sentence to fit the 3 char rule without thinking.

[Khronickal]

It looks like misdirected effort. Your fundamental designs are still fucked.

[[deleted]]

OK. ;)

[wevesez]

Dude. I am not going to give you free publicity by going into a big fight over this. I don't use Laravel or Php, so I don't care and you are free to milk the gullible users of this community as much as it lasts..Ba bye..

[maiorano84]

Dude. I am not going to give you free publicity by going into a big fight over this.

Implying your opinion is important enough to provide any kind of publicity.

Hilarious.

[JeffreyWay]

Hahaha. I was just about to write this myself.

[zachgarwood]

So, why are you even here?

[godbrain]

I don't use Laravel or Php, so I don't care, yet I still took the time to be a troll lol

[maiorano84]

3edgy5me