5

Drupal 8 fractured the community, dead ended projects that had years of being built up and supported, started a downward trend in overall number of websites using Drupal when it was still increasing market share, homogenized Drupal with other less successful frameworks that had already attempted it and failed by using composer to replace drush, twig to replace PHPtemplate, and Symfony to butcher Drupal and hang parts of it on.

The mission statement was to "bring Drupal to the modern era" and "be more enterprise friendly". All I've seen them do is make it worse. I have stopped using Drupal now, I still maintain some Drupal 7 sites but now that they killed the Drupal 7 community it's basically dead. Some small attempt was made to salvage it with Backdrop but it will likely never be as big as Drupal was and is mostly dead itself, for one thing it's not directly compatible with the huge library of modules either.

Another thing I loved killed by those without vision and giving into the "industry standards" that make one question the intellect of everyone who subscribes to them being a good idea. But hey that evil procedural programming that worked so long for so many was finally defeated. It's surely better now right... right?

At least this movement was supported by people that can't even tell the difference between the use cases in real projects between Drupal and Wordpress. Software Development is in such a good place and has no hypocrisy. One would never suggest it has lost sight of its original purpose of solving real world problems with computing and become self absorbed with its own navel gazing.

If still in doubt check attached image, it tells a very clear story about how to ruin the life of a CMS. It honestly feels like a hitjob attempted to sabotage it rather than an earnest attempt to improve something that has been doing well since 2001.

Comments
  • 4
    People still use drupal?

    I haven't even thought about it since 2005.
  • 0
    @sariel it was increasing in userbase up to 2015 when drupal 8 came out and it powers a lot of companies.
  • 1
    I think quite some ideas behind Drupal 8 where really good. Unfortunately it was too much of a shift for a lot of people and important module development stayed behind. A shit load of bugs and lack of polish also made it hard for early adopters.

    What they did good was:
    A. No more devastating updates 8 (6to7 was also a pain). Fix latest deprecated notices and you are good to go for the next major version.
    B. Use composer like the rest of the world.
    C. No more difference between fields and properties on an entity.
    D. API first focus.

    Ultimately Laravel does D. and web application with symfony better. Even the Drupal shop I've used to work for is switching to that. Also because it's easier to find Devs for it.
  • 0
    @hjk101 forgot the biggest improvement in Drupal 8: Configuration management (config in code). This allows you to develop something locally and then push to testing and production... In theory, the mess of ID's and links to content, stupid module uninstall mechanism makes it tricky.
  • 0
    @hjk101 B) is not a plus, drush was fast, took little ram, almost always worked and wouldn't mess up your install even once. composer on the other hand takes tons of ram, is super slow, and even after using so many resources manages to screw up your installs and become a time sink. Every project I have had to use composer in it was a minus. I'm not against package managers but apt or yum composer is NOT. It's a wonder how they managed to code such an inefficient error prone mess.

    D) is a silly thing to care about most the API's I've seen are just glorified versions of function calls, or call the same thing from a URL using REST or SOAP. It's mostly a buzzword imo, one you don't really need for drupal unless you are integrating it with another application, which I've never had to even do, and if I did, I'd just setup database access because it's more powerful. The only time it's that useful is if 3rd parties are integrating.
  • -1
    @Lucky-Loek I find the opposite is true, symfony is over-engineered and hard to customize and purposefully opaque. Drupal was straight forward and simple.

    I've done entire projects in a few weeks in Drupal that I would never trust to Symfony/Laravel. I've setup other people's Laravel projects and just installing and configuring it took an obscene amount of time compared to a drupal install. Honestly I'd be fine if I woke up tomorrow and both of them were vanished off the planet.

    As an experiment I tried to add a php tag to execute php code in twig, which was tied into symfony. The result after 10 hours work was reading their code and altering it was a nightmare and I recommend it to exactly no one.
  • 0
    @progresshuh guess we use it differently. Drush is fine for module dependencies but not for the rest. We actually use more deps ourself from the PHP ecosystem.
    The latter composer versions are quite ok and cache efficiently. Of course when you have a slow filesystem you are going to get hurt. Drush itself also uses composer (I'm actually a contributor there).

    We build quite some infractions between sites and a webapplication with a separate frond end. The strong API support (JSON:API) was a huge upgrade compared to the crap we had to pull to make it work in 7
  • 0
    @hjk101 I'd say drush is S tier for modules and managing your drupal install. I've used it for a ton of things over the years from cron job scripts to resetting passwords to upgrading. Even sql or php one liners.

    composer's other features are generalized in comparison and not made for drupal. I'm also not a fan of a lot of the php libraries people use out there and it often adds bloat. For instance using guzzle at an uncomfortable number of SLOC vs using curl. If you need the equivalent of curl functionality abstracted away to make you comfortable I just think you're a bad dev, and I haven't seen a case yet where curl can't do what I need easily.
Add Comment