Vanilla JS

I am a proponent of using Vanilla JS [1,2,3,4] wherever possible. It is plain JavaScript without external frameworks. In my last two jobs, I built many feature-rich and cross platform apps using HTML5, JavaScript and CSS, without depending on the popular frameworks such as jQuery, React or Angular. There are numerous articles on the web about the benefits (and problems) of using plain JS, i.e., without frameworks. Here, I present my thoughts and some reading list for developers who want to avoid frameworks too if possible.

Many JavaScript frameworks and libraries fall under two categories: (a) stop-gap measure until the popular browsers can implement the desired and standardized behavior, or (b) short cut way to quickly build a type of application. This calls for understanding the difference between a polyfill library versus a framework. Libraries and polyfills [5,5] are actually life savers for web development. However, frameworks are of concern, because they change way you need to write code, or structure the application, or fit your thoughts in a particular paradigm [7,8,9,10,11,12,13,14]. 

At the high level, many popular frameworks require or recommend developing single-page-applications (SPA). One reason is because of the inefficiency in reloading the framework code in every page of a multi-page-application. Another is for the ability to maintain state between screen transitions. Single page applications have their own drawbacks [15,16] - can cause bulky script injection in run time affecting the performance, or memory leak buildup over time - hence may not be suitable for long running mobile (or even desktop) apps. Without framework, such monolithic code becomes hard to maintain, and with framework, it is hard to develop beyond the features available in or allowed by the framework.

At the low level, some frameworks attempt to do the same things in JavaScript that are available natively in the browser in a more efficient manner, such as via CSS animation/transition or DOM nodes selection. When such applications are ported to mobile, e.g., using Cordova or PhoneGap, the effect on performance is visible. On the other hand, CSS transition and key-frames styles are powerful, versatile and fast, and behaves like native animation on mobile devices.

Emerging web standards and their availability on modern browsers is outstanding. With web components [17,18,19], a chunk of web page and related processing can be delegated to separate independent code. Alternatively, iframes can be used to modularize the software into loosely-coupled components. Unlike SPA, using iframes carefully can avoid long running memory leak buildup - the content and related memory is unloaded when the iframe source is unloaded. Constructs such as defined in ES6 and Promise further help create short, concise and easy to understand code in plain JS.

In the end, whether framework is used or not, good programming practice always wins. I agree that a good framework can avoid common programming mistakes by mediocre developers. However, the technical debt it can incur and the frustration it can cause can be huge if not carefully planned. So are you ready to take the no-framework challenge? [20]

No comments: