Why Write A New Framework?

Summary
A framework is essentially a way to put all of your best practises into a single place so that you can reuse them over and over again. This should make you more efficient and make your time more financially viable to clients. If the framework you use slows you down or does not cater for the way you like to develop then sack it off and do your own thing. A vast majority of the framework community seems to have a massive fanboy attitude which is totally unneccessary. You can use a framework for a few years then change your mind and write a few apps in a different one. It doesn't make you a traitor, it just makes you a free thinking logical developer who uses the best tools for the job at the right time.

Use whatever you like and don't be negative to anyone who wants to work in a different way. There is no one framework that does everything right for everyone and there never will be. I have my three favourites and I'll be using those until I change my mind. I prefer to have my options and you're welcome to yours, just don't tell me I'm wrong for wanting to work in the best way I can or I won't have anything polite to say.


.....................

在他回應的文中有一段

There is so much great stuff in Rails, such as the irb, Migrations, Scaffolding, etc but at the same time there is stuff that drives me mad. I can't manually assign an ID to anything in ActiveRecord for example. But beyond that is a knowledge gap. I can spend 20 minutes and build something absolutely amazing with Rails, but then I can spend a day wrestling with inconsistent date formatting in my queries across environments or some other trivial task and all the productivity that Rails and it's auto-magic provides is shot out the window and things are made uncontrollably late.

http://philsturgeon.co.uk/blog/2011/04/why-write-a-new-framework

The Framework Myth

One of the key points here is that the framework is dictating the application flow, rather than the developer who is using it. This is what the Martin Fowler (who literally wrote the book on refactoring) would describe as a Foundation Framework:

A Foundation Framework is … built prior to any application that are built on top of it. The idea is that you analyze the needs of the various applications that need the framework, then you build the framework. Once the framework is complete you then build applications on top of it. The point is that the framework really needs to have a stable API before you start work on the applications, otherwise changes to the framework will be hard to manage due to their knock-on effects with the applications.

While this sounds reasonable in theory, I’ve always seen this work badly in practice. The problem is that it’s very hard to understand the real needs of the framework. As a result the framework ends up with far more capabilities that are really needed. Often its capabilities don’t really match what that the applications really need.

He recommends instead a Harvested Framework:

To build a framework by harvesting, you start by not trying to build a framework, but by building an application. While you build the application you don’t try to develop generic code, but you do work hard to build a well-factored and well designed application.

With one application built you then build another application which has at least some similar needs to the first one. While you do this you pay attention to any duplication between the second and first application. As you find duplication you factor out into a common area, this common area is the proto-framework.

As you develop further applications each one further refines the framework area of the code. During the first couple of applications you’d keep everything in a single code base. After a few rounds of this the framework should begin to stabilize and you can separate out the code bases.

While this sounds harder and less efficient than FoundationFramework it seems to work better in practice.

http://www.simple-talk.com/opini ... the-framework-myth/