Category: JavaScript

writings about JavaScript/ECMAScript and Node

Categories
Books JavaScript

Douglas Crockford’s Good Parts of JavaScript

Recovered from the Wayback Machine.

My editor at O’Reilly sent me a copy of Douglas Crockford’s JavaScript: The Good Parts, which I found to be both interesting and useful. The volume is slim, 153 pages in all, but packed full of information about JavaScript—the good parts and the bad.

I found myself nodding more than once, raising my eyebrow a couple of times, and chuckling a time or two, especially when reading about the equality operators, those “evil twins” of JavaScript, according to Crockford.

The book is not intended for neophyte developers, or even those new to JavaScript. It does, however, give you insight into the mind of a very experienced JavaScript developer. Such insight can provide the information necessary to take you from being familiar with JavaScript to being experienced with JavaScript. In particular, the book’s fourth chapter on Functions is, by itself, worth the price of the book.

Crockford writes clearly and without pretension, which I found refreshing. His aim is to clarify, but without pandering. He doesn’t hold you by the hand, and don’t expect him to explain every last bit of the subjects introduced. However, reading through his material is a nice confirmation as to whether your understanding of JavaScript is comprehensive, or if you’re missing out on some of the bits. I particularly liked his chapter on regular expressions, because I suck at regular expressions.

You’ll also be served a hefty dose of Crockford’s opinions on the JavaScript language, which is no bad thing. I didn’t necessarily agree with all of his opinions, such as avoiding the use of new, but I liked reading the opinions because they help me question my own use of the JavaScript language: is this necessary? Could this be improved? Why am I doing this?

I don’t usually have opinions, good or bad, about components of a language. I either like the language, and learn to adapt to the awkward pieces; or I don’t like the language at all. I like JavaScript, so I tend to like all of JavaScript, even the grungy parts. If there’s one thing I consider to be a “bad” part of JavaScript, it is the experts in JavaScript who tell us not to do this or that, but either give no reason for their opinion, or the reason they give borders on the obtuse and cryptic—assuming that we, of course, know exactly what they’re talking about (if we’re worth anything as programmers, goes the implication).

Reading Crockford laying out his opinion as to what he considers “bad” in JavaScript, and why, in clear, unambiguous terms—with examples—is like a breath of fresh air. His doing so is also worth the price of the book (leaving me to wonder whether I should, in all fairness, pay twice). I can only hope other experts, in whatever language, follow his lead.

My only quibble with the book is one paragraph in the chapter on Objects, and that’s because I’m still puzzled by what I read. Crockford writes:

The simple types of JavaScript are numbers, strings, booleans (true and false), null, and undefined. All other values are objects. Numbers, strings, and booleans are object-like in that they have methods, but they are immutable. Objects in JavaScript are mutable keyed collections.

My understanding of immutable objects is that these are objects, not some form of pseudo-object, or second class object. If I had been a tech reviewer for this book, I would have asked for additional clarification of this paragraph in the text.

Other than this relatively minor quibble, though, I really enjoyed this book. It is a nice read, and invaluable for any JavaScript developer.

Categories
JavaScript

We can’t afford another browser war

Recovered from the Wayback Machine.

It was with a sense of foreboding that I read the posts that swam past on Planet Intertwingly today. First came Mozilla’s Brendan Eich’s chastisement of Microsoft’s Chris Wilson, followed in a short while by commentary by Sam Ruby, where he wrote:

It is interesting how the don’t-break-the-web meme means different things to different organizations: Mozilla, Microsoft.

I’m not a language designer. My only stipulation with a new scripting language is that whatever constructs are added to ECMAScript4 need to be backward compatible. We can’t afford to re-write a couple of billion web pages because the ECMAScript group got clever. From what I’ve read in the past and in these new writings, Eich concurs, as does several other members of the team.

