DailyJS

DailyJS

The JavaScript blog.


Taghoj
Featured

language history hoj

History of JavaScript: Part 8

Posted on .

This article is part 8 of our History of JavaScript series. Last week I
covered the features in ECMAScript 5. These are the core language
features that have partly appeared in browsers and interpreters. The
other piece of the puzzle is the complimentary web APIs that we can
expect to see now or in the near future.

Although many of these APIs are published by the W3C, the WHATWG
community played an important role in the development of HTML5.

WHATWG

WHATWG was founded by people from Apple, the Mozilla Foundation, and
Opera Software in 2004. The group was founded partly as a reaction
against the direction the W3C were taking HTML through XHTML.

It might be some time before HTML5 is recommended for production use,
but with initiatives like this we already have access to some of these
APIs in recent browsers.

Web Workers

The idea behind Web Workers is to allow developers to spawn background
workers running in parallel to the main page's thread. Demonstrations
have already been created that run in modern browsers (we've talked
about the API on this blog before).

File API

The File API allows
programmatic manipulation of files. It addresses the limitations of
current browser file handling to allow us to handle multiple files,
binary data, file metadata, and error handling.

Read more in HTML5 File
API
.

Canvas

Canvas makes programmatic drawing easier. This is another W3C specification,
currently at the working draft stage.

Other APIs

Conclusion

WHATWG played an important role in the direction of the web's future.
The desire for more "application-like" features are useful if you're an
application developer. If you're a designer it means you'll have richer
tools for creating more reliable and intuitive user experiences.

Many UI issues can be overcome without specific API support -- drag and
drop support would be nice but we've been doing it for years. And even
though there are good techniques for overcoming the single origin
policy, better messaging would be nice, especially for real-time
applications.

Combining the File API with more modern messaging and offline
capabilities will make web apps suddenly feel more like desktop apps in
a way they haven't before (without Java or Flash). Pure HTML and
JavaScript manipulating local binary data is really the last piece of
the puzzle, and some browsers already support it.

If you want to read more about HTML5 APIs, if you use the WHATWG
specs
there are
annotations with information about browser support, tests, and links to
demos.

Featured

language history hoj ecmascript5

History of JavaScript: Part 7

Posted on .

This article is part 7 of our History of JavaScript series. Last week I
covered the history of JavaScript animation. This week I'll take a look
at ECMAScript 5.

JavaScript 2

If you recall part 3, JavaScript
2 died as the community fought over the direction of the language's
future. ECMA-262 5th edition was approved in
2009
.
The original press release states:

Work on future ECMAScript editions continues as part of the previously announced ECMAScript Harmony project.

ECMAScript 5th Edition

ECMAScript 5th Edition isn't as radical as JavaScript 2 was supposed to
be. It's a very different beast. The main changes are relatively
conservative:

  • Array methods: indexOf, lastIndexOf, forEach, filter, every, map, some
  • String.trim: remove whitespace from the start and end of a string
  • Native JSON
  • Date: now, toISOString, parse

There are also some more fundamental language changes:

  • Function.prototype.bind
  • Updated object model
  • Strict mode
  • Constants
  • Getters and setters

Updated Object Model

Object gets a lot of new methods: Object.create, Object.getPrototypeOf,
Object.keys, Object.getOwnPropertyNames, object descriptors,
Object.seal, Object.freeze.

I don't want to write about all of these new Object methods, but
basically: we now have a way of freezing objects, and safely enumerating
over methods that want to be enumerated over.

There's coverage in Enhanced Scripting in IE9: ECMAScript 5 Support and
More

and
Object.getPrototypeOf.

These methods will give more control to API authors and a greater sense
of control over objects.

Strict mode

use strict; will instruct the interpreter to run with
strict mode. This is a useful way of ensuring that code only uses
ECMAScript features, rather than a dialect:

The strict variant of ECMAScript is commonly referred to as the strict mode of the language. Strict mode selection and use of the strict mode syntax and semantics of ECMAScript is explicitly made at the level of individual ECMAScript code units.

Constants

Constants aren't actually in ECMAScript 5, const is marked
as a future reserved word. Some interpreters support it already,
although I wouldn't rely on the behaviour the exhibit being totally
future-proof.

Getters and Setters

The keywords get and set are used to decorate
functions that are getters or setters:

user = {
  first_name: 'Alex',
  last_name: 'Young',

  get full_name() { return this.first_name + ' ' + this.last_name; },

  set full_name(name) {
    name = name.split(' ');
    this.first_name = name[0];
    this.last_name = name[1];
  }
};

user.full_name
// returns: Alex Young
user.full_name = 'Alex Smith'
user.full_name
// returns: Alex Smith

You can already use this in Rhino and Firefox, as well as V8 and
probably lots of other interpreters.

This is being used out there in the wild, so it's worth getting used to
the syntax.

Future

ECMAScript 5 adds enough syntax sugar to keep developers happy for the
foreseeable future. It also addresses some areas in the object model
that we were left to code for ourselves. The Array and
String changes also add things we've previously had to
patch ourselves. More importantly, these changes combined with use
strict
help in areas where JavaScript interpreters had diverged,
which means hopefully future browsers (and our code) should be more
consistent.

