We’re excited to announce the 5.0.0 release of Dojo. This version builds on previous releases with a vast array of bug fixes and improvements throughout the framework.

Conditional Polyfills - Serving Less JavaScript

One of our primary goals for modern Dojo is to improve performance by serving minimal JavaScript bundles by default. For version 5, we’re happy to announce an out of the box solution to optimize the user experience for dealing with bundling and loading polyfills in Dojo applications.

The Dojo build produces separate platform bundles that will be only be loaded based on two key conditions:

1) The shim module is imported somewhere in an application.
1) A users browser does not natively support the browser feature.

In short, if your application does not use the browser feature or you use a browser with native support, the polyfill will not be loaded! This change means serving less JavaScript and improving your application performance without compromising on features.

New Polyfills Added to Shim

We’ve added additional third party polyfills to @dojo/framework/shim:

• @dojo/framework/shim/fetch - The Fetch API provides an interface for fetching resources (including across the network).
• @dojo/framework/shim/IntersectionObserver - The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.
• @dojo/framework/shim/WebAnimations - The Web Animations API allows for synchronizing and timing changes to the presentation of a Web page, i.e. animation of DOM elements.
• @dojo/framework/shim/ResizeObserver - The ResizeObserver interface reports changes to the content rectangle of an Element or the bounding box of an SVGElement. The content rectangle is the box in which content can be placed, meaning the border box minus the padding.

To use these additional polyfills they should be imported like any other ponyfill provided by @dojo/framework/shim and they no longer need to be explicitly added/imported to your Dojo application.

Better Build Time Rendering (BTR)

Build time rendering provides the rendering of your application to HTML during the build and in-lines critical CSS. BTR allows an application to render static HTML pages and offer some advantages of server-side rendering (SSR) such as performance and search engine optimization without the complexities of running a server to support full SSR. Build time rendering has been available via the Dojo cli-build-app command since our initial 2.0.0 release.

There are a number of stability and feature enhancements in the 5.0.0 release thanks to the BTR process now running your application in a real browser environment. New features include:

• Dojo Blocks
• Support for StateHistory API (see below)
• Multiple page HTML generation
• Screenshots of pages visited during Build Time Rendering
• Better error messaging

Routing support has been extended to support a HistoryManager using the browser history API via the @dojo/framework/routing/history/StateHistory. For StateHistory BTR produces a static HTML file for each of the paths defined in the build time rendering configuration.

To configure build time rendering to create static pages for the BTR paths, ensure you are using the StateHistory in your application and update your BTR config to specify paths without a # prefix.

"build-app": {    "build-time-render": {        "root": "app",        "paths": [            "home",            "about",        ]    }}

Introducing Dojo Blocks

Dojo Blocks is a new mechanism leveraging Build Time Rendering that allows executing code in Node.js as part of the build. The results from the execution are written to a cache that can then be transparently used in the same way at runtime in the browser. This opens up new opportunities for performing operations that might be not possible or unperformant in a browser.

For example, a Dojo Block module could read a group of markdown files, transform them into VNodes, and make them available to render in the application, all at build time. The result of this Dojo Block module is then cached into the application bundle for use at runtime in the browser.

A Dojo Block module gets used like any other meta in any Dojo widget. As a result there is no extensive configuration or alternative authoring patterns needed.

For example, a block module could read a text file and return the content to the application:

// src/read-file.block.tsimport * as fs from 'fs';import { resolve } from 'path';export default (path: string) => {    path = resolve(__dirname, path);    return fs.readFileSync(path, 'utf8');}

Using the text.block.ts module in your application with the Block meta:

// src/MyBlockWidget.tsimport Block from '@dojo/framework/widget-core/meta/Block';import WidgetBase from '@dojo/framework/widget-core/WidgetBase';import { v } from '@dojo/framework/widget-core/d';import readFile from './read-file.block';export default class MyBlockWidget extends WidgetBase {    protected render() {        const message = this.meta(Block).run(readFile)('../content/hello-dojo-blocks.txt');        return v('div', [ message ]);    }}

This widget runs the read-file.block.ts module at build time, loading the file path passed which gets used as the children in the widget. The rendered application’s HTML and CSS get written to the built index.html:

<html><head>    <title>Dojo Blocks</title>    <meta name="theme-color" content="#222127">    <meta name="viewport" content="width=device-width, initial-scale=1"></head><body>    <div id="root"><div>Hello Dojo Block World!</div></div>    <script type="text/javascript" src="bootstrap.js"></script></body></html>

Simplifying Testing with Assertion Templates

Assertion Templates make testing widgets with the testing harness even easier. Instead of needing to manually curate each expectedRender result per test, you can now use the Assertion Template primitive to easily modify and layer outputs for the expected render.

Assertion Templates allow you to build expected render functions to pass to h.expect(). Assertion Templates always assert against the entire render output, modifying portions of the assertion itself as needed.

To use Assertion Templates, first import the module:

import assertionTemplate from '@dojo/framework/testing/assertionTemplate';

In your tests, you can then write a base assertion which would be the default render state of your widget.

Given the following widget:

class NumberWidget extends WidgetBase<{ num?: number }> {    protected render() {        const { num } = this.properties;        const message = num === undefined ? 'no number passed' : `the number ${num}`;        return v('div', [            v('span', [ message ])        ]);    }}

The base assertion might look like:

const baseAssertion = assertionTemplate(() => {    return v('div', [        v('span', { '~key': 'message' }, [ 'no number passed' ]);    ]);});

and in a test would look like:

it('should render no number passed when no number is passed as a property', () => {    const h = harness(() => w(NumberWidget, {}));    h.expect(baseAssertion);});

Now let’s see how we would test the output when the num property gets passed to the NumberWidget:

it('should render the number when a number is passed as a property', () => {    const numberAssertion = baseAssertion.setChildren('~message', [ 'the number 5' ]);    const h = harness(() => w(NumberWidget, { num: 5 }));    h.expect(numberAssertion);});

Here we’re using the setChildren() API on the baseAssertion, and we’re using a special ~ selector to find a node with a key of ~message. The ~key property is a special property on Assertion Templates and will get erased at assertion time, so it doesn’t show up when matching the renders. This approach allows you to decorate the Assertion Templates to easily select nodes, without having to augment the actual widgets render function.

Once we have the message node we then set the children to the expected the number 5, and use the resulting template in h.expect. It’s important to note Assertion Templates always return a new Assertion Template when setting a value, this ensures you don’t accidentally mutate an existing template (potentially causing other tests to fail), and allows you to compose layered Templates incrementally building on each other.

Improved Stores Middleware

Middleware for Dojo stores has always gotten executed after a process has completed or throws an error, enabling users to make decisions based on the result and perform some additional actions. However, this was limiting middleware from running before or effectively wrapping a process. Version 5 of Dojo introduces before and after middleware to perform such actions around processes completely. Read more on the @dojo/framework/stores readme.

