RightJS 2 Release Plan Updates

My dear fellas, this lovely Friday's evening I'd like to share with you some updates on the RightJS 2.0 release plan. And yes, by "updates" I mean delays.

No need for dirty swears, because there are two good reasons for that. 1) Rails 3 which should come out any moment now, and 2) upcoming IE 9 beta which is scheduled to September 15th. And as we all know well those funny MS folks, I think you'll agree that it's better to wait couple of weeks rather than pull your hair off later.

And it's not all that bad, there are good news too. I'm almost finished porting the UI modules to RJS 2, which means there well be the RC2 release in about couple of days I think. RC2 will include the core with all the latest updates and all the plugins and widgets ported to the new system. Generally this will be the final version and unless someone find a bug it will go to the actual release as is.

You'll have couple of weeks to play with it until the IE 9 release, and I'll have couple of weeks to brush up the docs, update rightjs.org and rework right-rails. Thinks that should give as a good runaway for a nice and smooth release.

This is about it. Take care!

RightJS UI 2 The Battle Plan

Hello people. As I'm currently elbow deep in porting rightjs-ui modules to RightJS 2, I'd like to share some ideas and thoughts behind the changes so you knew what to expect.


RightJS 2 With New UI System

First of all the RightJS 2 release will be not just the core release, there are lots of cool new features and some dramatic changes, so I'm porting all the plugins and ui widgets to the new development approach, and with the RightJS 2 release I'll release updates for all the plugins as well.

This way we will have some sort of a clean slate, and you'll be able to start with all new tools right away.


Widgets === Elements

One of the biggest change in RightJS 2 is those really cool object-oriented dom-wrappers feature, and in the RightJS UI 2 we will take full advantage of it. If in the current system all the widgets are classes with some limited interface, in RightJS UI 2, all the widgets will be inherited from the dom-wrappers, so you will be able to manipulate with them as if they were normal elements.

// say you have a calendar unit
var calendar = new Calendar({
  // some options
});

// now you can do anything you want as if it was a normal Element
calendar.insertTo('my-element', 'top');
calendar.addClass('my-calendar');
calendar.set('id', 'my-calendar-id');
calendar.onChange(function() {
  // do something about it
});

// you also will be able to access it through the standard navigation methods
$('my-calendar-id'); // -> the 'calendar'
$('my-element').first('div.my-calendar'); // -> the same calendar

// it will be also follow the general inheritance structure
calendar instanceof Calendar; // -> true
calendar instanceof Element;  // -> true

You've got the picture, everything you can do with any element on the page you will be able to do with the widgets and do that directly.


Unified Initialization

RightJS UI were growing a bit chaotically during the last year and we have some diverse ways to initialize units. With the new release all of them will work via the same initialization process with the same principles. The rel hacks are gone, instead of that we will use the HTML5 data-widget-name attributes.

<input data-autocompleter="{url: '/some.url'}" />

<input data-calendar="{format: 'US', hideOnClick: true}" />

Meta-framework and Modularity

In current incarnation all the RightJS UI widgets are pretty much independent, which means that we have some duplications here and there, same things work slightly different, not really clean styles and so one.

It's time to refactor the mess, with RightJS UI 2 there will be a meta framework which will provide common bits of elements and styles, like say buttons, panels, spinners, various common functionality and so one. This way we will have a consistent elements behavior over the widgets, plus it will be easier to create new widgets with the common blocks of code already existing.


Unified Stylesheets

The stylesheets also will be cleaned up and unified. There will be common classes for buttons, panels, spinners and so one. One of the reasons is that now we will be able to create skins in a civilized way.

There will be no actual skins with the release, we simply do the preparation work, but the skins constructor is one of the first things to do right after the release.



Summary

As you can see with RightJS 2 release we will bring to the next level not just the core, but the ui modules as well.

I've already ported the Autocompleter and Calendar widgets, you can check it out at the 2.0.0 branch on github. I estimate it will take about a week to port the rest of them to RightJS 2.

After that there will be RC2 release where I'll publish RightJS core and all the modules for tests. And in about a week after that (by the end of August) we shall release.

This is about it.

And btw, if you have thoughts about new features for some of the existing rightjs-ui widgets, that's a really good moment to let me know.

Now that's it.
Take care!

DOM-Wrappers In RightJS 2

Put your tin-foil hats on people, because it's your next brainwashing session about upcoming RightJS 2.

When you heard that RightJS 2 is going to have dom-wrappers instead of direct dom-units access you might think "oh, that's not a big deal, jQuery has dom-wrappers from the very beginning!". And you will be dead wrong! I already touched it a bit in one of my previous articles, now let me show this beauty in details.


DOM-Wrappers == Classes

First of all, dom-wrappers in RightJS are not just a bunch of functions behind a namespace, dom-wrappers in RightJS essentially are normal classes, with inheritance and functionality-injection support. For example you have the basic class Element and two subclasses Form and Input, which means you can say normally call instanceof on them.

$('div') instanceof Element;   // true
$('div') instanceof Input;     // false
$('div') instanceof Form;      // false

$('form') instanceof Element;  // true
$('form') instanceof Input;    // false
$('form') instanceof Form;     // true

$('input') instanceof Element; // true
$('input') instanceof Input;   // true
$('input') instanceof Form;    // false

You also can extend them separately and all the methods will follow the inheritance structure principles

Element.include({
  global_method: function() {
    // this method will appear on all elements
  }
});

Input.include({
  inputs_only: function() {
    // this method will appear on Input elements only
  }
});

You can use polymorphism, redefine the meaning of methods, etc. For example the Element#select will search for matching elements by a css-rule, but Input#select will put the focus on the input element and select its content. No problem, you can do that easily.


Define Your Own Wrappers

The usual extending methods like Element#include, Form#include are fine, but in RightJS you are also allowed to define your own wrappers for certain types of elements. For example you can define a tables-sepecific wrapper

Element.Wrappers.TABLE = new Wrapper(Element, {
  sortBy: function(column) {
    // sort the table body
  }
});

Or you could create a textareas wrapper the same way

Element.Wrappers.TEXTAREA = new Wrapper(Input, {
  spellcheck: function() {
    // spellcheck the content
  }
});

NOTE: we inherited the Element and Input classes as you would normally do with any other classes in RigthJS.

Once you've done that, anytime you access a table or a textarea you'll have those new methods available

$('my-table').sortBy('name');

$('my-textarea').spellcheck();

This feature will let you to adjust and completely redefine the framework itself for the needs of your application.

But this is not the most kick-ass thing yet. Because we have much more!


Private DOM-Wrappers

With RightJS 2 you are not limited to the actual dom-nodes and tags. You can define your very own private dom-wrappers that won't be tied to the framework structure in any way. Why would you need that? The answer is simple - widgets.

How do you normally write a widget? You create some class which aggregates some main element and then you have all the headaches with different contexts and bindings, because half of your logic is in your class and half is in your elements

var MyWidget = new Class(Observer, {
  initialize: function() {
    this.element = $E('div')
      .onClick(this.clicked.bind(this));
  },

  clicked: function() {
     // do something about it.
  }
});

Then more, you'll have to create several proxy methods to delegate the methods to actually insert the widget on the page and do other normal dom-manipulations and so one and so one. In more or less complicated case those things tend to get quite messy.

Well my friends, you don't have to suffer anymore, because now you can define your widget as a private wrapper and inherit any existing dom-wrapper directly just like that

var MyWidget = new Wrapper(Element, {
  initialize: function(widget_id) {
    this.$super('div', {
      'id': widget_id,
      'class': 'my-widget'
    });
    this.onClick('doSomething');

    // build your entire widget over here
  },

  doSomething: function() {
    // do something about the click
  }
});

NOTE: now you never leave the actual element context, don't need to worry about bindings, and then, can manipulate with your widget as a usual element on your page.

var widget = new MyWidget('widget-id');
widget.insertTo('some-element', 'after');
widget.addClass('custom-class');

// more of that!
$('widget-id') instanceof MyWidget; // true!

And there is more! You can inherit your private wrappers as any other and create different versions of your widget!

var MySuperWidget = new Wrapper(MyWidget, {
  initialize: function(widget_id) {
    this.$super(widget_id);

    this.onClick('doSuperThing');
  },

  doSuperThing: function() {
    // do the super thing over here!
  }
});

You can create abstract widgets, share modules between them, do any sorts of crazy things, the possibilities are endless! And at the end, you still have an Element, which you can toss around the page in the usual way.

---

Oh yes my dear fellas, RightJS 2 will help you to kick some serious ass! The right way!

And this is about it. Come over for the next session, it will be fun!

Prepare Your Project For RightJS 2

Some notes for those lucky of you who already is hooked to RightJS and the ones who think about giving it a try, but afraid that when RightJS 2 will start saving the world, the ones code will go south.

Rule #1 don't panic, despite of all the massive changes in the dom-stack and all the new finest kickassery, the actual API almost didn't change, just instead of real dom-nodes/events/etc you will receive some proxy objects, which have the same exact API. The difference is that you will have no direct access to the dom-unit attributes, so if you want your code to be working both in RightJS 1 and RightJS 2, use the Element#get, #set and #has methods instead.

// instead of this
$(element).id = 'boo-hoo';
var id = $(element).id ? $(element).id : 'default';
  
// write it like that
$(element).set('id', 'boo-hoo');
var id = $(element).has('id') ? $(element).get('id') : 'default';

If you need to access an element innerHTML use a simple patch like that

Element.include({
  html: function() {
    return this.innerHTML;
  }
});

Later, when you will migrate to the actual RightJS 2, just remove it, RightJS 2 will have this method out of box.


Rule #2 don't access `window` and `document` directly, when you need to access some of the RightJS methods, put them through the same `$()` function first as you do with the dom elements

// instead of those
document.onReady(function() { ... });
window.sizes();

// call it like this
$(document).onReady(function() { ... });
$(window).sizes();

Rule #3 don't use `Form.Element` this unit will be renamed to Input in RightJS 2, so don't touch it or create a simple reference like that

var Input = Form.Element;

and work with the Input object instead.


This is about it. If you follow those three simple rules, all your code should be in working condition when you switch to RightJS 2.

The Circus of Web Development

You might think of the web-development area (or sphere if you will) as some sort of a circus. For example.

Say there is an elephants show of Java developers, they big, slow, but precise. Then there is a exotic pet show of Python developers. Fearless camel riders with the perl guys. JavaScript people will be magicians, weird fellas who make things appear and disappear by some flimsy tricks.

Then there are a bunch of trained monkeys of Ruby kids (yes my agile friends we are :)). ASP.NET folks will be gipsy fortune-tellers, barely connected with the reality and no-one listen to them. And there are bears on monocycles in silly turkish hats, those are the PHP people (you are comrades, you are).

Clowns! Those will be the web-architects. Just like the real clowns, they barely can do a thing properly, and yet, they think they own the circus.

RightJS 2.0.0-rc Is Out

Okay folks, RightJS 2 came to the point where it has a proper number and the '-rc' suffix in it's name. And here are some notes on the new sweet features we have since the beta release.

You can download the build over here, the archive contains both normal and safe-mode builds.

Generally this is almost the final line, I've finished packing it with new features and this is practically all we will have in the actual 2.0.0 release. There might be some tweaks here and there during the plugins and UI modules porting, but nothing dramatic. So lets check what we've got.


Dom Wrappers

In RightJS 2.0 we have a new kick-ass object oriented dom-wrappers system. Our dom-wrappers are essentially classes, with types, inheritance and all the nice functionality injection features. Currently we have the following wrappers Window, Document, Event, Element, Form and Input, which formerly was known as the Form.Element unit.

Dom-wrappers work transparently and have all the same nice API we had in RightJS 1, the only difference is that instead of the actual dom-element all the methods now operate with dom-wrappers.

$('element-id')  // -> dom wrapper
$$('#css .rule') // -> a list of dom-wrappers

All the dom wrappers are inherited from the same unit called `Wrapper` and have a common property called `_` which refers to the raw dom element, for example

$('element-id')   // -> Element wrapper
$('element-id')._ // -> the actual dom-node

$(window)         // -> Window wrapper
$(window)._       // -> the window object

$(document)       // -> Document wrapper
$(document)._     // -> the document object

So every time when you fill like it, you can always quickly access to the raw unit the same way across all the wrappers.


Dom-Wrappers Typecasting

As you might noticed we have three types of wrappers for dom-elements, the Form and Input classes are subclasses of the Element class and when you access your dom-elements they dynamically typecasted

var element = $('my-form');
element instanceof Element; // -> true
element instanceof Form;    // -> true
element instanceof Input;   // -> false

var element = $('my-input');
element instanceof Element; // -> true
element instanceof Input;   // -> true
element instanceof Form;    // -> false

This way you can check which type of element do you have and you can extend all of them separately

Element.include({
  global_method: function() {}
});

Form.include({
  forms_only_method: function() {}
});

Input.include({
  inputs_only_method: function() {}
});

You even can use polymorphism and use the same method names

And you also can define your own types, for example

Element.Wrappers.TABLE = new Wrapper(Element, {
  orderBy: function() {}
});

Later on there will be also private dom-wrappers which you can use in your app without extending the RightJS core and interfere with other applications.


Bubbling Dom-Events

RightJS also received several fixes for the traditionally problematic dom-events like focus, blur, change and submit, now all of them properly bubble on all the supported browsers.

There is nothing kinky about it I didn't use any special event names, just use the usual ones like nothing happened.

$(element).on({
  focus: ...,
  blur: ...,
  change: ...,
  submit: ...
});

