Plans to compete with Laravel
Permalink
Hi.
I'd like to know what the "elders" and real programmers of concrete5 think about Laravel, its popularity, power, tools, features and how concrete5 can compete with it in the future. It's not a question of which one's better. It's a question of Laravel certainly having extremely powerful and useful tools and features and how/if concrete5 are planning if not to beat, at least to offer something close to Laravel's.
concrete5 has a lot of what Laravel doesn't. But it would be great if concrete5 also had what Laravel does have. The way models-migrations, events-providers-listeners, policies, routes, middlware, validation, Vue integration etc. are done in Laravel. I don't have skills to develop such things, but the ease of use of these for my level is extraordinary. Is anything near that going to happen in the new versions of concrete5?
I'd like to know what the "elders" and real programmers of concrete5 think about Laravel, its popularity, power, tools, features and how concrete5 can compete with it in the future. It's not a question of which one's better. It's a question of Laravel certainly having extremely powerful and useful tools and features and how/if concrete5 are planning if not to beat, at least to offer something close to Laravel's.
concrete5 has a lot of what Laravel doesn't. But it would be great if concrete5 also had what Laravel does have. The way models-migrations, events-providers-listeners, policies, routes, middlware, validation, Vue integration etc. are done in Laravel. I don't have skills to develop such things, but the ease of use of these for my level is extraordinary. Is anything near that going to happen in the new versions of concrete5?
Why would C5 compete with a framework that it was built upon? Laravel is a PHP framework that applications (such as C5) are based off of.
As far as I could dig out info on c5, c5 is built WITH Laravel, not ON it. c5 seems to be built on Symfony.
Somewhat off topic but I just started reading about learning Laravel. I am not a programmer bu a designer so good luck to me. Mainly only know html5, css3, and a little php. Anyway, I know this is an old thread but my purpose of asking is I am trying to learn to build web applications on frameworks. Did you build your Job Search Application addon using laravel and react? I just stumbled across it and it looks very interesting. Be more suiting to me if the employers and employees could get charged fees for posting/searching if site admin wished to charge for memberships.
Considering purchasing the addon.
Considering purchasing the addon.
Hi,
The Job Search addon is purely for the Concrete CMS framework and can only be used in it.
It does not have the fee for ad/search functionality. The Classifieds addon does, but it't not dedicated to the job search functionality.
The Job Search addon is purely for the Concrete CMS framework and can only be used in it.
It does not have the fee for ad/search functionality. The Classifieds addon does, but it't not dedicated to the job search functionality.
I know it's for C5. I meant I may get it to use for one of my C5 projects after I review it some more. The pay feature would make it more appealing. I was just stating that I would like to start learning Laravel so I am looking at Laracasts and the documentation because I want to learn how to build web applications, not only websites. Thanks for replying to such an old thread.
For a quick bit of context, I've been developing with Laravel for 5-6 years, where I've used it to develop both APIs (using Lumen) as well as several large applications.
I'm a big fan of Laravel, it's continued to evolve in positive ways, and (at least in my impression) its become the de facto PHP framework. The patterns and structure in it make it great for working with others as well.
So my everyday work generally consists of swapping between Laravel projects and concrete5 projects, including working on systems that use both platforms together. I lot of the code I write looks very similar across both type of project, sometimes it's cut-and-pasted.
I think the main thing I'd stress is that Laravel is purely a framework - by itself it doesn't do anything. Whereas concrete5 is obviously a full featured CMS, that also has the ability to be _used_ like a framework.
So they're not really directly comparable, nor are they really something that would compete. I use concrete5 when I need great content management features, permissions, file management, etc, already built. And then I use Laravel when I need to build a system more from scratch, giving me more flexibility at the cost of not having features already built. It all depends on the project.
That being said, when 5.7 was released, it adopted a more modern structure (PSR, etc), and components from the Laravel world, made a heavier use of composer to pull in libraries, so there are a huge number of similarities between both platforms:
- both can take advantage of composer
- both use autoloading of classes
- both having custom routing (I think it's the same library underneath)
- both have controllers and a view layer
- both have middleware
- both have migrations available
- both use facades for common API usage
- both handle requests and responses in the same way (same libraries I think)
- both have command line functionality, and a nice way to create your own command line functions
- both have localization
- both having caching systems
- both have an events system
- and a whole bunch of other stuff in common, I could go on for a while..
A lot of what they have in common I'd attribute to just solid design and working in a modern way with PHP.
The differences that come to mind are:
- Laravel has Blade templating, whereas concrete5 uses PHP directly in templates
- Laravel has Eloquent to manage models and relationships, and this is an 'ActiveRecord' implementation, whereas concretes uses Doctrine
- Laravel has Laravel Mix, which is designed to build front-end assets. Whilst concrete5 has an asset compiling step only for developing concrete5 itself
- Laravel arguably has more developer focused functionality such as queuable mail, task scheduling (which is amazing), more powerful validation, and other built in stuff like connecting to different file systems. Not that concrete5 doesn't have lots of that stuff, but it's more of a focus in Laravel because of the framework having such needs
- Documentation for both platforms is quite different and Laravel's is quite succinct, but I'll defend concrete5 here in that it has a _lot_ more to cover, as it has to try to explain all the CMS aspects and API, on top of the more generic framework related stuff.
But the main difference is that concrete5 is effectively an already built application (with the ability to extend it), while Laravel is like a blank slate.
It's then hard to compare both platforms, as we're simply not using them for the same reason. But from a development point of view they're not _that_ different.
Some further thoughts about the differences:
- I find Eloquent pretty damn nice to work with (it can make you really lazy too!), and it took me a lot longer to get my head around Doctrine. Arguably Doctrine is more sophisticated and powerful, but it can be quite confusing to set up in contrast to Eloquent models. Much of the time I sort of cheat and treat Doctrine entities a bit like ActiveRecord anyway by giving them a save() function. If concrete5 started offering Eloquent as an option I'd be pretty happy, but Doctrine also works fine for similar tasks.
- I do like Blade templating, it's easy to work with and keeps things fairly neat. That being said, we end up doing a lot more template related work in Laravel than we do in concrete5, so I don't know if there would be anything to gain by adding in that to concrete5. Some people hate template systems anyway.
- Doctrine has an advantage that its annotations will automatic create database tables and fields for you, which means you don't need to write migrations every time you need a new field, that can be really nice for things like package upgrades.
- I use vuejs in my Laravel projects, and have also used it concrete5 as well. Nothing really comes to mind that makes it harder to do so in concrete5.
If anything, I'd say it's just a case of concrete5 continuing to embrace many of the modern PHP practices which it's already doing. It's great to have both available, but they certainly are competitors.
I'm a big fan of Laravel, it's continued to evolve in positive ways, and (at least in my impression) its become the de facto PHP framework. The patterns and structure in it make it great for working with others as well.
So my everyday work generally consists of swapping between Laravel projects and concrete5 projects, including working on systems that use both platforms together. I lot of the code I write looks very similar across both type of project, sometimes it's cut-and-pasted.
I think the main thing I'd stress is that Laravel is purely a framework - by itself it doesn't do anything. Whereas concrete5 is obviously a full featured CMS, that also has the ability to be _used_ like a framework.
So they're not really directly comparable, nor are they really something that would compete. I use concrete5 when I need great content management features, permissions, file management, etc, already built. And then I use Laravel when I need to build a system more from scratch, giving me more flexibility at the cost of not having features already built. It all depends on the project.
That being said, when 5.7 was released, it adopted a more modern structure (PSR, etc), and components from the Laravel world, made a heavier use of composer to pull in libraries, so there are a huge number of similarities between both platforms:
- both can take advantage of composer
- both use autoloading of classes
- both having custom routing (I think it's the same library underneath)
- both have controllers and a view layer
- both have middleware
- both have migrations available
- both use facades for common API usage
- both handle requests and responses in the same way (same libraries I think)
- both have command line functionality, and a nice way to create your own command line functions
- both have localization
- both having caching systems
- both have an events system
- and a whole bunch of other stuff in common, I could go on for a while..
A lot of what they have in common I'd attribute to just solid design and working in a modern way with PHP.
The differences that come to mind are:
- Laravel has Blade templating, whereas concrete5 uses PHP directly in templates
- Laravel has Eloquent to manage models and relationships, and this is an 'ActiveRecord' implementation, whereas concretes uses Doctrine
- Laravel has Laravel Mix, which is designed to build front-end assets. Whilst concrete5 has an asset compiling step only for developing concrete5 itself
- Laravel arguably has more developer focused functionality such as queuable mail, task scheduling (which is amazing), more powerful validation, and other built in stuff like connecting to different file systems. Not that concrete5 doesn't have lots of that stuff, but it's more of a focus in Laravel because of the framework having such needs
- Documentation for both platforms is quite different and Laravel's is quite succinct, but I'll defend concrete5 here in that it has a _lot_ more to cover, as it has to try to explain all the CMS aspects and API, on top of the more generic framework related stuff.
But the main difference is that concrete5 is effectively an already built application (with the ability to extend it), while Laravel is like a blank slate.
It's then hard to compare both platforms, as we're simply not using them for the same reason. But from a development point of view they're not _that_ different.
Some further thoughts about the differences:
- I find Eloquent pretty damn nice to work with (it can make you really lazy too!), and it took me a lot longer to get my head around Doctrine. Arguably Doctrine is more sophisticated and powerful, but it can be quite confusing to set up in contrast to Eloquent models. Much of the time I sort of cheat and treat Doctrine entities a bit like ActiveRecord anyway by giving them a save() function. If concrete5 started offering Eloquent as an option I'd be pretty happy, but Doctrine also works fine for similar tasks.
- I do like Blade templating, it's easy to work with and keeps things fairly neat. That being said, we end up doing a lot more template related work in Laravel than we do in concrete5, so I don't know if there would be anything to gain by adding in that to concrete5. Some people hate template systems anyway.
- Doctrine has an advantage that its annotations will automatic create database tables and fields for you, which means you don't need to write migrations every time you need a new field, that can be really nice for things like package upgrades.
- I use vuejs in my Laravel projects, and have also used it concrete5 as well. Nothing really comes to mind that makes it harder to do so in concrete5.
If anything, I'd say it's just a case of concrete5 continuing to embrace many of the modern PHP practices which it's already doing. It's great to have both available, but they certainly are competitors.
Hi Ryan.
Thank you for such an elaborate reply. Great to know what c5 developers think about the differences.
I find it mindbogglingly easy to use routes (MVC in general, REST is awesome) in Laravel which end up with tens of lines of code while I get hundreds and hundreds lines of code in c5 for some reason. I just can't figure out if c5 has a similar way routes can be used as in Laravel. By same I mean the same ease of declaration and use throughout the framework.
Events-providers-listeners is another great thing. I know c5 has events. But can't find it if it also has the similar providers and listeners approach. Queues and mailers are fantastic.
I hate templates other than pure php+html. Although I understand the blade is more powerful. Can c5 stick views into the templates like in Laravel?
I love the way CSRF is used in Laravel. You just don't have to think about it except for adding a single word in the template, the rest is done automatically.
Eloquent is indeed brilliant. Again, tens of lines vs hundreds of Doctrine.
I've checked most of the best dashboards for and complete CMS on Laravel - they're nowhere near as good as c5. They all look fantastic visually, but functionality wise they seem like pimped up WP blogs. About the appearance, really looking forward to c5 v8.6 or v9 with the newest Bootstrap and hopefully Vue.js out of the box.
Thank you for such an elaborate reply. Great to know what c5 developers think about the differences.
I find it mindbogglingly easy to use routes (MVC in general, REST is awesome) in Laravel which end up with tens of lines of code while I get hundreds and hundreds lines of code in c5 for some reason. I just can't figure out if c5 has a similar way routes can be used as in Laravel. By same I mean the same ease of declaration and use throughout the framework.
Events-providers-listeners is another great thing. I know c5 has events. But can't find it if it also has the similar providers and listeners approach. Queues and mailers are fantastic.
I hate templates other than pure php+html. Although I understand the blade is more powerful. Can c5 stick views into the templates like in Laravel?
I love the way CSRF is used in Laravel. You just don't have to think about it except for adding a single word in the template, the rest is done automatically.
Eloquent is indeed brilliant. Again, tens of lines vs hundreds of Doctrine.
I've checked most of the best dashboards for and complete CMS on Laravel - they're nowhere near as good as c5. They all look fantastic visually, but functionality wise they seem like pimped up WP blogs. About the appearance, really looking forward to c5 v8.6 or v9 with the newest Bootstrap and hopefully Vue.js out of the box.
Sorry if it was a bit of a ramble, I think it was just interesting to consciously compare the two.
I would agree with you that a lot of things in Laravel do feel quicker to set up, for example you don't have to create getters and setters for Eloquent objects, that's a big difference.
But personally I don't find the difference in the amount of code quite as large as maybe you do, it might come down to process.
If I'm creating a new model in Laravel I have to:
- create a new Eloquent model (quick)
- create a migration to create the database table (medium, depends on the complexity)
In concrete5/doctrine I have to:
- create an entity file, in within in define the fields I want to have
- create getters and setters for each field.
But for that last point, I don't actually _write_ the getters and settings, I will generate them automatically once I've defined my fields using a function in PHPStorm.
Relationships are fiddlier to define in Doctrine, but much of the time I'm really just cutting and pasting another example and changing the nouns.
So when I compare both those steps, I'm almost _writing_ the exact same amount of code, I just end up with more code in the doctrine entities. In both cases I have to write a list of fields and what types they are, and really that's the bulk of the work.. that's almost the same amount of time.
With CSRF, I also like how that it handles in Laravel automatically by the middleware, it's so simple. But it's really only two or three extra lines of code in concrete5, not something I've ever felt is laborious.
With routes, they really work almost the same across both. You can map routes to controllers, or to a closure function, you just have to define them somewhere like in the on_start of a package controller, e.g.https://github.com/concrete5-community-store/community_store/blob/ma...
And here's an example of a route I set up years ago in our Snipcart addon:
_Very_ similar to Laravel I'd say!
I think vue.js is already included as an available asset in the core now.
Mailers feel pretty magical in Laravel.
Version 9 is going to be very exciting, as concrete5 is already immensely powerful and the user interface improvements are just going to make it easier to market and more enjoyable to use.
I would agree with you that a lot of things in Laravel do feel quicker to set up, for example you don't have to create getters and setters for Eloquent objects, that's a big difference.
But personally I don't find the difference in the amount of code quite as large as maybe you do, it might come down to process.
If I'm creating a new model in Laravel I have to:
- create a new Eloquent model (quick)
- create a migration to create the database table (medium, depends on the complexity)
In concrete5/doctrine I have to:
- create an entity file, in within in define the fields I want to have
- create getters and setters for each field.
But for that last point, I don't actually _write_ the getters and settings, I will generate them automatically once I've defined my fields using a function in PHPStorm.
Relationships are fiddlier to define in Doctrine, but much of the time I'm really just cutting and pasting another example and changing the nouns.
So when I compare both those steps, I'm almost _writing_ the exact same amount of code, I just end up with more code in the doctrine entities. In both cases I have to write a list of fields and what types they are, and really that's the bulk of the work.. that's almost the same amount of time.
With CSRF, I also like how that it handles in Laravel automatically by the middleware, it's so simple. But it's really only two or three extra lines of code in concrete5, not something I've ever felt is laborious.
With routes, they really work almost the same across both. You can map routes to controllers, or to a closure function, you just have to define them somewhere like in the on_start of a package controller, e.g.https://github.com/concrete5-community-store/community_store/blob/ma...
And here's an example of a route I set up years ago in our Snipcart addon:
Route::register('/snipcartproductblock/{bID}', function ($bID) { $block = Block::getByID($bID); if (!$block) { return false; } else { // output the block link here, through this mechanism data should always be publicly accessible, regardless of permissions echo '<!DOCTYPE html><html><head> <title>Product</title><meta http-equiv="content-type" content="text/html; charset=UTF-8" /></head><body>'; $block->display('view'); echo '</body></html>'; } exit(); });
_Very_ similar to Laravel I'd say!
I think vue.js is already included as an available asset in the core now.
Mailers feel pretty magical in Laravel.
Version 9 is going to be very exciting, as concrete5 is already immensely powerful and the user interface improvements are just going to make it easier to market and more enjoyable to use.
