Category: JavaScript

writings about JavaScript/ECMAScript and Node

Categories
Books JavaScript Technology

Finished tech review and the move to Node 0.8x

Just finished the final tech review of my Learning Node book. At 400 pages, it’s a big book. I must admit to being more than a little tired. Right now, I feel I could sleep for a week.

The big announcement in Node land is that unstable 0.7.x is being moved to stable 0.8.x next week. As a final act for my book, I put all the examples through a 0.7.10 tests. The results were better than I expected, not as good as I hoped.

I hit a couple of minor deprecation issues. For instance, path.exists has been deprecated in favor of fs.exists. I used the exit event with one child process application, and I needed to convert it to the new close event. This new event not only waits for the process to end, but all stdio pipes are closed.

Other modules ran into the same deprecation issues. Most of the testing modules in Chapter 14 won’t work with Node 0.8.x, but I think the changes to make them work will be minor.

Socket.IO didn’t work with 0.7.10 and the developers know it. I’m more than a little surprised at the reaction to people turning in issues related to the problem. Not to mention, closing the bugs without even attempting a fix. As I wrote in comments to the issues, today’s 0.7.x stable is about to become next week’s 0.8.x stable, and this bug is going to get very popular.

The db-mysql module also didn’t work with 0.7.10, and the highly popular jsdom module also had problems.

I noted the compatibility issues in the chapters, and provided alternative examples for those I could correct. That is the best I can do.

I’ve giv’n her all she’s got, Captain!

Categories
JavaScript Writing

Future. Perfect.

I finished copy edits on my JavaScript Cookbook, which now enters the production process.

The first half of the book focuses on the basic components of JavaScript, while the latter half gets into the more complex material. I touch on the basic JavaScript objects, such as String and Number, but also spend a considerable amount of time covering new ECMAScript 5 and HTML5 scripting features: HTML5 drag and drop, postMessage, the Files API, worker threads, the wonderful new object methods, and so on.

I devoted one chapter to covering ARIA, Accessible Rich Internet Applications, as well as some other accessibility features. The more I work with ARIA, the more I view it as more of a rendering semantics than something purely for screen readers. For a data person like myself, ARIA is a very comfortable technology to use. I’ll have more on ARIA in later writings at MyTech.

Speaking of which, I’ve added ARIA landmarks to my web sites. Use View->Source to look for the role attribute, which is how ARIA landmarks are added. It was easy to update the Drupal templates to incorporate the new material. Unfortunately, the pages don’t validate, but I no longer care about validation. Frankly, the days of trying to code your pages to meet some validation criteria are over. Nowadays, pragmatism is the word in web development.

I am at work on my next book, but it’s not going to be for O’Reilly. Instead, I’m going to try my hand at self-publication, which is why I’m spending so much time working with ePub and other eBook formats. I’m also trying to strengthen my self-editing skills. After 18 books, I’ve become dependent on copy editors—my writing has become sloppy, and full of typos. Speaking of which, I strongly recommend, Paula LaRocque’s “The Book on Writing: The Ultimate Guide to Writing Well.” LaRocque’s book has proven invaluable as I root out my bad writing habits.

Categories
Graphics/CSS HTML5 JavaScript

Declarative Elements versus JavaScript and CSS

Over time as I looked at several of the new elements in HTML5, I saw a trend: many of the elements are single purpose derivations of popular, and commonly occurring, JavaScript and CSS applications. Consider the following list:

  • the progress element
  • the meter element
  • the hidden attribute
  • the details element
  • the telephone input type
  • the email input type
  • the search input type
  • the color picker
  • various date pickers

As I wrote in one of the change proposals, any one of these would have be welcome ten years ago, when HTML4 was released. But now, after we’ve come so far with using JavaScript and CSS, not to mention SVG and the Canvas element—what is the lesson we’re learning from these additions?

Ten years ago, support for CSS and JavaScript was poor enough that something like a color picker was almost impossible, unless you used Flash. Now, though, there are dozens of good libraries available that can implement a color picker. Drupal’s color picker is based on the jQuery UI, but it’s not the only option.

We’ve also had date pickers for years, too. Date pickers in all shapes and sizes, and most configurable by the user so they can get the absolute best date picking experience. The same can be said for progress bars, and if meter is supposed to represent a gauge, there are libraries that provide gauges, too.

As for the input types, such as telephone and email, most of the validation for these types of values can be handled with one line a code and a regular expression. The types also beg the question: where does it end? If we need single purpose data types such as telephone and email, why stop there? What about social security number for people in the states, or zip and/or postal codes?

One of the primary reasons for regular expressions in JavaScript is to ensure that a given string fits a given format. If we don’t know how to use regular expressions, that’s OK, because just like the iPhone, there’s a app for that. There are many libraries that automate the format validation for us. All we have to is assign a class to the relevant input fields.

