Which Framework?

[designermonkey]

The question has again arisen as to which framework we should use to build Next.

Most votes are with Laravel, some are with Symfony.

[ijy]

From a working perspective I don't think it's anywhere near as much of an issue as it used to be since the introduction of Composer and PSR-0. You can mix and match any components you like so you're not really stuck with one stack anymore. As long as any framework suggestions have Composer and PSR-0 compliance then essentially it's an open deck.

However in terms of aligning with business objectives if one of the aims is to increase adoption of Symphony as a CMS then it would make sense to use a framework which is a little more user friendly and is attracting a lot of people in. In Laravel you have a fast growing and passionate community with conferences now taking place, books being written, the likes of Nettuts and a slew of others promoting the framework and providing easily digestible introductions to getting started. If Symphony provided the CMS and a powerful UI on top with Laravel underneath it's a powerful pairing of the two communities which would attract many both now and in the future. I think it's less of a barrier to entry and more of a marketing push than Symfony 2 (even though it can contain a large number of Symfony components). You get the best of both worlds.

Let's not forget that Laravel also provides a layer of abstraction that is meant to mean less code to get things done and some very powerful and elegant tools. With version 4 it's now reach a point of maturity and stability so it's a good point to jump on board.

I guess at this stage a better question would be why would Laravel not fit the bill?

[ijy]

Maybe it's a good idea to also create a list of business objectives for Symphony Next with priorities so any decisions can be made with those very much in mind.

[designermonkey]

Maybe it's a good idea to also create a list of business objectives for Symphony Next with priorities so any decisions can be made with those very much in mind.

Allen, Brendan and myself will be having a conference call very soon to discuss that.

After looking at Laravel a little, I really like it; As a replacement for something like Codeigniter. But to me it is a framework for building a site, not building a CMS to build a site, does that make any sense to anyone?

[DavidOliver]

If Symphony provided the CMS and a powerful UI on top with Laravel underneath it's a powerful pairing of the two communities which would attract many both now and in the future.

I think for this to be true in a meaningful way, Symphony would need to be addable to Laravel projects - not something which developers have to choose instead of Laravel. Personally, I would also like to be able to start a Laravel/Symphony project, use Symphony for the content management parts and do whatever else I want in Laravel without having to deal with a different file structure, etc. I would like Laravel and Symphony to work together to maintain the best of both at all times. In other words, I'm thinking that Symphony should follow as many Laravel conventions as possible to gain the most benefit of using that framework.

But if it's decided that Symphony is going to go its own way and be an application in itself that doesn't really allow developers to extend the underlying framework as they normally would (which is how I (mistakenly?) interpret @designermonkey's proposals), my impression is that Symfony might be a better fit.

Do my concerns make sense technically or am I talking rubbish?

[bpierre]

My vote is for Symfony components (not the full framework), and more generally PHP components. I think that the glue / structure provided by Laravel, Symfony (full) or Silex is more or less exactly what we want to change in order to implement the Symphony requirements.

My comment from #9:

I think that Symphony CMS could provide its own structure (and opinion) on top of PHP / Symfony components, as Laravel and Silex does. I don’t see Symphony as a final application (which is, I think, the target of these frameworks), but more like a CMS / framework hybrid.

What Silex and Laravel are providing is mostly a glue between PHP components and a “way to do things”, which is handy for quickly building a website, but not so much for building a CMS / framework with a lot of special requirements. If we have to get around a lot of things because building an easy to install CMS (for example) is not targeted by the authors of the framework, maybe it is not the right tool for the job.

The good news is that with PSR-0 and Composer, almost every component used by Silex and Laravel can be used separately, without having to use the whole framework (but Laravel 4 is still in active development, and every module − including Eloquent − is physically in the same repository for the moment).

That being said, I really like Laravel, I just finished a project based on Laravel 4 (I chose it over… Symphony CMS!), and I find the framework clean, understandable and easy to use (reading the code helps a lot, the code has moved fast while I developed on top of it the last 4 months, and the documentation is a bit behind).

I think Laravel 4 can technically be used for Symphony Next, but maybe not at its full potential because of the Symphony specificities: plugins, easy install, Symphony workspace, XSLT, updates without composer, etc.

I think we should list here the Symphony requirements which are likely to be hard to implement with a end-user framework (e.g. plugins).

[bpierre]

@designermonkey

But to me it is a framework for building a site, not building a CMS to build a site, does that make any sense to anyone?

Totally makes sense to me, this is my main concern. In a way, Symphony could be considered like a framework, in a sense that it has its own way to do things (e.g. workspaces, plugins, installation, XML, XSLT), and we use it to build websites.

@DavidOliver agree, Symphony could be a Laravel package, which will be the “Laravel way” and be really powerful for Laravel users, but it seems like a huge change in the Symphony direction.

[ijy]

These things all seem to blend in together and cross conversation threads :) but if the reason to not use a framework goes to the need to break conventional application structure, which goes back to a potential minority in the limitations of some shared hosting environments then I don't really agree that's worth breaking structure for. The technical limitations will no doubt be less of a problem in a year/18 months then they are now.

