So, I’ve started new page in my career. In a great company with great products and great history, but most importantly with great opporunities for me to make impact on the Web. That’s what I always wanted to do: change the Web. Raphaël shaped the Web a little; as much as a niche JavaScript library can. It’s mission is not over yet, but I have desire to hit a bigger drum.

I started my work at Adobe as Senior Computer Scientist. I will work on Web Standards and represent Adobe at W3C. Instead of just complaining about how something is bad or ugly, I hope, I could actually change things. Or create new things that wouldn’t be ugly, right?. We shall see. Either way, I am excited to turn around this corner and see what is waiting for me over there. There is a great team of people deeply passionate about web standards and I am lucky that I could work alongside those people. And, by the way, we are hiring. Do you want to change the world too? ;)

I am not saying that using new operator is a bad idea, it’s an essential operator, but asking me to use it with your API is a bad idea. Lets look at box2d.js API for example. Because it was supposed to copy C++ API, it took all C-like decisions and copied it straight to JavaScript. It’s ok for something that was ported, but I see the same patterns in APIs created in JavaScript from the scratch.

This will create new attribute segment, which you could set up like el.attr({segment: [x, y, r, a1, a2]});. Basically the function we defined earlier will translate our custom attribute into set of common attributes, in our case segment will become a path. The important thing is that now as an attribute segment could be animated. See demo: growing segments of the pie.

What about keyframes? Well, you can simply specify animation in additional format:

This is more like CSS 3 animation does it. And as a bonus you now can run multiple different animations at the same time over the same element. See demo: asynchronous animation.

Note: If you upgrade you could have issue with animation of translation or rotation. To fix it simply add el.stop() before call to animate method, because animate wouldn’t stop older animation anymore.

In JavaScript nothing is what it looks like; you rarely work with actual values.

Most of the time values morph from one type to another, just so they can morph to yet another type later on. That's the way of language. And if that weren't enough, I recently found that the way I was writing some functions in JavaScript was wrong. It wasn’t particularly my fault, though, as it looks like most of us did it wrong the way.

And when we call it successfully an attribute is set. And it’s not only setting what we send, it additionally checks that attributes appear in a white-list before setting them. All seems good. Or is it?

The difference can be subtle as it’s between “Is this variable’s type ‘object’?” and “Is this an object?”.

As you know a function is an object and function… new Number is an object and a number…

This way of thinking about JavaScript isn’t limited to typing—it impacts the comparison operator, also.

You’ll often hear that “==” is a bad part of JavaScript. I not so sure. It is often better to use “===” instead of “==” only if you don’t clearly understand how those operators work or are simply in doubt.

The brackets don’t hurt, but putting them everywhere just because you used to is redundant. And it’s the same with “===”.

Taking a look at our “is” function, you’ll notice I don’t care if type is a string or not as long as it equals (==) “object” or “null”, etc. We’re embracing the flexibility of the language, and not fighting against it.

Don’t code as though the types are fixed, they’re not.

Next time you’re going to use typeof or “===” think about whether it’s the best choice. Remember that in JavaScript nothing is always what it looks like.

I added resetScale method, which will reset scale counter on the object, so next time you will scale it, it will happen absolutely, not relatively.

Scaling text is not supported. I added partial support in 1.4: now position of the text will change, but not the actual size.

Fixed annoying long lasting bug in IE for rectangle with rounded corners. There are couple of other bugs have been fixed.

New method drag was added, due to huge demand. Now you can make something draggable as simple as: element.drag(onmove, onstart, onend); I will update documentation soon, but so far you can take a look at the updateddemos.

Last is the big one: multitouch support, now all mousedown, mousemove and mouseup are replaced with touch event handlers on touch devices. In additon drag method will allow you to drag multiple objects at the same time. Watch the video. Or try the demo yourself if you are lucky iPhone/iPod Touch/iPad holder.

More and more people on the Web digging into JavaScript and using it
for daily tasks. It is always fascinating to watch how they approach
inheritance in JavaScript. Most of the time two patterns are used:

The only problem with this one is that it uses the constructor of the first
object to create middle object, which is going to be a prototype for
o2. There is no guarantee that this constructor will be empty. Adding
an alert in it will make the code unusable. A simple workaround leads us to
second pattern.

Now, it is important to note that there is no way to do clean
inheritance in ECMAScript 3. Fixing constructor in line:
“f.prototype.constructor = o2;” makes it enumerable, which means it
will show up in a “for in” loop. This pattern creates a real prototype
chain. Changing o1 prototype will affect not only john, but also
bill. Depending on the model this could be good or bad thing. You
inherit everything: to remove a method, one has to overwrite it with
undefined.

Downsides: bill.a is two steps away. The more you use this pattern
the more steps away it will move, costing time and processing. And, as I mentioned, the constructor property is fake.
It is enumerable.

This does the same as the others without prototype chain creation. Method
“a” is nicely shared across two objects. You could alter o1 prototype
without worrying about o2. Just as in previous case, depending on the model
this could be a good or bad thing.

