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.

[IbnSaeed]

someone mentioned that Laravel is heavy.

Then which framework does it leave behind, Symfony ?

[iwyg]

There's a significant large part of L4 which is swiftmailer. If you'd rather go with phpmailer or something else you can also do this.
Actually I don't bother how "heavy" a server side framework is.
If you prefer slim over a different solution because it has a small footprint, keep in mind, that it's just a routing/http layer (or did I miss something?).

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it.
Just my 2 cents.

[IbnSaeed]

Why not list 3 to 4 pros and cons of laravel, symfony2, silex, or stackphp etc each, list only those which would benefit Symphony CMS the most. Select the one which is best suited, and move on from there.

[michael-e]

I don't know much about these framworks, but I used Swiftmailer some years ago. It is a monster, and Symphony does a better email job with just a few lines of code. Indeed the usage of Swiftmailer is one of the strongest arguments against Laravel. It makes me feel uncomfortable that they accepted it as part of the framework.

[michael-e]

And generally speaking, I do care how big the framework is. Like with CMSs, isn't the big one potentially worse? (Remember why you love Symphony: It's small yet powerful.)

[IbnSaeed]

What do you suggest michael ?

[iwyg]

Symphony does a better email job with just a few lines of code

Yea, right. In what universe?
Sending emails in Symphony is a pain in the bottom. However, Laravel's implementation is quite handy, works well and is sophisticated.

one of the strongest arguments against Laravel

Its un-testability and its weak system architecture is one of the strongest arguments against Symphony. So why do you use it anyway? I don't care much about swiftmailer, because most of the time I don't need a full smpt/imap stack php implementation.

isn't the big one potentially worse?

No, definitely not. Why do you think so?

Why not list 3 to 4 pros and cons of laravel, symfony2, silex

Are they actually comparable? When you say symfony2, do you mean the frameworkbundle or the components in general?

This might be an anti-example as I don't know much about joomla and haven't used it since like forever (and know there're many out there who don't like it. The pre 3 versions at least), but what they did is to write a framework for joomla, because they felt they need something that does it the 'joomla' way.

My believe is that many here feel the same about Symphony. So maybe this would also be a better way for Symphony. But I don't know, really.

[IbnSaeed]

I meant the complete framework, not its components. If all what is needed are components, as Drupal is doing it, would it benefit our cms ?

From what i see here, is that everyone has there own opinion as to why we should use this framework over the other.

I think we should compromise over some features if they are missing in the potential framework.

Then theres Yii framework as well.

If the majority is in favor of Laravel, then lets settle for Laravel and move on, even with its cons.

[michael-e]

Yea, right. In what universe?
Sending emails in Symphony is a pain in the bottom. However, Laravel's implementation is quite handy, works well and is sophisticated.

I was referring to the SMTP and encoding stuff, which is pretty simple and works great. Have you, for example, ever compared the "source code" of emails? You will see what I mean.

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it.

So you also prefer using smaller building blocks? ;-)

What do you suggest michael ?

I don't think that I can be a big help. I tried to install Laravel, but you need composer, which won't run without this (was it "brew"?) which in turn needs that, and in the end it didn't work without an Apple developer account (needed to download Developer Tools). So I stopped that for the moment, I was just too angry. From comments in other threads you may have noticed that currently I am bit fed up of "hip stuff" that — along the way — wants to change some important folder permissions on my machine in order to do its work and will create additional dependencies in my workflow, and technically as well.

So right now I would be happy if someone said "Let's simply develop Symphony." Which would, for example, prevent the pain of dropping our own email code in favour of Swiftmailer. But that is propably short-sighted. I know that @brendo and some others have a completely different horizon than me when it comes to programming. And they have good reasons for the undertaking that we call Next.

So a framework it is. Honestly I think that @allen and @brendo should decide, based on all the contributions that have been made.

@allen: Count me in if Next will be written in Haskell, I'd like to learn that, some day. And there is definitely nothing "hip" about it, which is a big plus! :-)

[ijy]

Indeed the usage of Swiftmailer is one of the strongest arguments against Laravel.

It can easily be removed as a dependency.

someone mentioned that Laravel is heavy.

It's all modular, you pick and choose what you want, exclude or remove components as well as dd. You can edit the folder structure as desired.

Then which framework does it leave behind, Symfony?

If you're talking full-stack then that's bigger. If you're talking components then what's different to Laravel?