[DavidOliver]

[...] then I don't really agree that's worth breaking structure for. The technical limitations will no doubt be less of a problem in a year/18 months then they are now.

I think that's an excellent point. PHP hosting as a whole is improving and moving more into line with what other scripting languages have taken for granted.

But I don't think hosting is the only reason a complete file structure change was proposed. I understand it to be more a conceptual thing...

[iwyg]

So, the actual question is weather Symphony want's to be a monolithic CMF as it is now or more like a sophisticated admin bundle on top of an already opinionated application framework such as Laravel or Silex.

At this point I'm not sure what would be the greater benefit for symphony's popularity, but in the end it really comes down to what Symphony's business objectives are going to be. And once these things are sorted out we may discuss which tools are right for the job. So in my opinion the ongoing discussion here might be a bit premature.

But to throw in another two cents of mine: I think Laravel is a great tool for building (enduser) applications as it is opinionated and gives you a quick start and requires almost no boilerplate to kick of your projects, but it's less suited to build another framework on top of it.

[lewiswharf]

So, the actual question is weather Symphony want's to be a monolithic CMF as it is now or more like a sophisticated admin bundle on top of an already opinionated application framework such as Laravel or Silex.

I believe this is the unanswered question plaguing/diluting all discussions revolving around Symphony Next.

[designermonkey]

I agree. I have my opinion, but until it is discussed with the project leads and owner, I can't dictate it.

I think this will come down to a decision from @allen, and maybe even a vote from the working group. @allen, @brendo and I will be formalising the working group by way of official announcement, and sorting access rights, assigning roles etc, so when this happens, it may end up as a vote, we shall wait until @allen says.

[ijy]

My bet is that it's a complete rewrite in Ada. Do we have any takers on Haskell at 13/1 ?? ;)

Using Symfony components makes sense and it's fast becoming the Standard building blocks in the PHP world with Drupal even making a dramatic switch to use quite a few components in version 8 (Twig too). It would set a higher barrier to entry in terms of attracting others in than using Laravel.

But to me it is a framework for building a site, not building a CMS to build a site, does that make any sense to anyone?

I think I know where you're coming from but I don't think it's limited to a specific type of build. I know that the popular PyroCMS is being completely rewritten in Laravel and that decision wouldn't have been taken lightly or if the capabilities of the framework weren't there:

You may not be the only person on your team. For example, by using Laravel 4 for PyroCMS the barrier to entry for contributors and developers is much lower than if I just decided to use Symfony2 because I know how it works. See the difference?

It's all good though so I'm sure it'll kick-ass either way.

[allen]

I'll have a deeper discussion with Brendan and John when we have our call. Maybe we should even record it? Well, as long as people in the chat don't get all weird and self conscious.

I'll say this for now:

