The web development scene has moved dramatically since my own minor experience at an Internet business company 14 years ago. Back then we created web pages in ColdFusion/PHP/ASP marked-up HTML. Our main tools were frames and tables and a lot of homegrown convention to ensure headers/footers looked right. We spent most of our efforts on effectively using CSS to make our lives easier – not separating views from data or dynamically updating HTML elements.
People now create web applications instead of individual pages. Web apps look a lot like native applications, are responsive and dynamic, and have very high-level frameworks that provide application-wide abstractions for business models and the abstraction of the view logic.
This article describes my current understanding of the technologies used in constructing modern web applications, largely based on a few years’ lurking on Hacker News and a couple weeks’ not-so-intense investigations.
Modern web applications are built many layers of abstraction on top of this. An extreme and relevant example of this is the XMLHttpRequest (hereafter XHR) function. Prior to HTML5 WebSockets, all single-page web applications used this single function to receive dynamic updates from a remote server, through a technique commonly known as AJAX. Likely few web apps actually use the function directly however – most these days use high-level MVC frameworks (more on these below) to connect the visual elements the user sees in their browser (the view) to entity abstractions updated from a remote server (the model).
Here’s a few reading recommendations I would like to read one day:
- MVC Architecture for JS – building an MVC framework in JS from scratch
- Large-Scale JS Application Architecture – a guy who knows his stuff on various approaches to building ‘large’ web apps
- Mozilla Developer Network – Intro to OO JS – everything you need to know on how
newprovide OO on top of simple JS function
thisworks, for example)
It’s very difficult to figure out which of the myriad JS frameworks are worth investing in, as they come and go and are easily replacable. However some toolsets and frameworks have become totally indispensable timesavers to anyone making a web application.
- jQuery – a low-level toolset that vastly simplifies common JS tasks such as manipulating the DOM and using XHR
- RequireJS – a library that makes including third party modules simple
- Handlebars – a very popular template parser that uses
- Backbone.js – allows user-defined model objects to be dynamically linked up to HTML elements for automatic updates
- Ember.js – an exciting MVC framework that I think is built on top of Handlebars and Backbone, or something like it. More below
- Angular.js – a Google library that promises to deliver similar functionality as Ember.js, but with a syntax that is meant to look more like a natural extension of HTML
I think I’ll likely want to look into at least these frameworks:
- Yeoman provides a set of tools for creating and manipulating a web app on a workflow level
- Bower for application dependency management. It automatically downloads and configures dependent frameworks for an app
- Grunt for running preconfigured tasks from a Gruntfile. For example running, testing and previewing web apps
As an example of these technologies, here’s what it takes to create a basic Ember.js application (a more in-depth starter can be found here):
1 2 3 4 5 6 7 8 9 10 11
Serving and hosting web apps
I’ve been concentrating mostly on the browser end of the web application architecture equation. So far my thoughts on the matter of hosting haven’t really gone too far. Two obvious options come to mind however.
A Yeoman-generated Application that I think by default uses a simple web server like Unicorn, started from a Grunt script. There are plenty of instructions on the web for deploying these applications to Heroku or other hosting services.
A Rails RESTful Application hosted on something like AWS. Ruby on Rails is a hefty web framework that also follows the MVC framework. I think it’s a full-stack framework in its own right and prefers its own HTML templating engine. I intend to use it to expose a REST API instead of HTML however so I can totally separate the server logic from the UI framework, and perhaps write separate front-ends altogether.