I will be hosting a series of online React workshops every two weeks and videos of every session would be shared at bit.ly/JavaScriptMentor channel at youtube. Any feedback is appreciated.
@maiamcguinness not at all, this is the very right question to ask!
Let's have a quick look at the trade-offs here:
- A lightweight AMD API along with lazy loading:
First tradeoff is the same when @jrburke created almond.js which is having a minimal AMD API. Using DefineJS you have a minimal AMD API like almond.js which also offers the lazy loading with a realtime script loader API (almond.js doesn't have a script loader for lazy loading).
- Nonstandard functionalities:
But actually the main idea behind DefineJS was not just offering a lazy loading process for JavaScript modules. The initial vision for DefineJS was offering new useful but nonstandard functionalities based on the latest JavaScript features like Promises and new syntaxes like es6 generators.
- Promised Modules:
Using the same AMD module style you can have privileged promise based modules, which allows to have a lazy module definition.
- Promised Modules, lazy module definitions, partial module definition and a synchronous looking code to require a dependency when it is actually an asynchronous are the four main features that DefineJS has managed to offer so far based on this vision.
- When coding for NodeJS everything looks much cleaner because of the CommonJS style of coding, the only way to have such a clean coding style in browser is possible using browserify:
>Browserify lets you require('modules') in the browser by bundling up all of your dependencies.
DefineJS v0.2.31 now is also offering the similar style just by adding a extra yield keyword like:
var module = yield require('module');
DefineJS is still missing bunch of standard features to offer the whole CommonJS coding style, but most of them are in the todo list.
Hope this explanation is clear enough to answer the question.
[comment deleted]fixjs 3428 days ago. link 1 point ▲▼
DefineJS is a lightweight implementation of AMD but other than regular AMD module pattern, it also offers couple of nonstandard but useful modular coding patterns.
'ES6 generators' and 'Promised Modules' are the main DefineJS features which both need JavaScript community's feedback.
@maiamcguinness not at all, this is the very right question to ask! Let's have a quick look at the trade-offs here: - A lightweight AMD API along with lazy loading: First tradeoff is the same when @jrburke created almond.js which is having a minimal AMD API. Using DefineJS you have a minimal AMD API like almond.js which also offers the lazy loading with a realtime script loader API (almond.js doesn't have a script loader for lazy loading). - Nonstandard functionalities: But actually the main idea behind DefineJS was not just offering a lazy loading process for JavaScript modules. The initial vision for DefineJS was offering new useful but nonstandard functionalities based on the latest JavaScript features like Promises and new syntaxes like es6 generators. - Promised Modules: Using the same AMD module style you can have privileged promise based modules, which allows to have a lazy module definition. - Promised Modules, lazy module definitions, partial module definition and a synchronous looking code to require a dependency when it is actually an asynchronous are the four main features that DefineJS has managed to offer so far based on this vision. - When coding for NodeJS everything looks much cleaner because of the CommonJS style of coding, the only way to have such a clean coding style in browser is possible using browserify: >Browserify lets you require('modules') in the browser by bundling up all of your dependencies. DefineJS v0.2.31 now is also offering the similar style just by adding a extra yield keyword like: var module = yield require('module'); DefineJS is still missing bunch of standard features to offer the whole CommonJS coding style, but most of them are in the todo list. Hope this explanation is clear enough to answer the question.