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.
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.