[knieveltech]

I'm kind of enjoying watching the developer community turn on Drupal like a pack of wolves. That said, aren't performance issues more or less unavoidable when you're dealing with a CMS? The scope of use cases they try to cover is pretty wide which is sure to lead to bloat.

[epimetheus]

I deal with Drupal (7.x) on a daily basis, so that's why you'll probably detect bitterness from me. Personally there are a myriad of reasons why Drupal rubs me the wrong way, most are Developer issues though (Such as their annoying comment form API, and arrays, arrays everywhere).

There are better CMSs out there, IMO, but we have to use Drupal because it's the only one that has a Certification of Networthiness (I work in the DOD) - and to make things worse for us, we have to use Drupal on IIS with MSSQL (for now). Why can't we just go with Umbraco (.Net)!?

[knieveltech]

I've been working with Drupal professionally since 4.7, have code in several contributed modules in D6 and D7, and used to organize the local Drupal User's Group. I know all about the bitterness. I've spent the last 10 years watching a lightweight and infinitely hackable CMS turn into a bloated morass of opinionated overweight APIs that make easy things complicated. Yeah I'm looking at you renderable arrays.

Anyway I'm counting the minutes until an Acquia PM spots this post and starts spraying down the comments section with 35 paragraph word salad breathlessly defending the heroic efforts of the core dev team to drag D8 into the 21st century, in the process entirely missing the point that this may very well be the first core release of Drupal that will not run on commodity hosting due to resource requirements.

[chx]

Note: I am not an Acquia PM. I am just someone who sent in a few core patches over the last 11 years.

When I got aboard Drupal core was a very lightweight CMS. Infinitely hackable, yeah, if you go and hack core. Been there, done that, got the T-shirt. Time flies, years pass, and contrib modules happen because users want to click in a browser and not hack core. CCK. Views. All that jazz. Maybe your core is still lightweight but surely not your whole site. Comes Drupal 7, we move some of that into core. Core near collapses under the tech debt incurred. Remember the issue "Field attach API integration for entity forms is ungrokable" reported by the ... field API maintainer. Opsie. So the core developers try to decrease that tech debt and move towards something they found desirable. That's how Drupal 8 came to be.

Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless. There are quite a number of things you could diss Acquia for, there's no doubt, but core is hardly one of them. In fact, they paid Wim Leers to undo as much of the performance damage -- by introducing vast amounts of caching -- as possible.

[knieveltech]

Hold on bub, you're trying to tar me with the "Acquia-has-taken-over-core" conspiracy theorist brush and that's not what's happening here.

I'm dissing Acquia for their history of ridiculous marketing blasts that try to convince IT managers to upgrade to Drupal $N 18 months in advance of the contrib module space becoming sufficiently stable to seriously consider platforming a production environment on top of. Also for their PMs skulking around in various media channels breathlessly defending Drupal from any criticism regardless of accuracy.

I've been intermittently following your attempts to get various core initiatives to back away from the metaphorical ledge off and on since DC Portland. Sorry for all of us you weren't more successful.

[mitm2mitm]

> Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless.

where can I read more about this? I enjoy good programming drama

[chx]

https://www.drupal.org/node/1874530 everything in this (short) issue is a lie: submitted as "Proudly Found Elsewhere" when a significant portion of the code was written by the author of this issue, just submitted upstream and then pulled downstream (check @author tags, it's right there but https://github.com/symfony-cmf/Routing/commits/master?page=9 also here for the sake of archives, commits start at 3b152c4) to avoid usual scrunity by downstream (ie the normal Drupal core review process). To avoid anyone catching this (and I haven't caught it for a very long time) it was submitted on Dec 26 when everyone is obviously away.

"I don't believe CMF is as stable as Symfony core" this is at best FUD, Symfony CMF won't see a stable release for another ten months http://symfony.com/blog/the-symfony-cmf-released-its-first-s... Symfony 2 core had several stable releases http://symfony.com/blog/symfony-2-1-3-released by this point.

I have no idea how the core committers didn't catch all this -- but you can't really blame them, there was a gigantic pressure to move ahead. And then based on this foundation, everything link related, inbound and outbound was converted to route names instead of paths which is a) absolutely unnecessary b) destroys performance.

Of course, there was history and reason trying to avoid review of this pile of code. Symfony, in general, is an extremely poor fit for Drupal: Drupal was a convention based system and Symfony is very heavily a config based system. The most obvious and very glarring misfit is hooks vs events and despite hooks being the central Drupal building block there never was a fundamental, through research as to what if anything to replace them with. Compare the scrutiny Symfony Foundation received in https://groups.drupal.org/node/167299 to how Symfony HTTP Kernel got added: via an admittedly "off-the-cuff" prototype https://groups.drupal.org/node/198538 . Note that I was trying to push back on this immediately with little success then or ever. So after shoehorning HTTP Kernel in over some bitterness and fighting it stands to reason the architect wants to avoid any scrutiny this pile of code would receive.

Ps. Events have so much overhead that by now Drupal only uses the interface for them as we rewrote the dispatcher to scale. Benchmarks at https://www.drupal.org/node/1972300#comment-9216069 .