Recently, I have been developing using a new front-end technology stack that includes bootstrap from Twitter and backbone.js (a subcomponent of DocumentCloud.org).
Here is a partial list
Bootstrap has had a lot of adoption in the last few months. It offers a great out of the box set of styles and behaviors that make sense, allowing the quick development of 'responsive web design' web designs that know the limits of the device at hand and respond by tailoring the layout appropriately. It requires jquery (of course) and builds on jquery.com by providing layout and default styles and a few basic components with great default behavior. Its CSS is managed nicely using less.js to provide your CSS with variables, mixins, functions etc.
Backbone is a javascript library supporting an MVC like framework to develop single page web apps (rendering a complete UI in one html page) where the only time to go to the server is to interact with REST resources for data. It organizes code into models, views and collections. It's 'controller' is implemented as a router that allows linking to behavior and routing as bookmark-able URLs for browser history. Views typically use client side template resolution implemented by underscore js and not implemented on the server. Models structure information passed to and from the server. Collections are collections of model objects that are associated with a REST resource on the server and support CRUD operations.
What is obvious by analyzing technology innovation on the front end is how much we rely on good javascript skills to make it all happen. However javascript allows as much clumsy programming as it offers in elegance (read JavaScript The Good Parts by the Great Crockford). Larger scale javascript code can be quite strange to read when trying to leverage the good parts and organizing js into classes and modules to scale. So pre-compilers like CoffeeScript and Closure offer amazing lexical simplification and cleaner code organization and optimization. Neither of which we are using currently, but we possibly may. The elegance and readability of coffee-script for instance or the compression and performance enhancements with Closure are very impressive.
Further, writing large scale javascript application requires more than just MVC, it requires modular development. Wrapping the javascript into good modular design is accomplished following the AMD pattern (as explained well in this blog). Using require.js helps solve the problem of dependencies when javascript itself has no 'import' or 'module' commands, as well as allowing asynchronous loading and plugin architecture for the loading of different kinds of resources (like text)..
And what about testing? Our team is big on developer testing before tossing our project off to QA, and we like practicing TDD (or now BDD). There is QUnit from JQuery. But we are beginning to use jasmine. Jasmine, like QUnit runs tests and renders results on a nifty html page showing passes and fails. Integrating this will a build system for continuous integration (CI) is more of a challenge. That brings us to automated building, packaging, deploying, and continuous integration testing and analysis.
Our back end is traditional J2EE. We expose REST resources via Jersey and interact with business services and information via EJB3 and JPA (and also the great SOA Suite layer from Oracle with BPEL, a Service Bus and traditional SOAP based service integration. We build using maven, continuously integrate with Hudson, run JUnit tests and generate reports on code coverage via JaCoCo or Coberatura. On the back end, we are used to automating this build and deploy cycle and assuring no breakage after each check in. But these tools and techniques are new to us on the front end side..
We need solutions for automated and scripted builds, running and analyzing tests, code coverage and other static analysis using continuous integration techniques. At least that is what we are used to and expect. This process must/should integrate with our existing continuous integration and code analysis tools if possible. Tools offered as part of Node.js are possible solutions. Also maven has a javascript plugin. Many others exist as well. Further analysis is required on this. I will update progress on this blog.
Sunday, October 14, 2012
Friday, October 5, 2012
The front-end Moves to the Front Seat
Sometimes the new is old. Back in the 'client-server' days (yes, I'm that old) the main development cost was on the client side. Using the likes of Powerbuilder, Visual Basic or other tools, developers would spend fantastic amounts of time on the front end connecting directly to a database, embedding sql (or proprietary data access api) and creating interactive screens and windows to present and manage data. A three tiered architecture would enhance the database operations with procedures or tirggers to enable server side processing. A brave few created purpose built server API's in C to support a true middle tier between the client and the database. And transaction managers and message oriented middleware were engaged to connect everything together. But even then, the main application logic would fall on the front end.
The web moved us back to a more 'time share' IBM 360/CICS/3270 kind of model (no, I'm not that old) where the client took a back seat and the application logic was all rendered on the server. The browser was the new 'terminal' displaying html pages with form fields and submitting requests to the almighty server to dice up a screen for the response. Though the back end divided into multiple tiers separating application front-end logic (typically a markup language) from business logic (e.g. EJB) from the database and other resources (n-tier), the client (browser) was still basically a dumb terminal. There were some spikes to make the client smarter: applets, flash, etc. and some javascript to enhance the experience with more sophisticated controls. But the browser was still a speed bump to drive processing to the front end.
Today the client is taking the front seat again. JavaScript, HTML5 and powerful and fast browsers have allowed much more sophisticated processing running on the client. New frameworks such as backbone js are allowing developers to build entire applications with a single page html dynamically rendered by javascript where the only interactions to the back end are to manipulate the data not render the screen. The client development is reminiscent of small talk, relying on Model View Controller (MVC) architecture to separate the display from the data and the control. The back end remains basically stateless providing a thin logical access to CRUD operations on data, and implementing business logic to shape, compute or aggregate data and coordinate functionality with other resources and tiers.
The web moved us back to a more 'time share' IBM 360/CICS/3270 kind of model (no, I'm not that old) where the client took a back seat and the application logic was all rendered on the server. The browser was the new 'terminal' displaying html pages with form fields and submitting requests to the almighty server to dice up a screen for the response. Though the back end divided into multiple tiers separating application front-end logic (typically a markup language) from business logic (e.g. EJB) from the database and other resources (n-tier), the client (browser) was still basically a dumb terminal. There were some spikes to make the client smarter: applets, flash, etc. and some javascript to enhance the experience with more sophisticated controls. But the browser was still a speed bump to drive processing to the front end.
Today the client is taking the front seat again. JavaScript, HTML5 and powerful and fast browsers have allowed much more sophisticated processing running on the client. New frameworks such as backbone js are allowing developers to build entire applications with a single page html dynamically rendered by javascript where the only interactions to the back end are to manipulate the data not render the screen. The client development is reminiscent of small talk, relying on Model View Controller (MVC) architecture to separate the display from the data and the control. The back end remains basically stateless providing a thin logical access to CRUD operations on data, and implementing business logic to shape, compute or aggregate data and coordinate functionality with other resources and tiers.
Subscribe to:
Posts (Atom)