Tabs were a major usability advancement for web browsers. They make it much easier to work with multiple locations at the same time and the ability to open links “in the background” turns them into a to-do list for pages that one still wants to read. However, before long, tabs also exhibit the negative traits of to-do lists: There are too many things still to consider and everything grows stale. This post presents ideas for how to tame tabs, for how to avoid those traits. Some of the ideas can be put into practice right now, others are about improving browsers and making a mental shift to fully exploit those improvements.
This post explores exemplars (factories for objects) and how to implement them. The term exemplar has been proposed by Allen Wirfs-Brock to avoid the term class, which is not a good fit for JavaScript: Exemplars are similar to classes, but they are not classes.
Quite amazing: PDF.js is a JavaScript library that displays PDFs in browsers. At version 0.2, it comes with the requisite warning: “Note: This is an early-stage prototype. Several documents might not render properly.”
2012-06-28: Restructured much of the content, to make it easier to digest.
2012-06-27: New section “More information on Servo”.
Recently, Mozilla stopped the Electrolysis project [1] that was to give Firefox per-tab processes. Hence, I was relieved when David Bruant pointed out to me that Mozilla haven’t given up on a parallel browser. They are working on a project called Servo which is being implemented in the Rust programming language.
Recently, the lightning talk “Wat” by Gary Bernhardt pointed out an interesting JavaScript quirk: You get unexpected results when you add objects and/or arrays. This post explains those results.
Underscore is a library that nicely rounds out JavaScript’s rather limited standard library. Thanks to the Node Package Manager, it’s very simple to install on Node.js:
Update 2012-07-20: O’Reilly has published my mini-ebook “The Past, Present, and Future of JavaScript”. It is free, but you have to enter a name and an email in the box at the right. This ebook can be considered an updated and extended version of this blog post.
JavaScript is used in more and more places. It started out as a scripting language for web content and has migrated to many areas. This post presents the historic milestones of this process. Note: The milestones are about things that changed the public perception of what JavaScript could be used for. Some of these milestones would not have been possible without prior work by others. For example: Mozilla’s contributions in advancing the state of JavaScript cannot be overestimated. The following are the milestones, in chronological order:
The idea is obvious: Why not standardize the bytecode of the virtual machines (VMs) that JavaScript runs on? That would mean that JavaScript programs could be delivered as bytecode and thus would be smaller and start more quickly (after having been loaded). Additionally, it would seem to be easier to port other languages to web browsers, by targeting that bytecode. This post makes its case in two steps: First, it shows that bytecode has several disadvantages. Second, it explains that source code is not as bad a solution as it seems.