We break it all down over at David Walsh Blog.
Check it out!
The techniques involved in creating modern web applications are continually evolving. It can be difficult to separate out the ones that are truly improving how web applications are developed from those experiments that, while often interesting, are ultimately not worth investing in. From this sea of ideas a couple of trends have risen to the top and are radically changing how web applications are developed. These techniques are microservice-based architectures on the server and single page applications (SPAs) on the client. While an initial review of these two techniques doesn’t reveal any relation, a deeper analysis shows that these two trends are actually great partners and can be combined to enable powerful, yet maintainable, applications to be created.
dojo.io.script), but the API has been less consistent than some of us would like (
dojo.io.script.get, etc.). Additionally, we’ve never provided a server-side implementation, and if we had, it would have been another module name and API call to remember.
With the release of Dojo 1.8, we have introduced the
dojo/request API which provides consistent API calls between browsers, request methods, and environments:
var promise = request(url, options);
Creating and Enhancing Dojo Classes
In Part I of Queued and AIR issues, I talked about some of the challenges we faced during the development of Queued, our AIR application that allows you to manage your Netflix queues. In this post, I’ll discuss five other issues we ran across.
SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.
Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an
onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.
During the course of developing Queued, we ran across a number of challenges developing with AIR that we needed to solve. Some were very difficult to get around, while others were the result of our team needing to think outside the web-based paradigm. In this post, I’ll talk about four issues we ran across that ended up shaping part of the Queued codebase.
SitePen’s new Queued application works very well with the Netflix API, but the smoothness of this functionality was the result of a lot of research, and trial and error. In fact, this experience led me to propose that future project timelines should budget extra time when working with an unfamiliar API—and even more time when that API is brand new and untested. Netflix released one of the more exciting APIs in recent months and SitePen began to work with it right away. The Netflix team did great work on their API and they were also very helpful with us when we had questions or there was a bug on their end. I can imagine the challenges of setting up a (Netflix) REST API with an existing system and a large and complex library of items was not simple. Integration with the Netflix API presented its own set of challenges to us.