Stay ahead and focused
Sep 16

Zero Framework for Solid Development

This article raises an interesting way of prototyping web application by using no fixed web framework. A classic "static" build is suggested instead to be used as the foundation of web projects where all other fancy framework (if integrated later) can fall back on.

I was born and raised in China, and watched a lot of movie when I grow up. There's always an old guy who can beat the crap out of bad guys by doing nothing. Yes, literally nothing, he does not need to prepare, and do very little movement and then he just get the job done. I think that was fairy tale. Well it is fairy tale, btw.

World with frameworks

Retrospectively speaking, picking any project that I have done in the past, there're majority of time the tech teams battles between different frameworks. And if we decided to use one, there's always a slight chance that we'll throw it away and do it again in another framework. Some of the projects actually just couldn't survive after one or two of these battles.

We have AngularJS, NodeJS, React, Sails, Ember, Meteor, the names can go on and on, everyday there might be some genius guy come up with some genius way of doing things. Each speed up one aspect of web development. Mastering each makes you more like the bad guy who just happened to find the killing weapon that can kill anyone with one blow.

Does mastering any particular framework actually make the web project any easier ? Ironically, the answer is No. I guess the problem isn't the tool or skill, it's the way you look at the problem.

When I refer to web project, it's the overall web project, from information architect, prototyping, developing, deploying etc. Therefore the efficiency does not solely depends on the tool we used for development. Also if you change the tool in the middle of the project, the overall efficiency can be hard to measure.

How about zero framework

There are so many frameworks these days comparing to ten years ago when we virtually have none. Back then, artist creates mockup, hands over to a guy who chops the images and put in a HTML layout. During this process, the project owner monitors the process and makes sure the project is delivered as planned. Pretty straight-forward, I don't recall anyone was unhappy about the process.

So suppose we use HTML as our only tool. Draft vision in mockup, code it in HTML and call it a day or move on to another page. Ten pages later, we stitches them together using a navigation menu. And then we have a website or web application prototype. It's static, but only static in data, not in interaction. Because you can add all the Javascript/CSS you want. You can achieve everything in the following list

  1. Page design
  2. User interaction
  3. Application workflow

This is referred as "static"2 build these days, ironically it's a new word, but in old days, it's the option. If you are not happy about the "static", you can turn the site into dynamic ones by out-sourcing the functionalities to third party web services.

If you are interested at "static" build, there are quite a few "static generator" in the market, ex. StaticGen, Hugo, WinterSmith, and Assemble1 etc. These tools help you work statically without sacrificing template redundancy and dynamic data.

Summary

This "static" build is apparently not suitable for everyone, as not many people can beat the crap out of all bad guys. In my general practice, it's really good for start-up companies, start-up ideas, or any prototyping projects. Master this approach, you'll have very solid foundation to start with, which even fancy technologies can fall back on and be more effective and compatible with your entire project.

References

  1. Assemble IO — Build Something
  2. Build Dynamic Website with Static Approach

Comments