In this installment of our series on building web applications, we look at the SitePen approach to solving challenges in web application development. We employ all of the solutions described in part 2 of the blog series. Additionally, we have some overarching principles we apply to our work.
The right architecture and an emphasis on quality
Solid applications and robust architecture begins with finding the right approach based on the goals and requirements for a particular application. There is no one right architecture for every application, but having the right approach to understanding requirements, translating those to architecture needs, and having a strong emphasis on quality lead to approaches that work for any application. We do this by making sure we ask the right questions and challenge our assumptions for every application we create.
While there are many challenges today with building web applications, there are also many options to address the issues we face with technology, process, and people, allowing us to reap the benefits of the web as an application platform.
While many of the challenges with today’s web applications come from the vast array of technologies that are available, there are clear strategies that can be employed to turn those same issues into advantages that can make building applications easier. The key is to use a technology portfolio that allows applications to be modular, simple, and isolated from any instability in the underlying platform. Another critical aspect of each member of this portfolio is that it must be able to maintain those abilities at the scale at which the application will be built.
Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software.
The benefits of web applications include:
- Simple distribution model for end users (e.g. no installation required)
- Instant propagation of changes
- Unified code base to support many platforms (desktop, tablet, mobile, etc.)
- Easy piloting of new features with a subset of users
- Lower total cost of ownership
- Well-established scalability models as user-base grows
Over the past few years, building the client-side portion of web applications has changed significantly. Web application development, while arguably better than any other platform available today, is not without its challenges. We categorize these issues as coming from three sources: technology, process, and people.
We thought it was a good opportunity to take a step back and look first at the challenges, and then the solutions for building modern web applications, and to share some of the strategies and techniques we use at SitePen to improve our approach.
In this installment, we’ll begin by looking at the challenges currently faced when building web applications.
One of the additions of the recent Dojo 1.11 release is a modern flat theme created with the Stylus preprocessor. The flat theme allows you to apply a modern, flat look and feel to existing Dojo applications.
As part of our efforts toward Dojo 2, we knew we needed something much better than DOH, which led to our work on Intern. We described our thought process on creating Intern in a previous blog.
For the Dojo 1.11 release, we spent time updating to a more modern testing framework and converted all DOH-based tests in Dojo core to use Intern. This will allow the Dojo Toolkit to ensure code coverage across the toolkit and also allow streamlined regression testing to more quickly accept fixes and patches from the community.
Intern, via the Leadfoot WebDriver library, provides a lot of low-level control over the browsers it uses to run tests. Tests can navigate to new pages, resize the browser window, examine elements on a page, and interact with controls like inputs and buttons. Unfortunately, with all this power can come great complexity. Many testing tasks will involve a large number of low-level operations and dealing with these can be error prone and make tests difficult to follow. Command helpers to the rescue!
One of the nice features of testing with Intern and Leadfoot is the ease of authoring functional tests to mimic end-user behavior. The API for retrieving relevant DOM nodes is relatively straightforward, usually with a single line of code needed to get a reference to the relevant node.
When we started writing tests for Dijit, we realized that it was often a fair amount of boilerplate to get references to specific widget instances, attach points within those widgets, and property values of widgets. One of the advantages of Intern is you can integrate this boilerplate into a helper. So, we set out to create a simple Intern helper utility to make these operations as efficient to author as normal functional tests.
It’s been over a year since the release of dgrid 0.4, which brought about some major changes, including integration with the new dstore API. Since then, we (and others) have used it in numerous applications, and we’ve continued to refine it.
Now, at long last, we’re proud to announce dgrid 1.0!