Thursday, February 16, 2006

Some thoughts on Frameworks

Frameworks is the big question of our decade, which to use, what's the best for what kind of development environment I am in. I find these are all valid and important questions.

I find that I have some reasonable concerns on frameworks, and although I have them, I am not trying to say that frameworks are bad or evil. I just don't think we're at the highest level of quality yet.

Here are a few of my needs for a framework:

1. Works well in individual or team environments
2. Is not visible to the end user, end users see each web page as a seperate page and application.
3. Eliminate any and all processing that is needed for a framework to run, so that each application is just loading it's own functional needs.
4. Each application can be stand-alone or part of a whole application farm, and if different frameworks are used for different applications, that they can seamlessly work together.
5. Clean and Easy to read so that non-framework users can just as easily read,add or modify that application.

Now, I know as we keep upgrading and adding new frameworks, we are going to eventually be at this point, I can feel it in my blood. (I hope) But let's discuss, the where's and why's of each need, so even if you disagree with me, at least you can understand what i say, and perhaps why I say.

Need 1: Works well in individual or team environments

Face it, not all of us work in big shops, and sometimes whole websites, applications are written by 1-2 people, not necesarily working together.

So we need to find a framework with ways that works well with both. And of course it is nicer and more learning involved in a team environment, but reality is not always on our side.

Need 2: Framework invisible to End User

I totaly admit that I am a Jacob Nielsen, usability fan. And honestly as great as the framework applications may be in maintainability and stability, it bites in terms of usability to the end user. Frameworks are very important to us as coders, but let us not forget that it's our end users that need to be able use these applications, whether they be for Intranets or Ecommerce Portals.

People do enjoy bookmarking sites, and to help them we need to have readable bookmarks. And I admit that non-framework sites don't always have this well done either. But there are ways to make it seamless.

For example which is easier to read?

1. http://www.mysite.com?index.cfm?fuse=shopping.cart

2. http://www.mysite.com/shopping_cart.cfm

I know some claim that most people don't read the web page links or don't really bookmark them. But how many of are willing to take that chance? Read more about this here at Useit.com.

And btw, there are ways to make this streamlined, for example creating shopping_cart.cfm that just has the correct includes to your x-framework specific code. But then it's all invisible to the end user, which is a good thing.

Need 3: Eliminating Unecessary Processing

As part of setting up each aspect of the framework, it takes some processing per page, to help it both setup, and recall which applications to load. I think this an honest balancing act, that needs further tweaking. Perhaps the big question is what processing should be done for the framework on every page, and what processing should let the application code itself do. I think this is something for open discussion on the blogs.

Need 4: Stand-Alone Applications - Frameworks and Non-frameworks have to be able to work together.

One of my personal pet peeves, is that working for X Company and they outsourced some code, and this one application was done in fusebox, while 100% of our other code was all done in normal cfml code.

Simply there has to be a way so that your framework can easily be worked along side with other frameworks, or easily translated if necessary.

Maybe this is just a fantasy, like having Randy Moss on my fantasy football team. But honestly sometimes we are forced to take in applications made in different frameworks, and yet they're all for the same website. So we have to somehow find a way to integrate them, so they can work well together, and not make it too difficult for anyone following us, and seeing code for a website, done in many different methods/frameworks.

Need 5: Easy to read and modify

You created this beautiful application, in the most hotly used framework, everyone you chat with loves this application especially in the framework you did it in.

However when you turn it in for your client, they look at you, and say something like...

"What framework is that? We don't use that framework, so it's going to be hard in the future to be able to read/modify that application, especially since we didn't ask you to create it in X Framework......"

They're not saying the framework is bad, or evil, just if we do things in frameworks, they have to be easy to read and modify by other people who are completely unfamiliar with that framework.

Is this realistic perhaps not, is it needed, heck yeah.

Maybe I am just sharing some of my pet peeves from my years as an ColdFusion Developer, but I feel these are real needs and hopefully set some goals for future framework development and upgrades.

Thank you very much...

P.S. A Happy and Belated Valentines Day....

