4 ms·

I'm skeptical about investing anymore time into Drupal after using 7 extensively for the past few years. Any work I've done was mainly custom module development

I'm skeptical about investing anymore time into Drupal after using 7 extensively for the past few years. Any work I've done was mainly custom module development, soap, rest apis, aws integrations, ecommerce, etc. Pretty app heavy stuff. It's not well suited for these tasks but it can do them if you get creative. This, of course, has great overhead and complexity. I'm going to look closely at other options. It seems at this level that Drupal has been outgrown and that once you hit that point, for me, it feels like pressing the reset button and starting over. I'm bummed it has a growth ceiling. I also feel strongly that the productivity level is deceiving. You race out of the gate with clicky this and module that, to later find working with a custom data model to be extremely painful or that you can only do things via interface and not in code. Unit testing, at least in 7 is non existent. Short term gains and long term pains. It does not feel like it was ever designed with developer speed and procutivity in focus. So while I'm curious to hear of the new release I also just feel you can't teach an old dog new tricks. Part of this is the.community it has built for itself. Time will tell. I have a feeling D8 is between a rock and a hard place. At some point a framework is just way better. Tool for the job I guess.

mercer 11y ago
I agree. While there are probably a bunch of use-cases where Drupal is a good solution, I find that it doesn't hit any 'sweet spot' that I care about. For very simple sites I'm inclined to use a static site generator. For relatively simple sites that need a CMS, I use Wordpress (much as I dislike it). The clients are often familiar with it, and it is pretty easy to set things up. And if I'm going the Wordpress route, I might as well take advantage of the high amount of plugins and the complete (and often cheap) themes that target specific industries. For anything more complicated, I used to be in the Drupal camp, but now I opt for a framework approach. Rails, Express, or something like that. With every single site I've built in Drupal I always ran into the problem that the time spent on 'clicky this and module that' eventually outgrew the initial speed advantage, and I would have been better off doing these things in code in a environment optimized for this approach ('true' frameworks). I think it's analogous to how many of my clients insist on using Wordpress and paying more for that instead of a static site. They would've been better off with a static site that I update for a small fee, or perhaps even a small lesson in FTP-ing and editing a file, but they wanted the 'option' of logging in and changing stuff. But many of them never do. Similarly, the choice of Drupal sometimes seems to be primarily project managers who want the 'option' of making complex changes through the admin interface, just so they have the option. Never mind that the complexity tends to be high enough that you need a programmer anyways to pull it off, so you might as well just go the framework way.

mercer 11y ago

I agree. While there are probably a bunch of use-cases where Drupal is a good solution, I find that it doesn't hit any 'sweet spot' that I care about. For very simple sites I'm inclined to use a static site generator. For relatively simple sites that need a CMS, I use Wordpress (much as I dislike it). The clients are often familiar with it, and it is pretty easy to set things up. And if I'm going the Wordpress route, I might as well take advantage of the high amount of plugins and the complete (and often cheap) themes that target specific industries. For anything more complicated, I used to be in the Drupal camp, but now I opt for a framework approach. Rails, Express, or something like that. With every single site I've built in Drupal I always ran into the problem that the time spent on 'clicky this and module that' eventually outgrew the initial speed advantage, and I would have been better off doing these things in code in a environment optimized for this approach ('true' frameworks). I think it's analogous to how many of my clients insist on using Wordpress and paying more for that instead of a static site. They would've been better off with a static site that I update for a small fee, or perhaps even a small lesson in FTP-ing and editing a file, but they wanted the 'option' of logging in and changing stuff. But many of them never do. Similarly, the choice of Drupal sometimes seems to be primarily project managers who want the 'option' of making complex changes through the admin interface, just so they have the option. Never mind that the complexity tends to be high enough that you need a programmer anyways to pull it off, so you might as well just go the framework way.