In regards to the new items added to the language: I share other concerns that ECMAScript–no let’s call it JavaScript because that’s how it’s known in the world–may become bloated and over large. I can understand about making it into a ‘real’ language, but I’m less concerned with posterity than I am getting a job done, quickly and efficiently. In other words: I don’t have any ego involved with the fact that I work with a programming language many folks consider somehow less worthy. If the extensions make a better language enabling me to do a better job, that’s great. Otherwise, leave the esoteric for ACM papers.

The future perfect ECMAScript is currently not my concern. My concern on this interchange between Mozilla’s Eich and Microsoft’s Wilson is that we’re seeing the seeds being planted for another round of browser wars, similar to what we had a decade ago. However, today’s web isn’t like the web of a decade ago, because today’s web pages are much too complex to attempt to cover every nuance and difference in implementation with if statements and conditional tests. It was especially disquieting to read comments to the effect that, it’s OK if the companies don’t agree: we can use Flash. Flash is not an alternative to open standards. We don’t need any more Flash dependency as a way of ‘soothing over’ corporate intransigence. Neither do we need more SVG plug-ins, or Google cross-browser libraries. Workarounds are no longer acceptable.

Any company is going to want to implement a version of any specification that favors what they currently have, as much as possible. Of course, this is understandable. Accept the fact that this is understandable. What keeps this behavior in line is there is enough push from other forces that everyone eventually has to compromise, and no one is a clear winner. When no organization is a clear winner, this typically means that everyone, eventually, ends up being a winner.

There’s no denying that Internet Explorer continues to be a problem. I found it unacceptable that Microsoft would put in time to create its own 2D graphics system with Silverlight, when one already exists with both SVG and Canvas (the Canvas object, not markup element). There was absolutely no good reason for this, and no amount of plushy blue monster or outreach effort is going to hide the fact that Microsoft basically did it’s own selfish thing with Silverlight.

There is no denying, however, that Microsoft’s browser continues to dominate (though every year, it dominates less). There is also no denying that Eich has considerable ego invested in ECMAScript–to the point where I have to wonder if this may make him overly aggressive, leading to confrontations that could injure the likelihood of pulling together a new version of JavaScript all browser makers are willing to endorse. We need a consistent platform: no matter how good the language, if a sizable number of people are using a browser that doesn’t implement it, the language is screwed, the browsers are screwed, we’re screwed.

“So I’ll expect to see no more of these lies spread by you.” No matter how angry you get, or frustrated, or peeved, if you want to work in an open standards group, particularly if you want to lead an open standards effect, you can’t write statements like this! Period. End of story. Along with the authority of leadership comes responsibility, and such statements are irresponsible. Where is Mitchell Baker? Time for her to step in and exert a calming influence. At a minimum, act as referee.

The same could be said for the Microsoft representation. No matter how subtly worded, we’re picking up our marbles and going home, neener, neener is not ‘working together as a team’; nor is it considering the true best interests of the web, in general, and of those loyal to Microsoft products, specifically.

Sam mentions that this issue is one based on culture. Frankly, from these exchanges, it seems more like a pissing contest to me.

Disappointing.

update

Could have done with a little less Scoble fandom, but a good overview of the players. I’m a little concerned about references to offline discussions.

Money quote in comments, by Douglas Crockford: “Simplicity is underrated.” Amen.

Categories
JavaScript Technology

We can’t afford another browser war

It was with a sense of foreboding that I read the posts that swam past on Planet Intertwingly today. First came Mozilla’s Brendan Eich’s chastisement of Microsoft’s Chris Wilson, followed in a short while by commentary by Sam Ruby, where he wrote:

It is interesting how the don’t-break-the-web meme means different things to different organizations: Mozilla, Microsoft.

I’m not a language designer. My only stipulation with a new scripting language is that whatever constructs are added to ECMAScript4 need to be backward compatible. We can’t afford to re-write a couple of billion web pages because the ECMAScript group got clever. From what I’ve read in the past and in these new writings, Eich concurs, as do several other members of the team.

