Development Wars: Misperceptions of Front-End Development

I am convinced that something went awry in programming (or maybe in programmers) at the genesis of the World Wide Web. Prior to the meteoric rise of the Net, developers understood with abundant clarity creating applications required software engineering principles be applied from the server through the client fully. But with the advent of the Web, the front-end became relegated to the domain of template-makers and snippets of code not organized in any specific methodology. It was a reduction which did not concentrate flavor, as in cooking, but compounded egregious loose habits, rendering front-end efforts a thin soup of muddled HTML, CSS and Javscript .

Proper separation of presentation and core business logic is a necessity for good software development. We all worship at the temple of the Model-View-Controller (MVC) pattern. However, there are nuances to the MVC faith. In the early years, one faction found favor and was embraced unstintingly - the Controller was wholly the purview of the server-side, and the View essentially became a slave, a thin client without any cognizance or idiomatic expression. Indeed, the state of affairs became so dire the back-end generated HTML and spat it back to the View for display. Here, the pattern was obviously blurred. Why should the back-end care about display? The Model exists to preserve state, and sufficient decoupling from appearance allows the Model to serve as a engine for many Views of the same data to be displayed contextually as per user/role requirement.

Besides, on the presentation side, logical flows which enhance user experience required some mechanism to enact a microcosmic MVC expression. Enter the XMLHTTP Request Object. The ability to make requests to the server without reloading all the scripts running in a page opened a host of potentialities and catapulted the front-end into the arena as a possible contender to share the Controller with the back-end. Further, these interactions on the front-end made it absolutely essential that there be an overall coding strategy adopted.

Javascript up to this point had been widely used to compose scriptlets dealing with form validation and some level of event handling; but its capability far outstripped these utilizations. Due to its open nature and flexibility, it is a powerful tool which can see the realization of true object-oriented code for extensibility. This necessitates creating wrappers and idioms for things like classes, object instantiation, inheritance, polymorphism and encapsulation. Quintessentially, behaviors native to Java and C++ can be simulated by nurturing the construction of a framework to guide and gird developers from unsafe practices with Javascript.

The greatest challenge has been that whatever virus the back-end developers caught at the beginning precludes them from grasping that exactly what they construct on the server-side is infinitely possible on the client-side. Design patterns are solutions no matter which code they reside in and can be emulated without regard to programming language. Scripting languages should not be regarded dismissively because they are interpreted. Java, usually the principle argot to the back-end, is both compiled (to an intermediate format) and interpreted. So if one casts stones then one must be careful to not crack the house of glass in which one resides.