As ever, Simple Made Easy is apropos here: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy. It is well w

As ever, Simple Made Easy is apropos here: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy. It is well worth the hour, either watching it or downloading the MP3 and listening to it on your commute, jog, etc. One point the speaker, Rich Hickey, argues is that we have a bad habit of focusing too much on our experience sitting at our desks ("look how quickly I can do this one thing") at the expense of complexity in the code. It's a short view as opposed to a long view, since over time your project inevitably becomes larger and more complex. When you're trying to add a feature to a large, possibly mature product, you're seldom doing the same kind of work you see for a framework or language's demo code. Complexity will dominate everything else, to the point where it probably won't matter as much how easy it is to change the color on a div or whatever. That said, if you can isolate complexity behind an API (not just hide it, but truly abstract it), it's probably better for your software. The problem is that software only seems to get more complex over time, and after a while your framework which ostensibly abstracts adds its own complexity, complexity incidental to the problem at hand. Anywasy, I sympathize. :) As I see it, programming as we know it tends to involve gluing together frameworks and APIs more often than it does writing raw code. It's a huge stack of abstractions and I wonder at what point it's futile to try to understand more than a certain subset. That said, some people like being able to write code which ships almost instantly ~everywhere, or to a great many tiny computers in people's pockets. It's not all bad, right? It could be simpler, but it just isn't, so the decision is to take it or leave it. (Or try to replace it, but now you have two problems and/or N+1 frameworks.)