The new elements, attribute, and input types aren’t just treading in JavaScript and CSS territory. Supposedly the reason for the hidden attribute is accessibility, as is a reason for several of the other elements. Yet the WAI-ARIA effort has provided the exact same functionality and semantics that can be used and reused with any number of elements.

ARIA is to accessibility, as JavaScript is to behavior, as CSS is to style, as RDFa/Microformats/Microdata are to semantics, and as HTML is to structure. Except, suddenly, HTML is no longer about structure. The clean separation between the various domains that has worked so well in the past is seemingly no longer of interest to the HTML WG. Consider the following statement in the HTML5 specification:

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.

Why?

The arguments I’ve read are that declarative alternatives can be used by non-developers, but they’re no easier for non-developers to use than most of the JavaScript libraries I know, which usually only require adding a class to an element.

I’ve also read that declarative alternatives aren’t impacted when JavaScript is turned off, but in my opinion, that’s not a good thing. People have become used to JavaScript-based functionality on the web. They know if a section is exposed via JavaScript that turning off the JavaScript should display the section by default. People can control JavaScript and Flash in their browsers, which means they can control the behavior of the web page. They can also turn off CSS, if they wish. But they have no control over declarative elements and animations.

Consider, too, the costs involved with all these new elements and other objects. Rather than browser developers focused on making the most efficient JavaScript engine, the most secure browser, adding support for SVG and Canvas, Video, WebGL, and any of the other new technologies, the developers now have to focus on what is nothing more than a duplication of functionality already available via libraries, apps, and widgets. Which they also have to support through the core technologies of CSS and JavaScript.

Then consider all of the HTML editors and WYSIWYG tools that now have to add several new input types and elements, including having to provide a live preview of the functionality. Implementing all these new elements, attributes, and input types must seem a daunting task.

How about the web authors and designers? New toys, eh?

New toys that lack both the sophistication and customization capability that we’ve had with our existing libraries. New toys that aren’t accessible until we can convince the screen readers that no, seriously, not only do they have to support ARIA, they have to support all these other new things, too.

Categories
JavaScript Technology

Sun sells out and there goes Java and MySQL

I guess I will now be looking at how to port my Drupal installations to PostGreSQL, since Sun sold out to Oracle. The Java issue doesn’t impact me, as I saw the writing on the wall as regards to Java a long time ago.

However, support for MySQL will most likely be completely undercut, if not eliminated. Or it will go through that fine Oracle touch, which means you can’t depend on support for the database in the future—not without it being either bloated, or “monetized” in some way. This is how Oracle works.

I can hear it now: But MySQL is open source. Oracle can’t hurt it, because it’s open source!

Being “open source” will protect MySQL. Yeah, right. And I believe I’m Superwoman and can’t be hurt by bullets, so just shoot me now.

I completely forgot about Sun and OpenOffice. I use OpenOffice for all of my writing. Guess I can kiss that good-bye, too.

I’d like to just kick IBM right now, for transmorphing back into the stupid, clumsy Big Blue dinosaur of days of yore. It let itself down, by not buying Sun. And it let the rest of us down, too.

Interesting reading the old post on Sun buying MySQL AB, from last year.

I think Sun is the best possible buyer, because of the following reasons: (Note that this is of course my interpretation)

  • Sun is committed to open source.
  • Sun doesn’t have an database of their own; In other words, no risk of internal conflicts between similar products.
  • Sun understands what it means to be a virtual company where people work from home.
  • Sun has a good understanding of developers needs and there is a good chance that the integration of the two companies will be relative smooth.
  • Sun has said they will let the MySQL developers continue work as before in their own unit and without big changes (except of course changes for the better!).

Of course, the early founder of MySQL left Sun, and started another open source MySQL company. We’ll see where this goes.

Last update, but the original founder of MySQL, Michael Widenius, has posted a note on the Oracle/Sun merger and MySQL.

The biggest threat to MySQL future is not Oracle per se, but that the MySQL talent at Sun will spread like the wind and go to a lot of different companies which will set the MySQL development and support back years.

I would not like to see this happen and I am doing everything I can do to keep this talent pool together (after all, most of them are long time personal friends of mine). I am prepared to hire or find a good home (either at Monty Program Ab or close to it) for all core MySQL personnel.

The man is probably inundated with resumes right now.

Categories
JavaScript

The jParallax library

Every once in a while, something comes along that is so well executed, it makes you want to jump up and down. That’s what the jParallax library, and the wonderful demos did for me.

Don’t take my word for it. You have to check out the library and demos yourself. No, you really have to.

(Thanks for the link, Michael.)