Wednesday, August 20, 2008

Living In Harmony

The big news in the Javascript community for the last week has been the announcement of ECMAScript Harmony. A lot of news is really just overblown, but this is a big development, and one that any Javascript developer should be following.

Some Background


There's been a lot of talk in the Javascript community over the past 9 years or so about the development of ECMAScript 4, what was to be the foundation for what was being called Javascript 2. It was a controversial and fairly dramatic change from ECMAScript 3 (Javascript). There was going to be support for classes, inheritance, type annotations, namespaces...the whole flavor of the language was going to dramatically change.

ECMAScript 4 was being developed primarily by Adobe, Mozilla, Opera and Google and was primarily based on the features those organizations wished to implement. Others, including Microsoft and Yahoo, found the proposed changes in ES4 to be to dramatic, and instead wanted to implement minor changes and bug fixes to ES3, labeling it ES3.1 instead.

What Happened?


Obviously with division among such major organizations, something was going to have to give. So, at a recent TC39 meeting (the committee in charge of developing the ECMAScript standard) met and a resolution was met. The two sides would merge their ideas together with a new committed focus to ensuring simplicity in the new changes to the language...enter ECMAScript Harmony. In an email, Brendan Eich of Mozilla laid down the 4 primary goals of ECMAScript Harmony:

  1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.

  2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.

  3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.

  4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.


What Does It Mean?


Well, for one, it means that the series of posts I had started on Javascript 2.0 are now completely worthless...and no...I will not reimburse you for the time spent reading them.

