Drupal 8 Feedback from a customer standpoint

Thank you for your feedback.

They need something that is easy to learn and maintain and comes mostly out of the box with a little or moderate customization. They also usually need a fairly quick turnaround.

This was never true of Drupal.

Even little things like update time (5 minutes for 7 core, 15 - 20 for 8 core) make a huge difference from a usability and maintenance cost point of view.

Composer is taking 20min to update your system? That definitely sounds excessive.

From my perspective, the core should be pushed when the main third party modules are ready and live, not years before

Chicken and egg problem.

It also disturbs me that now that 8 is out, 7 is not being developed.

Where do you expect the resources for developing both in parallel to come from?

So, you don't find configuration management to be helpful? (just as an example). To me, that is such a huge improvement for managing changes to existing sites. It's revolutionary. Now we can confidently offer clients ongoing improvements, rather than holding off and struggling to deploy stuff through features + lists of manual steps. The semantic versioning is huge too - improvements coming all the time.

And are you seriously updating all those sites through FTP transfers ?!?! A simple Drush up should take only a few minutes to run. Or move to Pantheon or something like that where they do it for you. On Drupal 8 composer is the way to go (similar to Drush, should only take a few minutes to run updates). If this sounds complicated: it's not. If I can do it so can you :)

That said, if you're really turned off by Drupal 8, but like Drupal 7, you should check out Backdrop.

I completely agree. We have a client in our company that wanted a Drupal solution. It is really unbelievable to me how under documented Drupal 8 is. Even if I google something I only get posts from 2013 or something. Most of the modules are far from production ready. And even community support is really lacking. I built some sites with Drupal ages ago and that is why I was appointed to lead this project, I thought how difficult can it be, it's just a CMS and I already have some experience in it, boy how was I wrong. Everything in Drupal 8 seems to be a pain.

And just a frustrated note to contrib module developers. I appreciate your dedication and work but you would do this community a big favour if you could take 10 minutes on top of many hours you invested in rewriting modules and just add simple instructions on how to use it.

This project was a nightmare for me and I will definitely advise against the use of Drupal in our company. Drupal 8 is far from ready and Drupal 7 is old.

I'm going to try to be as objective as I can, even if it hurts. For rockstart developers and for the core developers, Drupal 8 architecture is technically superior; no one can deny that. However; for the site builder who now has to deal with composer and for the self-tough PHP developer who now has to re-learn PHP (the object-oriented way) on top of having to learn Simfony, Drupal 8 can feel like a nightmare.

We always talk about the community; let's not forget that the community is made out of individuals. Drupal 8 has been very disruptive for many people and, in my opinion, the benefits doesn't outweigh the pain. Many people's job depends on Drupal. I'm seeing people quitting Drupal, others losing their jobs and others looking for new jobs. One of the talking points from Acquia and the Drupal association was that Drupal 8 would allow agencies find more developers and at a lower cost. Please, tell me where can I find lots of people with knowledge of OO PHP, Symfony and Drupal?

The Drupal developers community has some rockstar developers, but in its majority it is a long tail of self-taught PHP programmers that always supported Drupal with their small contributions. This long tail has been basically left out of Drupal 8 for the sake of a more elegant source code.

More legant source code doesn't necessarily translates into a better system. Over a year ago Jeff Geerling published a benchmark demonstrating that Drupal 7 was three times faster than Drupal 8.

Acquia and the Drupal association are pushing Drupal 8 very hard. So hard that you may be wondering whether it is just you being wrong and not "getting it". Wonder no more, there is about a million Drupal 7 sites out there and by now their owners are probably aware of the existence of Drupal 8. Since Drupal 8 was released there has been plenty of time and plenty of eyes evaluating it, yet its adoption rate hasn't been anywhere near the adoption rate of Drupal 7 for the same initial period of time after their respective release.

If you are a small agency or if your clients don't have big pockets or if you are still using FTP instead of Git; don't feel bad, the majority of Drupal site owners are not sold on Drupal 8 and the majority of Drupal developers are not sold either. Remember what I said about the long tail?

Drupal 8 hasn't been good for business, it hasn't been good for the community, it doesn't perform better than Drupal 7 and, so far, it doesn't provide anything that is substantially better than Drupal 7 as to justify the pain.