In my experience, the most common case is when you create
objects’ constructors in the beginning and don’t alter their
prototypes later on. Altering prototypes during your script is a tricky
and dangerous procedure. I guess there are some cases when it is the
best solution, but I can’t think of any of them off top of my head.

What I am trying to say is that the second pattern above will serve 99% of the current
scripts where “inheritance” is used but long prototype chains make every
call to the object’s property run through the whole chain and
those runs are not free.

This pattern also makes the “instanceof” operator work,
but I am not sure how useful it is in general. (I mean is (obj
instanceof o1 === "a" in obj) always true? No. So, what the point?)

I reckon the second pattern only makes sense when you are about to
mutate your objects during your script and benefit from this connection
between prototypes. Otherwise you are creating infrastructure you are
not going to use, but still have to pay the maintenance for. Why do that?

Recently I started to ask twitterverse JavaScript related questions, just for fun. I called it “jsquizz”, but twitter is very fast media, so I decided to copy some of this questions here, so I could easily find them later.

var a = Math.floor(b);
// if b is always positive, we could make it shorter
var a = ~~b;

var a = new Boolean(false); // how to quickly check if (a)?
alert(typeof a); // "object"
alert(!!a); // always true, because a is an object
alert(!!+a);
// right result, because “+” is calling valueOf
// method and convert result to number “0..1”
alert(a>0); // even shorter

[0, 1, 2][0, 1, 2] // what the result of this expression?
alert([0, 1, 2][0, 1, 2]); // 2
// first brackets is array declaration,
// second brackets contains comma
// operator, so it is almost equivalent to
alert([0, 1, 2][2]); // 2

In Raphaël 1.2 release I did two major changes that I want to explain: IE optimisation and animation revamp.

For drawing in IE Raphaël uses VML. VML syntax for path is different to SVG: it uses different letters for commands and it doesn’t support floating point numbers. So to insure correct work I have to replace commands and round the numbers. But this not the end, IE doesn’t support quadratic curves and arcs. To work it around I convert everything into cubic curves. Conversion takes time. In IE we facing world slowest JavaScript engine, so on big paths performance could go down to unacceptable level. In 1.2 I optimized it a bit. I convert path to curves only if it has cubic curves or arcs, otherwise I just replace commands and round the numbers. Unfortunately I can’t come with a better solution at the moment, but if you have any, drop me a line.

The animation in Raphaël was done not in the best way: for each animation I created separate timer, so in case if you animate multiple objects at the same time, they are moving asynchronously. I unite all animation under the same timer and it made animation smoother in Safari and more accurate in all browsers. But there is still an issue with the fact that when you animate a large group of elements it is impossible to start animation for each element at the same time. The worst JavaScript engine the bigger is the gap between animations and on long run it is quite noticeable. To fight this I introduced new method animateWith, which first argument is an element you wish to stick to. Raphaël uses it internally when you animate set, so I would say the easiest way to animate two elements synchronously is to unite them in set and call animate method on the set.

In the video I created 150 circles and animated them to the same X. You can easily see the difference.

It was an argument in web standards talks for a while. Tables for layout, style attributes, JavaScript event attributes, inline script tags and even font tags are ok. Take a look at google.com. Right. Google.com is probably most visited page in the web, so if <font size=-1>blah</font> is smaller than correct semantic HTML and CSS, even by one byte, then it worth it. Because every byte counts. With such a traffic every byte of home page costs some quite visible money to the company. (I even heard a stories about some guy, who managed to reduce size of the google.com page by couple of characters and received a bonus from the company…) Google just put size of the page as a priority above valid mark up, right?

Not really.

If you look at the source code of the google.com home page, you will see that size of it could be decreased a lot. In particular inline JavaScript can be compressed at least by 10%.

I just saved 51 byte! There are more, literally kilobytes of code to be saved, but it looks like nobody cares. Wait, if nobody cares about page size, why we have ridiculous font tags in the page? May be I don’t understand some obvious thing or may be the King is naked.

Recently I released Raphaël 1.0 RC1. The most noticeable change for users of the library is differences in the API: removing moveTo, lineTo and friends from the path object. Why did I decide to do this? The biggest drawback of these methods is that they apply immediately. That means that if you draw path consisting of three segments, path element is updated three times – each time with increased number of segments, so total number of segments drawn is 1 + 2 + 3 = 6. The more segments your path has, the longer it takes to draw. In geometric progression.

To avoid this I could introduce some method “draw” that could be called after you define all segments, but this doesn’t look like an elegant solution and doesn’t suit the library’s name. There is a soluton that is compact, simple and you could easily work with it. Say, you want to change some point on the path. There is no interface for this apart from SVG path, and I can’t think of any elegant and easy to grasp API for this. Manipulating strings is what JavaScript can do very well. So I removed these methods from the library to external plugin, which you could concatenate with the Raphaël if you really rely on them. I suggest you learn SVG path syntax: it is simpler than it looks.

Other big thing is adding support for angle in arc. This is very rare thing, and frankly, I haven’t seen it in the wild, but without it SVG path support wasn’t complete. To make it happen I rewrote arcTo for VML completely. Now it converts arc to bezier curve, because VML doesn’t have support for angles in arc segments. The same method is now used in animation (for SVG & VML), which makes animation more smooth. Conversion of the whole path into bezier curves let me do path bounding box calculations more precisely, especially in VML. In fact, Safari doesn’t calculate bounding box for path correctly either.