If you prefer slim over a different solution because it has a small footprint, keep in mind, that it's just a routing/http layer (or did I miss something?).

Slim's cool. Love it for smaller projects and prototypes but yes it's just a routing framework. It starts getting messy when you need to start developing a larger app however (although perfectly possible). I don't think re-inventing the wheel there really provides any benefit. In terms of a working example Jeremy Kendall created a personal app (flaming-archer) based around the Slim routing framework but when you see how it progressed and look at the code, in hindsight you realise you just recreated a lot of the stuff that was already ready to go in an alternative framework such as Laravel. So you have basic routing, but you then need dependency injection so you add Pimple for an IoC container, you need an ORM so you add Doctrine, you need to make it testable so you create your service providers and interfaces and abstract away, you need logging so you add monolog, you need templating so you add Twig (and all of it's dependencies), you build to MVC so you create a similar folder structure, you need authentication so you add Zend Authentication, you want a CLI so you add PHP CLI Tools... etc etc. Suddenly you realise you just recreated what Laravel provides ready to go. There's nothing wrong with a micro framework but it's just one component and if you know ahead of time that you're going to need these things and something provides them (and arguably more integrated and more powerful with the likes of Laravel's IoC, Authentication, Routing is more powerful, Eloquent, Boris is also included in 4.1, etc) then it make sense to go with the shoe that fits from the start and save yourself some time. Anything else can be swapped out if desired but there's not a lot of fat in there. Not to mention many many other very useful additions such as migrations and seeding, generators, ease and speed of setup, easy resourceful routing, ability to use the CLI or interact via PHP, and the myriad of resources available.

And generally speaking, I do care how big the framework is. Like with CMSs, isn't the big one potentially worse?

We could look at it the other way and see what we would want to remove or swap out from the dependencies and see what it weighs in as. Other than Swiftmailer I'd imagine the other components would be needed and more on a project like Symphony.

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it.

Good call. Also included with Laravel.

how about stackphp and httpFoundation?

From the release of Laravel 4.1 StackPHP's implementation of the HTTPKernel so it's possible to add your own layer of middleware to the HTTP Layer. The best of both worlds. :)

Then just decide on one and move this forward.

...

[ijy]

I don't think that I can be a big help. I tried to install Laravel, but you need composer, which won't run without this (was it "brew"?) which in turn needs that, and in the end it didn't work without an Apple developer account (needed to download Developer Tools). So I stopped that for the moment, I was just too angry.

Ha, yeah, and they say things are getting easier. :) Actually you can get away with only installing Developer Tools now without the full XCode package. You can just run this from the command line:

xcode-select --install

Homebrew isn't needed if you don't already use it and to install Composer you just need to run this:

curl -sS https://getcomposer.org/installer | php

That will install it globally so you can run "composer ..." without "php composer.phar". Then you can just install Laravel by navigating to the directory you want to install it to and running:

composer create-project laravel/laravel project_name

Then you should be up and running with Laravel. :)

[michael-e]

Thanks for that all your explanations, @ijy, I will give that stuff another try! I am just playing the "angry old man" sometimes. Still I know that (on the long run) some of the hip stuff will actually be the next step. (Where would be be, for example, without Git?)

[iwyg]

So you also prefer using smaller building blocks? ;-)

I bet both components have more code than symphony :)

[iwyg]

was it "brew"?

you'll love it. It's a package manager for OS X.

[iwyg]

so basically it's

> brew install node
> npm install -g bower grunt grunt-cli
> bower install <insert javascript lib here> 

[michael-e]

Thanks. Will do (when I find another time slot for "next steps").

[ijy]

No worries @michael-e, I know what you mean. Things seem to move so fast it's a full-time job just trying to keep up with it all as the next thing vies for our attention. :) Once you get the chance to play however they aren't as bad as they seem.

Homebrew is the only way I fly. brew update && brew upgrade and y'er done! ...And brew install composer in this case. :)

[michael-e]

brew update && brew upgrade

Actually I use Debian's apt-get a lot. :-)

[ijy]

Or yum on RPM-based Linux distro's (I generally prefer CentOS). Package managers FTW!

[designermonkey]

Right. I'm in a bad mood, so sorry if I ruffle some feathers here (having a nightmare exchanging house contracts over xmas). Again, sorry for this rant and possible language.

I am f*&king sick to death of this argument. This is why I am not having anything to do with current discussions on Symphony and it's future. Apart from now (I see the irony, yes).

