When writing object-oriented source code, you generally only want to expose a very specific API to whomever is using it. In many languages you would control this by marking methods and properties you do not want other developers to use as
private keyword for object properties and methods. The best option we have prior to EcmaScript6 (ES6) to protect data is to hide it inside a closure. But this comes with problems of its own, notably that data must be shared across instances, deliberately removed in order to prevent memory leaks, or new privileged methods must be allocated each time the object is instantiated. Fortunately, ES6 brings us WeakMaps, which we can use to achieve legitimate privacy without the risk of accidentally blocking garbage collection.
Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting. As developers, we wisely work for better performance by understanding performance characteristics, and verifying performance with tests. However, one aspect of performance can be particularly difficult to assess, and its effect can easily be underestimated. Memory consumption can have a large impact on performance, but in ways that can easily be missed and ignored.
It’s been a while since we’ve dove into Dojo’s Deferred module on the SitePen blog—the last time was back in 2010 when we introduced the promise-inspired improvements that landed with Dojo 1.5. Quite a lot has happened since on the topic, including a ground-up rewrite of Dojo’s asynchronous foundations in 1.8+, so it’s about time we take another look at deferreds and promises and how it all fits together in Dojo.
When building web applications, developers often face the dilemma of whether to use traditional server-side rendered pages, or client-centric applications that rely on Ajax/JSON data requests, with client-side rendering of data. These two approaches also tend to dictate navigation (among other things), leading to traditional page navigation or a single-page application (perhaps with hash-based navigation). With the traditional approach, content is delivered in HTML form, relying on browser-driven page loads for different views. However, modern applications with more sophisticated user interfaces, often use a single-page style, controlling events, view updates, and relying on Ajax-style communication with the server to load additional content, typically in structured object format, like JSON. The traditional approach naturally works well with search engines, and browser navigation and can be quickly rendered by the browser. Single-page applications facilitate well structured user interfaces, with clean separation of presentation and data. But is there a way to combine the best of both worlds?
This was a very large amount of work, and we learned a number of interesting things along the way that should be useful to you in writing your own tests.
We think it’s a real shame that there are developers that have to go it alone because they are in remote locations or can’t travel to one of our many in-person workshops. So we spent countless hours and many sleepless nights creating a way to ensure that no developer misses out on the opportunity to learn best practices building web apps with the Dojo Toolkit!
We’re very excited to announced that we are now offering…
Online, public workshops!
We will be using our very cool, Dojo-based workshop tool to deliver four hours of workshops each day, where you can expect to learn the essentials of using Dojo core, Dijit, and dgrid while watching expert developers live code all the while having the chance to try it yourself and ask questions, real time!
Are you In?
Register now! Demand for this workshop will dictate how soon we’ll hold the next one!
If you have any questions, ask in the comments or contact us.
While it will not happen often, there may be times when you need to patch your Dojo source. Perhaps you discovered a bug and are waiting for the fix to be committed or released, or your application uses an older version of Dojo but you want to use features found in newer releases. Dojo’s AMD plugin loader makes it possible to apply patches without resorting to modifying the source files themselves, making it easier to upgrade your version of Dojo.
As an example, Dojo 1.10 introduced
dojo/throttle into the core—along with the extension event
dojo/on/throttle—for ensuring that a function is fired only once during the specified interval. However, if you are developing with an earlier version of Dojo (for example, 1.9.6), you will either need to upgrade to 1.10.x or provide a patch to use it with 1.9.6. In this post, we will create patches for these modules.
We normally try to schedule new minor releases of Intern about once every four to six weeks, but when we are working on a major release, there will often be a larger than usual gap in the release cycle. In order to keep our users informed of what’s going on, we wanted to write about what we’ll be doing over the next six to twelve weeks for Intern 3, during which time there will be no new releases (except for possible critical patch releases).
A common scenario with web applications is accessing protected resources, which require authentication with the server in order to proceed. A common flow is as follows:
- User opens web site
- Web site presents authentication screen
- User enters credentials
- Web site presents protected information
This is simple enough to begin with, but what happens when the session times out? Or perhaps the application does not require authentication initially, but once the user initiates an action to access protected resources authentication is required? A common approach is to use redirects to an authentication page: