4 ms·

Couldn't disagree more, and that's after having lived through just the situation you and the OP both described. Pick the right CMS for the job, make sure your p

Couldn't disagree more, and that's after having lived through just the situation you and the OP both described. Pick the right CMS for the job, make sure your people are fluent with it (this is key) and you vastly reduce the amount of wheel reinvention not to mention effectively outsourcing large swaths of your codebase to a community of a few thousand developers. 100% bespoke makes sense if what you're doing is trivially easy or a complete departure from the available canned feature set of a CMS, in all other instances you're artificially limiting your pool of developer talent and taking on massive technical debt in the form of code you're on the hook to maintain.

dasil003 16y ago
I get what you're saying, but this is what I characterized as boilerplate. It's not a totally fair characterization, since Drupal gives you a lot of freedom. It's not particularly limiting in the design sense, modules are highly configurable, and the provided hooks let you do pretty impressive things with existing code. Drupal is an amazing piece of software for what it is. However the out of the box functionality comes with a lot of baggage. You never use all the functionality, yet you are forced to deal with the implications of that functionality. The design decisions are meant to support arbitrary content, but for most sites you have very specific content. If what you are doing is boilerplate functionality, then a CMS saves you a lot of time. However as things diverge from the standard case, the weight of the infrastructure can become crippling very quickly. An example was that I needed to reverse the order of two of the checkout screens in the Drupal ecommerce module. For the project in question this was a dramatic improvement to the user experience. There were no hooks to accomplish this, instead it had to be hacked into the ecommerce module. But the ecommerce module is incredibly complex. It attempts to do anything you could possibly imagine, 95% of which was not needed for this project, yet in order to hack in the solution, it was necessary to understand those issues holistically. The time to figure that out, hack the module and test it was longer than just grabbing ActiveMerchant and coding up a checkout flow in Rails from scratch. If you just let Drupal modules do what they are designed to do, then yeah it's amazing, but a great user experience is highly tailored to the application at hand. My experience is that even when you are doing something that a CMS is well-suited to, you still end up making little concessions to the architecture you are dealing with. Those concessions might be worth the cost savings, but it's undeniably a tradeoff. For me personally after a while I felt crippled by it—I couldn't stand my UX to be influenced by software designed for mass solutions. I believe the sweet spot is in frameworks and libraries with fine-grained tools so you can use only what you need without accepting any baggage you don't.
- knieveltech 16y ago
  Thank you for this very well-written response! Are there specific frameworks that you're using now for your projects and if so what are they?

dasil003 16y ago

I get what you're saying, but this is what I characterized as boilerplate. It's not a totally fair characterization, since Drupal gives you a lot of freedom. It's not particularly limiting in the design sense, modules are highly configurable, and the provided hooks let you do pretty impressive things with existing code. Drupal is an amazing piece of software for what it is. However the out of the box functionality comes with a lot of baggage. You never use all the functionality, yet you are forced to deal with the implications of that functionality. The design decisions are meant to support arbitrary content, but for most sites you have very specific content. If what you are doing is boilerplate functionality, then a CMS saves you a lot of time. However as things diverge from the standard case, the weight of the infrastructure can become crippling very quickly. An example was that I needed to reverse the order of two of the checkout screens in the Drupal ecommerce module. For the project in question this was a dramatic improvement to the user experience. There were no hooks to accomplish this, instead it had to be hacked into the ecommerce module. But the ecommerce module is incredibly complex. It attempts to do anything you could possibly imagine, 95% of which was not needed for this project, yet in order to hack in the solution, it was necessary to understand those issues holistically. The time to figure that out, hack the module and test it was longer than just grabbing ActiveMerchant and coding up a checkout flow in Rails from scratch. If you just let Drupal modules do what they are designed to do, then yeah it's amazing, but a great user experience is highly tailored to the application at hand. My experience is that even when you are doing something that a CMS is well-suited to, you still end up making little concessions to the architecture you are dealing with. Those concessions might be worth the cost savings, but it's undeniably a tradeoff. For me personally after a while I felt crippled by it—I couldn't stand my UX to be influenced by software designed for mass solutions. I believe the sweet spot is in frameworks and libraries with fine-grained tools so you can use only what you need without accepting any baggage you don't.

knieveltech 16y ago
Thank you for this very well-written response! Are there specific frameworks that you're using now for your projects and if so what are they?