References

Featured

animation language history hoj

History of JavaScript: Part 6

Posted on .

This article is part 6 of our History of JavaScript series. Last week I
discussed the history of prototype-based programming. I've been writing
a lot about JavaScript animations lately, so this week I thought I'd
cover the history of JavaScript animation.

The DHTML Era

Animation in web design used to involve roll-over effects, animated
gifs, image maps, and other things that have been largely superseded
with simple CSS. The blanket term for these techniques was DHTML
(Dynamic HTML), and a great deal of books were written on the nebulous topic. I hardly ever hear the term DHTML anymore, and it seems like
post-dot-com era designers and developers have quietly moved on.

When Netscape 4 came out people started doing incredibly advanced tricks
with JavaScript and the layer tag. I blog a lot about
cutting edge JavaScript -- HTML5 games, animations, applications -- but
this has all been done before almost 10 years ago, albeit with less
elegant markup and legacy technology.

Netscape invented layers in 1997, at the same time the W3C were working
on the div tag, so it isn't surprising that layers died
quickly. There was a lot of hype and excitement about layers, but their
big downside was they were Netscape 4 specific. Positioning and sizing a
layer was straightforward, as was moving one.

Another relic from 4th generation browsers is
revealTrans. We still use filter: in IE to bend it into supporting
things like opacity, but revealTrans could be used to
create transition effects for elements or entire pages.

Browser-specific APIs and poor use of these effects gave DHTML a bad
name. The rise of the web standards movement encouraged designers to try
out new techniques.

Standards Movement

Cross-browser and semantic XHTML became the next big thing. And even
though IE6 was the elephant in the room making life difficult for
designers, innovators still looked at how to build better sites without
breaking the specs.

Sites using animations and effects started to look dated. Online
communities like A List Apart preached the
good word of standards compliance.

At this point I felt like dynamic HTML and JavaScript animation might be
something left in the past, but then Matthew Linderman at 37signals
published Web Interface Design Tip: The Yellow Fade
Technique
. 37signals had
become famous for simple, focused web design, and pushed the
standards-based approach. The Yellow Fade Technique used a little bit of
JavaScript to briefly highlight a changed item on a page in a web app.
It didn't matter if the browser couldn't display it, it simply enriched
the experience where available.

A design-savvy company backing what could have been regarded as a dated
DHTML-like technique meant people began to take animations more
seriously again. And 37signals' relationship with
script.aculo.us through Rails meant JavaScript animation caught on with a new generation of developers.
Although other animation frameworks were appearing, script.aculo.us was
probably the most widely known and a key piece of the JavaScript
animation renaissance.

The Solution

Back in the 90s while Netscape and Microsoft were battling each other
with proprietary technology, our core present-day animation tool was
already available. In fact, setTimeout was introduced with
JavaScript 1.0 in Netscape 2.0.

Netscape even had an example called Sliding
Tower

that used setTimeout to animate moving a picture. It's ironic that while
browsers fought each other with flashy new techniques, all we really
needed was good old setTimeout and a workable DOM.

Originally setTimeout was considered too slow because of
the performance of browsers and computers in the 90s. But now most
animations on the web use this family of functions.

To create animations with setTimeout or
setInterval, styles are manipulated through the DOM. This
commonly involves manipulating opacity or positional attributes. Modern
browsers can even use GPUs to render effects: 3D
Transforms
on
webkit.org has some examples.

Animated vector graphics using the canvas tag has increased
in popularity with the rise of JavaScript libraries that translate SVG
to IE's VML.

CSS Animations

Apple's war with Flash means Apple is a big backer of CSS
animations
. The working
draft of CSS Animations Module Level
3
has three editors, all from
Apple. WebKit browsers already have support.

Purists argue that JavaScript should deal with behaviour, while CSS
should be left to styling. Jonathan Snook makes an argument against CSS
animations in CSS Animations in
Safari
.

It seems like the future may be driven by mobile devices, which might be
why Apple would prefer to offer highly optimised effects through CSS
rather than JavaScript. I'm sure in 10 years we'll be either laughing at
Apple, Adobe, CSS3, or all of the above.

References

Featured

language history hoj

History of JavaScript: Part 5

Posted on .

This article is part 5 of our History of JavaScript series. Last week we
looked at the development of Ajax, XMLHttpRequest, and the rise of Web
2.0.

Prototype and Objects

I haven't been able to track down a concrete answer to the question "why
is JavaScript prototype-based?". If you recall part 1 of this series,
you might remember this quote from Brendan Eich:

And we were pushing it as a little brother to Java, as a complementary language like Visual Basic was to C++ in Microsoft's language families at the time.

It's clear that JavaScript's creator wished to make something simpler
than Java, and as most of us know Java's object model is extensive.
Conversely, JavaScript's object model is very simple. Advanced OO-like
features can be built using JavaScript's core features: prototype
objects and closures.

Class-Oriented Programming

