My freelance business has grown, and reached a critical decision point for my future development. I've been puzzling over this for a while - why no...
For further actions, you may consider blocking this person and/or reporting abuse
No matter what project, I would go with Symfony and Symfony only. Especially with Symfony4 (and Flex) you can put together the pieces you want and omit ones you don‘t need.
I think there is no better framework in terms of architecture and design than Symfony. I do not lile the stuff Laravel does (did?) with static methods and a lot of magic.
In terms of maintainability and co., you always go better when using a framework. I honestly don‘t want to write code handling HTTP requests/responses - somebody else will do it way better than myself.
I agree wholeheartedly. Seeing as I do have some experience with Symfony (3-4 years worth), I can say that it gives you a well-structured codebase, all the joys of MVC and minimal BC breaks. You're only limited by the PHP version on your server. Regarding the cost of maintaining the codebase, I'd go with a monthly fee.
Then you surely should try ZendExpressive )
It really depends on your goals and how much you care about the architecture/maintainability of your codebase over time...
I'm a DevOps engineer working with teams of php Devs. If it were up to me we'd be using symfony, but the Devs need to make their own choices (and possibly mistakes) and chose laravel.
The biggest reason for choosing symfony over laravel for me is that, although laravel is alot quicker to build with (there's alot less 'plumbing' to be done). It makes it far too easy to write code that is very hard to maintain, and has poor separation of concerns.
For instance, the facades and app->make function in laravel allow you to utilise any service, be it a database, a queuing system, or a redis cache from ANYWHERE in the application. Without highly experienced developers keeping an eye on this, you'll tend to see things like database calls being made from blade templates. This is horrible to debug and pretty much destroys the concept of MVC (which most php Frameworks are designed to follow).
Also, eloquent is a huge pain due to model class structures not being very explicit. What I mean here is that if I wanna know which fields exist in an object, I can't just look in the class definition and see the class properties; I end up having to look in migration files to see the name of the public property that needs changing (if your lucky there may be a few arrays, with some strings in which are the property names). Also if you have alot of business logic associated with your models such as when I set X value on this model it should affect its y value, you're gonna have to create a lot of wrapping services to encapsulate logic which should actually exist in the model itself (normally in setter methods). Otherwise you find yourself duplicating logic all over the shop.
Dont get me wrong, laravel can be an awesome framework to use, but you need to learn to ignore some of the more standard practices in laravel...and use doctrine instead of eloquent. Seriously, I can't state enough how much better doctrine is.
The way I always try to explain why I'd choose symfony over laravel is this: symfony requires more plumbing than laravel, but this plumbing is a necessary evil which helps ensure a healthy codebase. When using symfony you have to think alot more about 'how do I access that service from here', and then do it through proper channels (i.e. dependency injection) as symfony only really allows things to be done in certain ways, whereas in laravel you can just use a facade from anywhere.
I know I'm slating laravel alot here, but I do see laravel being suitable for an agency that will throw a site up somewhere and then forget about it...if you're gonna be maintaining it yourself forever and are bothered about a well structured codebase, symfony is the one.
As a bit of background, I've worked on large scale e-commerce sites in both symfony and laravel. The symfony site, was pretty standard symfony (with some problem areas mostly due to poor oversight and rushjobs; not the framework). The laravel one required quite alot of restructuring to meet the requirements for speed of delivery whilst keeping clean code (try implementing Domain driven design in laravel;not fun). And oh yeah, you can probably guess, we replaced eloquent with doctrine.
This right here is a fantastic comment. This is very helpful, and mirrors some of my own thoughts.
Thank you kindly for taking the time to write this. I think this really tipped the scales for me toward Symfony.
😁👌
No framework can help lame developers from writing terrible code.
I've seen people without experience tricking Java & Spring. It was blood and sweat, but they did it :)
A Great saying.
Hi, to give a bit of background I have more than 15 years experience in PHP, started by doing small business website and hosting (pretty much what you are doing) and now developing full backend application that have millions of users. I also did a master's degree about PHP framework for startup.
That being said I'll make some assumption:
Base on that and reading the other comments here are some thoughts.
API Platform is not for you. If you are not building SPA/Mobile application that need a API there is no reason to use this.
Laravel have a history of bug, low quality, breaking backward compatibility and I agree that thy push wrong programming practices. They might have put a LTS for their version 6 but this is pretty new.
Never heard of ZendExpressive but heard of ZendFramework that it's based on, not a good track record either.
So to keep it for the last Symfony would be my recommendation. Learning curve is a bit hard but they have the track of building the best component/libraries (Laravel is base on Symfony component and probably a few tools mention bellow). It's impossible to not update your stack for 10 years, Symfony have probably the best track to be backward compatible, even some bundle (how to provide extension to the framework) from version 2 are still compatible with version 4 and most of the time they provide tools to upgrade their major release but for sure a good UPGRADE documentation. They are really transparent about the roadmap (LTS) symfony.com/roadmap
If you have a admin to build you could use those to bundle:
A more light one but will still cover most of you need
symfony.com/doc/current/bundles/Ea...
Or a more complex but flexible solution. They also have some CMS extension
symfony.com/doc/current/bundles/So...
If one of your customer project become bigger or want to have a mobile app (or progressive web app) with symfony you will be ready (there is plenty of bundle to do this event the API platform could be add later). There is also a HTTPCache layer that can be easily configure with file if you just have one server and don't have access to a cache proxy like Varnish (building your site thinking about how to cache it could increase drastically the response time going from hundreds of ms to less than 90 ms)
On a more long term point of you I would use Symfony and be really careful about which bundle you use. I encourage you to develop your own bundle (when you have specific needs) and release them open source and manage them via packagist so it will be easy to maintain. There is also a way to have a private package hosting solution if you don't want them to be open source. For the hosting part of your business I suggest you to find a great hosting solution (shared in your case) and open the your customer account on it, there is legal issue (ssl, data privacy security, etc) up time, etc. That you don't want to be responsible for. You are still the point of contact for your customers and charge for the application maintenance but it's a lot easier, the time you save on hosting issue can be put in finding other customers.
Thank you for your very helpful feedback! You're correct in your assumptions - most projects are small and low traffic. I do resell robust shared hosting to my clients with the whole suite of their needs (email, SSL, etc).
I too am leaning toward Symfony. I love that it starts as a microframework and can grow with my needs, and focuses on backward compatibility. :)
You're comparing Laravel 3 with Symfony 2. And telling symfony 2 is compatible with v4 is anything but true. Our team put ~ 100hrs (!) upgrading a medium sized symfony 3.3 project to v3.4.
The problem is that most of the comments here are based on random rants found on the net and vague, vague experience.
This Laravel encourages bad practice vs. symfony is the enterprise php framework mantra is super outdated in 2019 and is also very superficial.
Both systems are very mature, very similar and have their pros and cons. Not to mention that they're copying each other a lot.
There's no jolly joker. The less upgrades you want the more you should think about managed platforms. Do you really have to actually write code to solve your client's problems?
Why do you stick to php?
The requirements you define put you in a position where there's no right choice for you. And the more seasoned you become, the more you'll see.
I suggest to start the requirements from the client needs and not from your preferred tech stack.
I don't see the comparison of Laravel 3 with Symfony 2... Never said that everything in symfony 2 is compatible with 4 but on a lot of thing are backward compatible and dependent of the bundle it might be compatible (if composer requirement allow it). In any case if the bundle is not about modifying core behaviour or advance stuff they are pretty easy to update following the guideline that are normally provided.
I have put less effort to migrate a medium size project (we should define medium) from Symfony 3 to 4...
But yes I do fount that Laravel enforce bad practices, never check the version 6 maybe the "fix" this but this is more a design choice than anything else. I do agree that they do copy each other, the same way Symfony did copy concept from Spring framework in Java and that Doctrine is greatly inspired from Hybernate too (at least a while ago).
For the "stick with php" I would make the point of knowing a stack on the tips of your finger help a lot. Maybe if you have a "expert" in every stack you may be able to pick the best stack every time but most of the time the best choice is to pick the stack that you have the resource to with. Than it's just a question of being professional and being able to let potential client that the stack you know and use is not well suited for there needs and refer someone else. From what I understand of the use case he might be alone in the company, having a lot of different technology may not be a option.
And if you have only one project a rule of thumb is to put the lowest amount of different technology in it, it's easier to maintain, document and find new employee if you need too. I am not saying that we should do "standard" web site rendering html because we don't want to add Angular in you stack, but you don't want to have php, node js, python in your backend stack just because you could. The same way you should not try to force php in to do a socket server for a real time application (like a game) even if it's possible, it's not made for that.
What I wanted to point out is that we could solve many of the problems without writing a single line of code.
I've been struggling with developers (incl myself) to open their minds and take a fresh look at the requirements without opening the IDE first.
Programmers have an obsession to the code. We should write much less code. Static sites don't necessarily require code (wix, managed wp, etc). Data processing and visualization doesn't require code (AWS Glue, Athena, QuickSight). Many many webshops don't require code (shopify, hosted magento, woocommerce).
I was surprised at my current work how many brilliant things were solved without writing code. It just needed non-programmers in the room.
Back to Laravel: I've been working with Symfony since 2007 and used to say this Laravel bad practice mantra as well. The reason was I never did a single project with Laravel, just opened the Laravel doc saw some static calls, went to some random forums, read ppl ranting about it and called it a day. Then we were kinda forced into a Laravel project and after a few months I've realized I knew nothing about Laravel before.
And then when I saw the new features of Symfony 4 at SymfonyCon in 2017 I was nodding because quite a few were concepts existing in Laravel. Dotenv, FQCN as service name in the DI container, Interface binding to implementation, class name based injection, the updated folder structure just to name a few.
We should be much more pragmatic about our profession and be less obsessed with the choice of technology.
Yes you are right about using tools that are not related too coding. He does it by using wordpress (pantheon offer and self hosted solution) and it would be worth to expand those solution with the tools you mention. Having a few tools predetermined for some use case to pick from is a good idea and evaluate where the project will go and the plan if it need to grow is the way to go. I am personally only working on project that is worth using symfony it's more a "if you could do it with word press or shopify, (or something else) go for it since it's the best solution but this is not what I do/work on."
For the laravel point I have been force to work with Laravel (version 4.*) and mhy opinion didn't change. I do agree that Symfony did bring some feature from Laravel, I think they did it better, but we could look at it another way Angular2 was doing injection with FQCN detection on service, did they do it before Laravel ? (I honestly don't know and don't care really) my point is that everything is getting better (I do hope so) and it's hard to know who did it first but having some serious competition help to push things further.
Why would you want to call yourself a programmer if you don't even code, if you want to do content management / admin work, be a data input guy.
Is there something you didn't like about Slim? I'm a massive fan of this microframework because it is minimal and has a good history of sticking close to accepted community standards. Then again, it doesn't include much, so if you are looking for a framework with a lot of pre-built pieces to throw together, it would not be the right choice.
Slim 4 is on board with PSR-15 and seems like the right choice for a seemingly good DIY developer such as you have presented here with a brief description of your projects.
All three are good choices. Our team of two has been maintaining 9 NOT small Laravel applications ( thousands of lines of application code ) for years. I gotta say it checks off everything on your TLDR; list. Straightforward upgrades, no blockers to being on most recent PHP, fabulous stability, and maximum ease of development for everything from a two page site to a beefy Enterprise web app. Again you probably are in good shape with Slim or Symfony as well and ultimately I think you should go with the one that you have the most fun using but I think Laravel would be an excellent choice that will make your work easy for years to come.
Do you use Shift for your updates?
We do for side projects but for work we can't let stuff out of the network per company security policy so we do manual upgrades on all our projects and packages every year. Takes about a week for one of us, it's really not bad once you've done it once. His upgrade guides are very thorough and we've never had a problem that wasn't addressed by the community within 24hrs or so, usually some obscure function signature that got changed that's used by a very small portion of the total install base and we just happen to be one of them. Having robust test coverage saves us from deploying it if it's not working. Almost never an issue on small projects that are using basic Eloquent features. But Shift is great if you can use it.
See that's a big concern of mine. If each upgrade takes a week. If I have 6 projects, that's a month & a half for every release. Yikes.
Oh, sorry, no, that's 10 apps and 12 private packages all in a few days for all of them. The individual migrations are maybe an hour max. With Shift it's even faster.
Oh, thank god! LOL
That's really good to hear actually. Thank you for sharing your experience!
Both Laravel and Symfony are awesome frameworks with their pros and cons.
Laravel is very easy to get started and has a lot of functionality ready for you.
This does not mean that Symfony is harder but it needs more work and initial configuration.
Having said that I would choose Symfony for 3 main reasons:
What I don't like in Laravel is the fact that you can access everything (container, request, session etc.) anywhere in the application code just by using Facades and helper functions. This will lead to poor and difficult to maintain code in my opinion.
In the end I would advise to study both frameworks. They have many similarities and you never know when that knowledge will come handy.
P.S.: To learn Symfony I highly recommend symfonycasts.com tutorials. Ryan Weaver is an awesome teacher and he is the lead for Symfony documentation.
Doctrine is a huge + for Symfony.
I would recommend laravel :
Thanks for your comment. Though to be honest, Laravel's instability is the root cause of my dilemma, or I would have jumped on Laravel without hesitation. I recently learned Laravel and created a college course on it - so I'd choose it if I could. But I get the impression that backward breaking changes are a frequent part of Laravel's updates. And things are changed and removed on a whim.
I hear that v6 is going to start using SemVer. Which is nice... but Taylor has expressed that this won't slow down the pace or style of updates for Laravel - so I suspect the major version number will jump up frequently which doesn't really solve the problem.
I think it's great that Laravel is going through this rapid evolution. I'm sure this is leading Laravel quickly to a really awesome state (it's already awesome), and if I had only one giant project to focus on I'd choose Laravel in a heartbeat. But since will potentially have many, many projects on the framework I choose, I can't be going through BC breaking updates so frequently.
LTS versions for laravel are supported for 2-3 years (bugs-security)
Symfony has 3-4 years of updates on their LTS versions
symfony.com/roadmap
Personally I use laravel (4.2 + 5.5) and never had problems with backwards incompatibility.
Upgrade paths are clearly documented, and there are also free and payed upgrade tools available.
If backward compatibility is that important, go for laravel LTS, which is either 5.5 or 6.0... That should settle your mind a bit...
I am have maintained a legacy Laravel based solution (5.5), looking to start a green field project with Laravel 6, had a Symfony 4.1 solution and lost on which framework to use for a side project that I have been putting off for too long.
My heart is with API Platform (based on Symfony), but Laravel currently seems to be doing all the right things with developer experiences simplifying usages.
You are not crazy to leverage frameworks, because the more years you work with tech, the less code you want to write (since you will need to test, maintain and evolve it), as you get slower and have more responsibilities
The maintenance fees approach vary:
API Platform (based on Symfony) is the best thing that happened to me this year. I would be putting up a post with my experience on it soon 😎
Working with API platform on a real project was really painful for us. We got rid of it completely in the latest version of our api. (Still running on the previous version).
What were the blockers that you faced? How did it not fulfil your needs? I am keen to learn as I keep an eye on it for a future API driven project
Oh I was never going to write what a framework does myself. Rather, just use a few stable packages for the small stuff.
I did the build my own framework thing 10 years ago. It's still in use. All this research is me moving away from the internal framework. :D
Great tips!
Shameless advertisement, but if you like slim but you're prefer something smaller (Lines of Code) and less complex (Cyclomatic Complexity), please take a look at github.com/chubbyphp/chubbyphp-fra...
PS: Go for a microframework expressive, slim or mine (PSR7, PSR15 based). Not only are they easier to understand, but thanks their not event driven, easier to debug.
I'm (actually) a fan of Rails, so if I translate that to the PHP world then that would be Laravel, which is indeed what I tend to use when I need to use PHP. However, I'm mostly building "applications" meaning that I definitely benefit from what Rails or Laravel have to offer.
Now, first thing that came to my mind as a was reading your post is "Laravel is probably overkill for 90% of the author's projects". But then at the end of your post I was reading "Ok to have one option for small stuff and one for big projects". So that made me think "Laravel" again.
(or did you actually mean two different options, one for small site and one for bigger sites?
In that case, for the small/simple website - why not forego PHP completely and go with a static site generator, Gatsby or Jekyll or Nextjs or whatever, and Github pages or Netlify instead?)
Anyway ... do most of your projects (even the simple ones) use a database (and for instance login)? If so then I'd say don't worry about 'Laravel is overkill'. If you have php 7.2 or higher installed, and you type this in your terminal:
then 30 seconds later you'll have created a simple and lightweight website called "blog". Next run the following command:
and you can view your site in the browser, a simple page with some links (instead of
php artisan serveyou can of course just use Apache or Nginx instead).Now, the app as just generated comes with authentication and database connectivity, however if you view your newly generated app (see above), then it will actually not hit the database or show a login screen. So it just works without a database, until you try to activate the authentication functionality.
As for the size of the generated app, most of it is in the "vendor" directory which is around 62MB. However, in production you can cut this in half (32MB) by running:
So that's going down to 32MB on the server (most of which would not be loaded or executed at all, and none of which would be downloaded by a user) - not a lot of overhead for your 'simple' site, and the good thing is that:
if ever your simple site needs to grow and become more complicated, Laravel has you covered, and for the smaller site it arguably doesn't get in your way
you get to utilize your Laravel experience for both the smaller and the bigger projects - call it leverage
One critical note:
I was referring to Ruby on Rails in the beginning. While it's undeniable that Laravel was inspired by Rails, I always get the feeling that Rails keeps it just a bit more simple and lightweight (call it elegant).
When I write Rails code I can do it pretty intuitively, with Laravel however I more often wonder "isn't this more complicated than it needs to be". But maybe that's just me, or it's the syntax of PHP which is more convoluted than Ruby.
By the way, I don't have experience with Symfony. I've read articles explaining that Symfony promotes "better architecture" than Laravel, however I believe Laravel is a bit simpler and easier to get stuff done. Symfony might be beneficial when you need to build really big and complex stuff.
Do you really need a framework? You have one in WordPress. 180+million installs does have some weight. I use WP+PHP for my work and rarely do I miss anything "frameworky" that WP doesn't offer.
If you absolutely positively need a framework on top of WP just take one of the big ones - it really doesn't matter at all. Cake, Symfony, Laravel. Pick one. Laravel is basically Symfony in better looks, Cake has its own thing going but is a veteran and very well put together.
Good luck and welcome to the choice effect. :-)
I may be a little late to the game, but...full disclosure I have about 20 years experience with PHP, I've used Cake (large oil & gas company and large computer manufacturer), CodeIgniter (also at o&g company), and for the past 4-ish years Symfony (3.x) for a smaller HR company (we're now migrating to 4.x and it's pretty painless). None of what I've developed would equate to a small site with little traffic. We're (small dev team) tasked with keeping things current/up to date and Symfony has been the easiest to update relative to the other frameworks (very few bc breaks). With the built in debugger, extensive logging, and well written framework error messages, pinpointing a problem is much easier in Symfony than the other frameworks though that may have changed over time.
It's completely possible to wire your ORM or heavy business logic into a Twig template if you work at it in Symfony - but you shouldn't. Symfony doesn't so much enforce good coding as it encourages it. You can bloat up your controllers with business logic, forms, and all sorts of junk or you can spin your business logic off into services, put your queries in reusable libraries, write a mess of reusable twig filters, and get your controllers down to a scant dozen or so lines of code.
I only have about 2 months of experience with Laravel - just long enough to know it's just too tempting for me to wire things incorrectly "just to test something out". I know I'd be coming back in 6 months to try to fix that little shortcut and it would be pinned in place by 20 other things that grew off of it in the meantime. Laravel to me seemed like it would be a great framework to knock together a quick prototype/proof of concept.
My vote would obviously be for Symfony - it's not really a beast to set up, you can spin up a default Symfony project in a minute or two with composer. In a few more minutes you can have a workable prototype - a few views and matching controllers, some queries/repositories/tables using Doctrine. Symfony 4 with Flex is really nice. I imagine you could say most frameworks are overkill if you're doing simple websites but I'd still use Symfony - if the site starts to grow you've got the ability to bolt on all sorts of stuff, if not, you're good where you are. Look into the Symfony LTS versions - read up on their release processes, backwards compatibility promise, how frequently they release, etc. symfony.com/doc/current/contributi...
Good luck with the decision if you haven't already made one.
Thank you. This was a very nicely detailed reply. And very much in line with the conclusion I came to as well.
Symfony 4 I think is good choice now, it's getting simple and faster, thanks to PHP 7.x as well.
I have old legacy PHP web that use no framework, but after I using Symfony, I try create my own framework by using some key components from Symfony, what is that? The Twig templating system and the routing component, plus composer ready, the rest code is my own PHP way, even still use mysqli_* functions hahah. Search on GitHub called Brutal PHP Framework but it still work in progress but maybe you can get the idea.
Maybe you can use some PSR standard components and use it in something like a non framework approach. So that you are not vendor logged-in into a special framework.
github.com/PatrickLouys/no-framewo...
I've never used Symfony so I can't speak to that. But having written sites in PHP from scratch, with Laravel, with Angular + Laravel + Lumen, I've never been happier since switching to Node.
As far as longevity, the Angular + Laravel + Lumen app has been in production for years and it's not terrible to maintain from a code perspective, but any deviation from the norm was a headache. I can throw some pointers your way if you decide to go that route.
The tooling 5 years ago also isn't what it is now and if I started today it may be easier.
But I just enjoy the experience so much more in the JS / TypeScript ecosystem. Pick the level of abstraction you want and go from there. I only touch PHP today because I have to maintain things.
I was in the same boat as yourself. I've used my own MVC Framework but after a while, I felt it would be best to start relying on a more robust solution.
I compared Laravel and Symfony, and ultimately ended up using Symfony. Laravel's interpretation of semver, scares the hell out of me. I built an app based on Symfony 4.3 a while back and have recently upgraded it to Symfony 5 without a hitch. The whole process took a matter of minutes. Granted the app was not that sophisticated. I was also fortunate that some 3pl bundles I was using were updated within a few days of Symfony 5's release...
I'd recommend giving Symfony strong consideration.
Thanks geeShoe
Thanks! I very much agree with you.
It's funny that Laravel moved to SemVer recently, but that just means all their packages are getting a major version bump almost every update. I also heard that even core packages that weren't changed are getting the version bump to keep them all at the same version num. Strange.
I want stability. At least save up the BC breaks & pack them all together in a major release less often. It feels like they still don't get the point.
Which sucks because I want to use Laravel. It's beautiful & the ecosystem is great.
Hey, I work at a small dev agency and we primarily switch between 2 PHP technologies depending on the requirements. These tend to boil down to how large the project is and how much editing the client will do.
We will use laravel for a bigger web application, where the client won't be doing much editing. Obviously laravel is not a one click upgrade but if you use pick a LTS version to build on (6 has just been released) then it'll be supported for a few years with security patches and bug fixes.
The other route we go down is Craft CMS. We use this when a great authoring experience is key and there's lots of client editing. Think if it as a pretty version of WordPress that is built on a stable PHP framework, Yii. This makes it easy to extend as your client requirements grow, it has a one click upgrade and is extremely developer focused. It also has the benefit of only needing to maintain one system, not a separate PHP application and a WordPress installation
Check it out! Hope this helps.
I really don't think you can go wrong with Laravel. 6 just released and is a LTS version meaning you don't need to worry about support going away anytime soon. Laravel also has a great toolset for managing your site through forge or the soon to be released vapor.
While you may not need every feature it supports out the box, you do have some added comfort that it can support almost any type of project and grow with you.
I recently transitioned my Linux webapp from Laravel MySQL and Apache with angular frontend as separate app to .net core MySQL and Apache with angular as separate app. Coding with .netcore and Angular 8 in vs code is really awesome and it's all open source and can run on linux
Have you considered using Drupal 8?
I manage a lot of WordPress and Drupal sites in my job and I have a similar experience to your own. Many of the sites I work with started off small, but later grow into something much larger. In my experience WordPress is not good at adapting to this sort of growth without using lots of badly built and vulnerable plugins. Drupal 8 on the other hand is actually based on Symfony and while it has a steeper learning curve it really encourages good code which helps with maintenance over time. It also has a dedicated security team that regularly review plugins (modules in the Drupal world). You should give Drupal 8 a shot.
"I'm also considering sticking a few stable Composer packages together for a light version of a 'framework' that will cover all but my few large projects."
This. Have favorite packages for different things and use only as many as you need for a project. /2cents
Yes! I also thought that if I favour Symfony components... I'm half way there if I ever need to jump to full Symfony.
Have you tried some cms systems that also work well as frameworks like processwire or silverstripe.
Especially proccesswire might be a good fit since they seem to really care about backwards compatibility and you write basic php code for most things.
I'm seeing some posts here about rolling your own framework, I'd like to advise against this for something that holds your client's personal data.
Have you thought of all the security implications of what your doing? Well you can be pretty sure that the developers of Symfony, Laravel, etc. have and are continuously testing their code for vulnerabilities. I'm also seeing posts about frameworks being slow, what's the scale of these web sites? If its not something humongous I don't think performance should stop you from using a framework...
I'm not saying that rolling your own framework isn't fun or a good learning experience, I'm just saying it's a lot of work to cover all the bases.
I have zero intention on rolling my own framework. That was my situation prior to this, and my research today is on replacing my internal framework.
Closest I would get is assembling some solid 3rd party packages for small projects.
Okay that's what I thought, I was more saying that for others who may be tempted to roll their own.
Here's my argument for Laravel:
You're wrong about backwards compatibility. Laravel has been very stable for years. There have been very few upgrades over the past 5 years or so that I've done that have taken me more than an hour to do. It's in their interest to keep breaking changes to a minimum. At this point, given that you've said you won't use most of what it has to offer, I wouldn't stress over these BC breaks when they come as they likely won't affect you.
It doesn't break backward compatibility on a whim, it has shifted to adhere more closely to SemVer and has a regular and predictable release cycle for major versions and support lifetime.
It's extremely well documented You say you've spent some time with it already, so I'd say you're already a few steps ahead there. You'll know the docs are very approachable and there are lots of other learning materials within the ecosystem. I've not found better elsewhere yet.
It will grow with your needs. Laravel has almost everything you're likely to need ready for you out of the box. If it's not part of the core, it's often available as a first-party package or a third-party package developed by a reputable dev house with years of experience.
Use only what you need and don't worry about cutting stuff out that you don't need. PHP has become very good at keeping your app performant when there's a load of code you have but don't use. Unless you've got a really good reason to only ship hot code paths, don't worry about this at all.
It's a known quantity
While you may not use most of it, whatever you do need is there and well understood and for the most part, well covered by first-party packages. You won't be struggling learning some new set of dependencies or making trade-off decisions between multiple possible options and then figuring how to plug those in to your application reliably every time you realise that your standard setup is missing something that you now need.
You won't even get this with Symfony, which is generally un-opinionated about this sort of thing. Caveat emptor: my experience here is with a company running multiple large Symfony apps that they are essentially afraid to upgrade because of how custom their structure is. I haven't actually tried to do the upgrade.
If you keep your app structure aligned with how Laravel does things, then you'll benefit in multiple ways:
To answer some of your final questions, I have spent the past ~10 years building and maintaining applications on Laravel. I've built everything on it. And I've loved every minute.
By contrast, when I've worked with Symfony, I've felt a lot of pain - the docs need a lot of work and the way some folks have built on top of it is just plain crazy. The fact that it's so un-opinionated has led to a wild variety of styles of doing things, which is fine, but it does make things trickier.
This is only anecdotal, so take it with a pinch of salt.
As for how I handle upgrades for my clients, I explicitly tell them this is a part of my work and I will take time out from their monthly retainer to keep things up to date, that it's necessary for their safety and security and that it improves my efficiency.
This ends up being just a few minutes worth of work each week (
composer update) and then I know that in Q1 each year I'll likely need a bit more time for the next major release - I currently budget for about 2 hours from start to finish, just to give myself some headroom.I refuse to work solely on feature work and bug fixes at the expense of upgrades. The further behind you let those upgrades slip, the worse it becomes.
Totally fair.
Though this decision was made long ago & I'm all-in with Symfony. Though I do touch a Laravel app from time to time.
Start with the domain,have conversation and learn about the domain, take a look at architecture,try to decouple your domain from infrastructure/framework or if you go cqrs/es understand libraries or framework that facilitate that. The frameworks are good for things that everybody does like cruds or helping you with some infrastructure like database or http, but won't help you with your domain,only learning and storming ideas(together with clients/domain experts) will do. Frameworks may help you cook something fast but won't help when customization will come into your way if of course you are coupled with the framework.
learn.userfrosting.com/
demo.userfrosting.com/
Userfrosting's good if you need built in user & permission management as a starting point
Hello, I'm the CTO of a small software development company with 35 people. We use PHP for most of our solutions. Framework of our choice is Laravel, we use it since Laravel version 3, at very early stages. We also tried Symfony for a few large scale projects, but probably we will never use it again.
Unlike Symfony, Laravel gives you all the stuff that you will most likely need. Saves your hundreds of hours in a long run. It has many built-in solutions like Queue, Filesystem etc. Eloquent has awesome built in solutions for eager-loading, polymorphic relations etc. The best part is that every developer don't need to learn every single project's structure and features, because its all same for all Laravel projects. When a new developer opens any project, he only needs to learn the business logic and the architecture, then he is ready. He knows how the things are working and he can immediately start developing.
Laravel is very well documented, and also very easy to understand.
Btw, stop about thinking developing your own framework or using spaghetti PHP. Every junior falls the same mistake. After using a real framework, you will never look back, and will laugh when someone says "Hey I developed my own framework".
Not planning for a second to roll my own framework again. No way.
Straight up fark php!!
Fark docker!!
Fark k8s!!
I have developed with both laravel and symfony (which is the best)
Choose a cloud provider and build server less. I choose AWS
Cognito user pools
Amplify
Appsync (graphql)
Dynamodb
Lambda functions
Greengrass
IoTAnalytics
Sagemaker
S3
Quicksight
Build this with a framework.... Hahahaha I'll see you in 2080, at which time you'll be dead or uploaded to the cloud
If upgradability is your main concern, I can recommend Flow, the Framework especially developed for Neos.
They have a strong focus on maintainability and upgradability and provide migrations which can even upgrade your custom code.
Laravel.... or feel the Python love and try Django
I go for laravel nowadays... more and more people look for laravel developers on indeed, linkedin, upwork, freelancer etc.
Well, my awnser would be this: dev.to/phpandcigars/why-i-choosed-...
Did you ever tried Yii2 PHP framework ?
Nope, not yet!
You owe it to yourself to give Craft CMS a try, which is built on Yii2. Coming from WP experience Craft will make you feel like you can finally breathe. And when you get into extending it with custom modules or plugins, it's mostly been a joy for me. The only projects I haven't converted to it are either too small to deserve a framework or too specialized to use someone else's.
Finally some yii2 love.
We have an in-house CMS pretty much like craft, tailored for our needs which include: deploy using deployer.org, docker for local development and some configurations magic for SEO/routing - my point is, yii2 is really good, fast and reliable. Give it a try OP
It might be interesting to look at the new version of CodeIgniter which has just launched the first Release Candidate for version 4 of the framework.
It's been extensively reworked and has been brought up to date in terms of modern PHP practices. It's still has a small footprint and great performance. It's flexible and not opinionated about the best way to do things. Documentation Here.
Symfony is great choice. I'm personally prefer ZendExpressive - it's great, fully PSR compatible microframework, but it is not best choice for "small and maybe growing" projects.
I've maintained many Laravel-based applications over the years from v3 to ~v5.5
Based on my experience and your priorities, I would recommend Symfony.
I'm very happy with laravel. I like some concepts they provide for developing manageable applications.
If you don't like all the extra stuff that Laravel provides, you should check out Lumen maybe!
If you mostly just build basic websites, why do you need an MVC framework? Why not just build with Wordpress?
I do use WP for projects that fit the CMS mould. And that's a large chunk of my customers. Though I have no interest in working in the WP ecosystem writing custom plugins and features, for reasons. ;)
So custom projects are on an MVC framework.
Why don't you use WordPress as a decoupled combo? It's perfect for small-mid sized businesses.
I do use WP for projects that fit the CMS mould. And that's a large chunk of my customers. Though I have no interest in working in the WP ecosystem writing custom plugins and features, for reasons. ;)
So custom projects are on an MVC framework.
The biggest problem I see is not Laravel vs. Symfony. You want 10 years of backwards and 10 years of forward compatibility. Do you really want to use the same thing for 20 years?
I don't want that at all.
Hey you can have a look at codeigniter, 3 is a bit old nit they are on the verge of releasing a new version, think rc1 just got public
I have one project on an old version of Codeigniter. It was my first use of a 3rd party framework & I recall it being a nice experience. I also love the name!
But I'm not confident enough in Codeigniter's longterm outlook to really consider it.
Laravel over Symfony