Symphony to me has never focused a great deal of time practicing the art of framework-making. It's evident in Symphony 2 that outside of our early architectural design, the demand and features for Symphony quickly and vastly outgrew what we had designed for the core. We tried to solve the provlem with S3, but let's leave that beaten horse to rest.

Symphony to me is not fundamentally a monolithic CMF, we don't bring enough innovation to the table to really warrant that title. Leveraging what many others have already done (ACL, versioning, DB abstraction, etc.) to achieve what we actually have a lot to say about, though, is certainly something we should do.

To that end, what we do bring to the table is: we have a way of doing things in Symphony. Our approach to CMS is through a very specific workflow that is unique to us; and that is what we need to keep.

[allen]

Do we have any takers on Haskell at 13/1 ?? ;)

I'm game! Haskell to this date is still my favourite language.

[iwyg]

I'd opt for brainfuck

[michael-e]

I hear that Haskell is pretty cool. :-)

[iwyg]

lolcode anyone?

[designermonkey]

OH GOD.

[iwyg]

KTHXBYE

[s-e]

Befunge. That is all.

 12345
 ^?^
> ? ?^
 v?v
v6789>

[lewiswharf]

Well said Allen and I like your thinking; except for that part about Haskell... where's the Doctor when I need him!

[designermonkey]

PS, don't get me wrong about all this, I really like Laravel. Really. I just want the best for the project, but I think the majority is leaning toward Laravel, and we should go that way then.

[jensscherbl]

Little late to the discussion, mostly agree so far.

I think Laravel is a great tool for building (enduser) applications as it is opinionated and gives you a quick start and requires almost no boilerplate to kick of your projects, but it's less suited to build another framework on top of it.

Why build yet another framework on top of another framework? Let's just build a really good, flexible and easily extendable content management application.

[bpierre]

If Laravel 4 is going to be used, I have some questions that I think will be useful to make some decisions about the architecture, since I am familiar with both solutions.

• Will the Symphony update system rely on Composer and Laravel migrations?
• How are the Laravel migrations going to be used? By the Symphony app itself, or by the final user? Maybe both?
• How Symphony Next plugins are going to work? Are they Composer modules? Are we going to edit the composer.json file, and add plugins alongside the modules already used by Symphony? If so, what happens if Symphony need to update the composer.json file?
• Will the Symphony Next Plugin API use the Laravel events system?
• Will Symphony Next keep compatibility with the Laravel template system?

I can’t see any point explaining how the sugar added by the Laravel end-user framework could be useful for Symphony (except the hype that Laravel is currently receiving in the PHP world). I think it will need some serious hacks to make it work with Symphony (and new hacks with every Laravel update), and I guess some features won’t be used at all (e.g. Laravel templates and helpers).

Laravel 4 is:

• An app (laravel/laravel), which provides an end-user framework for building apps.
• A “low-level” framework (laravel/framework), which is basically a monolithic collection of classes (I hope it will be decoupled in small Composer modules soon).

It is just my opinion and I can be wrong, but I think that Symphony Next should use the laravel/framework (and any other useful Composer module), and build its own structure around it, instead of trying to fit in the end-user app, laravel/laravel. laravel/laravel could be a base or an inspiration, but Symphony should not be built on top of it.

[iwyg]

I hope it will be decoupled in small Composer modules soon

it is and was from the beginning, see here

[bpierre]

Oh right, thanks!

[ijy]

It does get confusing. I'm sure more light will be shed on the Illuminate, laravel/laravel, and laravel/framework relationship come May 28th (Official launch).

[brendo]

It does get confusing. I'm sure more light will be shed on the Illuminate, laravel/laravel, and laravel/framework relationship come May 28th (Official launch).

Illuminate is the collection of components that make up laravel/framework. laravel/laravel is the application built on top of the framework for developers to use. I anticipate that laravel/laravel is targeted to developers building an application (website). laravel/framework is targeted to others building new application for developers to use (such as a CMS/API etc) and Illuminate is another level, allowing developers to pick up components that they don't want to write and drop them into their own framework (what Laravel did with reusing symfony components). Perhaps @taylorotwell can clarify :)

