Cool front-end technologies we should be inviting to "the party"

Backbone.js (or other MV* frameworks)

Backbone is used for building single page architecture applications, and by single page meaning that the entire page, screen, view handling is performed internally by the application inserting/generating DOM content and not by requesting a new HTML page from the server.

In Backbone concerns are split into views, models and collections - this excerpt from the Backbone.js website explains them eloquently:

"With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a "change" event; all the Views that display the model's state can be notified of the change, so that they are able to respond accordingly, re-rendering themselves with the new information. In a finished Backbone app, you don't have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves."

You don't store and query the DOM for your data this means, everything happens directly from your models, so that working with JSON and REST is the preferred method of working with the server.

Examples:

http://www.usatoday.com/
https://soundcloud.com/
https://www.easel.io/
http://earth.nullschool.net/
http://www.jolicloud.com/

Benefits:

• Far more organised and scalable!
• Decouples front and back end development - a lot of the features/functionality of the Backbone.js client application can be developed in isolation from the server, using mock JSON obects. This means environment set-up is less of an issue. When problems occur on an env. back-end devs won't waste time fixing, front/back-end aren't so dependent on what each other is working on.
• The client / server application paradigm makes testing easier. Backbone.js plays nice with unit testing frameworks Qunit, Jasmine and SinonJS - TDD on JavaScript
• Requesting chunks of HTML from the server to replace blocks of the page is over, instead, when a change occurs on a model, a view listening to state changes will automatically re-render that information where ever it exists on the page and target the change to the exact DOM node on the page if necessary - no page reloads to update the view state!
• All data on the page is in sync. and consistent
• User experience is much slicker - interface is much more responsive, page changes and fragment loading is handled gracefully
• Page state is handled via URI hashes or HTML5 push state - A router object listens to URL changes and handles state changes via method calls. Behavioural analytic tools like Piwik and GA integrate well
• Back-end developers would look at views as JSON outputers, no need to worry about handling JSPs and assigning ActionBean properties
• Backbone.js using technologies like Require.js (AMD) encourages composite development. This makes scaling JS applications, adding and changing functionality is much easier

Asynchronous Module Definitions - Require.js

Require.js allows JavaScript code to be separated into self-contained modules and then intelligently handles a module's dependencies.

Sprinkling Asset.load calls down the page in no particular order is bad practice! How do you explicitly handle dependencies? The only way to do it is by changing the order of calls in the document and that isn't practical or explicit. Instead Require.js uses one single entry point on the page, one single <script> tag in the head which loads the Require.js library, then starts your application and loads the define module which starts your application.

Your code is then split up into modules where the dependencies of that module are explicitly called at the top. The global window object is not polluted!

When deployed into production, there is a build process that bundles modules up into one or two files so that 20 HTTP file requests become 1.

http://requirejs.org/

Handlebars.js - templating

Handlebars is a templating framework where templates are compiled in the browser. It uses syntax based on Mustache and comes with logic for block expressions, conditions, iterating over collections and an assortment of helpers which are customisable.

Working on Virgin Money i've witnessed some pretty crazy practice where UI is generated by calling the Mootools Element method and then layered up until the desired structure of that dynamically generated DOM content is created. The code to do this was complicated, ugly and not maintainable. A Handlebars template is straight forward, intuitive and highly maintainable.

http://handlebarsjs.com/

Bootrap 3.0

Bootstrap is a UI toolkit full of common UI components and best practice patterns for HTML/CSS development - it uses a consistent naming standard/conventions so multiple devs working on the same CSS document making changes don't get carried away with their own quirky, esoteric way of labelling - they have to conform to a standard that everyone will intuitively understand and adhere to. This means that theming is very easy to achieve and ultimately everything is consistent. Plus an awful lot of boiler plate code is scrapped in the process by using and reusing common components.

http://getbootstrap.com/

LESS / SASS - CSS pre-compilers

Extends CSS to allow nested rules, mix-in functions, expressions and variables within CSS. This then compiles into standard CSS when deployed into production, and in development a JS plugin compiles in the browser.

http://lesscss.org/
http://sass-lang.com/

Server Sent Events and WebSockets

This is just cool more than anything else. These technologies allow your interface to be essentially real time. WebSockets aren't HTTP! It's not about request, response, die. Client and server establish one single connection for the entire session, then exchange data via messages which are two way. Any update to a database or other event on the server can be immediately be published as an event to the subscribed client. You can simulate this using "HTTP long polling", where a client makes an HTTP call to a server, and only when an event occurs will the server send a response to that call, the client makes an another long poll and continues in that fashion repeatedly - it's quite inefficient though.

http://socket.io/ - this is just for Node.js - not sure how this would work with Tomcat/JBoss in Java to be honest
http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet
http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource