I am playing around with a different way (at least for me) to construct a JavaScript toolkit. It is called Blade, and you can follow it via the Blade GitHub repo.
I have had this on my local drive for a few weeks now, and the germ of it started with this post. I wanted to get it more polished, but best to get it up somewhere to get some feedback at least on the principles.
There is not much there now, basically a tiny amount of spaghetti code that is not really usable. However, I list out the guiding principles in the README.md, visible on the GitHub source tab.
Wednesday, October 28, 2009
Thursday, October 22, 2009
Raindrop, Open Messaging for the Open Web
I work for Mozilla Messaging, and we just opened the doors on Raindrop. Raindrop is the reason I had the opportunity to move to Vancouver, BC. It has been fun building it, seeing if we could get something to work.
Raindrop is still very much an experiment and not useful for any day-to-day work. However, it has potential and we need community help to take if further.
Why I like it:
Dojo's dynamic code loader and Dijit's well-defined methods on widgets have enabled the slick things we are doing with in-place extension editing and updates. JQuery is also included in the page, mostly for extension developers, so you have a choice on what to use, Dojo or JQuery.
While I expect many of the decisions I made about how the front end works might change over time, it has been a joy to make what is there so far.
There is lots to do though. If you want to get involved with the code, check the Hacking page is a good place to get started. There is a screencast of the architecture on the Raindrop home page. There is a Community page too.
Raindrop is still very much an experiment and not useful for any day-to-day work. However, it has potential and we need community help to take if further.
Why I like it:
- It is driven by product design. We want an extensible platform, but a strong, simple product design will be driving much of the development.
- It is not trying to be a message service in itself, but collect messages from existing services.
- It is web-based: the default UI is plain HTML/JavaScript/CSS goodness.
- It is frickin awesome to be able to play with your messages: data mine them, and do interesting display things using simple script languages like JavaScript and Python.
- It is open: open source and motivated by the Mozilla Manifesto.
- The Mozilla Messaging team is talented and smart. They are motivated and care about what is best for users.
Dojo's dynamic code loader and Dijit's well-defined methods on widgets have enabled the slick things we are doing with in-place extension editing and updates. JQuery is also included in the page, mostly for extension developers, so you have a choice on what to use, Dojo or JQuery.
While I expect many of the decisions I made about how the front end works might change over time, it has been a joy to make what is there so far.
There is lots to do though. If you want to get involved with the code, check the Hacking page is a good place to get started. There is a screencast of the architecture on the Raindrop home page. There is a Community page too.
Sunday, October 18, 2009
RunJS updated: module modifiers and function modules
I pushed some changes to allow lazy-loaded/lazy-evaluated module modifiers and also better support for modules that just define a function. The changes are documented in the documentation page.
I am experimenting with using JSLint as a code formatter. We'll see how it goes.
All these changes bring the size up to 3.1 KB minified and gzipped. I would like to be under 3 KB, but I want to be sure the right functionality is in place first before squeezing it down.
The module modifiers are a bit of an experiment. I wanted some way to separate a bunch of bad, wordy code out for the normal cases of a module but only in bad cases load the bad code. The example I give in the documentation is a module that gets DOM node dimensions and position. In standards mode, it is fairly compact, but in quirks mode it gets uglier. So I only want to load the quirks mode code if the page is in quirks mode. I never want to develop in a quirks mode page, but for a general JavaScript library it might be important.
So I am still not sure if the module modifier approach is the right way to go, but I have used it a little bit so far on another project, and I will see how that works out.
I am experimenting with using JSLint as a code formatter. We'll see how it goes.
All these changes bring the size up to 3.1 KB minified and gzipped. I would like to be under 3 KB, but I want to be sure the right functionality is in place first before squeezing it down.
The module modifiers are a bit of an experiment. I wanted some way to separate a bunch of bad, wordy code out for the normal cases of a module but only in bad cases load the bad code. The example I give in the documentation is a module that gets DOM node dimensions and position. In standards mode, it is fairly compact, but in quirks mode it gets uglier. So I only want to load the quirks mode code if the page is in quirks mode. I never want to develop in a quirks mode page, but for a general JavaScript library it might be important.
So I am still not sure if the module modifier approach is the right way to go, but I have used it a little bit so far on another project, and I will see how that works out.
Monday, October 12, 2009
RunJS updated: simple modules and i18n bundles
I pushed some changes to RunJS, the stand-alone JavaScript file/module loader.
Newest changes are support for simple module definitions and internationalization (i18n) bundles.
Simple module definitions are possible when there are no dependencies for the module. In that case the function wrapper for the module is not needed:
If you want to try out the latest code, you can use one of the following URLs to fetch the code:
In addition to the documentation, some of the test files might be of interest to see how RunJS can be used.
RunJS is still nice and small with these new features, around 2.7KB, when minified via YUICompressor and gzipped.
Newest changes are support for simple module definitions and internationalization (i18n) bundles.
Simple module definitions are possible when there are no dependencies for the module. In that case the function wrapper for the module is not needed:
i18n bundle support is handy for separating out strings that might need to be translated into other languages. Quick example for a my/nls/colors.js that will define a bundle:
run(
"my.simplething",
{
color: "red",
size: "large"
}
);
Then define a file at my/nls/fr-fr/colors.js that has the following contents:
run(
"my.nls.colors",
[{
"root": {
"red": "red",
"blue": "blue",
"green": "green"
},
"fr-fr": "my.nls.fr-fr.colors"
}]
);
See the documentation for more information.
run(
"my.nls.fr-fr.colors",
{
"red": "rouge",
"blue": "bleu",
"green": "vert"
}
);
If you want to try out the latest code, you can use one of the following URLs to fetch the code:
In addition to the documentation, some of the test files might be of interest to see how RunJS can be used.
RunJS is still nice and small with these new features, around 2.7KB, when minified via YUICompressor and gzipped.