Why I Don't Want Your JavaScript Framework but I Love You

If you were to start a web project today, would you start it from scratch, or go through a framework election process? Would you use the framework you are most comfortable with or the framework you last used on a project while it's still fresh on your mind?

With all of the articles and tutorials available on the web with titles like "What's the best JavaScript framework for you?", and "Which JavaScript framework should I use for my project?", I'd like to to propose a question: are developers even asking the right questions to properly harness the information available?

Plan your application before planning to use a framework

Has enough work been done in the planning stages to understand the components of your application?

A user on StackOverflow posted a really specific query with a detailed level of planning and analysis (it's really worth a read and an upvote). The user clearly lays out the basic and advanced features of their application, an analysis of the frameworks/libraries they've considered thus far, and asks, "Where have I gone wrong?"

This is a posting that demonstrates that they "get" engineering and problem-solving, and that they are simply looking to improve that capability with the help of eager community members.

This doesn't need to be a post stressing the importance of planning, so I'll leave you with this:

He who fails to plan is planning to fail.

  Winston Churchill & a fortune cookie I once read

Understand the concepts of application development

Can a framework-user deeply grasp the vast amount of decision-making being done and opinions enforced by authors of and contributors to these frameworks? Is an effort consciously being made by the framework-user to absorb the implementation details of these decisions and assess the validity of these opinions as they go?

No matter which framework you elect, if you think you can bootstrap your project and get to work right away, you may find yourself refactoring the project two or three times as you burrow neck-beard deep in shoddy documentation, only to realize your assumptions about the development of your application do not align with the framework authors.

The truth is, under the hood of these frameworks, a lot of decision-making has been done by a lot of brilliant people. Supporting two-way data-binding in IE6 is not a trivial engineering feat by any means. Client-side Routing in IE < 8 is no trivial feat either! I certainly wouldn't want to write these from scratch every time I need to support IE<9.

If you've never worked with client-side routing or two-way data-binding at all, you may not be the right candidate to build an application with those features in legacy browsers - at least in a production capacity.

It has nothing to do with your intelligence or capabilities, and everything to do with this simple point: when there is a bug in production, and a contracted client needs a solution as quickly as possible, do you want to spend the next 2 days awake next to your coffee machine trying to save your employer's reputation?

In contrast, one of the great things about these frameworks is that they are a collection of Best Practices and expert techniques that allow less experienced developers to quickly perform feats that may have otherwise been a major undertaking. The important thing is to read the source of your chosen framework and develop an understanding of these features while you are using them, so that if and when you have to troubleshoot them later, you know where to look.

If you consult the source of the framework as you are developing with it, you are avoiding this common pitfall of framework usage: successfully developing an application while neglecting to strengthen and grow your own abilities as a developer.

Match framework features to the components of your application

Popular Google Search

Do these frameworks list available features or merge hype with marketing to create initial intrigue?

Developers (myself included) tend to think we are immune to marketing antics. A manager once told me, "Every decision you make is the result of marketing." This viewpoint is incredibly cynical (I like cynical), but according to Politifact, Mostly True.

The Ember.js team's home page actually does an incredibly good job of listing the primary features of their framework. They also do an incredibly good job of breaking them down into digestible laymen's terms - instead of "two-way data-binding", they say "your HTML stays up-to-date when the underlying model changes."

They also say "Ember.js incorporates common idioms so you can focus on what makes your app special", which is an incredibly vague and loaded statement, whose repercussions you may not discover until you're halfway through the project thinking about how you wish you used framework n instead.

Knockout.js offers "Templating", but the flavor of templating offered in Knockout is DOM-invasive and, if poorly implemented, can generate major code smell. Additionally, they do not support alternative template engines like Handlebars - although you could write your own plugin. I completely understand why the core team wouldn't want to be responsible for a variety of templating engines. If you get to the point where you say, "Okay, they have templating! That's what I need!", you download it, and start building your application around it, you may then realize you cannot bear to look at your HTML anymore.

Just a quick note: I think the Ember and Knockout teams are incredibly brilliant. I also think that a lot of effort has gone into increasing adoption that might have been better spent improving documentation (FWIW, Ember's documentation is stellar compared to earlier version). For example, at the time of writing this post, neither framework has a comprehensive listing of supported event types for Views.

Measure the value of a framework while you use it

How much time do you save bootstrapping your application compared to time spent searching documentation to accomplish things you may already know how to do?

A lot of frameworks claim to take care of the boilerplate for you. Exactly how much time are you saving? The next time you give your employer an estimate, are you going to be able to reduce it by n because you use framework x? The next time you refactor your website? Or begin a new personal project?

Make sure each time you use a framework, you can measure the time it takes you to accomplish regular tasks:

  • initial project setup
  • basic features of your application (routing, MVC structure)
  • web-service integration

Are these frameworks living up to their promises? Tools like ember-data and Angular's ngResource will have your RESTful API functional so fast your head will spin! The first time I ever loaded ember-data, I actually thought it was magic. Thankfully, the source revealed otherwise.

Reflect on your learning and measure your growth

What impact does using a framework have on your problem-solving capabilities, marketability, and future in this field?

Based on some loose Google Trends data, and any number of messages from recruitors and job posters, you can see that framework experience and usage can certainly increase your up-front marketability.

Expertise with a particular framework may even be a requirement for some businesses. I highly recommend avoiding companies who put a higher value on your understanding of a framework than your understanding of engineering. It's a nice courtesy that it is mentioned in a job description, but, an organization who clings to framework names is probably just as likely to fall for the hype on the front page of those frameworks' websites.

Remember you are not an [Insert Framework Here] developer, you are a developer - an expert - who knows when to use a variety of tools available. And there is no doubt that there is a right time and place to use these tools.

If you look deep into Angular's ngResource/$resourceProvider, you'll not only realize how much goes into securely/correctly integrating RESTful webservices, you'll also realize:

  1. That it's the next morning
  2. The sun has risen and you're late for life
  3. There is a lot to learn from the developers behind Angular.

It's important to keep in mind that the time you spend groking this stuff is incredibly valuable for your growth as a developer, but also can take as much time as coding your app without a framework.

Additionally, remember to factor in the time it might take you to healthily consume the learnings you can achieve by consulting the source of your chosen framework. I cannot stress enough how important it is that team members continue to relentlessly increase their engineering prowess.

When the project is over, your employer will appreciate that they have a team member who has "leveled up" and gained experience that can be applied to future projects.

Ponder the impact on a larger scale (and why I Love You)

What impact does it have on our field when newcomers are learning JavaScript frameworks before learning JavaScript, and potentially delaying the learning of core concepts of application development?

This isn't something I expect framework authors to react to - keep doing what you're doing because it's awesome, you're awesome, I love having the opportunity to learn from you folks, to help where I can, and to use these frameworks when they are appropriate - but lead developers, mentors, teachers, tutorial authors, and people answering questions on StackOverflow should really think about the impact this has on the long term problem-solving capabilities of their coworkers, students, or readers.

The web as a platform is becoming increasingly more advanced, and there are some brilliant superheroes working on specs for awesome features coming to a browser near you. Other people are talking about Zero Framework Manifestos and the ways the new features of the web will decrease the need for frameworks.

A few years from now, or maybe even a few months from now, some of these frameworks may lose relevancy. But you and your team members will be engineering solutions for years to come, so don't let any out-of-the-box solutions get in the way of honing the craft!

comments powered by Disqus