It is just my opinion and I can be wrong, but I think that Symphony Next should use the laravel/framework (and any other useful Composer module), and build its own structure around it, instead of trying to fit in the end-user app, laravel/laravel. laravel/laravel could be a base or an inspiration, but Symphony should not be built on top of it.

Correct, we'll build on laravel/framework. This allows us to use the components while dictating our own style and not stepping on laravel's toes. We may even be able to take a step back and pick and choose Illuminate components instead of starting with the full laravel/framework stack.

I believe this is the right mix of allowing extension developers/website developers to be able to reuse their existing Laravel knowledge, but also giving us flexibility to add in Symphony concepts (such as /workspace). Laravel has some great ideas for inspiration too, I particularly like the configuration overriding/environment management.

[ijy]

I just wasn't sure if Illuminate was going to be rescinded once Laravel 4 was officially released and where it effectively merges into laravel/framework. But yes, that all makes sense now and I completely agree. :)

Perhaps @taylorotwell can clarify :)

Incidentally, and somewhat off-topic but just to mention it, he'll be at Peers Conf next month along with the best of the best in the PHP framework and CMS world. It's mainly a friendly conf with EE, Craft, Statamic, and Laravel chats and breakout coding sessions and workshops included. It could be a great time to ask questions directly, get advice from those who know better, and learn from other ideas. There will be lots of Laravel fans there and Taylor himself will no doubt be very hands on. In terms of promotion Symphony fits in perfectly with EE and Craft in it's resource description approach (sections, custom fields, custom URI schemas etc). I was at EEUK last week and mentioned Symphony to a lot of the EE guys. No one had ever heard of it but all wondered why and wished they had before. Some of them are giving Symphony a try now. I'll ask Jess (organiser) if she has any spots left on the speaking roster if anyone's up for spreading the Symphony word whilst there? Sometimes a little cross-pollination can be a good thing in gleaming ideas, getting advice, and a little publicity. Being an open source CMS among commercial offerings Symphony would no doubt pick up a lot of interest in it's current offering and keen developers to help out with it's Next offering.

[designermonkey]

@ijy I'm really happy to hear you've done that, that makes me very happy indeed. It's good to hear that people are out there spreading the word. It would be good to know if some of our American colleagues would be up for talking to people about this stuff too.

[brendo]

I wonder, who's close to the ground in Chicago? @bauhouse probably?

[ijy]

No problem at all. It's just surprising that so many developers haven't heard of it before but when they do their reactions are all the same. There are sessions like "Build a website with Craft", and "Dive in Laravel" so something like "Build a website with Symphony" would give people enough to get their attention and open up many discussions in the social breaks when the beers start flowing. :) I'll be there but I'm not sure I know anywhere near enough about Symphony to be able to do it justice or be prepared for all kinds of Q&A. Just an idea but Symphony would more than hold it's own in such company.

[designermonkey]

More likely @lewiswharf as he's on that side of the country.

[lewiswharf]

@designermonkey

I'll ask Jess (organiser) if she has any spots left on the speaking roster if anyone's up for spreading the Symphony word whilst there?

Very bad timing, otherwise I'd be on this like XSLT on XML.

[ijy]

I'll have a deeper discussion with Brendan and John when we have our call. Maybe we should even record it?

Has the conversation taken place yet with @allen @designermonkey @brendo etc? Was it recorded? It could be good to hear the thinking behind decisions and you'll probably cover a lot more ground than text based conversations. What's the latest with Symphony Next as a whole now after a few months of brainstorming various issues? Have any decisions been made?

[designermonkey]

There has been no call yet I'm afraid and I'm not too sure of the status either. I've been having a bit of a play to learn Laravel, as has @nils-werner and @iwyg, and I think that may be all that is happening at present, learning I mean.

We will have to see what @allen and @brendo think.