But far more importantly, it means that progress should speed up immensely. (There are ES4 proposals from 1999.) The plan appears to be to implement certain de facto standards rather quickly. For example, getters and setters are already implemented in each of the major browsers except for IE, and they will be thrown into the ES Harmony specification. (Which, by the way, brings up the interesting situation where implementation precedes specification, something that occurs often on the web and something you'll probably see me talk more about in the future.)

Meanwhile, ActionScript 3.0 was already built to reflect the ECMAScript 4 proposed specifications...so it would appear they're kind of left a bit high and dry. It sounds as though they are definitely committed to keeping in line with specifications, and that they plan on implementing new features laid out in the newly developed specification. They are also going to continue to keep their current features, like classes and type annotations, available in their language...think of it as an extension to the ECMAScript standard.

My Thoughts


All in all, I think the outcome is positive. ES4 had been taking forever to get going, and ES3.1 hadn't been sounding like it would do much besides fix bugs. Now, we'll have a new implementation soon and while it won't have the same dramatic changes ES4 had in mind, there will be some interesting new features being added.

While I would've enjoyed some of the new features, Javascript gets to maintain a lot of flexibility here. ES4 would've tightened that up a bit, and I still haven't really made up my mind on whether that would've been a good thing or not.

It's also quite encouraging to see so many major players working together. Microsoft, Yahoo, Google, Mozilla, Opera and Adobe all working together in harmony. (I apologize for the pun...it was just there, and I decided to go with it.) One can only imagine having these organizations working together will ensure a high quality specification, and also lead to faster implementation of the spec.

Around the Web


This is certainly a huge development, and there has been no shortage of postings about it. There's a lot of high quality discussion going on by some major players in the world of Javascript and ActionScript, and I highly recommend checking them out.

Tuesday, August 12, 2008

Undermining the Industry

<rant>

It's no secret that the web design industry is often not given the respect it deserves. People treat it as if it's a much simpler task than it really is. Forgive me if I come off sounding a bit arrogant, but it seems like people seriously underestimate the work involved in creating a quality web site.

One issue, for example, is people expecting to see comps of work without payment. It happens quite a bit, but it's a ridiculous request. Do people ask mechanics to make the first couple of repairs on their car for free so they can get a feel for how they like working with them and then, based on that, decide whether or not to go with that mechanic and pay them? So why ask a web design company to create a few mock-ups first before deciding to actually pay them for their work?

Then there's beautiful journalism like the article posted yesterday in the Wall Street Journal telling companies how to build their own site with 8 hours of work and $10. Brilliant...because that's all that goes into a quality site.

Really, there are some fantastic gems in the article like this one:
All you need to know is that a block of HTML essentially, a bunch of gobbledygook words and symbols can add extra features to your site.

And this isn't some second-fiddle publication being read by 5 people, this is the Wall Street Journal. A highly regarded and professional publication.

So where does all this undermining come from? It think a lot of it stems from a lack of understanding. For almost as long as there has been the web, there have been "build-your-own site" tools easily and readily available. This gives people the feeling that that's really all it takes...a couple clicks of a button, drag a few things, and you have a site.

But the reality, as we all know, is that there is so much more that goes into the design and development of a site. So much more planning and "strategerizing" goes into the process. Can you build your own site with these free tools? Yes. Should you? That really all depends on how serious you are about making your website a business tool. If you really want to maximize it's impact, then the answer is probably no.

I understand I'm preaching to the choir a bit here, but after coming across Jeff Croft's link to the WSJ article, I just had to vent a bit. It's sad to see such a lack of understanding and respect of our industry come from such a well-known and highly regarded paper.

</rant>

Monday, August 11, 2008

New Way to Store Custom Data

There's a lot of interesting new features being suggested for HTML5 and XHTML2. Some of them are extremely useful, some of them seem to be more questionable additions. One feature being implemented in HTML5 that I do like is the addition of custom data attributes to HTML elements.

Manage Your Data


A custom data attribute is simply any attribute starting with the string "data-". They can be used to store data that you want kept private to the page (not viewable by the user) in cases where there is no appropriate attribute available. Every element can have any number of custom data attributes.

For example, consider a form validation script. The script needs to know what form of validation is required for each field. Currently, many of these scripts will use the class attribute to signal that.




Making use of the new HTML5 custom data attributes, we might choose to store the information like this instead:




To gain access to the value of the data-validation attribute, there are two options. First, you can simply use the getAttribute() method. This method should be familiar to anyone who's worked with the DOM in Javascript and is supported by all major browsers. The second method is to make use of the new dataset DOM attribute. Currently, no major browsers support the dataset attribute, but to be fair, here's how you would use it:

  1. var theInput = document.getElementById('myInput');

  2. var validationType = theInput.dataset.validation;


What I Think


Custom data attributes have been met with varied opinions...some think it's fantastic while others either don't get the value or simply don't like the idea. Personally...I think it's a good idea.

Currently there's two popular ways of providing hooks for scripts in HTMl where no appropriate attribute exists:

  1. Use an existing attribute even though it may not necessarily be semantically correct.

  2. Create a new attribute and have the page no longer valid.


Where you stand personally along those lines, of course, varies. Some people don't mind a page that doesn't fully validate and would rather not clog up their id's and classes. Others don't mind adding an extra class to an element as long as the page is valid.

With the new data-* attributes, you can have the best of both worlds; your page can validate and you don't have to add extra classes and id's to make your scripts work. It's also very easy to implement, and manages to keep all the data needed for scripting together in one dataset. What's not to like?

You can actually start making use of custom data attributes right now. The page won't validate for HTML4 of course, but once HTML5 rolls around you'll be set. Just remember that to access the dataset values in Javascript you will need to use the getAttribute() and setAttribute() methods as the dataset DOM attribute is not currently supported.

Sunday, August 3, 2008

Excuses, Excuses

I did what I said I told myself I would never do...I only posted one item the entire month. I always told myself that if I was going to have a blog going, I was going to commit to it and ensure that the blog never went stale...there would always be fresh content on my site. I think I may have underestimated the wonderful curves that life throws out there!

I do have what I feel are a few fairly good excuses for being quiet lately. I just recently purchased my first home, which my wife and I are quite excited by. It has kept us both busy moving and making some quick touch-ups and improvements. Even more exciting, we found out that my wife is pregnant with what will be our first child. Again...extremely excited, but I am finding that I am spending a fair amount of time ensuring that things are in place for when the little one arrives.

Finally...I started a new job in June. It's much more development heavy than my prior position and I'm enjoying it greatly. That being said, there was some time spent ensuring that I get up to speed with the company's existing projects and work styles. Nothing irritates me more than knowing that I could do something much quicker if I had a better handle on things. I don't like that "introductory period" where I have to turn to ask questions about simple little procedures simply because I don't know the company's tendencies, so I like to get familiarized as quickly as possible.

So between those three things, all exciting as they are, I have had very little time for updating the site. Which is unfortunate...I've been working on getting the site switched over to PHP and have some cool and important improvements that will come with this (one of which is an improved comment spam filter....those spammers are amazingly persistent).

There are also numerous posts I have written up that I just need to take the time to add to the site. So the content is there...or, I guess, will be there. The resolution for August is to get back to a regular schedule for updating the site...so stay tuned.