I also added the custom events bubbling. If in RightJS the custom events didn't go anywhere from the node where you fired it, now they properly bubble up to the document object, so you can take advantage of them using the events-delegation technique.

Speaking of which.


New Events Delegation API

In the later releases of RightJS 1.5 we already had some elements of the events-delegation feature support, now it's time to take it to the next level.

First of all the String unit now has all the same API as Element, so you don't need to learn nothing new, just use what you already know.

"#div .span".on('click', function() {...});
"#div .span".onClick(function() {});
"#div .span".onClick('addClass', 'marked');

// you also can make the normal checks
"#div .span".observes('click'); -> true
"#div .span".observes('mouseover'); -> false

// and you can unbind the listeners the usual way
"#div .span".stopObserving('click', function() {});

Then the Event.delegate and Event.behave methods are gone and instead of them we have a proper events delegation API on dom-wrappers which look like that

$(document).delegate('click', '#css.rule', function() {});
$(document).delegate('click', {
  '#css.rule1': function() {},
  '#css.rule2': function() {}
  ....
});

// delegation checks
$(document).delegates('click');
$(document).delegates('click', '#css.rule');

// disabling delegation
$(document).undelegate('click');
$(document).undelegate('click', '#css.rule');

More of that the same API was adde to the Element wrapper so you can attach your delegating listeners at any level of your web-page

$('my-list').delegate('click', {
  'li.one-thing': function() {}
  'li.another':    function() {}
});

This way you can scope the delegation to some block of your document and handle the things locally.

You also can delegate custom events too

$(document).delegate('bingo', {
  '#one':   function() {}
  '#another': function() {}
});

$('one').fire('bingo');
$('another').fire('bingo');

Generally there are no limitations and you handle any sort of events simultaneously via the same api.


$$ Is Back!

As you might noticed I moved the $$ function back. I tried to use the jQuery-like unified $ method but didn't like it and brought the $$ back.

Amen.


Semi-Safe Mode

As you might know RightJS 2.0 will have the safe-mode build, which will hide everything behind a single RightJS object and won't extend a thing on the user's page.

A typical use case would look like that

RightJS.$('element-id').onClick(....);

var MyClass = new RightJS.Class({
  ...
});

There is also a way to access the language unit extensions by passing variables through the RightJS object

RightJS(['boo', 'hoo', 'doh']).filter('includes', 'oo');
RightJS(4).times(function() { .... });
RightJS('boo hoo').endsWith('hoo');

In the RC release I added a semi-safe API for the non-safe builds, meaning you can put your variables through and access the RightJS units via the RightJS object. This way if you need say to write a plugin that supposed to be working in both safe and non-safe modes, you can simply write it for the safe-mode and it will be working in the non-safe mode too.


JSONP Support

In RightJS 2.0 there is the JSONP format support for the Xhr unit. It all works transparently via the same Xhr API with all the same principles, the only thing is that now you have the jsonp option where you can specify your callback name variable, or simply use true for the default 'callback' value.

new Xhr('/some/url', {
  jsonp: 'myCallback',
  onSuccess: function() {
    // ....
  }
}).send();

Xhr.load('/some/url', {jsonp: true});

It even will assign the responseJSON and json varaibles

Xhr.load('/some/url', {
  jsonp: true,
  onSuccess: function() {
    console.log(this.json);
  }
});

New Language Level Methods

There are also several new javascript level extensions were added. Object.each, Array#reject (which is useful with calls by name), Array#min, Array#max, Array#sum

Probably something else that I have forgotten.



The Next Steps

Now when the core is finished, there are quite a lot of work with porting the plugins to the new version and reworking the documentation. The site also needs to be reworked to support the new building system.

At the moment I estimate it like 2-3 weeks of work. So the delivery-day is somewhere by the end of summer.

Okay, think that's all I have for know.
Take care!

Why Albeit Packing Is A Bad Idea

Okay I did it quite a lot on RightJS, but I've learned my lesson. A quick and self-explanatory example would be like that.

Say you have the following piece of javascript

a1.looooongMethod();
a2.looooongMethod();
a3.looooongMethod();
a4.looooongMethod();
a5.looooongMethod();

Being an optimization junky, you might think, "Oh! I can make it smaller!"

var b = 'looooongMethod';
a1[b]();
a2[b]();
a3[b]();
a4[b]();
a5[b]();

Then you look at the size, the first one weights 104 bytes and the second one 70.

"Woohoo!", you say, "30% optimization!". And will be wrong.

Because when a web-server gzips your code, the first one will weight 61 bytes and your optimized version will be... TADA! 72 bytes. Yup, bigger than it was before 8)

That's the whole story. Gonna go and unoptimize things back now.