This addition of before and after middleware is a breaking change. However, if your application was already using createCallbackDecorator to create your middleware, then your application should continue to work with your application in version 5 of Dojo application as the createCallbackDecorator function has been adapted to transform existing middleware API to the new API.

Improvements for serve and watch options in @dojo/cli-build-app

The @dojo/cli-build-app command includes a number improvements for running a development server:

• The previous watch modes, memory and file have been consolidated into a unified watch option
• Rebuilds your application when you make any changes within the project directory, not limited to src and test directories.
• Live reload when the application is rebuilt during watch and running the development server using serve
• Customized live reload client that does not affect your built application bundles
• Conditionally loads the live reload client only when using the serve option
• Fallback to default index.html and rewrite resources when using the StateHistory history manager with @dojo/framework/routing

Extended TypeScript Support

Dojo now supports TypeScript versions from 2.6.x to 3.2.x, please see our TypeScript and Dojo compatibility matrix for more information.

Update to Dojo 5.0.0

Visit the Dojo version 5 migration guide for detailed information and guidance on updating your application. Updgrading from 4.0.x to 5.0.0 should require running one command for most users.

After installing the latest version of the @dojo/cli-upgrade-app, run the following command:

dojo upgrade app

Beyond version 5

We are working on a detailed roadmap for the next major release, however, in the meantime check out our future roadmap for ideas we want to investigate over the next 12 months.

Support

See the release notes for more details on version 5 of Dojo.

Love what we’re doing or having a problem? We ❤️ our community. Reach out to us on Discord, check out our roadmap and see where we are heading with Dojo,, and try out the new Dojo on CodeSandbox. We look forward to your feedback.

Developer ergonomics, efficient source code, consistent and flexible architecture, interoperability and alignment with modern standards, and strong community support are fundamental reasons for choosing a framework. We’re constantly looking for ways to improve Dojo and provide the community with the best possible modern framework.

Dojo CLI Tooling

The main focus of version 4 of Dojo is improving application optimization and analyzing, focusing on tooling that can enable these features by default. Separating a Dojo application into bundles (often referred to as code splitting) has been possible since the initial Dojo release. Although this did not require you to change your source code, it did require adding some configuration to specify how your application should be bundled. We wanted to do better by default and in version 4, the Dojo build tooling will automatically split an application based on its top-level routes!

The application template used by cli-build-app provides this functionality out of the box. In addition to this a bundle analyzer is automatically generated when running a build in production mode, providing even more insight into you bundles.

This is provided by the template app generated with @dojo/cli-create-app.

Even with version 4 of Dojo being a step in the right direction, there’s much more we can and are planning to do including critical path bundling, bundle size analysis and budgets, lighthouse reports, and more.

Enabling you to create applications that perform better for your end users is very important to us, however, we also want to ensure that the development experience remains streamlined. As a result, we’ve made a number of changes to our build tooling to enable features such as HTTPS and proxy configuration support.

Other CLI improvements include the support for externals, allowing non-modular libraries or standalone applications that cannot be bundled normally to be included in a Dojo application.

The automatic parsing, hashing and bundling of resources from index.html, and inclusion of assets from the catch-all assets directory. These changes support the creation of more complex applications.

Performance First

To keep applications as small as possible, the CLI follows a few key principles:
Evergreen builds by default, with support for older browsers back to IE11 by explicit opt-in. This reverses behavior in the past of supporting all browsers by default, so that newer browsers get smaller and faster applications as they add support for features natively.

As part of our support for Progressive Web Apps (PWA), we optimize for the the PRPL pattern:

• Push critical resources for the initial URL route.
• Render initial route.
• Pre-cache remaining routes.
• Lazy-load and create remaining routes on demand.

The HNPWA reference Dojo example is less than 20KB gzipped and is among the fastest performance of any client-side JavaScript application framework!

The CLI tooling has three main pathways for the creation and building of apps, themes, and widgets.

Dojo Framework

It has been a busy release for @dojo/framework also, which adds a range of new features plus a few changes to existing concepts and patterns. The focus has been cleaning up the existing codebase and creating better ergonomics for a few concepts.

The Virtual DOM engine has been redesigned and rewritten from the ground up. This was a large undertaking which identified and resolved a number of bugs in the old engine, enabled a number of new features, improved rendering performance and finally reduced the overall size of the framework!

The are a few improvements when using the w() and v() pragmas, including better composition of nodes, rendering a dynamic import directly using w() and enabling the use of meta for nodes that are passed as children to a widget.

The routing system within the framework received an improved route matching algorithm for this release. Additionally a more flexible Outlet works via a render property. The ActiveLink widget also applies classes when an item is considered active.

dojo/stores adds middleware support for Local storage in this release, and a new StoreProvider eases the injection of application state.

Widgets

With the concentration on the CLI tooling and @dojo/framework itself, it has not left much time for @dojo/widgets. But…. yes but, as part of Dojo 4 there is a new data grid available, it’s currently very basic in terms of features, but over the next few months we will be working on improving, with a focus on feedback from our users. This feedback will help us decide which features to work on next.

If our @dojo/widgets grid does not work for you yet, a new dgrid wrapper has been added to @dojo/interop. The wrapper can be used in combination with the CLI build externals to support using dgrid with Dojo version 4 and includes support with some of the most populate dgrid mixins.

The existing widgets received many accessibility, keyboard, and focus refinements.

Migration

All of the breaking changes in Dojo 4, were carefully considered beforehand as we understand the impact that they can have on your decision to upgrade. To assist with the transition we have updated the CLI upgrade command, which will automatically upgrade your Dojo dependencies, upgrade your application code where possible and highlight areas in the application that require manual intervention. For more information on what has changed in Dojo 4, please see the migration guide.

TypeScript forwards-compatibility was updated from 2.7 to 3.0.

Support

See the release notes for more details on version 4.0.0 of Dojo!

Love what we’re doing or having a problem? We ❤️ our community. Reach out to us on Discord, check out our roadmap and see where Dojo is headed, and try out the new Dojo on CodeSandbox. We look forward to your feedback!

Within the past few years, new features get added to browsers at breakneck speed. The time between proposal and standardization has dropped from years to months, and browser vendors are eager to maintain similar turnaround times for implementing new standards. In many ways, it has never been a better time to be a web developer.

Networks, on the other hand, are neither universally reliable nor universally performant. As developers, we have a responsibility to ensure our users do not suffer from our technical decisions. One step we can take against this is by delivering our application using Progressive Web Applications (PWA) technologies which are resilient to network issues.

At its most basic definition, “Progressive Web App” (or “PWA”) is an umbrella term for a web application that applies a set of techniques and technologies to mimic the responsiveness and feel of a native application. Since progressive web apps at their heart are regular web pages, they run in the browser and bypass any native app store.