Things can change in the future and I'll be one of the first rooting for Drupal 8 when it gets better (or if it gets better) for its primary users i.e. site builders and self-taught PHP developers. Defending Drupal 8 over Drupal 7 at this particular point in time (May 2017) is just a matter of stubbornness. I'm not ready to drink the coolaid. For me, the king is still naked.

As much as it hurts to admit.

Drupal 7 is the Windows XP of Drupal. It was the perfect balance of being able to use ugly procedural for quick and dirty to get it done now and convert it to OOP when it was time to clean up your mess. It provided enterprise stuff at SMB prices. THAT was the magic. I feel like it's gone. I do Linux admin and even did Assembler when I was middle school so it's not like I'm a total moron

I had a job interview to join a team of developers trying to clean up a quick and dirty mess made by a company that had grown from 1 person to an large international organization. What he failed to understand when he bemoaned how this would be so much easier if the founder had started with OOP is that he wouldn't have a job and the company wouldn't exist if the founder had written OOP from the start. OOP is so damn time consuming when you need to do something simple and get it done. If the founder had written OOP from the get go he'd of never done everything else needed to go from zero to international.

Drupal 8 leans so heavy on structure that it is a burden even for someone who knows OOP and MVC. My thinking when I saw D8 was dear god, price of entry has gone from 20k to 100k. I kept hoping I would be wrong, but what I hear resoundingly is an inside group of people saying "you don't get it" and the people who are or would be future contribs saying "we do get it and you're not listening." Maybe Drupal has grown up and it's time to go down the enterprise route, but it definitely isn't nearly as accessible as it was, even for people who are pretty advanced developers. At least that's MHO. I'm sure I'll get lectured

Dear egarbeil,
you are right in a lot things which also webchick has mentioned a while ago.
I also get frustrated every time I need to start a project from scratch with drupal 7/8.
Collecting modules, do the settings, find the right module version combinations etc.

But you should not forget that Drupal is not a system for simple projects like you are mentioning.
It´s for highly advanced complex large scale projects with very custom needs and high security standards.

If you want a Drupal webshop or website with media ready to go - have a look at the Distributions: https://www.drupal.org/project/project_distribution/

Here a great list from Patrick: https://patrickschanen.blogspot.de/2017/03/drupal-distributions.html

All the best from munich,
Marcus

Maybe my experience as a one man band might be useful to some. I'm 3 sites into D8 now, and still supporting a number of D7 sites. I'm not a software engineer, I'm self-taught, though I do understand OOP principles.

The first was a simple but real brochure site on 8.0-alpha3 in 2014, custom theme, lots of custom code workarounds for things that weren't there yet. It never went live, but that wasn't D8's fault at all. I was planning to eat any rebuild time when D8 went beta as an upskilling exercise anyway. That taught me D8 wasn't a write-off.

The second was a small quick and dirty affair in late 2016, custom theme but minimal custom module code, ridiculously low budget by most standards, mostly clicking modules together and writing a little glue code for a brochure mortgage site. Came in on budget, I learned a bit in the process. Contributed some module patches.

The third has been a rebuild of a mid-size D7 site. It was time for a rebuild anyway, we needed to re-examine all the content, and it needed a redesign, so not a migration, though some custom module code was re-usable. Quite some learning curve, and has taken a few months, but in the end the budget has been equivalent to what we spent on the D7 site over time to achieve similar functionality. It's live now, took longer than expected, without some features, but a "phase 2" was always part of the plan, and phase 2 does include Commerce, which we are running now anyway without a public face yet. I sold this on the basis that D7 security support will go away eventually, there will be a cleaner transition from D8 to D9 and beyond, and that if they are a growing business (they are) then they can't let their website technology sit still.

And you know what? Maintaining those D7 sites now seems very very sucky. Config in the DB, very very ewww. I'm finding the D8 / Composer / Drush / Git workflow far improved over D8 / Features (ugh) / Strongarm (ugh) / Drush / Git, though I agree Composer updates are prone to stalling. I don't like working on the D7 sites.

Would I build a new site from scratch in D7 now? Hell no. I might clone an existing one if the spec was very very similar, but I would be sure to tell the client that the lower cost comes at the expense of future pain.