I remember hearing about a talk by Dave
Thomas
where he bemoaned the overuse of
classes in object oriented programming. Is object oriented programming
about objects or classes? The way most people are taught is class
oriented.

This is something worth keeping in mind when we talk about
prototype-based programming. It's not always easy for those trained in
classical object oriented programming to see the distinction between the
two.

The History of Prototype Programming

Prototypes came from a desire to further develop object-oriented
languages, with the language Self. The
language was first publicly released in 1990. In 1991 the developers
moved to Sun Microsystems which may explain the JavaScript connection.

Self challenges the notion that classes and objects are distinct. In
Self, much like JavaScript, copies of objects are made rather than
instantiating objects from a template. Objects used to create copies are
known as prototypes.

You can learn about Self in the Language
Reference
.

Between Self and widespread adoption of JavaScript, other interesting
prototype-based languages were developed. Lua was created in 1993, and
is now widely used in the games industry for scripting tasks. REBOL
appeared in 1997, using the make function to construct and
return objects.

One prototype-based language I've played with quite a bit is
io, which was created in 2002. It's succinct and easy to learn, and I think it should appeal to Lisp or
JavaScript enthusiasts.

Trends in Prototype-based Languages

If you look through the popular prototype languages you'll notice a few
common themes:

  • Simple syntax
  • Dynamic
  • Inspired by languages like Scheme
  • Small, efficient VM

Conclusion

Prototype-based languages like JavaScript and Lua have found their
respective niches, and more developers than ever are versed in this
style. Given the amount of innovation in VM design and implementation,
these languages will continue to grow in popularity.

Featured

language history hoj

History of JavaScript: Part 4

Posted on .

This article is part 4 of our History of JavaScript series. Last week we
looked at the development of Rhino, and the downfall of JavaScript 2.
This week I'm going to dig into Ajax and JavaScript frameworks

Ajax

As we've already seen, Microsoft had a version of
XMLHttpRequest pretty early on. Mozilla quickly followed,
by adding support to Gecko, but it wasn't fully-functional until around
2002. Other browsers eventually implemented similar functionality, prior
to standardisation by the W3C.

Meanwhile, Jesse James Garrett published an
essay entitled Ajax: A New Approach to Web
Applications

in February 2005. Garrett cited XMLHttpRequest as a major
component in what Adaptive Path dubbed Ajax.

The importance of this new approach quickly became apparent. The main
lesson people took away from the essay was the power of asynchronous
client-side code. The term Ajax quickly became synonymous with the more
awkward term XMLHttpRequest.

I still prefer Adaptive Path's original definition of Ajax, and I think
it's useful to draw a distinction between the terms. It hasn't helped
that certain popular JavaScript libraries confuse Ajax with
XMLHttpRequest.

XMLHttpRequest

The W3C published a working draft for the XMLHttpRequest
object in April 2006. The last version is draft 19, published November
2009, at
www.w3.org/TR/XMLHttpRequest/.

Even though the first draft of this spec was 2006, 2005 was the start of
the web 2.0 revolution.

The Rise of Web 2.0

Interest in web applications waned after the dot com crash. This was the
era in which I graduated, so I have first-hand experience trying to
survive in that period. Thankfully, by 2005 Garrett's essay and popular
sites like Google Maps inspired a new breed of web application.

I remember colleagues telling me that Ajax was dangerous because of the
number of HTTP requests clients would generate back to the server. It
was actually very rare that this was a problem, and JavaScript libraries
started to appear that addressed web 2.0 technologies like
XMLHttpRequest.

The first library I remember using was Prototype by Sam Stephenson. It
used a lot of conventions from Ruby, and it was popular with Ruby
developers due to ties with Rails. It made XMLHttpRequest
easy to use, and it also patched a lot of cross-browser issues which had
plagued JavaScript development.

Other libraries also appeared in 2005:

  • Dojo Toolit
  • MochiKit
  • Scriptaculous

Scriptaculous built on Prototype to provide rich UI features.

A New Type of API

Libraries like Prototype were influenced by other programming languages.
Their internal structures and APIs are similar to traditional OO
classes. While libraries were battling to support the next fashionable
UI widget, other developers were wondering if there was a more natural
way to work with JavaScript in the browser.

One of these brave souls was John Resig. In Selectors in
Javascript
he discusses
a library called Behaviour, and ponders ways of linking JavaScript code
to CSS selectors.

By pushing what JavaScript could do natively, he had created the basis
of jQuery. A year later, jQuery 1.0 was
released
.

Historical Lessons

I have a lot of respect for Sam Stephenson, Thomas Fuchs and John Resig.
They took their projects in different directions and made a lot of
things easier for us developers in the trenches. The lesson we can take
away from this period, however, is that playing to the strengths of your
language will always pay off in the end.

As kangax pointed out this year, Prototype's approach of extending the
DOM has major issues. It looks like Prototype 2 might work more like
jQuery. Rather than bringing in a Ruby, Python or Java influence, Resig
stuck to his guns and looked at how to write natural JavaScirpt, and
this approach paid off.

References