It turns out, we are all very passionate about this topic and quickly agreed! So we gave it a shot and created a podcast. Is the name the result of too many brainstorming by committee meetings? Marketing gone wrong? Or did we simply mess up the name and decide to keep it? Listen to the podcast and find out!
Let us know what you think
This episode is a pilot which means that we need to show the big studio execs that people are interested. At least I think that’s how pilots work in podcasting. I actually don’t know. Either way, let us know if you’re interested in hearing more!
We have released dstore version 1.1, which features a new set of stores for local DB storage. This feature provides the ability to store data locally in browsers, and use high-performance querying capabilities through the disparate technologies of IndexedDB and WebSQL (and localStorage), through the consistent dstore interface. Complex queries can be formulated in your application, and data can retrieved from local database storage with the same APIs and query format as is currently supported with other stores. Queries can then be automatically translated to SQL or cursor operations, depending on the underlying technology available.
At the end of 2014, we looked ahead to determine where to focus SitePen’s open source efforts in the coming year. After our successful contributions to dgrid and the new dstore package, it became increasingly clear that contributing to the future of Dojo was where our team would have the biggest impact and the most fun. So, we’re happy to announce that we are and will be actively contributing to the planning and development of Dojo 2!
SitePen In Action
So far, We have contributed our knowledge and expertise in developing enterprise web applications to what Dojo 2 needs to be; a modular, collection of packages that fit together to deliver high-performance web applications that are well-designed, highly performant and maintainable.
We’ve also poured our hearts (and design resources) into the overhaul of the Dojo Website, which was in dire need of a modern design and cleaner information architecture.
So Much Excitement!
A few of the reasons we’re looking forward to contributing to Dojo 2:
- the final result will be a tight collection of packages that feel familiar to Dojo developers while leveraging the capabilities and improvements of the modern web platform.
- Helping to reshape and grow the Dojo community!
Don’t delay! Check out the new Dojo Web site, read the Dojo 2 vision and roadmap and when you’re spun up like us, hit the contribute button and tell us that you want to be part of the future of Dojo!
Dijit and dgrid provide a powerful set of user interface components, allowing for fast construction of sophisticated web applications with excellent performance and interactivity. However, one particular configuration of dgrid that can impact memory and performance: heavy use of persistent Dijit editors within grid cells. The dgrid’s
Editor plugin makes it very easy to leverage various Dijits for editing cells. However, using the default “always-on” mode, where a Dijit is instantiated for every editable cell, in combination with a several columns with numerous rows can quickly consume a lot of memory and create a noticeable drag on your application’s performance.
Dijit editors can help provide some fantastic functionality, with powerful widgets for auto-completion, date input, and validation. In this post, we’ll review two approaches to achieving advanced data input in dgrids that are designed for heavy data manipulation without compromising performance or memory consumption.
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.