On Frameworks

Building any non-trivial app, one of the toughest decisions to make is which development framework to base your work on. And there’s no way around this decision once you realize there’s no such thing as “not using a framework.”

Even if you’re just binding together 3rd party components, a framework will be born out of any development work, and it will have its own tradeoffs to consider.

  • Will it be documented?
  • Will it be tested?
  • Will it have a community of people working on/within it?
  • Will it have a plugin architecture encouraging code reuse?
  • Will you have access to plugins written by people outside your team?
  • Will configuration be easy/reusable?
  • Will it address code/UX scenarios you hadn’t considered?
  • Will you get free bug fixes/features from outside developers?
  • Will it securely handle password and protection against XSS, CSRF, etc.?
  • Will other developers be able to jump into the project?

Developers, plugins, sub-frameworks, tools, and shops all form an ecosystem around a framework that tends to build value as it grows. A strong ecosystem can make up for product weaknesses; a trip through the Drupal and WordPress codebases will have some seasoned developers shuddering at some architectural choices made (long ago), yet that code runs great due to the work of tons of people over time. And, thanks to the wealth of plugins available, and to the continual transfer of knowledge from one developer to the next, devs who are experienced on those platforms can build impressive systems quickly.

On the flip side, there are properties of mature frameworks that are important to consider:

  • They can be slow to change, which may mean maintaining a separate git branch with your own fixes.
  • They rarely bend to support the use cases of individual sites.
  • They tend to have older code that may be harder to integrate with the latest practices.
  • They can be large; any framework that solves a lot of problems out-of-the-box will be. Microframeworks can be a great choice, but their value tends to be limited to plumbing.

Thankfully the ideal framework needn’t be chosen first. You may be better off prototyping something as quickly as possible—by any means—then rebuilding after the requirements are clearer. The danger is the temptation to ship prototypes as production systems, where they grow to become liabilities over time.

EA Skate started as a text game

EA’s Scott Blackwood talks about prototyping the flick-it controls for EA skate.

But we really liked it on paper. We worked with our lead programmer at the time, and really, in about two or three days, he built a prototype, and it was great. We actually were up and playing the game — no rendering, no game, and no animations. But what we did was that we were reading the stick, and we could start to dial in different gestures and motions.

We could put in any different gesture and say, “We’re going to call that a kickflip. That’s going to be starting in the middle, going down to six o’clock, and then up to one of the sides.” And it would spit that out and say, “You did a kickflip.” It would measure it based on how accurate you were, and we would rate that from one to five.

So one was like, “Okay, you weren’t really accurate, but you sort of did the kickflip.” Five was, “You did it perfect.” The other one would give you a rating based on the speed with which you did it. So one was like, “You were kind of slow,” and five was, “You were fast.” So if you could be five and five, you did it fast, and you did it perfectly accurate.

It was funny, it was just a little text-based game with flick-it controls, that turned into us grabbing the controller from each other going, “Oh, I can do better than that.” And we dialed in… how we imagined flips, ollies, and inward heels and all that. We were playing the game a year before we ever had to care about graphics. And we learned a lot, too. With prototyping, it’s amazing the things you learn.

And the physics engine:

Actually, at that time, RenderWare had a really cool physics package that one guy developed, and they were called Drives. Essentially what Drives were, was a hinge. It’s a neat way to make an intensive thing like a saloon door.

Our guys took these Drives and turned them into all the joints in your body. So now with Drives, we can create a full, physically accurate replica of the human body and all the joints, and you can even… say, take your right knee, and we can weaken it by 50 percent, and your guy would walk differently, based on that. So we use Drives as the foundation for everything that we do in physics, even your skateboard. Your trucks are Drives, and your wheels and hinges. Everything’s Drives.

In fact, the way you’re popping your board off the ground, it’s not animation-driven. It’s actually real forces on that board popping off the ground. We’d never have been able to get the same feel without our team [taking the] foundation of Drives and [building] a lot on top of it. We did mocap, and we have all that animation in the game, but animation is a target.