Sunday, August 9, 2009

Choosing a Web Development Framework

Here is a list which helps in choosing the web development framework -
  1. Support for MVC (most frameworks have pretty decent support for that now)
  2. Extensible MVC (need to be able to extend the way controllers and views operate. Some frameworks do it by convention and limit you to a set of popular conventions.)
  3. Allows you to build your domain in isolation. (I want my domain model to be completely decoupled from any web technologies, persistence, etc... Just a plain OO domain model)
  4. Gives you very flexible persistence options. (I might decide to use a fully featured ORM (ActiveRecord is not fully featured), or I might want to use SQL, or heck, I might want to do both for efficiency or to scratch a morning itch, who cares about the reason, please let me choose. Oh, and one more thing, what if I don't want to use a SQL database at all? I want to use a native XML store or better yet a key/value store. Even if it's just to piss someone off, I want to do this and one should be able to accomplish that pretty easily. I'm not asking for a mapper for these stores, simply just don't make your framework bound to some relational store though making the work of turning this dependency off a 5 hour chore.)
  5. Supports AJAX (I should be able to easily render JSON or XML views, without much plumbing or lots of mappings and annotations. The authentications and forms support should also expose some form of ajax compliant interfaces, so that forms and authentication can be done using ajax if I choose so. Be able to easily parse submitted data into some data structure and validate/synchronize it with the domain model.)
  6. Bindings (All frameworks have some sort of bindings. Some of them are limiting. I don't want to create command objects to just simply bind the data and than synch with my domain model. If I have domain object graph(s), I should be able to bind it in the view layer. Bindings should be customizable. In Spring MVC for example, you can only bind one input control to a field or set of fields in the command object, but what if I want to bind 3 input fields that collectively represent one field in the domain object, I'm out of luck, unless I use javascript to first serialize those input fields into one field. That really sucks.)
  7. Support RESTful, stateless, and other web concepts in a straightforward way. (I want to be able to configure every part of HTTP and the web and make the application work, look, interact in my way that's compatible with the web, not your way. Some component based frameworks make that harder that it should be, like the fact that they are inherently stateful by default. Some make it hard to support RESTful or custom URI schemes, because they transfer state through URL rewriting. All of these problems don't exist in some frameworks, like Rails, Spring MVC, Grails, etc..., so I know it's possible.)
  8. Validations (Most have fully fledged validation support, but I can't say that it can't be made a bit easier. I do like Spring's flexible validation support.)
  9. Forms (This is a big one. Can you provide a flexible way of creating forms and layouts. I mean seriously, we're developing forms today the same way we've developed forms 15 years ago. Every other aspect of development has moved on, but we're still doing bullshit html form controls. XForms is a way out, but no browser support and pretty hard to integrate support from vendors like Orbeon and Chiba makes the standard useless. Can we either embrace it or come up with something else. Am I the only one that gets an anxiety attack every time I think about creating yet another interactive form that doesn't do anything much differently than the form I created 4 months ago for a different project, though I either have to copy and paste all the cruft or start from the absolute scratch. Wow, that's sad IMO.)
  10. Scalability. I know this one again is not up to the framework, but as I mentioned before, the framework can make it easier or harder to achieve. For example, inherently stateful frameworks that require either session affinity or replication of session state, make it very hard to horizontally scale. Yes, I know you can scale with replications tools available out there, but any synchronous replications is not linearly scalable. So any such frameworks makes it harder. There are many other criteria that can make a framework more scalable than others, but in general, statelessness, stability, and speed makes it viable for faster scalability tunes.)
Original Source

No comments:

Post a Comment