JavaScript Frameworks

Recently, I've had a big problem deciding what kind of JavaScript M-V-(whatever) framework to use. I don't think there is a one-size-fits-all solution out there, but I have struggled in my first few attempts to find a framework that fits my needs and coding style. To that end, I started building out a framework called TangoJS, but I am hesitant to release yet another framework on the world.

Then I thought... why not build the same application with each framework the same way the TodoMVC project does? I can use it as a way to find a framework I want to use, or at the very least, treat it as research for what to put in my own framework. So here is my goal: in the next 20 weeks I am going to build the same application in at least ten different JavaScript frameworks. First things first...

What to build?

This is always a tough thing to figure out. It seems like every time I want to try out a new framework or library, I struggle with discovering what I can build with it that will help gain the knowledge and take the least amount of time and effort. At the rate new technology comes out these days, you have to ration your time on the bleeding edge stuff or risk losing a lot of time to a fad.

I learn best trial by fire, so I decided that I couldn't build anything that closely resembles existing projects. The temptation to skip past important lessons for a quick result is too great. Sometimes, it is better to learn things the hard way.

I needed something that was simple enough to understand within a few minutes of reading it, but that was complex enough to discover pain points during development. Without any ideas, I decided to start with figuring out my requirements and go from there.

My Requirements

First and foremost, the application needs to be a Single Page Application. Using a server side renderer to do the more difficult template rendering would defeat the purpose of the exercise. I use this technique a lot for handling complicated cases for UIs. It takes the workload off of the browser and lends a lot of utility to problem solving, but it isn't appropriate for this project.

Building a backend to try out different frontends seems like a lot of extra work. A combination of laziness and not wanting a surprise bill from my hosting company gave me the second requirement: No server apis.

Perhaps the most important requirement is the third one. The application has to solve a real world problem. The problem doesn't need to be something that is solved a whole lot, but it must be real.

I was pretty stumped until I ordered a pizza.

The Problem

There are a lot of opportunities for interaction when ordering a pizza. You have to choose how much cheese, the size of the pizza, whether or not it is a specialty pizza, and then if not, what toppings you want on it. It is small enough to be written with a new framework in a week or less, but large enough to get a true feeling for how things are done.

From a purely technical point of view, a pizza customization page requires model binding, nested views, a variety of different form controls, and some event handling. This should be enough to know what advantages or otherwise disadvantages it has.

Getting Started

I'm currently working an example of a pizza ordering page finished in KnockoutJS and am nearly finished. Stay tuned for more on that!