"Zero framework"
I was born and raised in China, and watched a lot of movie as 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 happen 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're so many frameworks these days comparing to ten years ago when we virtually have no framework. 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. Luckily, you can achieve everything below
- Page design
- User interaction
- Application workflow
This is referred as "static" build these days, ironically it's a new word, but in old days, it's the only option. If you are not happy about the "static" tag, you can turn the site into dynamic ones by outsourcing the backend 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 Assemble 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.