Friday, November 14th, 2008
Category: Articles
Francisco Tolmasky of 280 North has written a very nice piece on adding Undo and Redo to your Web application with Cappuccino.
He creates a very cool sample application, FloorPlan, that shows off much more than undo/redo. He also discusses how Cappuccino gives you built in undo/redo support and how to make it discoverable.
Cappuccino has built-in support that can allow you to plug undo and redo right in by just by adding a few lines of code. In this tutorial, we will be exploring how to add sophisticated undo and redo support to a graphical application in the browser. We won’t be creating the entire application from scratch however, but instead building off of an existing example. We’re doing this for two reasons. For starters, we don’t want to get distracted from our main task by having to wade through unrelated code. Instead we’ll simply review whatever code we need to as we get to it. More importantly, the sample provided is complex enough to serve as a true real-world example, as opposed to the contrived code we’d be forced to put together in the limited scope of space and time of this tutorial. This also has the benefit of displaying the modular nature of undo support in Cappuccino, and how we can add it to an application without knowing every detail of its implementation.
It would be nice to be able to tie into the Undo menu in the browser.
Thursday, August 28th, 2008
Category: Articles, Editorial, Standards
I met with a colleague recently who wants to take his project and create a standard on the web that actually gets adopted. We talked for a long time, and when we finished up I pointed him at a paper that had a huge impact on me, called “In Praise of Evolvable Systems” by Clay Shirky.
This paper was written a long time ago in the ancient year of 1996 by the web’s timeline, but everything in it still holds on why the web won and some possibilities of how we can move forward from where we are today. Under the tagline for his paper Clay has the summary “Why something as poorly designed as the Web became The Next Big Thing, and what that means for the future.”
Clay starts by pointing out how bad the Web is:
If it were April Fool’s Day, the Net’s only official holiday, and you wanted to design a ‘Novelty Protocol’ to slip by the Internet Engineering Task Force as a joke, it might look something like the Web:
- The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.
- The server’s primary method of extensibility would require spawning external processes, thus ensuring both security risks and unpredictable load.
- The server would have no built-in mechanism for gracefully apportioning resources, refusing or delaying heavy traffic, or load-balancing. It would, however, be relatively easy to crash.
- Multiple files traveling together from one server to one client would each incur the entire overhead of a new session call.
- The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.
- The tag set would be absurdly polluted and user-extensible with no central coordination and no consistency in implementation. As a bonus, many elements would perform conflicting functions as logical and visual layout elements.
HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes. For anyone who has tried to accomplish anything serious on the Web, it’s pretty obvious that of the various implementations of a worldwide hypertext protocol, we have the worst one possible.
Except, of course, for all the others.
The web, however, was better than the contenders of that time. He argues that all the other formats, such as Gopher, Interactive TV, and so on were too well designed and had too much internal consistency:
These various [non-web] protocols and services [Gopher, Interactive TV, AOL, etc.] shared two important characteristics: Each was pursuing a design that was internally cohesive, and each operated in a kind of hermetically sealed environment where it interacted not at all with its neighbors. These characteristics are really flip sides of the same coin — the strong internal cohesion of their design contributed directly to their lack of interoperability. CompuServe and AOL, two of the top online services, couldn’t even share resources with one another, much less somehow interoperate with interactive TV or CD-ROMs…In other words, every contender for becoming an “industry standard” for handling information was too strong and too well-designed to succeed outside its own narrow confines. So how did the Web manage to damage and, in some cases, destroy those contenders for the title of The Next Big Thing? Weakness, coupled with an ability to improve exponentially.
Clay then goes on to argue that successful systems must be evolvable and gives three rules:
Evolvable systems — those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once — have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.
- Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. Think VMS vs. Unix, cc:Mail vs. RFC-822, Token Ring vs. Ethernet.
- What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
- Finally, Orgel’s Rule, named for the evolutionary biologist Leslie Orgel — “Evolution is cleverer than you are”. As with the list of the Web’s obvious deficiencies above, it is easy to point out what is wrong with any evolvable system at any point in its life. No one seeing Lotus Notes and the NCSA server side-by-side in 1994 could doubt that Lotus had the superior technology; ditto ActiveX vs. Java or Marimba vs. HTTP. However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.
I know we sometimes get frustrated with the state of the web today, but its useful to know why we are here, and what characteristics any new ideas, features, or standards probably need to have in order to be successful; Clay’s paper helps guide me in terms of navigating these issues.
Thursday, July 17th, 2008
Category: Articles
Jeffrey Barke has written up a tutorial detailing how to create a density map with Prototype, the Google Maps API and the HeatMapAPI.
The heat map API looks cool indeed, and that piece of code looks simple:
JAVASCRIPT:
-
-
addHeatMap: function() {
-
var heatMap = new GEOHeatmap();
-
heatMap.Init(this.width, this.height);
-
heatMap.SetData(this.data);
-
var preUrl = heatMap.GetURL();
-
var heatmapOverlay = new HMGoogleOverlay(preUrl);
-
this.map.addOverlay(heatmapOverlay);
-
}
-
Monday, April 14th, 2008
Category: Aptana, Articles, JavaScript, Server
Davey Waterson of the Aptana Jaxer team has posted an article on using jQuery on the server-side with E4X and more that shows an example of server-side Ajax with a popular framework.
The article describes a polling application that features:
- Using jQuery server-side to manipulate a DOM before it's sent to the client
- Doing some database / SQL interactions, server-side in javascript of course
- User sessions in javascript (Jaxer.session.set('status', status);)
- Using E4X on the server-side.
There are fun little features such as nuking portions of the page if the permissions call for it:
JAVASCRIPT:
-
-
$((status == 'voter') ? '.nonvoter' : '.voter').remove();
-
Since the application delivers no JavaScript itself, this would all work even if the user has JavaScript turned off, on a simple mobile phone, etc.
Friday, March 28th, 2008
Category: Articles, JavaScript
JAVASCRIPT:
-
-
TheRulesAre(function() { with(this) {
-
-
a(Player).mayNot('buyProperty').unless(function(player, property) {
-
return property.owner === null &&
-
player.funds>= property.price;
-
});
-
-
a(Property).mayNot('addHouse').when(it().isMortgaged());
-
}});
-
Composing DSLs in JavaScript is James Coglan's latest perusal into fun with JavaScript and DSLs.
He walks through the building of this DSL in a step by step manner. He uses his JS.Class library, but you could of course substitute your favourite JavaScript library.
Tuesday, March 25th, 2008
Category: Articles, JavaScript
Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important.
Douglas Crockford got to act all curmudgeonly as he talks on how The World's Most Popular Programming Language Has Fashion and Luck to Thank.
He starts out talking about the black art of languages:
The art in language design is knowing what to leave out. The features of a good language work together harmoniously. A good language helps us to better understand a problem and to find the best expression of its solution.
A good language is composed of a limited set of features. But there is little agreement on which features are best. Programmers can argue endlessly about features and whether a set of features makes one language better than another. Features matter, but we just don't understand yet how they matter.
Language design has more to do with fashion than technology. It may seem strange that fashion is a major factor in the nerdliest of arts, but it is true. A language with radically different syntax, for example, has no hope of finding broad adoption, regardless of the brilliance of its design. This tends to constrain the rate at which languages evolve.
Just like fashion, a programming language is often a product of its time. The deep problem in language design is not technological, it is psychological. A programming language should equip us with structures that help us to reason more effectively.
And then he gets to JavaScript itself, and how it has managed to become the most deployed language in history even with its foibles.
Thursday, March 13th, 2008
Category: Articles, Dojo, JavaScript
Neil Roberts has posted a great article on Creating Your Own $ with Dojo:
The bling, one of the best global variables in JavaScript. A tool which has come to mean, as a function, a way to locate a node or set of nodes. And, as a namespace, a simple way to access often-used functionality. "This can't be done with Dojo," you insist. But you're wrong, it's really easy. The ideas behind this little symbol are quite simple and I'm going to show you how to create your own customized version of it.
He manages to walk us through a path where he gets $ working in a way that mimics jQuery. He starts with $ = dojo.query; and ends up with:
JAVASCRIPT:
-
-
$ = dojo.mixin(function(){ return dojo.mixin(dojo.query.apply(this, arguments), $.fn); }, dojo, { fn: {} });
-
He then tackles plugins and using:
JAVASCRIPT:
-
-
$.fn.click = function(callback){
-
dojo.forEach(this, function(node){
-
dojo.connect(node, "onclick", function(e){
-
callback.call(e.target, e);
-
});
-
});
-
}
-
You end up being able to do:
JAVASCRIPT:
-
-
$("li.expandable").click(function(e){
-
$(this).toggleClass("expanded");
-
});
-
Very cool indeed!
Tuesday, February 26th, 2008
Category: Articles, Canvas, JavaScript, Prototype
"agrath" has developed a very nice Canvas example using Prototype that makes use of a common Prototype-isms: Object.extend, Class.create, bind, enumerables, $w, $.
The Polar Clock is a different visualization of time and the example walks through all of the work required to implement it using Prototype 1.6.0.2 and Canvas, including the draw method:
JAVASCRIPT:
-
-
draw:function(){
-
this.clearCanvas();
-
var w = 20;
-
var r = 260;
-
this.date = new Date();
-
var cr = r;
-
$('labels').update()
-
$w("month day weekday space hour min second").reverse().each(function(interval){
-
cr = cr - w - w/2;
-
if(interval != 'space')
-
{
-
var ir = this.intervalToDegrees[interval].bind(this.date)();
-
var i = ((ir / 360) * 255) + 147;
-
var color = this.cc.rgbToCss(this.cc.hslToRgb(i.wrap(0,255),205,127));
-
this.drawSolidArc(color, cr, w, ir.toRadians());
-
$('labels').insert(this.getIntervalLabel[interval].bind(this.date)() + '<br />');
-
}
-
}.bind(this));
-
},
-
The article walks through a lot of Canvas as well as the Prototype side of things. Very thorough.
Thursday, February 21st, 2008
Category: Articles, JavaScript
Peter Michaux has done some very thorough work on feature detection in the browser and cross browser widgets.
In his feature detection article he walks through a myriad of approaches with pros and cons:
Feature testing is not easy and there is no one right answer. From a practical stand point, the more strict your tests are the more likely your code runs only when it will run successfully.
There are some obvious wrong answers like navigator.UserAgent inference, unrelated execution inference and unrelated object inference. Check the library you are using. Does it use any of these techniques? I have seen many uses of these techniques in mainstream libraries even where there is a well known, better test available. The mainstream libraries cannot consider claiming to be state of the art until they remove these bad practices at the very least.
The above discussion focuses on tests against a single object to infer if that object or similar ones work. Sometimes it may be necessary to use multiple objects together to make an inference about one object. An example for scroll reporting. Even when using multiple host objects in a test the three isHost* functions will be useful.
Feature detection is not easy, but as professionals, we should use the best tests we can.
In his cross browser widget article he goes further to create a library to handle cross browser widgets:
Build a robust widget for the general web is hard work and the example above has room for improvement. The level of feature testing could be increased at the cost of file size. For example, on comp.lang.javascript, David Mark suggested that the browser could run out of resources and a call to createElement could return null. He also admitted this may be overly paranoid. I think it is and by testing for the existance of document.createElement I've inferred that calls to it will work as expected.
I've tried the tabbed pane in all the browsers I have and it is either enabled an works or it is disabled and doesn't throw errors. I suspect there is a browser out there somewhere that will throw an error. That is just the nature of the cross-browser challenge. In a perverse masochistic way, I somewhat hope someone can find a browser in which this widget breaks. That is one way we can continue to improve.
Tuesday, February 19th, 2008
Category: Articles, IE
Two articles were shot onto A List Apart this morning. We have Jeffrey Zeldman on the threat or menace of version targeting. Then we have Jeremy Keith on browser shooting.
Both are opinions on the version targeting issue that has blown up on the Web recently.
Jeremy concludes:
Version targeting is not a bad idea. The choice of delivery mechanisms—meta element or server header—is inspired. As an optional feature, this could prove to be a real lifesaver in some development environments. As a mandatory millstone however, it strikes a blow against progressive enhancement.
The proposed default behavior for version targeting in Internet Explorer solves the problem of “breaking the web†in much the same way that decapitation solves the problem of headaches. In its current state, version targeting is a cure that will kill the patient. Version targeting could have been an opportunity for Microsoft to demonstrate innovation. Instead, the proposed default behavior demonstrates a fundamental misunderstanding of the World Wide Web, a place that according to its creator, Sir Tim Berners-Lee, will always be “a little bit broken.â€
Jeffrey concludes:
Version targeting is a mind-bender. It shakes our browser-agnostic faith. Its default behavior, although beneficial to skilled and unskilled developers alike, runs counter to our expectations, and seems wrong. And it presents at least one Sphinxian riddle: namely, how can IE8 pass Acid 2 if IE8 behaves as IE7 by default? You can spend weeks on that one and not come up with a logical answer. Call me Lewis Carroll, but I’m okay with it.
He talks about how JavaScript already is opt-in:
And actually, Mozilla has offered opt-in version targeting, first when Firefox 1.5 introduced support for JavaScript 1.6, and later, when Firefox 2.0 did the same for JavaScript 1.7. In both cases, you had to explicitly opt in. The comparison is Mozilla’s favor, for they targeted scripting language versions, not browser versions. But although Mozilla did it more cleanly, both browser makers offered targeting, and for the same reason: to protect developers from unintended behavior as their browsers’ scripting support improved.
Non-standardistas have been writing JScript for years. While the CSS changes in IE7 may have “broken†a site’s layout, IE8’s JavaScript improvements could easily render a site useless. Real DOM support is a game changer. Enabled by default, it would bring many sites to their knees. That would break the web, and not in quotes. Providing IE8’s greater compliance on an opt-in basis is the only way to get everyone over the scripting hump.
But while the opt-in protects old-fashioned coders from a major change in the scripting environment, it also offers unique benefits to even the most die-hard standardista.
The opinions keep on coming!
Tuesday, January 29th, 2008
Category: Articles
Michael Morrison, author of Head First JavaScript, has written a piece for CIO magazine titled You Used JavaScript to Write WHAT? which is part of a series of articles on when to use a particular language or platform.
It is always interesting to see what the CXO folks are reading wrt our beloved Web :)
The other side of the coin is the mentality of viewing a Web application as a program, as opposed to a page. In this scenario, the application is utterly dependent on the active functionality made possible by JavaScript, which means it's okay to forego users who lack JavaScript support. Google has embraced this philosophy in several marquee products, two of which are extremely popular: Gmail and Google Maps. Both applications make extensive use of Ajax (JavaScript), and neither apologizes to users who can't run them due to a lack of JavaScript. If this article had been written just a few short years ago, I might have used an e-mail application as the ridiculous example of when not to use JavaScript, instead of Halo. But Gmail has pushed through that barrier.
Even if JavaScript-powered, web-based e-mail ultimately takes hold, surely there are other stand-alone applications that will just never make sense in Web form. Two such applications that come to mind are video and photo editing. Similar to games, these are such media-intensive applications that they just can't make sense in JavaScript, right? Yet Adobe has already released Premiere Express for online video editing and is putting the finishing touches on Photoshop Express for Web-based photo editing. What's interesting about these applications is that they aren't technically built in JavaScript; they're built in ActionScript, a close cousin of JavaScript used in Adobe's Flex development environment. But the ActionScript in these applications is compiled, so the net effect is more akin to a native application. Adobe may be foreshadowing the future of Web scripting to some degree, at least in terms of building more feature-rich applications. And in doing so, they're forcing us to rethink just what is possible with scripting languages.
Monday, January 28th, 2008
Category: Ajax, Articles
Coach Wei, of Nexaweb and Apache, has published a study of Ajax performance issues in browsers, and they won't surprise you:
Obviously, we would like to see browser vendors take a serious look into the following issues and put them on their roadmap:
- In all major browsers, performance with Array and HTML DOM needs improvement in general.
- Browsers need to provide API support for Computed Box Model and Style;
- FireFox needs to improve performance of “evalâ€, object creation and “in†operation
- Internet Explorer needs to improve performance in general to be at least on par with other browsers. Beyond that, “String†manipulation on IE needs continued improvements;
- Safari: “pop†operation performance needs improvement
- Just-in-time (JIT) compiler: This maybe a bigger task than an incremental fix of some existing features, however, it is worthy of every penny. JIT will not only fix the String manipulation issue, it will enable JavaScript to truly shine in matching the performance of native applications. The amount of client side logic (aka, JavaScript code) needs to grow in order to accommodate the growth of application complexity, for which JavaScript runtime performance problem can be a major bottleneck.
Read the study to get the details on each item. It includes the results such as the DOM operation performance information:
Thursday, January 24th, 2008
Category: Articles, Games
James Edwards has written a very detailed tutorial on using dhtml to create a game which is part of his book:
In this chapter, we took the languages of CSS and JavaScript well beyond the tasks for which they were intended?the presentation and basic behavior of HTML documents -- and used them to create an interactive 3D maze.
First, we looked at the basic principles by which triangles can be displayed using only CSS. We then extended that concept to render a perspective view, creating the illusion of three dimensions. Next, we established a convention for specifying floor plan data, and for dynamically translating that data into a perspective view. By adding listeners for user events, we successfully created an interactive maze that can be completely customized
