The greenfield project is both a blessing and a curse. On the one hand, you’ve been handed the chance (sometimes finally the chance) to start a product or project from scratch. On the other hand, how do you choose a way to build when there’s so much out there? How do you select the right web framework for your team?
There’s the old saying, “if you don’t know where to start, start from the end.” With that in mind, I consider the outcomes of the project first, before I begin. I like to imagine that you can break a project’s outcomes (and 13 criteria) down into four major categories: business, technical, operations, and team, and when evaluating a framework, make sure that the one you choose serves those interests as well as it can.
Business is one of the most evident outcomes to target – you have to solve the business use case. A technical team, however, can get caught up in other details without making sure business is served.
I’m throwing user experience into this bucket, because I sincerely hope your business folks care about user experience. Besides UX, this is also where you’d consider devices and appropriately targeting your app experience.
I’m not sure I know many people who fully understand software licenses, but even so, if you’re evaluating a framework, make sure your business can abide by its license – or pay for licenses if that’s the route.
How does your business team value different priorities, like SEO? What are the things that marketing/sales will be asking of the app (ex. great speed on mobile networks, ability to make badass customer queries, etc.)?
Technically, you need to evaluate the framework as a maintainable and iteration-friendly option. Will your code evolve as your application does?
As for the core, does it do what you need (and things you get, but don’t need, are just junk). I love that lots of framework READMEs conveniently provide bulleted lists of what you get, so be sure to note them.
How does it abstract your data? That’s a chief way that frameworks save time – providing a handy ORM to help you make abstractions.
Does the framework come with testing? Is is the kind you want? A new project is a great opportunity to create a culture of testing if you don’t yet have one.
How’s the documentation (which will help you both on your first and your worst day)? Is it clear and thorough or confusing with gaps?
Extension & Plugins
How extensible is it? Is it painful or enjoyable to plugin and extend (i.e., if you write something yourself, it’s gravy, and on the other hand, chances are, someone’s already written a plugin for your needs).
No web application stands without its operations team. I have a massive amount of respect for these folks – and it’s a good idea to keep them happy.
Consider how you’re going to serve the app when you start an evaluation – if you can’t put the language you want on a production box, then that conversation is a non-starter. There is a similar issue if your operations team can put it there, but can’t maintain it once it is there.
Security and Speed
You’ll also need to consider security and speed (hmm, so many operations concerns are bleeding into dev team concerns nowadays … probably a good thing). Does the framework have a record of maintenance/patches? And are those things accessible and simple to implement? Does the framework recognize and cover common vulnerabilities (ex. injection, etc.)?
The final set of criteria for a framework is how it will impact your team – it might not seem like they do directly, but they definitely will in the long run.
How long has the framework been around? How long will it be around. This will greatly impact your ability to hire. If it hasn’t been around, no one’s done it, and a few years down the road, if it’s out of date, no one will want to be doing it.
Are there user groups, conferences, screencasts, etc. for your people to skill up with? Community help is “free” (because you really ought to give back). As I like to say, if it’s free, take two.
If it takes your people a year to get decent at it (and no one decent is on your team), that means in a year you’ll have an unhappy, bloated application. Giving your people the time to learn “the right way” is key to success in any new project.
Of course, after reading those goals, you have to remember – we are talking about web frameworks after all, not magic code that writes your app for you. That’s the trouble with the framework landscape these days; it can be easy to forget the simple idea of the framework: stop writing the same code over again. But even so, every web app has different needs, so finding the framework that serves those needs is important.
Be sure to look at resources on frameworks that you can find in Safari Books Online.
Not a subscriber? Sign up for a free trial.
Safari Books Online has the content you need
|Web Anatomy: Interaction Design Frameworks that Work cites examples from both the successful and not-so-successful, breaking down the elements that comprise several common interactive web systems, discuss implementation considerations, offer examples of innovations based on these standards, reveal how frameworks work hand in hand with patterns and components, and show you how to integrate frameworks into your process.|
|Head First Design Patterns covers the best practices and experience of others, so that you can spend your time on…something else. Something more challenging. Something more complex. Something more fun. You want to learn about the patterns that matter–why to use them, when to use them, how to use them (and when NOT to use them). But you don’t just want to see how patterns look in a book, you want to know how they look “in the wild”. In their native environment. In other words, in real world applications. This book is for you.|
About the author