The last thing we should worry about right now is what to use to build it. Plan the goddamn application first before you decide on a framework which may end up buggering you because you got it wrong. Personally, Slim is for me. I am developing v3 with Josh with a Symphony style project in mind to make it more modular and extendable so it doesn't just have to be a micro-framework, but instead becomes a proper http request > response routing package for other apps.

(Just a note here but Laravel is dropping HTTP Foundation because it is bloated out).

That's where my eggs lie right now anyway, I'm not saying it is the right choice, but it's a component for my ideal setup for Symphony. Other components will be had written, others also chosen from existing ones. Also personally, I will never hand over any project of this magnitude to a single framework like Laravel. What if the entire direction goes somewhere we don't agree with morally or license wise? What if the project is dropped? At least with smaller components we can pick parts out for replacement etc etc blah blah.

I haven't got the time or inclination to make community decisions any more, as I stated a while back, as no one ever agrees with them, but if I were to do it, I would tell you all to actually plan out what you want first before PHP framework decisions are made. The discussion would be off the table, period. @rowan-lewis has already made headway and tried to get the discussion back on track by making a new organisation, and repo for this type of discussion, yet no one has even tried to start! The guy is very busy right now settling in to Romania with the intent of being funded to get this project rlling, and all anyone else does is disagree by way of personal choice over framework.

It's not your choice, the choice will be made by the project and it's requirements.

8 months has gone by. 8 months, and no progress. That will be the legacy of Symphony CMS unless someone grows a pair of balls (like @rowan-lewis, I hear they're huge!) and actually try to get something done. I tried, but all your bickering just told me to leave it alone.

Rant over.

[iwyg]

Thanks for bringing this up. I have a quite similar feeling (funny that we both currently do basically the same, although with small progress on my side). So Daniel is still up to it? Maybe he shouldn't have been so silent about it. It actually felt a bit discouraging keeping this a big secret, but what do I know.

Anyway. Do the really drop httpFoundation? How's that possible, they've just implemented stackphp? Thought they'd only drop the routing component.

[lewiswharf]

Release notes...

Laravel 4.1 features a totally re-written routing layer. The API is the same; however, registering routes is a full 100% faster compared to 4.0. The entire engine has been greatly simplified, and the dependency on Symfony Routing has been minimized to the compiling of route expressions.

[michael-e]

@designermonkey: So it's @rowan-lewis going to Romania? And you have been developing v3? And @rowan-lewis did (or will do?) the same, or s.th. different? Why do I never get information like that until you are in ranting mode?

[lewiswharf]

I love Laravel, but in the end I can learn and support any PHP framework that just "gets shit done."

[andrewminton]

I think @designermonkey meant Slim v3

[michael-e]

Ah! Thanks!

[iwyg]

Yes. Nonetheless it's true that there's already a s3 project going on.

[michael-e]

OK, got it, finally.

[IbnSaeed]

Let's just take the modules which we need from Laravel.

Does everyone agree on this?

[ijy]

Rant over.

You forgot the "bah, humbug!". ;)

I don't see any bickering here, just a lot of enthusiastic Symphony fans trying to make helpful suggestions. It's all with good intention and everyone has the same goal in mind so I see that as a positive. I think that everyone feels a similar frustration in the same way and everyone individually is equally powerless in a similar way. The crew are eager and willing but the captain is AWOL.

As a reminder to all of the original tasking, @allen set a direction over here. @rowan-lewis setup camp over here. I've just spoken to Rowan and he's trying to get a few things figured out himself first with some pretty radical notions in mind. :) From the IA perspective the list of requirements can still be made simultaneously. I've compiled my (deliberately non-specific) list here as just a starting point. Once we get to that point where both groups have completed their tasks then discussions can take place to start drilling out a plan. Rowan will be doing his superman thing (at -10°) in the meantime.

Also personally, I will never hand over any project of this magnitude to a single framework like Laravel. What if the entire direction goes somewhere we don't agree with morally or license wise? What if the project is dropped?

In that case why are we trying to build Symphony Next? The same argument could be made of building a website powered by Symphony. ;) Generally I don't think anyone minds what tools are used as long as they can build the house of our design. The majority of frameworks mentioned all look to have a very strong future and are all open source so that's a common theme at least.

Fortunately at present things can still progress without needing to decide on a framework just yet...so we can instead use it for spreading festive cheer and community team building spirt. ;)