[PostGreHipster]

No way. Tear through some Drupal core code and you'll be dizzy, and it's pretty much always been that way. Angular takes a much more simple approach (for now). It really cuts down the amount of code you have to write, unless you really want to.

[AdrianRossouw]

yeah, but i saw storm clouds.

i've seen how stuff changes over time, it makes me aware of this stuff.

Drupal wasn't always that complex either. I think i'm probably culpable. I identified the point where I complected Drupal and set it on this direction, but that's another article for another time.

[drawkbox]

I agree with this. Drupal adds a layer of not much improvement as a trade for lots of extra work.

I think Drupal is a relic of the past when monolithic frameworks rather than the microframeworks ruled the day, I agree the same thing is happening in javascript world. The smaller/component/message based libraries win out after people know how to do things. In the beginning monolithic helps people make the jump, but quickly become too all encompassing to the point it hides what you need to know (asp.net's famous fail).

Who knows, drupal might have started off clean but when you are an overarching monolithic framework that becomes the go to for marketing/bizdev technology decisions then it bloats to EOL. You won't find a happy developer in Drupal-land but you'll find lots of marketing/bizdev peeps that think they are working out the need for a developer by using the standard bloated CMS of the day. Angular is still on the developer front, but if it gets big enough and it is monolithic then it is a problem.

Drupal could be worse though, it could be Joomla, both flawed monolithic platforms from the PHPNuke evolution tree. That fad ended in 2007.

[jrochkind1]

> I identified the point where I complected Drupal and set it on this direction, but that's another article for another time.

I would really like to see that article. Because, I too have been involved in such things, several times, but have not managed to identify exactly where we went wrong (or even convince others that we were going wrong :) ). I think figuring out how to avoid that kind of complexity is one of they key challenges of certain kinds of software these days.

(For instance, some people think Rails has already jumped that shark, some people don't, but I'm not sure even the people who think it has become complectified all agree on when it happened and how it could have been avoided. When I see people starting something new that's supposed to be "like Rails, but without all that needless complexity", I just think, sure, Rails started out simpler than today's Rails too, and you'll end up in the same place (or worse) unless you can come up with an understanding of what went wrong other than "Those other people made bad decisions I would never have made because I'm a better coder", nope, that's not what happened.).

[AdrianRossouw]

you should really read the simple and easy vocabulary guide. It's part of a set of notes about a talk by the author of clojure.

I took so long to get the fourth in this series finished because i needed to get the necessary theory out there first.

http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de...

[jrochkind1]

Yeah, I took a look at that when I saw you link to it initially, and will try to find time to read it more carefully and watch the presentation.

I still think actual concrete examples from real world projects would be great. (Maybe the presentation has some).

(That's what I initially thought the 'Beautiful Code' book would be about, but it looked like more about algorithmic cleverness than success in architecting simplicity. Which is good too, but many of us spend a lot more time struggling with the challenges of architecting simplicity)

[cxj]

I think it would have gotten complected by others anyway, Adrian. No need to beat yourself up. :-)

[AdrianRossouw]

i'm not. every step on the way was the right decision.

i was just so busy watching where I stepped, that I never stopped to think if I would like where we were going.