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!
For the dgrid 0.4 release we added a new demo and helper utility, the dgrid Laboratory. This is more than just a demo, as it allows you to quickly explore and build different dgrid configurations, returning boilerplate code for efficiently including dgrid within your application. Although not every possible configuration is supported with this tool (sub-rows, column sets, and compound columns), it is very useful for visually generating complex base configurations for use in your applications. The dgrid Laboratory itself was built using dgrid as well!
Using the dgrid Laboratory
The left panel of the dgrid Laboratory allows you to select and modify the grid’s configuration. The right panel provides a preview of the grid as well as generated code. These right panel tabs are updated in real time as you make modifications to the dgrid options in the left panel.
Adam Klien, software engineer at Google, announced on ESDiscuss that they were withdrawing the proposal to implement
Object.observe and plan to remove it from V8 by the end of the year.
Object.observe, they assured me the other browsers would eventually implement the rest of Web Components. I also missed that Polymer 1.0 abandoned