Why you should consider not using an MV* JS framework
The problem
Building JavaScript applications that run on the client with little to no server side logic (mostly database interaction & static file serving) has become commonplace and has many advantages.
But then…vanilla JS is too verbose, and apparently very unopinionated which makes it a poor choice for big, enterprise team projects. The solution? We make a framework that abstracts the JS/DOM API and gives us simpler syntax to write applications in well tested, old & proven, patterns such as MVC.
And a whole jungle of web frameworks spawned into existence. All good right? Not until you realize the volume and level of abstraction we’re getting at. In fact, as you read this, there is a very good chance that someone is thinking of starting yet or actually writing another framework (Actually I’m fairly certain that’s true. Just have a look at TodoMVC.).
Not only does this create conflicting standards, confuse newcomers to the JS land, and reduce awareness of vanilla JS, but it also causes rivalry amongst the community and defames the whole ecosystem to developers coming from other languages (C# — I’d know…).
On the other hand, I do acknowledge that some of these frameworks maybe necessary for some projects. What I’m against is the existence of multiple frameworks that solve different problems instead of a single (perhaps 2 or 3, not a billion) framework that is heavily supported by the whole community.
I know what you’re thinking — ‘so you want to create yet another framework to rule them all?? That’s more fatigue!’. No, I’d like to make a less common suggestion hoping to ending all the drama.
The solution
Instead of writing & sharing frameworks that define their own rules, I am suggesting we start writing & sharing vanilla JS file organisation patterns instead.
This means, for example, having a standardized MVC file organisation pattern for JavaScript client side apps. Any disagreements on the structure of the pattern would give birth to a new way of organizing the files instead of a whole new framework.
These file organisation patterns would then be used in conjunction with vanilla JS (or JQuery if you desire) to produce apps that have an accepted structure
MVC file structure pattern example (and strictly an example):
- App
- — Views
- — — index.html //Main html to add cloned elements to
- — — reusables.html //Contains resuable html elements to clone
- — Logic
- — — domElementGrabber.js //Clones & stores elements
- — — dataLoader.js //Loads data into stored elements
- — — domElementAdder.js //adds edited elements to html
- — Controller
- — — init.js
- — — connectToServer.js
You get the idea. In a nut shell, why don’t we start sharing large organisational design patterns instead of creating new frameworks? It would reduce framework fatigue & allow for more organised, easy to understand (since the patterns are documented) projects that would allow effortless team collaboration .
Note
I, the author, am not the most experienced JavaScript developer. Please don’t take anything I write here offensively or too seriously. Feel free to debate any of the issues discussed, I’d love to be shown wrong!
