JavaScript web technologies have sprouted like weeds over the last few years. While I was busy working on desktop and mobile applications, it seemed like a massive JavaScript wave engulfed the software world. The last time I did anything in the web space was with ASP.NET, AJAX, Silverlight, Flash, and a little Ruby on Rails. When I did use JavaScript, it was only within a very small <script></script> block, used to manipulate the page elements via the DOM. As I kept hearing new buzzwords, it felt like I was drowning under the noise involving ‘something_new.js’ every day. So I decided to learn to swim by wrapping my head around these buzzwords. After scouring the internet and working on a simple tutorial, this is what I learned in succinct bullets:
Node.js
- is a platform used to create a web server and a web application all combined (no need to use Apache or IIS)
- runs on Google’s open source V8 JavaScript engine/virtual machine (same as used by Google Chrome)
- works in Windows (XP and later), Mac OS X (10.5 or later) and Linux (using IA-32, x64 or ARM processors)
- is lightweight
- usually runs as a single process
- has a single thread listening to requests (unlike traditional web servers), using an event driven architecture to handle them without blocking (see this post and this discussion to understand what it means)
- can be told to spawn child processes, to take advantage of multiple cores in the environment
- is stateless
- can be used with frameworks like Express and Restify and a million others that handle standard parsing of requests when creating browser applications and REST API services
- has a package manager called npm, used to download and install node.js libraries seamlessly, and run scripts defined in a package.json file
Angular.js, Backbone.js, Ember.js, Knockout.js, You name it.js
- are frameworks or libraries that allow client side JavaScript code to be written in a structured manner, without using hidden fields and other page artifacts used to store state information
- reduce the amount of server interaction, making the site more fluid and reactive
- use MVC style architectures
- have in-memory models to store state and data used by views
- use declarative templates along with data binding to render the view layer as HTML (similar to XAML in WPF, haml in Rails)
- are stateful, keeping track of user history
- reduce dependency on the DOM (or page elements), requiring less testing for cross-browser compatibility
Read this blog post for a detailed (albeit a little old) analysis of eight (the post says seven) of the frameworks.
WebSocket
- is a persistent, living connection between a web browser and the server, allowing two way communication to happen at any time with and without user interaction
- allows the server to send data as it becomes available, without having the client poll for data at regular intervals or use a technique called long polling, where the server keeps the request open till it is ready to send data
- is an HTML5 specification that defines the protocol and API for communication
- uses the same http and https ports of 80 and 443, respectively
- requires client side JavaScript to interpret the WebSocket handshake, and establish and maintain the WebSocket connection
See this for a very good explanation of a WebSocket connection.
Single Page Application
- is a single, server rendered HTML page that is manipulated by client JavaScript to display multiple application pages to the user
- involves the server after initial render only to asynchronously retrieve HTML fragments/templates or data
- gives the user the impression of a desktop app, because of the seamless update of relevant parts of the page on demand after initial load, without posts and gets that cause the whole page to refresh
See this blog for a good analysis of an SPA.
Now I feel a little less intimidated by the new web.
