Dojo 2
Dojo 2 refines and extends the original Dojo interfaces, removing obsolete features and harmonizing terminology in accordance with the additions made to ECMAScript since the initial release of Dojo in 2004. The goal of Dojo 2 is ECMAScript 5+ support only. So, features that were in Dojo 1 and that became part of the ECMAScript specification were removed from the framework.
Dojo 2 is written in TypeScript. This allows Dojo users to take advantage of the additional static typing and allows Dojo to be published to AMD, CommonJS, and ES6 format modules for use with native modular systems in any modern environment.
The Dojo Toolkit was created in 2004 by a group of like-minded JavaScript developers who are tired of reinventing the wheel and creating crutches around browser inconsistencies.
The Dojo Toolkit's mission is to ensure the integrity and ease of use of API functions that allow developers to create simpler supported web applications and not worry about inconsistencies and fads of each browser.
')
We released Dojo 1.0 in 2007 and continued to develop it continuously, introducing the concepts that have now become major in the development of JavaScript. At that time, the use of JavaScript modules, promises / deferreds, MVC, CSS preprocessor and build systems was perceived by many as complex and unnecessary. As we know, these things have become part of the development of JavaScript today, and we are very pleased that the majority of JavaScript developers are now seeking to develop in this direction.
We spent a lot of time thinking about what the next generation JavaScript framework should be able to do. It is not enough just to add new features, increase the version number and name it "Dojo 2". It should be a set of basic principles that determine future development. The world of JavaScript has changed significantly since the birth of Dojo. The mission of the framework remains the same, but the way it is done will be very different.
Nowadays (at least this week) in the JavaScript world they think that everything that can be divided into separate packages should be divided. For example, if all you need is basic DOM manipulation and event handling, then you can take a package that does just that.
This works great for small projects, but as requirements grow and complexity increases, more and more packages from multiple sources are added to the project. The idea that you can simply change the package to another later is utopia. When creating software for large corporations, it is often impossible to work in this way, because their legal departments require pure intellectual property - the code is reviewed and legally accepted before use.
Our approach to Dojo 2 lies in the golden middle between the individual packages and the single Dojo Toolkit. We will develop, build, and release Dojo core functionality along with packages such as dgrid, dstore, and Intern. Developers will be free to use and independently upgrade the parts they need, or use the assembled Dojo Toolkit release. Dojo separation will allow others to contribute more easily and releases will be faster and much less painful.
Dojo was probably the first in many directions, but, given the proliferation of JavaScript micro-libraries and tools, we often have no reason to support our own solution just because it is ours. Where there is a comparable or better implementation, we will think about using it. For example, we will document our code using JSDoc, not DojoDoc, as we did during the development of Dojo 1.x.
Speaking of documentation: we diligently worked on improving the documentation for Dojo 1.x, but our documentation requirements for Dojo2 are even higher. In many ways, problems with documentation were caused by the lack of tools. Using modern solutions such as JSDoc, Markdown and GitHub, we can increase the quality of documentation and the speed of adding and updating documents.
First, Dojo 2 will be written in TypeScript. While ES6 / ES2015 has brought many needed improvements, there are a lot of unfinished things. Languages ​​such as TypeScript allow you to add enhancements before they are added to the language. Then we can easily compose transpiler in AMD, CJS or ES6 modules. This allows you to improve the language itself, but more importantly, make life easier for developers.
In addition to desktop browsers, the goal of Dojo 2 is to support the largest possible number of modern JavaScript environments. This means support for mobile phones, tablets, Node.js / io.js, VR headsets, and more.
Widgets were one of the main features of Dojo 1.x, but much has changed since we introduced Dijit. We are still thinking about what approach to choose in Dojo 2 - Dijit, native widgets, web components or something completely new. Our initial focus is on defining the core functionality for Dojo 2, after which we will begin to define a common approach for widgets.
We work on each part of Dojo 2 in a few steps.
Design. Define core functionality and APIs to create a high “specification” for each Dojo 2 package.
Development. Using the specification created in step one, develop and document the functionality. Then use Intern to check that it works.
Release. Dojo 2 will be packaged as a set of different modules. With the completion of each module, we are closer to Dojo version 2.0.
Road map
Github
Dojo 2 is written in TypeScript. This allows Dojo users to take advantage of the additional static typing and allows Dojo to be published to AMD, CommonJS, and ES6 format modules for use with native modular systems in any modern environment.
The overall approach of Dojo 2
The Dojo Toolkit was created in 2004 by a group of like-minded JavaScript developers who are tired of reinventing the wheel and creating crutches around browser inconsistencies.
The Dojo Toolkit's mission is to ensure the integrity and ease of use of API functions that allow developers to create simpler supported web applications and not worry about inconsistencies and fads of each browser.
')
We released Dojo 1.0 in 2007 and continued to develop it continuously, introducing the concepts that have now become major in the development of JavaScript. At that time, the use of JavaScript modules, promises / deferreds, MVC, CSS preprocessor and build systems was perceived by many as complex and unnecessary. As we know, these things have become part of the development of JavaScript today, and we are very pleased that the majority of JavaScript developers are now seeking to develop in this direction.
Basic principles
We spent a lot of time thinking about what the next generation JavaScript framework should be able to do. It is not enough just to add new features, increase the version number and name it "Dojo 2". It should be a set of basic principles that determine future development. The world of JavaScript has changed significantly since the birth of Dojo. The mission of the framework remains the same, but the way it is done will be very different.
Modularity
Nowadays (at least this week) in the JavaScript world they think that everything that can be divided into separate packages should be divided. For example, if all you need is basic DOM manipulation and event handling, then you can take a package that does just that.
This works great for small projects, but as requirements grow and complexity increases, more and more packages from multiple sources are added to the project. The idea that you can simply change the package to another later is utopia. When creating software for large corporations, it is often impossible to work in this way, because their legal departments require pure intellectual property - the code is reviewed and legally accepted before use.
Our approach to Dojo 2 lies in the golden middle between the individual packages and the single Dojo Toolkit. We will develop, build, and release Dojo core functionality along with packages such as dgrid, dstore, and Intern. Developers will be free to use and independently upgrade the parts they need, or use the assembled Dojo Toolkit release. Dojo separation will allow others to contribute more easily and releases will be faster and much less painful.
Use of existing ecosystem
Dojo was probably the first in many directions, but, given the proliferation of JavaScript micro-libraries and tools, we often have no reason to support our own solution just because it is ours. Where there is a comparable or better implementation, we will think about using it. For example, we will document our code using JSDoc, not DojoDoc, as we did during the development of Dojo 1.x.
Improved documentation
Speaking of documentation: we diligently worked on improving the documentation for Dojo 1.x, but our documentation requirements for Dojo2 are even higher. In many ways, problems with documentation were caused by the lack of tools. Using modern solutions such as JSDoc, Markdown and GitHub, we can increase the quality of documentation and the speed of adding and updating documents.
JavaScript continues
First, Dojo 2 will be written in TypeScript. While ES6 / ES2015 has brought many needed improvements, there are a lot of unfinished things. Languages ​​such as TypeScript allow you to add enhancements before they are added to the language. Then we can easily compose transpiler in AMD, CJS or ES6 modules. This allows you to improve the language itself, but more importantly, make life easier for developers.
Modern environments
In addition to desktop browsers, the goal of Dojo 2 is to support the largest possible number of modern JavaScript environments. This means support for mobile phones, tablets, Node.js / io.js, VR headsets, and more.
Widgets
Widgets were one of the main features of Dojo 1.x, but much has changed since we introduced Dijit. We are still thinking about what approach to choose in Dojo 2 - Dijit, native widgets, web components or something completely new. Our initial focus is on defining the core functionality for Dojo 2, after which we will begin to define a common approach for widgets.
Plan
We work on each part of Dojo 2 in a few steps.
Design. Define core functionality and APIs to create a high “specification” for each Dojo 2 package.
Development. Using the specification created in step one, develop and document the functionality. Then use Intern to check that it works.
Release. Dojo 2 will be packaged as a set of different modules. With the completion of each module, we are closer to Dojo version 2.0.
More information:
Road map
Github
Source: https://habr.com/ru/post/262327/
All Articles