Network resilience that we see in native apps is provided in PWAs by a technology called Service Workers. A Service Worker is a worker that sits as a proxy between the page and the server. They can intercept requests and cache results. We also get the ‘install to homescreen’ experience courtesy of what is called the web manifest file (manifest.json). This manifest instructs the browser that the page is a PWA that is installable and provides things like application colors and icons.

Dojo makes it easy to deliver an app-like, offline-first experience to your users using only configuration settings supplied in the application’s .dojorc. Suppose we are developing an application for rock climbers that delivers information on climbing routes within the U.S. National Parks. The application allows users to view and rate routes, add their routes, and track those routes they have climbed. Further, the application contains an admin area and a user preferences screen. Finally, since there is a good chance that users do not get reliable wireless access while climbing, we need to ensure they can view route details offline.

Before delving into PWA features, we lay out a basic .dojorc that instructs the Dojo build to separate the user preference and admin areas into separate bundles that get loaded on-demand.

{    "build-app": {        "bundles": {            "settings": [ ... ],            "admin": [ ... ]        }    }}

Adding a Web App Manifest

The next step is to add a web app manifest that provides information about the application like a name and available icons to display on the users’ home screens. The manifest for our application contains a set of icons that can be displayed on the home screen, the name to display alongside the icon, a brief description, and the background color to display while the app is loading:

{    "build-app": {        "bundles": { ... },        "pwa": {            "manifest": {                "background_color": "#212329",                "name": "National Parks Climbing",                "short_name": "Climbing",                "description": "A guide to climbing routes in the U.S. National Parks",                "icons": [                    { "src": "./icon-48x48.png", "sizes": "48x48", "type": "image/png" },                    { "src": "./icon-96x96.png", "sizes": "96x96", "type": "image/png" },                    { "src": "./icon-256x256.png", "sizes": "256x256", "type": "image/png" }                ]            }        }    }}

With the above configuration, the Dojo build generates a JSON file and inline it within the <head> tag of the index.html. Since iOS devices do not currently use PWA manifests to read app data, iOS-specific tags get inlined as well. When the user adds the app to their home screen, either the name or the short name gets displayed (depending upon available space), along with one of the provided icons. We provide multiple sizes so that the user’s device can choose the most appropriate one to display.

If you are as internationalization-minded as we are, you should notice that there is no mechanism to localize the web app manifest. So your app uses the same icon, name, description, etc., regardless of the user’s preferred language. As a result, you need a server-side solution to localize your manifest.

Our application can now get installed on users home screens like a native app, but we still need a way to display content even when offline. That is where service workers come into play.

Adding a Service Worker

A service worker is essentially a proxy between the network and the application. It is a single JavaScript file that runs in a separate thread from the application itself, and it can intercept and modify network requests, cache responses, and control how the browser responds to those requests.

As with the PWA manifest, the application’s service worker gets generated entirely from options specified in the .dojorc, this time housed beneath the pwa.serviceWorker namespace. When Dojo builds the application, it generates both the service worker file and ensures it is registered when the application starts. At this point, the service worker gets registered, but by default, it does not control the application until the next refresh. This default may get overridden by setting "clientsClaim": true , which causes the service worker to take control immediately. That said, in most cases, this override is not necessary, and we recommend not setting it until you have proven you need it.

Once the service worker gets successfully installed, it can begin intercepting requests and caching responses. There are two types of caches involved: the precache that is populated when the service worker gets installed with the static assets required to render the application shell and the runtime caches that gets populated with responses from network requests sent while using the application. By default, all assets in the build pipeline get added to the precache, but this can be limited to a subset of bundles. Alternatively, specific bundles may deliberately get excluded from the precache as well.

Since we are only concerned with making climbing routes available offline, we exclude the admin and preferences bundles from the precache:

