If I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.

That position of "no compromises" is probably why you're not writing a framework on which others depend. Complex software always involves compromises, especially general purpose frameworks used by a large population.

Even if you're saying that only in performance there can be no compromises (but generally people who say things like no compromises don't bound those statements) it will cause large compromises in other areas, such a future feature development or long term maintainability and readability.

Perhaps you should leave comments about my personality to those who actually know me. But if you insist on talking about character traits, let me say this to you: People who don't know where to compromise and where not to comproise generally make bad software.

That's a fair call - I don't know you and I am speaking about character traits.

I don't feel your original comment reflected a position on knowing where to (or not) compromise, you made a strong assertion to take one option off the table in all situations.

In my experience, developers who are make blanket rules up front about what can and can't be changed in the future development of a system don't end up making much of value.

That's just my perspective, and I apologise if I've misread your character.

What I really wanted to express is a dissatisfaction with a general attitude among some framework makers towards performance. Of course there are exceptions to every rule. If the slowdown of ActiveRecord was down to fixing a dangerous security bug or possible loss of data, that would be such an exception. But piling on new features in a way that degrades performance needs to stop somewhere. Hard constraints are good to focus the mind even if you accept rare exceptions.

Compromises from whose point of view? One man's good compromise is another man's bad compromise.

All I can do is state my own point of view as clearly as I can. And my point of view is already a compromise. I didn't say make it as fast as possible even if you have to rewrite it in assembly. I didn't even say, don't write it in Ruby. All I said is don't make it significantly slower than it was before. That doesn't seem like such a big ask.

jquery is a great counter-example. Every version is significantly faster than the previous one, AND adds features.

Out of interest, what language is your framework for? I'm seriously thinking of stopping using PHP because of the weight of the frameworks -- at least on Python there are microframeworks in which I am not left with a massive bottlenecks on the simplest Hello World page. Sure, you can scale but it's becoming ridiculous that I am forced to be so frugal with processor intensive tasks in the rest of the web application just because of the framework.

My own framework and ORM writing days are long past and the software I write nowadays has very different constraints (data/text mining).

I totally share your sentiment about having to be frugal because of wasteful frameworks. My approach is to prefer libraries over frameworks. I start out using the most bare-bones configuration possible (no frameworks, no ORM, no CMS, etc) and then I selectively add well maintained libraries created by people whose attitude I understand.

I think code reuse is generally overrated, particularly when it comes to the rather trivial things that web frameworks do.

This is probably not very helpful to you. I apologize.