Some interesting perspectives about essentially the same topic-- don't let the reference to "non-profits" deter you-- it's not really a nonprofit specific discussion:

• https://www.mydropwizard.com/blog/drupal-sucks-non-profits
• https://www.mydropwizard.com/blog/drupal-8-has-left-small-non-profits-be...

From my pov, D8 is still hands off atm I'm afraid. I've tried several times to make the jump on a site build and always hit a brick wall. We're almost at v8.4 and that absurd toolbar flicker is still an issue. Contrib is lagging behind worse than ever-- even compared to the D7 lag caused by the simultaneous rewrite of views at that time. I'm an offender myself-- I can't find a reason to start upgrading my modules to d8 since I have no D8 sites to maintain.

Moreover, I've recently fully committed to a git/features based D7 workflow and, while I'm sure CMI is 'better', it fixes the one big downside I've always had with D7. I have fully created a git based DEV->QA->PROD workflow environment where I never have to actually login to QA or PROD unless I want to test something. New functionality and fixes get worked on in dev then committed and pushed to QA where they're tested and wait for monthly deployments to PROD.

I no longer even enter PHP anywhere in the UI, lol (not even for views contextual filter handling). I've shed all my bad habits with D7, so I have even less reason to make the jump.

I have a professional IDE and development environment, brushed up on my OOP skills, even dove in and started learning pure symfony (which oddly enough, doesn't actually help you with the Frankenstein monster Drupfony that D8 is).

D8 needs to be compelling-- and so far, all propaganda aside, its just not. Not for me anyway. And certainly not for my employer. D7 from D6 was a no brainer-- it WAS compelling.

Backdrop is what I always imagined/wished for D8, but contrib is still lacking some critical options and, most importantly, the community is still virtually nonexistent.

At this point, I'm weighing the option of just going with pure symfony/laravel for my next step. It's just that I'm so used to the speed and agility (in the pure sense of the word, not the scrum sense) that building sites with D7 enables.

I know I know-- I should 'put my money where my mouth is' and just dive in to make it better. However, I'm not in a shop, I build and maintain several very large drupal sites-- for my one fulltime employer. All my drupal contributions are personal, not subsidized or backed in any way. And given how my efforts to improve drupal.org were handled, and the almost antipathy for small time contributors I've witnessed in the issue queues over the years, I'm not terribly disposed to take the risk of completely wasting my time again.

Having used Drupal over 8 years as a site builder I had to chime in. My experience with Drupal 8 has been like pushing a marshmallow into a piggy bank slot. I feel 'something' is fighting me at every turn. Nothing has been easy. Not once have I had that "Oh that's cool" moment with any of its features.

Usability and learning curves in the new navigation were expected. Not being able to build a simple website without major issues and triple the build time was not.

At present I can not understand how Drupal 8 will compete for market share with other CMS's (something I thought that was highlighted with D8). Sadly the new WordPress versions will look like obvious choices if held next to D8. I early on only heard about the speed and elegance of this new build. I have yet to see it. In fact I find it slow. I have D7 sites on the same server that are snappier with more content, views blocks and the like. I see a lot of wheel spinning with D8.

I understand D8 was intended to compete with enterprise solutions. It sounds like a lot of Drupal experts are saying Drupal 8 is not what their company will use for any production website (as of this post). If that is case how are these enterprise companies going to be introduced to Drupal 8 when few people in the production world prefer it?

Anyway, I love Drupal. I love the community. I know there are countless man hours and thought that went into D8 - so please don't think I say this in the absence of gratitude.

With that said, for our business Drupal 7 has a long future. May even have to explore the path of BackDrop for the future beyond that. As of this post D8 has provided zero benefit to us.

While composer is something one gets used to, check out this incompatibility problem:

The composer utility and Drupal require conflicting PHP settings!!!!!!:

I recently ran into a problem with D8.x image upload that was only fixed by the PHP setting:

allow_url_fopen = Off

which is as documented on drupal.org for D8.x PHP settings requirements (see link):

https://www.drupal.org/docs/7/system-requirements/php#shortlist

Meanwhile the PHP setting above disables the composer utility which throws a specific error message stating that:

allow_url_fopen = On

must be set for it to operate (see composer error text):

The "https://packages.drupal.org/8/packages.json" file could not be downloaded: allow_url_fopen must be enabled in php.ini (https:// wrapper is disabled in the server configuration by allow_url_fopen=0
failed to open stream: no suitable wrapper could be found)
https://packages.drupal.org/8 could not be fully loaded, package information was loaded from the local cache and may be out of date
The "https://packagist.org/packages.json" file could not be downloaded: allow_url_fopen must be enabled in php.ini (https:// wrapper is disabled in the server configuration by allow_url_fopen=0
failed to open stream: no suitable wrapper could be found)
https://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date

Seriously?
I've come up with a hack, be such hacks should not be necessary.

Is it true that Drupal 8 forces you to use Drush and Composer?

So I was thinking I would give Composer the benefit of a doubt and install it to one of my Windows 7 development machines.

Here's how it went:

For the most part, the installation of Composer was simple. I started by following the instructions over at https://getcomposer.org/doc/00-intro.md and once I manually-installed the *.phar file, setup the *.bat file, and added everything to my PATH environment variable, everything tested out okay. I was even able to install their monolog example.

Now, feeling like one of the godly experts we keep hearing about, I decided to use the Commerce Guys Address module as my first real world attempt of using Composer for my own Drupal purposes. (Bear in mind that I installed Composer into C:\composer. So what this means for me is that when I try to execute Composer, I'll do it from that folder path in this comment but use the "-d" switch for Composer to be given a folder path necessary for my Drupal project location.)

So, per the Commerce Guys Address module page, their instructions indicate to use the following Composer command to install their Address module:

composer require "drupal/address ~1.0"

Seems simple enough but again, for me, this translated to the following command:

C:\composer>composer require "drupal/address ~1.0" -d C:\www\projects\mydrupal8project

Once I pressed the enter key for this, everything began to work... Or so I thought.

Just when everything was about to finish, Composer coughed up a lung:

In case my copy-and-paste image above doesn't publish with this comment, the error that Composer printed inside the console was as follows:

RuntimeException: Failed to clone https://git.drupal.org/project/coder.git, git was not found, check that it is installed and in your PATH env. 'git' is not recognized as an internal or external command, operable program or batch file.

So does GIT also need to be installed now just to download and use the Commerce Guys Address module on top of Composer or am I just screwing something up here? Funny enough, the module now appears in the Drupal Extend page but when I try to enable it, it does nothing and instead resets the module screen with the Address module remaining unchecked (indicating that it's not installed).

What's worse is that there isn't even any error messages anywhere (including the log file) indicating that anything bad happened. It literally just did nothing.

For anyone wanting to keep tabs on where this all might go, I'd advise you to subscribe to the following:

https://www.drupal.org/node/2908394

I have made a firm decision long time ago not to adopt Drupal 8 on any future projects. I simply don't use it. All my Drupal services run on Drupal 7. Put aside the new backwards non-compatible, poorly documented API, excessive needless complexities, new scattered folder structure, the fact that Drupal 8 is 3x times slower than Drupal 7 for authenticated users is more than enough reason to not care about it at all. 2 years on, contributed module porting is behind, composer issues. It is like a release that will never be complete. As for decoupling and creating API back-ends, there are superior frameworks available which allow creating back-end API's with high flexibility, in less time, with way shorter and cleanly written code, without all the headaches of Drupal 8. What takes 2 hours to do in Drupal can be done in 10 minutes in other frameworks. Drupal 8 is should concentrate only on allowing people create websites without the need of a developer.

This may not be the best place to voice my two cents. But I am a non-programmer/graphic designer that began learning Drupal 8 last September in an effort to create a new company website for the company I work for.

I watched OS Training's Drupal 8 videos and dove in.

Halfway through the project - I began reading the composer debate - but by that time I was too late. This October the site went live. Throughout the project I have darn near seamlessly updated through my cpanels file manager.

Re: the comment, above, that someone stated "Drupal offers nothing out of the box that Wordpress does not."
-- Yes it does, and early discovery was exposed filters that made it possible for me to attack a project slated for the future within the current web project.

I was delighted as were my superiors.

However - as a non-programmer/graphic designer I am now shaking in my shoes that composer may be required at some point in the future. I really like Drupal 8 and thought Drupal 8 was my entry into Drupal. However - the club seems exclusive and doesn't seem to want me. It feels like the metaphorical carpet has been yanked right out from under my feet.

Sorry if this rambles.

The proposed inclusion of React in Drupal core will finish the job which Composer, and the panoply of external libraries, started.

Of course some people do need such things, and Dries does his best to square the circle of looking after ordinary Drupal users, and looking after hundreds of jobs and millions of investment in an enterprise-focussed shop. Drupal tries to work for a diverse user base, and sometimes it is difficult.

Drupal is moving onto an island. Enterprise Island. Professional web devs are expected to know how to read the map (yes, I am learning React). Here is a funny and true--if slightly exaggerated--comment from the real world of web development:

The dirty little secret is that most "modern JavaScript development" is nothing to do with actually building websites - it's building packages that can be used by people who build libraries that can be used by people who build frameworks that people who write tutorials and teach courses can teach.

I'm not sure anyone is actually building anything for actual users to interact with.

(source: David Carson in a Disqus comment on Why I Moved to Vue.js from Angular 2.)

The original posters post is... SO Correct.  Drupal 8 "adds a whole lot more complexity".  D7 was so good!  If D8 would have just concentrated on "basic" things like a great WYSIWYG and a great "Media Manager" (like WP) and a couple other basic things, D8 could have taken on WP.  But... Drupal decided to go the exact opposite direction and make it even MORE complicated for the user and the developers.  I still use D7 but any new development is WP or Backdrop.  Try to defend D8 all you like, in the real world for real businesses... it's major overkill and too complicated.

Six months ago I posted my honest opinion on this thread and I ended it by saying that the king was naked.

Here is an update with what I have learned so far.

During the last six months a lot of modules have been ported to Drupal 8 (D8) and I have been able to build a couple of professional sites using D8 (e.g. https://damnjoan.com). In the process I have missed only a couple of D7 modules that had not been ported to Drupal 8 and were not that important, after all.

For site builders

I’ve read a lot of complains and anger about Drush and Composer on this thread, but Drupal and Composer are real time savers. Once you learn to use them, you will wonder how you’ve done it without them. Here is a little fact: I only have to use three composer commands and three Drush commands to get the job done. That’s not a lot to learn if you think about the time that it will save you.

If you invested years learning Drupal 7, do yourself a favor and learn the basic commands to install, remove and update a module with Composer and Drush so that you can stay relevant on D8.

I don't think a serious D8 project can be done without composer and Drush, I knew Drush already, for me it was just a matter of learning a bit of composer. I'm happy that I did.

I think the most difficult part for a novice about Drush and Composer would be to get them installed. There are lots of tutorials online. I’m the maintainer of a GitHub project that helps setting up an Ubuntu machine with all you need in order to work with Drupal (https://github.com/jcmartinez/drupalpro14). That’s how my machine is set up and I only had to add Composer to it in order to make it ready for D8.

Speaking about the machine; I think it is much easier to build Drupal if you are using Linux or Mac than on Windows. If you are on Windows, try the above GitHub project on a VirtualBox. I’m not saying that you can’t use Windows to do Drupal; I’m just saying that Unix based environments are friendlier for this type of work.

One of the biggest problems I had with Drupal 7 was transferring configurations from a development site to its live version. Yes, the features module was helpful but then features tended to get entangled and there was some potential for a mess. Now I can make a bunch of configuration changes on a development version and transfer them by typing two Drush commands:

$ drush cex

$ drush cim

The first command typed on Dev means: Configuration Export. The second command typed on Live means: Configuration Import.

Finally I don't have to keep notes and make the changes twice or deal with a bunch of features. 

For module and theme developers

Your best friend is something called Console, which can write the skeleton of a Drupal 8 module or a theme for you. Drupal Console is really helpful. You only have to type a few commands and Console will create the basic code for you. I wouldn’t start to write a Drupal 8 module without using console. By the way, I contributed https://www.drupal.org/project/pseudo_title. Console wrote the skeleton of this module for me. Big thanks to @jmolivas for creating Console. Man, you just made my life so much easier!

When writing a D8 module or theme, your other best friend is the Devel module. Devel has something called Kint that helps you see the content of arrays and classes. 

An understanding of OOP will be very helpful to you. If you don’t know what is OOP don’t try to write a module or a theme. Read some PHP OOP tutorials or books before trying to write a module or a theme. You don’t have to be a guru at OOP, but you do have to have some understanding of it.

Some of the D8 hooks are very similar to D7.

When I’m writing custom code for a Drupal project, 99% of the time is to override a form. Overriding a form in Drupal 8 is almost the same as in Drupal 7. The same hooks are available.

Theming is a little bit different on Drupal 8, but not by much. Looking at the source code of other contrib themes will help you figure out most things.

If you can't figure out things by yourself, there is now a lot more documentation on D8 than six months ago. Google and Stack Overflow solved most of my problems on D8.

For clients

If you are on a very tight budget and have very basic requirements, I don't think D8 could compete with WordPress.

For projects where there are lots of requirements that deviate from what WordPress is intended to do (i.e. blogging), then definitely, go with D8 as you will have more options in the future.

In summary

On my previous post (above) six months ago, I said that “I'll be one of the first rooting for Drupal 8 when it gets better”. Leaving aside the argument of whether it was necessary for us to go through such extreme changes in order to improve Drupal, I’m now convinced that Drupal 8 is ready for prime time and I will continue using it.

1. The development experience is much better, once you become familiar with the new tools (i.e composer, console, kint).
2. Module availability is becoming less of an issue and it will continue to improve as time goes by.
3. It is easier now to use libraries and code that wasn't "made for Drupal" originally.

My honest advice to all Drupal 7 developers frustrated with D8 is to stop resisting the change and don’t throw away all the effort that you've put into learning Drupal 7 because, if you know Drupal 7, you already know a lot about Drupal 8.

It is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment in which it finds itself.

- Darwin

Make a little effort to understand Drush and Composer and you will be rocking and rolling in no time. I'm glad I did!

Hope this helps.

They killed it with Drupal 8 - im turning away from Drupal now. 
I was hoping they made Drupal easier to use, instead they made it worse with all the composer and drush stuff that was previously optional, but now you must learn to use it. 

Installations crashes 99 our of 100 times when you update modules and core.

Thank you for many good years Drupal, but im sorry i have to leave you </3

Take this with a grain of salt, as I'm not one of the experts, by any stretch of imagination. Just sharing my experience...

I've spent a little time perusing this string, as i'm in the midst of a website overhaul, moving from D7 to D8. I had first visited the option about a year ago. I could see the benefits and the scariness of moving to D8. But, due to some company security concerns it was somewhat essential to begin making the switch. Time will tell, but Drupal 8 appears to have some security advantages over 7 that I suspect may become increasingly prominent/important over time. Also, Security features often benefit from being foundational, rather than back-patched.

Aside from this, one of the core complaints is difficulty. I'm not getting the sense that Drupal 8 is actually any harder than Drupal 7. It's just... different. The UI doesn't seem any worse, and in someways is better.

On the PHP side...I have an advantage that might illustrate an underlying theme in everyone's comments: I learned PHP several years ago, then gravitated away, as employment took me in other directions. When I started working with Drupal in the last couple years, my memory of PHP was pretty vague. So, I don't have any 'set ways.'

My relatively clean slate of PHP knowledge means that, with the Drupal 8 ecosystem starting to get a little more robust, I don't really have that much trouble adapting to the OOP way of thinking. I think we're essentially just looking at a combination of two issues:

     1. Drupal 8's reputation was a little bruised in it's first couple years by lack of resources and modules. (a chicken & egg problem)

     2. Thought patterns are hard to change. It sucks relearning. Being human, we lash out, protest, defy and walk away. Change sucks.

For my part, I've set up Composer and had no issues. And most of what I've needed has a module for it. If it doesn't exist, I understand that it's still a young ecosystem, for better or worse. There are innumerable things I've found to be better in Drupal 8, for my use-cases. 

And I have the benefit of a long break from coding, so my head isn't filled up with "but we've always done it this way." Maybe, it only seems more difficult to people, because ... well, sometimes it sucks to have to learn something new. Remember, as someone alluded to in a post a couple months ago - to adapt is to survive. 

Many of the stated problems with Drupal 8 are just not that visible to me. I have had very few problems updating modules either through Drush or admin panel. The caching/site speed issue seems non-existent, and is helped by the Bigpipe module's 'lazy-loading' (for lack of a better term.) And I have no real problem with the OOP model. But, remember D8 is not (and should not be) 100% OOP. There are still hooks a'plenty.

While it's fine to say "I'm never using Drupal 8," - I know plenty of cases where Drupal is just a bad fit, overall - Please understand the risk of overstating fears and concerns. - either you're left in the dust when D8 shines, or a potentially advantageous codebase falls into disuse because nobody contributed when such changes might've been all that was needed to make it shine.

That being said, there are still things to work out. Some important areas: Feeds is just beginning to stabilize as a usable tool. The migration tool from D7 to D8 is a bit unreliable, and using Solr 7 required a minor code patch. 

Some issues are not version specific, like website size. Neither Drupal 7 or 8 are for smaller sites. It would be like using a sledgehammer used to post a sticky note. So I think voicing concerns there is a non-issue. If you were considering Drupal of any kind for a blog site, you're probably doing it wrong. Use Wordpress, if you're making a brochure site or blog. Heck! Wordpress might even be a bit much for some of these cases!

Still, all told, things are improving. I'd conclude by saying, for the two basic issues I mentioned above: 

1. Things are changing... Don't let your opinions of Drupal 8 be frozen in time. You might be surprised how much it's improved. and how much more it does every day. 

2. Things are changing... Learn a new way of doing things, and accept that there's a slight chance the way we've been doing something isn't the better way. And a slight chance you may benefit greatly from the new knowledge.

Just my humble take, for what it's worth. Admittedly, I am a sample size of one, but don't write off Drupal 8. It's only getting better.

I was planning to eat any rebuild time when D8 went beta as an upskilling exercise anyway. That taught me D8 wasn't a write-off... 

Today when i was teaching to my students about drupal 8 ( i tried this many times in past but badly failed, so I left it and I stuck to D7 only for years. Today I thought that it would have gone for few better changes at least now ) and I was showing them how drupal 8 dashboard is cool and responsive.

And I installed first module i.e. admin_menu and it badly broken. Shame! Shame! Shame!

I think Drupal 7 is good for me! lol

i installed backdrop is's great its intutive its managable to port d7 modules there .... there are more d7 modules i consider ( for myself ) usefull than d8 modules. backdrop has done a great job onn the admin interface especially for non developers. d8 was always a pain for me!!! d7 felt enjoyable but needed that backdrop updates e.g. jquery update layouts and so on it feels really freah and even more modern than d8. About D8 i think there is a lot of Pepole who D8 is awsome for the work the Drupal community has done is amazing no doubt its just not the kind of cms i expected when using d8 after d7. OP is right in my opinion Propably D8 is awsome for enterprise solutions i cant really say if it is but i can say backdrop is more awsome than d8 to myself and feels fresh compared to d7

I'm really glad to see a post last that has aged like this. It provides some ongoing insight into how things are moving along for D8 as well as how others are feeling. I'm saddened to see that the grievances with D8 echo my own. I wasn't off the mark after all! I kept thinking that 'I wasn't getting it' either but no, my instinct was correct after all.

I've been a tech lead and front end developer with builds since D4 and it's abundantly clear that D8 severed the connection that experienced creators put into this system and where it is headed now. What baffles me is that the top tier group that leads the push for this change failed to see the intrinsic value of the community that turned Drupal into what it is today OR perhaps that enterprise opportunity really would pay off. It's an enormous gamble and looking at the stats we might agree that they are on the wrong side of that bet.

I've been pitching Drupal since about 2006, perhaps 2007. What I can say with absolute certainty is that I haven't been able to recommend D8 to a single client and the D8 deployments that have been done are very particular in the way that they need to be maintained. Absolutely no client is prepared to pay for the level of deployment, maintenance, and fuss that D8 demands and I have to be upfront about its expectations because my team's time is directly connected to it  I keep hoping that I can finally bring it to the table and it just hasn't materialized.

With D7 clearly winding down, it's time to look elsewhere for now. A small part of me hopes that D9 will center itself. We intend to skip over D8 completely and hold. I am looking at Backdrop as I write!

Thank you