In regards to the new items added to the language: I share other concerns that ECMAScript–no let’s call it JavaScript because that’s how it’s known in the world–may become bloated and over large. I can understand about making it into a ‘real’ language, but I’m less concerned with posterity than I am getting a job done, quickly and efficiently. In other words: I don’t have any ego involved with the fact that I work with a programming language many folks consider somehow less worthy. If the extensions make a better language enabling me to do a better job, that’s great. Otherwise, leave the esoteric for ACM papers.

The future perfect ECMAScript is currently not my concern. My concern on this interchange between Mozilla’s Eich and Microsoft’s Wilson is that we’re seeing the seeds being planted for another round of browser wars, similar to what we had a decade ago. However, today’s web isn’t like the web of a decade ago, because today’s web pages are much too complex to attempt to cover every nuance and difference in implementation with if statements and conditional tests. It was especially disquieting to read comments to the effect that, it’s OK if the companies don’t agree: we can use Flash. Flash is not an alternative to open standards. We don’t need any more Flash dependency as a way of ‘soothing over’ corporate intransigence. Neither do we need more SVG plug-ins or Google cross-browser libraries. Workarounds are no longer acceptable.

Any company is going to want to implement a version of any specification that favors what they currently have, as much as possible. Of course, this is understandable. Accept the fact that this is understandable. What keeps this behavior in line is there is enough push from other forces that everyone eventually has to compromise, and no one is a clear winner. When no organization is a clear winner, this typically means that everyone, eventually, ends up being a winner.

There’s no denying that Internet Explorer continues to be a problem. I found it unacceptable that Microsoft would put in the time to create its own 2D graphics system with Silverlight, when one already exists with both SVG and Canvas (the Canvas object, not markup element). There was absolutely no good reason for this, and no amount of plushy blue monster or outreach effort is going to hide the fact that Microsoft basically did its own selfish thing with Silverlight.

There is no denying, however, that Microsoft’s browser continues to dominate (though every year, it dominates less). There is also no denying that Eich has considerable ego invested in ECMAScript–to the point where I have to wonder if this may make him overly aggressive, leading to confrontations that could injure the likelihood of pulling together a new version of JavaScript all browser makers are willing to endorse. We need a consistent platform: no matter how good the language, if a sizable number of people are using a browser that doesn’t implement it, the language is screwed, the browsers are screwed, we’re screwed.

“So I’ll expect to see no more of these lies spread by you.” No matter how angry you get, or frustrated, or peeved, if you want to work in an open standards group, particularly if you want to lead an open standards effect, you can’t write statements like this! Period. End of story. Along with the authority of leadership comes responsibility, and such statements are irresponsible. Where is Mitchell Baker? Time for her to step in and exert a calming influence. At a minimum, act as referee.

The same could be said for the Microsoft representation. No matter how subtly worded, we’re picking up our marbles and going home, neener, neener is not ‘working together as a team’; nor is it considering the true best interests of the web, in general, and of those loyal to Microsoft products, specifically.

Sam mentions that this issue is one based on culture. Frankly, from these exchanges, it seems more like a pissing contest to me.

Disappointing.

Categories
JavaScript Technology

Clever document.write killer

Recovered from the Wayback Machine.

Some ad networks and other script-based entities, such as Google Ads, I believe, use JavaScript document.write to write out the content to our web pages. The organizations use this because they want the content embedded in the page at the point where the item is placed, and there isn’t a lot of control where this can happen.

brothercake at SitePoint has come with a way of eliminating the need for document.write, which is to give the script element an identifier and use it as point of reference where to place the content using the proper DOM functions.

It’s something that should have been obvious, but wasn’t until it was pointed out. As one commenter wrote, a real slapping the head moment.

(via Simon Willison)

Categories
JavaScript Semantics

Lists of good stuff

I love lists of good stuff:

Danny Ayers, Week of Semantic Web. I hope, I hope, I hope, Danny continues this.

Agile Ajax links several GWT tutorials, all in one post — handy if you’re into the Google Web Toolkit, or want to give it a try.