[ijy]

I'm with you on the learning. All part of the fun. :) It's probably a good idea to keep the momentum up and turning some of the debate into suggestions at least so they can refined a little more. Maybe converting ideas in these threads to a Trello board where it makes things a little more visual and easy to digest. Ideas can be voted on things can be seen to move through a decision making process in modern kanban style. Either way I'd be interested to know what the thoughts are at this stage.

[designermonkey]

So after a lot of debate, and a seemingly dead thread, I have done research into which framework we should be using.

Laravel is too heavy in it's packaged app form. End of.

We need a lightweight framework to add what we actually need to it, and yes, we need some of Laravel's awesome, there's no doubting that.

I have been playing with Slim Framework, as it is by it's own name, slim. It just does the basics. Coupled with Pimple for an IoC container (or wait for the next release where it is baked in) and Eloquent for database, we have a very lightweight starting point for our needs.

I want everyone who is still interested to list what they like in Laravel, and we can look at the packages that provide it.

[designermonkey]

Just to add, the codebase isn't really the sticking point here, as I always say: Anything is possible, with time and money (more time for OSS), but we need to plan what we want and what we need.

[nilshoerrmann]

Laravel is too heavy in it's packaged app form. End of. […] I have been playing with Slim Framework, as it is by it's own name, slim. It just does the basics.

I'm not a programmer, but I've been looking at Slim as well and I think you are just right, John.

[ijy]

I LOVE Slim. But it is just a Sinatra style routing framework where routing is it's only concern.

The Slim Micro Framework for PHP 5 is a micro framework that enables developers to quickly write RESTful web applications and APIs. I emphasize micro because Slim is just that — a lightweight and nimble PHP framework used to build smaller web applications and APIs. Unlike CodeIgniter and Symfony (excellent frameworks created by EllisLab and Sensio Labs, respectively), Slim forgoes controllers and abstract components for simplicity and ease-of-use.

You can build a Slim Framework web application with only a single file. Over time, however, projects grow in scope and size; better organization becomes necessary. Slim does not use controllers to organize application methods or routes; controllers are beyond Slim’s concern.

It could be used for routing but then again it depends what other components will be used. Silex is much the same as Slim but is also part of the Symfony group so if other Symfony components were to be used then they would fit right in. Twig for front-end templating for example (I often actually pair this with Slim too). At the same stroke however that's much of what Laravel is too (laravel/framework) in terms of providing the routing with other components able to be included as and when needed from Illuminate, Symfony, or anywhere else.

Rather than drag this out again I think the focus should be on what components are needed for the bigger picture - the vision for Symphony Next. Then we can mix and match components or frameworks and not the other way around. They're all valid and could ALL be used to build it. It's all just PHP and Composer. It just goes down to particular use case and overall benefit with the long term vision in mind. We need that vision. We need specs.

[bpierre]

Great, it seems much more suited for Symphony than Laravel.

Just for the sake of completeness, a similar solution is Silex. It is just an assembling of Symfony components, which lets you structure your app the way you want (everything is decoupled). I used it for a small project with Redbean and I liked it.

[iwyg]

This is actually what I had in mind: Build an application around symfony components (httpfoundation, config, etc.)

[bpierre]

They're all valid and could ALL be used to build it. It's all just PHP and Composer.

Agree, maybe an end-user framework will only be useful to bootstrap the application: every component can be replaced with a more suited one if the framework is modular enough, which is the case here. We just need someone to make the decision and close this issue :-)

[iwyg]

if we want xml config, there's a component for that :)

[bpierre]

@iwyg Totally agree (see my comments in this thread). We don’t need glue, Symphony is the glue! :-)

[designermonkey]

Now, I also like Silex, and that was in my research too. I just need to remember to write all my pros and cons down from now on ;)

[designermonkey]

if we want xml config, there's a component for that :)

We want xml all of the things!

[iwyg]

But what's the purpose of this?

[designermonkey]

What do you mean exactly?