I also worked on improving performance by applying caching and simply optimizing code.

Imagine the ocean. The ocean where live mermaids and lots of fisherman are chasing their luck. If you ask mermaids and fisherman about ocean they will tell you the same story: “I love ocean. Ocean is my home. I live in breath of the ocean only…” etc. But in fact their approach to ocean is very different. Fisherman care only about money they will get for fish. Ocean is just a big reservoir for them. For mermaids it is truly their home. They care about balance and purity of the ocean. Some fishermen don’t even believe that mermaids exist, some haven’t even heard of them. Fishermen can’t see the ocean as mermaids do, some of them tried: put their head under the water, everything is blurred, they can’t breathe. Pull head back. Never did it again. Some mermaids are tempted by the money they could make as a fisherman, but they lost their magic and become just “yet another fisherman”. Fishermen are winning. Huge tankers crossing the ocean and are taking enormous amount of fish from the ocean ruining the balance. Mermaids can’t stop fisherman, because they talk different language and can’t understand each other.

This ocean is called “the World Wide Web”.

There are web developers, who care about web, standards, semantic, accessibility, etc. They are mermaids. And there are web developers, who care about result only. If the web page is a soup of HTML, inline CSS and inline JavaScript, that’s ok as long as performance tests show us that it is even 0.5 ms faster.

I am very lucky person. I met personally so many great people, like Cameron Adams, John Allsopp, Lachlan Hardy, Russ Weakley, Tim Lucas and many more others who, I hope, will forgive my laziness. The problem is, I don’t remember when last time I was talking to any of them (except Lachlan who is my colleague at Atlassian). We proud of our community, we see each other on conferences and other events, but there is no time to talk there. I mean really talk, share ideas, search for advice, etc. This is only possible with some limited amount of people in the room. I know these guys for at least two years and I have never really talk to anyone of them. Ever. This is very sad. What to do about it? The simplest way is to grab the person you want to talk to and invite him for lunch. Most of us are working somewhere near CBD, so we should catch up more frequently. Send an e-mail to person you know for ages and invite him/her for lunch. Everybody will win. Do it today.

In the first case neither of objects (x or y) have property prop. What they have is a hidden reference to prototype. (Hidden, because only interpreter internally can access it.) When you ask for property prop JavaScript can’t find it in the object itself and look for it in linked prototype object, found it there and return it. So for you, as a programmer, it is no visual difference where property is stored: in the object itself or in its prototype. When you add new property to prototype object x didn’t change. When you ask for property prop JavaScript finds it in updated prototype.

In the second case we assign new object as a prototype. Now object x still refers to the old prototype, but object y refers to new. x and y do not share prototype anymore. Obviously old prototype doesn’t have property prop. Even worse, now you lost the only access point to it. Despite these two objects were created with the same syntax they are way different.

One more thing. As you know every object by default receives property constructor, which refers to its constructor (surprise). But just as propconstructor property doesn’t exists in object itself, but rather in its prototype. By rewriting prototype we rewrite constructor property as well:

Recently I was talking to friend of mine about objects in JavaScript. He is writing JavaScript for living and very good at it, however I found that he doesn’t understand some core features of the language. So, in case you have this gap in understanding JavaScript, I’ll try to explain.

Friend of mine give cite me one book:

“The interesting thing about ECMAScript primitive values for Booleans, numbers, and strings is that they are pseudo-objects, meaning that they actually have properties and methods.”

I am really sorry, but this doesn’t make any sense.

First lets take a look at this example:

var a = 5;
a.t = 3;
alert(a.t);

It will alert “undefined”. Why? If “a” is a “pseudo-object” then why it doesn’t keep my property? The thing is, “a” is not an object. Not even “pseudo-object”. It is primitive number. It doesn’t have properties. As you know JavaScript convert variable from one type to another on the fly:

var b = "w" + a + [1, 2, 3];

In this example number “a” and array [1, 2, 3] will be converted to string on the fly. The same is happening with anything before “.” operator, JavaScript simply converts left hand side parameter to object. So, at the second line of the example JavaScript creates new object Number with value equals to “a” (5 in our case), then create new property “t” with value 3. But then this object is not assigned back to variable “a”, it is just disappear in garbage. Third line will again create new object and will try to read it property “t”, which is undefined.

Primitive types like boolean, number and strings are not objects, they could be converted to objects. What the rule? JavaScript has six built-in types: null, undefined, number, string, boolean and object. The conversion rule is simple: if input is object, leave it as is; if input is null or undefined, throw an exception; otherwise create new object (new Number(input) or new String(input) or new Boolean(input)). Hope this small bit will help somebody to understand objects in JavaScript a bit better. Next type I write about prototype and friends.

Quick test for real understanding of JavaScript core beyond closures and scopes. Here five small scripts. Try to answer what will be alerted in each case without running them in the console. Then you could create a test file and easily check your answers. Ready?