7 comments:

  1. What I find worse than the framework/no framework choice for a project is the bolt-on/abandon a framework on existing applications.

    I'm working on a project right now that has all the trappings of a fusebox app (fuseaction urls, dsp_ files, act_ files, etc), without actually running the core files. A simple switch statement handles the fuseactions, but after that, all bets are off.

    Cleaning up apps like this can sometimes feel like you're building a house from the top down.

    ReplyDelete
  2. Hey Craig,

    I'm obviously a bit biased on the matter, but here goes. I don't mean this harshly, but I think your concerns are largely unfounded, and reflect that you haven't learned any of the main CF frameworks.

    Need 1: Works well in individual or team environments

    I've found that all three of the "main" frameworks (FB/MG/M2) are learnable helpful to both large and small shops.

    In my personal work, MG (well, MVC in general) keeps me well organized and makes it easier to work on apps that may get attention every few weeks.

    At work, MG lets us split up large apps and responsibilities.

    Need 2: Framework invisible to End User

    I don't know about Mach-II, but I've seen people do this in both FB and Model-Glue. Quick example: http://www.coldfusioncookbook.com/category/15/Caching - that's a Model-Glue app.

    Need 3: Eliminating Unecessary Processing

    Yes, frameworks have overhead. So does every other application worth its salt.

    If there's a poorly-performing application, framework or no framework, 99% of the time the poor performance is likely database related, and has about zilch to do with the framework.

    Additionally, frameworks typically make it easier to find and solve bottlenecks by providing what I would call "structured wiring" as opposed to "daisy chain" (in domestic construction terms).

    Overall, I think you'll find that most framework-driven sites provide better performance because the developers are more likely to 1) think about what they're doing and 2) know what they're doing in the first place.

    Need 4: Stand-Alone Applications

    I'm not too sure what the problem is here. I just use the same application name, and *foomp*, I've got one "application" with parts in no framework, MG, and M2.

    If you've designed your app in an MVC manner, portions in different frameworks can even use the same business tier, and even the same instances of singletons if they share a ColdSpring factory!

    Need 5: Easy to read and modify

    Frameworks force organization. When I deal with non-framework code, I spend at least half of my time figuring out how the heck it's laid out.

    Having the common organizational "vocabulary" that frameworks provide is a lifesaver when folks other than original authors need to work on an app!

    ReplyDelete
  3. I do agree architecture is important. But how important?

    And yes frameworks do have a hit on performance, even i noticed it during my fusebox class.

    Is there a lot to learn from frameworks absolutely!

    Once everything is setup, and everyone know's how to use it, it is clearly a winner in learning to know what does what.

    But however, not all environments are solidly 1 framework or another, and in the near to far future, has to be a better way for frameworks and non-frameworks to work together.

    How I don't know.

    And Joe, I may disagree with some things, but that does not mean i do not wish to hear your honest opinion.

    In my humble experience, I've always worked where I am on my own, or even have developers in my department, but I am coding my own whole application, and that does tend to have a different view on application building than those who do it on teams.

    I am not saying one way is better or worse than the other, but it is an honest consideration in having ways for frameworks and non-frameworks users being able to work together, towards a common goal.

    AKA Producing High Quality, High Scalible, Highly Profitable and Usable Applications that kick the butt off our competitive languages, ASP, Java, JSP, PHP, etc...

    I don't claim to have answers, I just have a few questions and desires to see things improve.

    ReplyDelete
  4. There are many arguments in my mind for using frameworks, but one that I always appreciate and find valuable is how easy it is to apply a consistant security model to your applications. Often in non-framework applications, and especially in multi-developer teams, you find a mix and match of security approaches and sometimes due to this you find holes as well. I have written a kind of jump-start application in Mach-II (and now Reactor) that includes role-based security that I use as a basis for my applications now. If I want to lock down an event I can use an approach in my config xml like:

    <filter name="CheckLogin" />
    <event-arg name="RoleId" value="2" />
    <filter name="CheckRole" />
    <view-page name="theSecurePage" />

    In doing that I have now ensured a consistant approach to a) making sure a user is logged in before they get to the secure page, and b) checking to make sure that the logged in user has appropriate rights to the secure page. I am not saying that it is impossible to have a consistant approach to this without a framework, but a framework makes like this so nice, clean, and simple when it is built properly.

    ReplyDelete
  5. That's a valid point as well, but how much processing should there be going on, other than the application that the end user is trying to use?

    ReplyDelete
  6. Roger Benningfield11:23 AM

    RE: Need #2

    That's not really a framework issue... mod_rewrite or ISAPI_rewrite can address the problem no matter how you write your apps.

    RE: Mike's comment

    Bear in mind that Fusebox existed long before Hal and company started cooking up "core files". The original FB was a switch statement, some file naming conventions, and a basic philosophy... those "trappings" were the whole thing.

    So your project doesn't sound at all odd to me. In fact, that's my perferred flavor of FB.

    ReplyDelete
  7. Roger Benningfield11:25 AM

    Oh, good grief. I actually typed "perferred". Blogger needs a spellcheck, or I need to learn to hit "preview" more often.

    ReplyDelete