{    "build-app": {        "bundles: { ... },        "pwa": {            "manifest": { ... },            "serviceWorker": {                "excludeBundles": [ "admin", "settings" ]            }        }    }}

While setting the precache is rather straightforward, controlling the runtime caches requires a little consideration. There are four strategies when determining how network requests should get handled:

• networkFirst instructs the service worker to attempt to load the resource over the network, falling back to the cache if the network is unavailable.
• cacheFirst instructs the service worker to deliver the resource from the cache, sending a network request only when the resource does not exist in the cache.
• networkOnly prevents the resource from ever being loaded from the cache.
• staleWhileRevalidate loads the resource from the cache while it gets simultaneously fetched over the network. This strategy is useful when a resource is updated frequently, but having the latest version is not crucial to the user experience.

Choosing the right strategy depends on the type of resource as well as on how the user needs to use that resource. For example, we know that the climbers using our application need the most up-to-date information on unexpected park closures or dangers like mountain lion sightings or lightning storms. We also know they want accurate data on route locations, access, difficulty levels, and that they also want any maps that depict those routes. At the same time, we recognize that loading maps or images over a poor network connection are not an option, so we want to limit any network requests to fetching the lower-cost text descriptions.

Armed with that knowledge, we can add sensible route handling to our config:

{    "build-app": {        "bundles": { ... },        "pwa": {            "manifest: { ... },            "serviceWorker": {                "excludeBundles": [ ... ],                "routes": [                    {                        "urlPattern": "\/parks",                        "strategy": "networkFirst",                        "expiration": {                            "maxEntries": 25,                            "maxAgeSeconds": 604800                        }                    },                    {                        "urlPattern": "images\/route-maps",                        "strategy": "cacheFirst",                        "expiration": {                            "maxEntries": 25,                            "maxAgeSeconds": 2592000                        }                    }                ]            }        }    }}

Let’s break this down. Runtime strategies get specified at the route level under the pwa.serviceWorker.routes array. Each route includes a ”urlPattern” that is converted internally to a regular expression and matches specific request URLs. Since users need to have the latest text information on parks and routes, we use the networkFirst strategy to ensure that users can get the latest data whenever the network is available. We then limit that cache to 25 pages, each cached for seven days before being removed. Finally, we instruct the service worker to load the route maps from the cache whenever possible and limit that cache to 25 maps with each expiring thirty days out. Of course, in a real application, you want to adjust the expirations according to what users access and how often.

With that, you are ready to begin upgrading your Dojo application to a PWA! There are of course several additional configuration options for both the manifest and the service worker, and you can even provide your service worker if the generated service worker does not meet your needs. Finally, if you want to get further background knowledge on PWAs, both Jake Archibald’s The Service Worker Lifecycle and MDN’s Introduction to progressive web apps are excellent places to start.

Building on Success

Some changes are happening with Dojo. As the project continues to stabilize around a set of modules and APIs, we are continually evaluating feedback from the community as well as our processes.

First things first, when we released the next generation of Dojo, we wanted to strongly disambiguate between the legacy Dojo toolkit by naming it Dojo 2. Now that we have released Dojo 2 and are moving on with further releases we are going to drop the version number, and from now on we refer to it as Dojo.

Also of note during the Dojo 2 cycle, we identified that pain points were going to become bottlenecks and affect the momentum of the project. Central to these issues was the complexity of managing the eight projects that make up the basis of the dojo framework: core, has, i18n, routing, shim, stores, test-extras, and widget-core. We found that managing these projects individually required a great deal of coordination when publishing and working with their inter-dependencies.

So We Made a Change

Now that the core Dojo packages are stable, we decided to consolidate these packages into a single one with @dojo/framework. In doing this, we have hopefully improved the Dojo project in a few ways:

• End users no longer have to worry about the current working set of package versions, there is just one package and version.
• A single place to raise issues and feature requests.
• A stronger focus on how dojo as a framework fits together to provide the best possible experience, over the old siloed packages approach.
• Simplifying our management and release process allowing us to iterate quicker

Migration

The new @dojo/cli-upgrade-app package aims to provide users with a friction-free upgrade path between major Dojo versions starting at 2.x. For more information see the v3 migration guide.

Support

In other news, our official chat support is now on Discord, so head on over to the Dojo Discord channel and also check out updated examples on CodeSandbox.

As the earliest, most comprehensive JavaScript framework, the Dojo Toolkit offered up intelligent building blocks for serious web developers. For example, Dojo’s very early work on deferreds and async patterns, widgets, modules, i18n, and a11y led to the standardization of promises, fetch, web components, ES modules and other best practices and mainstays of modern web development. Dojo was the first open source JavaScript framework that treated JavaScript and the browser as a platform for building robust software applications. Its focus on pushing the limits of the open web with diligent consistency means that applications authored in 2007 with Dojo still work today!

The web has come a long way, and with many Dojo solutions finding their way into the browser (success!) as well as inspiring even better tools, our team’s focus has moved beyond providing the building blocks and onto helping developers put it all together.

Dojo 2.0

Dojo 2 dedicates itself to creating an incredibly ergonomic and efficient way to build modern web apps.

Leveraging ES2015+, TypeScript, and many modern and emerging standards, best practices, and quality open source dependencies, Dojo 2 focuses on interoperability preventing you from being locked into the specifics of any one framework. Dojo 2 gives you the flexibility to reap the benefits of choosing your preferred micro-libraries to create a custom framework but most notably gives you a robust set of out-of-the-box options, so you don’t need to decide everything up front before you can be productive.

Let’s hear more about what’s Out-of-the-Box

Dojo 2 wants developers to be productive as quickly as possible – like in under a minute! With an eye on creating the best out-of-the-box experience, Dojo 2 makes it easy to get started. Some of these out-of-the-box features include:

• Reactive, Virtual DOM-based widget system including meta providers to preserve reactivity for things like animations, focus, and resize events and an intuitive CSS.Next-based theming system
• Streamlined support for Web Components including full support for importing and exporting Custom Elements for use within Dojo 2 and other frameworks
• Application-level declarative routing system focused on patterns for building applications from UI widgets
• A predictable, consistent state container for JavaScript applications, drawing inspiration from Redux and Flux architectures, with built-in support for common patterns, asynchronous behaviors, and undo.
• CLI tooling to create optimized applications with code splitting and build time rendering provided automatically
• An efficient test harness for efficiently testing your apps and widgets

To be a modern framework, we want to make it easy to leverage features like web components, and emerging web standards such as Intersection Observers, Resize Observers and Web Animations while preserving an efficient, reactive architecture. Consistently aligning with modern standards is our best option for extending the longevity of applications you create.

For the enterprise

With a long history of building mission-critical applications for Fortune 500 companies, Dojo 2 engineers know the pain felt by enterprise development organizations. Dedicated to solutions that promote scalability and complex application development, Dojo 2 adds to its out-of-the-box deliverables with features like accessibility and internationalization - because these should be part of the plan and not a clunky extension or costly afterthought.

An efficient and intuitive framework is about doing a million things right in a consistent manner whenever possible and leveraging ES2015+, TypeScript, and other patterns allow Dojo 2 to deliver a consistently ergonomic approach.

See Dojo 2

Dojo 2 does not sacrifice performance to deliver solid ergonomics. See the RealWorld comparison to see how Dojo 2 measures up!

View the Dojo 2 reference examples including RealWorld, HNPWA, and ToDoMVC, and check out the source code. To learn more about using Dojo 2, start with the Dojo 2 tutorial series.

Dojo 2 promises to do community right and do right by its community

The Dojo 2 team is excited about the opportunity to build a healthy, diverse and inclusive community to ensure that we are creating an intuitive and flexible framework that meets the needs of the enterprise developer.

We look forward to your ideas, input, and feedback to make Dojo 2 useful for the greater JavaScript and TypeScript community and we welcome your contributions!
You can participate in our community on Gitter, share information on Twitter.

We first started brainstorming ideas for Dojo 2 back in 2010. While development of Dojo 2 did not take quite as long as Diablo 3 or Duke Nukem Forever, we followed a very deliberate journey. Conceived initially as a modern clean-up for Dojo 1.x, with the introduction of ES6, TypeScript, web components, and an array of other features, we realized we wanted to take a different path and create an approach to building modern apps that would not just be a slight clean-up of Dojo 1 or a clone of other current frameworks, but a productive and efficient development experience and front-end architecture.

The result of these years of rewriting and rethinking is something we believe offers a compelling way to build modern applications with TypeScript, leveraging a dizzying array of modern standards and best practices including but not limited to ES2015+, TypeScript, custom elements (web components), Progressive Web Apps (PWA), reactive virtual DOM, Intersection Observers, routing, accessibility (a11y), internationalization (i18n), CSS modules, data stores, and much more.

When Dojo began in 2004, there was no significant JavaScript ecosystem, and the standards process was not evolving rapidly. Much has changed in 14 years!

As such, if a viable foundational approach exists that we can leverage or extend beyond the core of Dojo 2, we will choose this route rather than creating our own. By leveraging tools like webpack for building and optimizations, various shims for custom elements and Intersection Observers, Globalize and cldr.js for internationalization and more. On top of this foundation, we have built a reliable and consistent out of the box approach making it easy to get started building applications. Dojo 2 does not require each developer to make every architectural choice up front, but still provides easy ways to override our suggested approach when you prefer an alternative.

There are plenty of articles comparing frameworks, but needless to say, we took a long look at everything else because we want Dojo 2 to be part of the ecosystem rather than its own silo. By leveraging ES modules, TypeScript interfaces, and custom elements, we provide a robust level of interoperability with other frameworks and libraries.

So what are Dojo’s primary focus and advantages? It is an ergonomic way to build reactive enterprise web apps with TypeScript and numerous modern web standards and best practices, with an easy to use widget system and widget library, and other vital architectural components including routing, data stores, and much more.

Author widgets with @dojo/widget-core

Dojo has always emphasized the creation of widgets, and Dojo 2’s @dojo/widget-core package creates an environment providing developers with simple ergonomics allowing them to build robust applications. Leveraging a modern and reactive, uni-directional approach to data binding with a virtual DOM, @dojo/widget-core streamlines the process of creating widgets and apps.

There are many scenarios where it is challenging to preserve a reactive architecture when working with properties of DOM nodes, so @dojo/widget-core provides meta abstractions to help deal with DOM nodes without breaking the flexibility of a reactive architecture.

@dojo/widget-core embraces the future of the web platform with out of the box meta implementations for Intersection Observers, and Web Animations. With plans to add support for more existing and upcoming living standards from WIGC via meta in the future.

The following example renders a list with images. By leveraging the Intersection Observer meta, the image src gets added only when the item is in the viewport, which prevents needlessly downloading images until the user scrolls to them.

import { WidgetBase } from '@dojo/widget-core/WidgetBase';import { v, w } from '@dojo/widget-core/d';import { Intersection } from '@dojo/widget-core/meta/Intersection';interface ImageProperties {    image: string;}class Image extends WidgetBase<ImageProperties> {    protected render() {        const { image } = this.properties;        const { isIntersecting } = this.meta(Intersection).get('root');        const properties = isIntersecting ? { key: 'root', src: image } : { key: 'root' };        return v('img', properties);    }}interface ImageListProperties {    images: string[];}export class ImageList extends WidgetBase<ImageListProperties> {    protected render() {        const { images } = this.properties;        return v('div', images.map((image) => {            return v('ul', { key: image }, [ w(Image, { image } )]);        }));    }}

Css Modules and css-next

Dojo 2 uses css modules, out of the box to provide localized class names as standard. This ensures that your styles do not leak out of your widgets and provides type-ahead capability when importing your css files into your widget.

Css-next enables allows Dojo 2 widgets to use cutting edge css syntax and features immediately, such as calc, css-variables and various color functions. These are all compiled down to browser friendly variants at build time so there’s no need for a post processor such as SCSS or Less.

Dojo loves Custom Elements

A top priority for Dojo is interoperability with the web platform, both by utilizing current and emerging standards and providing a mechanism to coexist with other frameworks efficiently. The Custom Elements portion of the Web Components standard is one area to encourage interoperability between UI component libraries and frameworks.

The Custom Elements Everywhere project was released last year to highlight framework support for using custom elements, and Dojo 2 currently has a perfect score.

You can do much more than simply use custom elements within a Dojo 2 project, you can compile your Dojo 2 widgets to custom elements via one of our @dojo/cli commands, making it shareable and easy to distribute Dojo 2 widgets across projects and frameworks. So if you are in an organization where some teams use Angular, some use React, some use Vue, and some use Dojo, we provide a future today where you can write a component once and share it across those teams!

By default, Dojo’s custom elements are built for evergreen browsers to reduce overall bundle size, meaning most basic widgets are <20KB (gzipped) including all of the @dojo runtime needed to support the custom element.

The customElement decorator annotates the widget class and instructs the cli-build-widget command to convert it to a custom element:

interface HelloWorldProperties {    onClick: (event: Event) => void;    foo: string;    bar: string;}@customElement({    tag: 'hello-world',    attributes: [ 'foo', 'bar' ],    events: [ 'onClick' ]})class HelloWorld extends WidgetBase<HelloWorldProperties> {// ...}

To compile a Dojo widget into a web component, run the following command:

npx @dojo/cli build widget --elements src/HelloWorld

For ease of use, all @dojo/widgets are compiled to custom elements and published to npm and easily imported into your projects.

Learn more about creating your first Dojo widgets with the first Dojo 2 application tutorial.

The Dojo CLI

CLI tools provide an easy way to work with frameworks, a trend popularized in the JS community by Ember. The Dojo CLI is a collection of packages, providing a CLI architecture enabling a modular approach to create and work with commands.

One of our goals in creating an easy out of the box experience with Dojo is to abstract users away from complex configuration by using intelligent defaults internally.

To install the Dojo CLI, run the following command: npm install -g @dojo/cli

There are currently six officially supported CLI command modules:

@dojo/cli-create-app

Creates a skeleton Dojo 2 application to get started with development and includes all the Dojo 2 dependencies needed.

$ dojo create app --name my-first-dojo-2-app

@dojo/cli-build-app

A command to build your Dojo 2 application with basic command line options to specify the target development or production, start the command in watch mode and even create a basic http server to serve the application locally.

cli-build-app also provides powerful tools to code split dynamically imported widgets automatically and Build Time Rendering.

@dojo/cli-test-intern

A unit and functional testing command for Dojo 2 application using Intern, with support to run tests on popular services such as Browserstack, Saucelabs and TestingBot.

@dojo/cli-build-widget

The cli-build-widget command enables consumers to build custom elements from one or more of their Dojo 2 widgets.

@dojo/cli-create-widget

Creates a skeleton Dojo 2 widget module and all associated meta files.

@dojo/cli-create-theme

Creates a skeleton Dojo 2 theme from your chosen project’s dependencies.

Ultimately, each of the commands require zero configuration to get started, with only some advanced features requiring additional configuration via a project’s .dojorc file.

To use any of the CLI commands in your Dojo 2 project by adding them as a dev dependency to your project’s package.json.

Learn more about creating your first Dojo application in the Dojo local installation tutorial.

State management

No modern framework would be complete without a recommended approach to state management.

Managing state can become difficult to coordinate when an application becomes complicated with multiple views, widgets, components, and models. With each of these attempting to update attributes of state at varying points within the application lifecycle things can get confusing. When state changes are difficult to understand or non-deterministic, it becomes increasingly difficult to identify and reproduce bugs or add new features.

@dojo/stores is a predictable, consistent state container for JavaScript applications with inspiration from Redux and Flux architectures. However, the @dojo/stores package aims to provide more built-in support for common patterns such as asynchronous behaviors, undo support and more!

The @dojo/stores package provides a centralized store, designed to be the single source of truth for an application. It operates using uni-directional data flow, so all application data follows the same lifecycle, ensuring the application logic is predictable and easy to understand.

Key features of @dojo/stores include:

• Application state store designed to work with a reactive component architecture
• Out of the box support for asynchronous commands
• All state operations are recorded per process and undoable via a process callback
• Supports the optimistic pattern with the ability to roll back on a failure
• Fully serializable operations and state

When managing application state with the @dojo/stores package, there are three core but simple concepts - Operations, Commands, and Processes.

• Operations: Granular instructions to manipulate state based on JSON Patch
• Commands: Simple functions ultimately returning operations needed to perform the required state change
• Processes: A function executing a group of commands usually representing a complete application behavior

Dojo 2 also makes it easy to support other patterns such as those popularized by Unstated. Less complex applications can simply lift state up to parent widgets and use local state.

Documentation and examples

To get started, we have a series of Dojo tutorials and reference documentation ranging from the very basic to more complicated topics such as lazy loading, web animations and more. In addition to these resources, all Dojo 2 packages have detailed READMEs.

We’ve created a variety of examples of Dojo 2 usage:

• TodoMVC - TodoMVC is the canonical example used to demonstrate fundamental web application paradigms
• TodoMVC kitchen sink - Our extension of TodoMVC used to illustrate a selection of Dojo 2 specific capabilities such as theming and internationalization.
• RealWorld - A full web application example with authentication, code splitting, state management, routing and more.
• HNPWA - The spiritual successor to TodoMVC, Hacker News PWA is designed to demonstrate progressive web app capabilities with a focus on providing a fast, reliable experience with rich offline support
• Custom element menus - Demonstrates using Dojo 2 widgets both natively and as a custom element without needing to adapt the authoring pattern.

To learn more about Dojo 2 and get started, check out the Dojo 2 tutorial series.

What’s next?

In the release candidate stage, we will fix any critical issues reported and then have another release candidate. After a week with no critical blocking issues, we will announce 2.0.0!

We also hope to have Dojo 2 available on CodeSandbox in time for the 2.0.0 release as well.

Versions

After, we will be following semantic versioning for subsequent releases. 2.0.y will include bug fixes, 2.x.0 will provide additions, and 3.0.0 will be the next release with any breaking changes. When we are ready for 3.0.0, all packages will be updated to this version to keep them synchronized. As such, expect 3.0.0 to arrive within a few months rather than 10 years!

Feedback and help wanted

We still have quite a bit of work to do to update and refine our examples and documentation, so if you see an issue, please let us know, or better yet, create a pull request!
There is still much we want to complete after 2.0.0, but we are ready for you to start using Dojo, give us feedback, and let us know where we should prioritize our efforts.

Let us know what you think either on Gitter, Twitter or Discourse.

If you’re learning about Dojo 2 for the first time, please read our overview about the Dojo 2 beta 4 release.

Getting beta 5

Beta 5 is currently tagged as latest in npm, so simply updating to the latest version will provide you with the Beta 5 release. We also have a release tag of beta5 in npm if you want to focus just on using Beta 5.

This will be the final beta release for Dojo 2! As we make releases of packages in anticipation of Release Candidate 1, we will not publish those packages to latest until Release Candidate 1 is available.

Just getting started

If you want to get started with Dojo 2, the best way is to take a look at our tutorials or even take a look at Dojo 2 in action with our example applications (source on GitHub). Good starting tutorials are:

• Dojo 2 local installation
• Your first Dojo 2 application
• Creating widgets

New in beta 5

Since the beta 4 release, we have made a number of improvements. The biggest changes and additions are mentioned here, with a complete list of changes

Initial re-architecture of the build system

Prior to beta5, the structure of the build commands was focused around the tooling and not around the actual creation of applications. So we completed a re-architecture and restructuring of the commands to align more to their use. Specifically, @dojo/cli-build-webpack is deprecated and replaced with:

• @dojo/cli-build-app A command that builds an application
• @dojo/cli-build-widget A command that build a widget, including support for web components
• Other commands may be planned for the future

This refactoring is mostly complete for Beta 5, with a few remaining items to complete for release candidate 1.

Usage of the build system is reflected in updates to the Dojo 2 tutorials.

Improvements to using Custom Elements/Web Components

Added a decorator for the custom element descriptor. There is no longer a requirement for a separate module any more!

widget-core changes

• Focus meta
• Always render decorator
• Registry decorator

The primary breaking change in widget-core is that HNode was renamed to VNode

New widgets

Two new widgets were added in Beta 5:

• Progress (@dojo/widgets/progress/Progress)
• Toolbar (@dojo/widgets/toolbar/Toolbar)

These widgets may be viewed in the widget showcase.

Stores

A number of refinements were made since the initial @dojo/stores release in Beta 4:

• Add a basic onChange mechanism
• Improvements to providing type definitions for state and payload

See the @dojo/stores readme for more information about this package.

Updated examples

Our collection of Dojo 2 examples were updated for beta 5.

In particular, the kitchen sink version of ToDoMVC now uses @dojo/stores.

Also the Dojo 2 HNPWA example was accepted and is now available.

ESM packages

Dojo packages now ship ES modules alongside UMD! In the future we will be leveraging ESM for evergreen browser builds with webpack.

Theme creation

A new cli-create-theme package has been added to make it easier to create a custom theme.

Migrate to TypeScript 2.6

TypeScript 2.6 was released and introduced a number of significant improvements to the language, in particular the strictness of certain types of typings. These changes helped us further refine the type definitions and find a few bugs along the way. Dojo 2 beta 5 ships all of its packages leveraging TypeScript 2.6, and all packages conform to strict type mode.

What’s next?

We are nearly there for the initial 2.0 release. For RC1 in just a few weeks, you can look forward to:

• More end developer tooling improvements
  • dojo/cli-build-app Finish re-architecture of the build system
  • dojo/cli-build-widget Focused build process for Dojo 2 widgets as web components
• dojo/themes A new package for Dojo 2 themes
• dojo/widget-core Finish DOM abstraction
• dojo/widgets Standardize widget events
• Additional theme to provide Dojo 1 flat theme style interoperability

At the moment, we are planning for RC1 in early February.

We are also working on additional features post Dojo 2.0:

• Development and diagnostic tools
• dojo/dgrid Powerful data grid widget

Getting involved

If you want to get involved, you can see an overview of the parts of Dojo 2 at dojo/meta. In all of our repositories we use the labels good first issue and help wanted to help guide you on a good place to get started.

With a focus on leveraging cutting edge standards such as web components and intersection observers, as well as emerging patterns like CSS modules, progressive web apps, and the virtual DOM, Dojo provides an excellent experience for engineers and end users.

Dojo’s out-of-the-box experience takes under a minute to get started and provides a variety of features including user interface widgets backed by powerful and flexible internationalization and accessibility options. Intent on avoiding framework lock-in, its robust architectural flexibility and its support for modern standards makes Dojo a strong contender for enterprise development teams.

The latest beta 4 release has several significant changes and updates from earlier versions. Here we highlight the current state of Dojo 2, as well as emphasize the recent changes and additions in beta 4.

Getting Beta 4

Beta 4 is currently tagged as latest in npm, so simply updating to the latest version will provide you with the Beta 4 release. We also have a release tag of beta4 in npm if you want to focus just on using Beta 4.

With Beta 3, we revised our package versions to make it easier to keep a compatible set of packages. We are releasing all pre-release versions of Dojo 2 packages under major version 0, but are introducing breaking changes in the minor release (e.g. 0.2.0 has breaking changes from 0.1.0). The versions we publish to npm rely upon a minor range. You will see that some packages for Beta 4 are 0.3.# and some are 0.2.#, but all packages depend on a range where compatibility has been verified by the Dojo team. This means you do not need to reply upon a specific release tag. If you are managing your dependencies directly, you should ideally depend upon a minor release for packages (e.g. ~0.2.0).

As we make releases of packages in anticipation of Beta 5, we will not publish those packages to latest until we release Beta 5.

Just getting started

If you want to get started with Dojo 2, the best way is to take a look at our tutorials or even take a look at Dojo 2 in action with our example applications (source on GitHub). Good starting tutorials are:

• Dojo 2 local installation
• Your first Dojo 2 application
• Creating widgets

Integrated virtual DOM

Directly integrating the virtual DOM is the biggest change for the beta 4 release. Instead of depending on the Maquette virtual DOM library, we realized that our specialized requirements and needs are better solved by direct integration. So in Beta 4 we have replaced Maquette with @dojo/widget-core/vdom.

This change allows us to directly merge our abstraction of widgets and virtual DOM nodes that get rendered to the DOM. This increases the performance of the widgeting system, and also led to other performance and memory improvements to the widgeting system.

This alone would not affect users of Dojo 2, but it allows us to address many features and refactor code that introduces some significant breaking changes in the beta 4 release.

Explore the widgeting system via the Creating widgets tutorial.

Virtual DOM classes

One of the biggest usability issues with earlier Dojo 2 beta releases was managing CSS classes. In Beta 4, we have changed this significantly, and while it is a breaking change we think the end result is a lot more usable.

Previously, classes were actually an object map of keys with a boolean value. If you were using the Dojo 2 theming system, you would use a function to specify your classes in a more functional way, which would automatically generate a memoized map. If you were not using the theming system, you would need to memoize classes directly. While this approach might be ok to author, it was really challenging to test. It would look something like this:

import { v } from '@dojo/widget-core/d';import WidgetBase from '@dojo/widget-core/WidgetBase';import ThemeableMixin, { theme } from '@dojo/widget-core/mixins/Themeable';import * as css from './styles/mywidget.m.css';const ThemeableBase = ThemeableMixin(WidgetBase);@theme(css)export default class MyWidget extends ThemeableBase {    protected render() {        return v('div', {            classes: this.classes(css.root).fixed(css.rootFixed)        }, [ 'Hello world!' ])    }}

With the changes in Beta 4, this gets written as:

import { v } from '@dojo/widget-core/d';import WidgetBase from '@dojo/widget-core/WidgetBase';import ThemedMixin, { theme } from '@dojo/widget-core/mixins/Themed';import * as css from './styles/mywidget.m.css';const ThemedBase = ThemedMixin(WidgetBase);@theme(css)export default class MyWidget extends ThemedBase {    protected render() {        return v('div', {            classes: [ this.theme(css.root), css.rootFixed ]        }, [ 'Hello world!' ])    }}

The classes property is now just an array of strings. Also the mixed in .theme() method more clearly express intent over the former .classes() name. Fixed classes are simply added to the array, instead of being supplied to a chained function.

The testing tooling (@dojo/test-extras/harness) has been updated to reflect these changes, making it easier to test widgets. Themeable was renamed to Themed for improved mixin semantics.

Widget lifecycle changes

We have a goal with Dojo 2 to provide straightforward and efficient APIs. One of the biggest lessons we learned with Dojo 2 was that the widget lifecycle was far too complex. The Dojo 2 widget system handles the vast majority of lifecycle changes and updates automatically. There are some scenarios where you many need to know when an item is added or removed from the DOM by the virtual DOM system.

In Beta 4, we have introduced the onAttach and onDetach lifecycle methods to WidgetBase. They are designed to allow a widget developer to hook when a widget instance is attached to the DOM or detached from the DOM.

To use the lifecycle methods, simply override onAttach or onDetach:

import { v } from '@dojo/widget-core/d';import WidgetBase from '@dojo/widget-core/WidgetBase';export default class MyWidget extends WidgetBase {    protected onAttach() {        // perform actions when attached    }    protected onDetach() {        // perform actions when detached    }    protected render() {        return v('div', { }, [ 'Hello world!' ])    }}

Earlier, less effective efforts to provide lifecycle methods are deprecated and will be removed in the future.

Deferred properties

A virtual DOM node may have its property resolution deferred. Instead of providing an object of VirtualDomProperties, you may provide a function which accepts a boolean flag representing whether the virtual DOM node has been inserted into the DOM. This function returns an object of VirtualDomProperties.

Because these functions will be called during the next requestAnimationFrame (when the projector is running in its default asynchronous mode), this feature can be used to better handle CSS transition states. For example, you can now do something like this:

import { v } from '@dojo/widget-core/d';import WidgetBase from '@dojo/widget-core/WidgetBase';render() {    return v('div', (inserted) => {        return {            classes: 'fadeInTransition',            styles: {                opacity: inserted ? '1' : '0'            }        };    }, [ 'Hello World!' ]);}

Web animations meta provider

The Dojo 2 widgeting system strives to provide sufficient tools and abstractions to avoid needing to directly manipulate the DOM. Meta providers offer reactive ways to interact with features that would otherwise require direct DOM interaction. Dojo 2 includes meta providers for Intersection Observers, dragging on an element, node dimensions, and the matching of a virtual DOM node.

In this vein, we have added a web animations meta provider in Beta 4. It provides a way to easily animate DOM nodes in a reactive way, as just part of your widget’s .render() function. For example:

import { v } from '@dojo/widget-core/d';import WidgetBase from '@dojo/widget-core/WidgetBase';import WebAnimation from '@dojo/widget-core/meta/WebAnimation';export default class AnimatedWidget extends WidgetBase {    protected render() {        const animate = {            id: 'rootAnimation',            effects: [                { height: '10px' },                { height: '100px' }            ],            controls: {                play: true            }        };        this.meta(WebAnimation).animate('root', animate);        return v('div', {            key: 'root'        });    }}

Custom Elements/Web Components

A primary objective for Dojo 2 is to embrace and leverage standards wherever possible to encourage interoperability. One such area is Web Components, where it is possible to both use Web Components within Dojo 2 applications, and also use Dojo 2 widgets as Custom Elements outside the context of a Dojo 2 application. Beta 4 introduces several changes to the widgeting system to better support Dojo 2 widgets used as Custom Elements. Earlier, it was challenging to have a Dojo 2 Custom Element efficiently use other Dojo 2 Custom Elements as children. With Beta 4, this is no longer a problem.

If you write the following in TypeScript:

class Example extends WidgetBase {  private _onSelected(data: any) {    console.log(data);  }  protected render() {    return w(Menu, { onSelected: this._onSelected }, [      w(MenuItem, { key: 'a', title: 'Menu Item A' }),      w(MenuItem, { key: 'b', title: 'Menu Item B', selected: true }),      w(MenuItem, { key: 'c', title: 'Menu Item C' })    ]);  }}

You could express the same using Custom Elements, independent of a Dojo 2 application:

<demo-menu id="menu">  <demo-menu-item id="a" title="Menu Item A"></demo-menu-item>  <demo-menu-item id="b" title="Menu Item B"></demo-menu-item>  <demo-menu-item id="c" title="Menu Item C" selected></demo-menu-item></demo-menu><script>  a.data = { foo: 'bar' };  menu.addEventListener('selected', function(event) {    const detail = event.detail;    console.log(detail);  });</script>

We have a live custom elements example, along with the example’s source code.

Other widget system improvements

Additional widget system changes enable features and capabilities to make widgets more robust:

• Event listeners on virtual DOM nodes now allow the listeners to change between renders.
• Options for the root of a Projector are more flexible, including being able to return a widget node, or an array of nodes. Changing the root of the projector after the first render is now supported.
• Several internal performance and memory improvements to the virtual DOM and widgeting system.

New widgets

We have introduced two new widgets in Beta 4 and are considering more before the release of Dojo 2. While our focus is providing solid patterns and examples for building widgets, it is very helpful to have out-of-the-box widgets, especially for rapid prototyping.

We have introduced a new accordion pane widget (@dojo/widgets/accordionpane/AccordionPane):

And we have introduced a tooltip widget (@dojo/widgets/tooltip/Tooltip):

Other widget improvements

We are working to standardize conventions in widgets. Some changes have landed for Beta 4, with additional refinements planned for Beta 5. In particular we have been rationalizing our styles, clearly delineating between themeable and structural styles, making it easier to theme existing widgets. We are also investigating approaches to better customize and extend the out of the box widgets.

Stores re-architecture

The current API in Dojo 1 for managing state focused on a CRUD type API. Originally in Dojo 2 we directly adapted that API as part of stores. The concept of state containers has become a primary focus, so we created a solution that aligns to that architecture.

Instead of a CRUD type API, @dojo/stores focuses on three main concepts:

• Operation which is a granular state mutation based on the JSON Patch API
• Command a semantically aligned function which returns a set of operations to apply
• Process a function that groups commands into a process flow to represent a complete behavior

You can read more about the new API at dojo/stores.

A new approach to shims and polyfills

We have rationalized the way we introduce environment compatibility, and improved the build system to further optimize this approach when building an application. We realize that some packages depend upon third-party polyfills, but we did not have a consistent way to introduce them and elide them if not needed.

Now @dojo/shim/main loads all polyfills needed for the expected base functionality and @dojo/shim/browser will load polyfills for a browser environment. Most end developers will not need to worry about this as the other Dojo 2 packages will ensure that these modules get loaded.

If you are building an application targeting only certain platforms, any unneeded polyfills will simply result in a non-operation, but will still be included in the bundle. Beta 4 adds an additional static build optimization feature, where a specially formed pragma will denote the feature that the next import will be polyfilling. If that feature is not required based on the build targets, it will be removed from the build. More information can be found in the elided imports documentation.

Iterators

Previously we provided a functional replacement for for...of constructs, allowing developers to author code that worked in older environments. We also provided shims for Symbol and the built in ES6 iterators. TypeScript 2.3 added a down level emit for iterators. We have restructured our packages to use for...of instead of the @dojo/shim/iterator.forOf() function and will likely remove forOf() in the future. We recommend users of Dojo 2 also migrate to this syntax.

TypeScript helpers

When emitting to JavaScript from TypeScript, each run-time module included all TypeScript helpers needed by that module. This increases the bundle size because these helpers would be duplicated many times. In Beta 4, we import helpers from tslib and automatically include these helpers once as part of the CLI build tool, eliminating any duplication of TS helper code.

What’s next?

We are planning many things for Beta 5, which will always chop and change a bit. You may look forward to:

• A re-architected build tool, which will include build time rendering to automatically identify critical path resources in the build, providing automatic code splitting and build optimization.
• More performance improvements for the widgeting system.
• More examples and applications of @dojo/stores based on the new architecture.
• Improvements to the tooling around widget themes

At the moment, we are planning for Beta 5 in December and a release candidate for Dojo 2 in January.

Getting involved

If you want to get involved, you can see an overview of the parts of Dojo 2 at dojo/meta. In all of our repositories we use the labels good first issue and help wanted to help guide you on a good place to get started.

A new generation

Dojo 2 is a next generation framework authored to emphasize:

• Efficiency. Code structure and developer ergonomics have been challenged at every turn resulting in impeccable code quality.

• Longevity. Sustainable code that will last and adapt as the platform changes is a key consideration for large-scale development projects.

• Modularity. Designed as a collection of packages that may be used independently or cooperatively, allowing for development flexibility.

• Focus. The focus is enterprise-driven, highlighting scalability as well as powerful, built-in features including support for large data sets, a11y and i18n.

The Tenets of Dojo 2

Common Patterns & Standards

Dojo 2 strives for an efficient development approach through common patterns and best practices. Refined APIs and consistent paradigms lead to a robust, forward thinking approach.

Quality

Dojo 2 focuses on quality, with exhaustive test suites and comprehensive code coverage. The deliberate architecture joined with a purposeful combination of tools and technology creates a smooth approach to building modern web applications.

ES6+

With a foundation on ES6+ and its annual release cycle, we begin with a solid base feature set and a strategic approach to shimming future features.

TypeScript

TypeScript extends ES6+ to support development time types and interfaces, leading to first-class IDE support and powerful tools for understanding your code. Dojo 2 leverages TypeScript’s quarterly updates to help teams deliver code with clearer intent.

Reactivity

Dojo 2 embraces functional reactive programming concepts, which have come a long way since Dojo 1’s early get/set methods and virtual scrolling grids. Dojo 2 supports a unidirectional data flow approach, where one can easily react to and/or observe changes to data.

And much more…

Simple OOTB

Dojo 2 was conceptualized with the guiding principle that a developer could have a build up and running in seconds and modifying and deploying real apps in minutes.

Widgets

The Dojo 2 UI widget system provides a system for building Reactive, TypeScript Web Components. It leverages a Virtual DOM and HyperScript over templates or JSX and raw CSS and css-next over traditional preprocessors.

Its widget-scoped CSS classes and autocomplete make it easy to discover those classes for use within our widget code. It also provides a suite of out of the box widgets which are easily extensible including dgrid, charts and more.

Roadmap

The Dojo 2 roadmap highlights many of the details, but at a high level our goal is to release Dojo 2 later this year following 3 Beta releases and a release candidate phase.

Community

Though positioned to meet the needs of the enterprise, at its core, Dojo 2 will be focused on building a healthy open-source community that promotes growth, best practices and code stewardship to its users in an environment that embraces respect and inclusivity.

Evaluate

Dojo 2’s Beta 1 release is intentional and focused. We welcome you to explore Dojo 2 through our initial tutorials and source code via Github.