You are reading a MIX Online Opinion. In which we speak our minds. Nishant Kothary Meet Nishant Arrow

Opinions

7Comment Retweet

Every Flashback has a Silver Lining

Feb 24, 2009 In Design By Nishant Kothary

Every Flashback has a Silver Lining

We recently moved to a new building on campus that doesn’t have its own cafeteria. As blasphemous as that is, we’ve learned to deal with the situation and have gotten into a cadence of walking to a neighboring cafeteria with a teammate for lunch. Lunch conversations – what a concept!

Joshua and I went to lunch last week and ended up talking about the web development experience, specifically, how far it’s come in a decade, yet how much it’s remained the same. The last couple of decades we’ve been using text editors to write markup and scripts. And today, despite the advent of IDEs with all sorts of bells and whistles, we’re still using simple text editors to write markup and scripts. A recent poll by Smashing Magazine revealed NotePad++ to be the top web developer code editor (with 23% of the market share), and Vim and TextMate coming in second sporting 11% each. Most of us revert back to good ol’ handwritten markup and scripting and generally, productivity features such as code completion and coloring are sufficient to make us happy. But hold that thought for a minute, and let’s change the topic to Flash.

Yes, Flash.

Flash 5 introduced ActionScript 1.0 – true scripting, procedural programming,and for the brave of heart,object-orientation through the prototype chain. There were a few of interesting things that I remember about that period:

  • Flash broke away from being just a designer thing. It was predominantly an animation tool before AS 1.0 but with a decent scripting language in place, developers entered the Flash scene.
  • A unique community was born: one made up of developers, designers and everyone in between.

In hindsight, the steady trickle of developers entering the Flash world upon the introduction of AS 1.0 wasn’t a surprise. Here was a time where your only other build-once-run-everywhere option aside from HTML/CSS was basically Java. And, if you wanted to build a powerful GUI using Java, you either started from scratch or extended Swing. While it was powerful, you needed to be a Computer Scientist to do the simplest of things. Compared to that, Flash and AS 1.0 were approachable – extremely approachable, actually. The birth of a community around AS 1.0, too, was a natural phenomenon. After all, the web is the biggest democracy and historically, the most approachable technologies have garnered a strong following (sure, some campaigning, i.e. bundling a plug-in into the operating system, never hurts adoption).

Despite its ubiquity and popularity amongst creative developers, Flash got its share of beatings once it went mainstream. Among the notable gripes – flash content wasn’t search-engine friendly, flash sites broke established browser metaphors (back/forward button, etc.), accessibility issues and my personal favorite (I paraphrase, of course) – Dear Flash, you’ve now armed the world of web monkeys with guns, and I hate you for that. Signed, Irate User Who Just Clicked "Skip Intro." Some of you may remember the issues published in a flaming summary destined for immortality by Jakob Nielsen in his Alertbox article: Flash: 99% Bad.

Looking at the complaints across the board, the source of the issue in my mind has always been at an architectural level. The Flash movie (i.e. the compiled swf that you embedded into the page) was effectively a black box that sat smugly on the page and it put up quite a fight if you tried to get it to talk to the rest of the page and vice versa. Here was this awesome thing sitting in the middle of the web page, but it just didn’t care to be a first-class citizen of it. Admittedly, I’d place some of the blame on the browser plug-in model that doesn’t have any requirement for how the plug-in integrates with the page DOM. Not to mention, Flash was never meant to be a something that extended the capabilities of the HTML DOM or even integrated with it; it was a way to embed animations in a web page. But, still.

This little architectural nuance has had far-reaching and deep implications on the workflow for us – the creators and keepers of the Web. If you are setting out to build a site that has a few instances of Flash on a page, you have to piece together interactions and UI in the Flash IDE, compile to a .swf file, embed the .swf in a web page and repeat; looks pretty neat and clean on the surface, but anyone who’s lived it knows otherwise. It breaks the typical workflow where you may simply create more code files in your text editor, or embed some scripts inline. And getting that .swf to pretend like its just another HTML tag is generally beyond the scope of most projects. This has resulted in the development of the RIA trend that has become commonplace today – most RIAs are either clumsily hosted apps within an HTML page or they take over the entire page without rhyme or reason. Granted, there are many cases where this makes sense, but a vast majority of the cases you come across are simply gratuitous. More so, instead of improving the experience for a user, they hijack established design patterns in the name of "rich" experiences.

This is not a Flash-bashing marathon (in the spirit of full disclosure, I’m a former Flash junkie and author), and to set the record straight, Macromedia and Adobe have addressed many of the concerns Mr. Nielsen complained about a few years ago. In fact, the stuff I’ve written above is hardly unique to Flash; Silverlight shares most of its characteristics from a development experience perspective. For instance, you need Visual Studio to make the magic happen, it’s all compiled down to a .xap that you have to embed, and so on. Silverlight requires you to leave the comfort of you text editor just as Flash does.

But from an architectural perspective, Silverlight is natively friendlier within the context of the browser DOM. If you look at Silverlight 1.0, you don’t have to stretch your imagination much to see where the line becomes blurry between HTML, CSS, Silverlight and JavaScript. Just "view source", and follow the path from CreateSilverlight() and you’ll get it. The UI is built using a plain-text, declarative markup language – XAML – which is transparent to the browser DOM. The programming model lets you manipulate this XAML using JavaScript – you can invoke FindName() to return a reference to any element of the UI declared in XAML as you would do on an HTML DOM element using getElementById(). Effectively, in its debut form, Silverlight was a way to truly enhance a web page – a compiled Canvas on steroids, if you will.

Interestingly, Silverlight retired the v1 programming model and developer experience in favor of the round-trip, write-compile-embed-repeat workflow. If you buy that one of the key uses of a rich element on a page is to enhance the overall experience of the page, then the programming model we currently use to develop Silverlight (and Flash) applications is counter-intuitive. Period. It doesn’t promote thinking about Silverlight (or Flash) as first-class elements of the page. Not to mention, the overhead for building these little islands of extended functionality is substantial and too tedious for most of us to bother ourselves with.

Let’s face it, for better or for worse, HTML/CSS form the backbone of the Web. History has repeatedly shown that any web technology that attempts to muscle its way into the browser without paying nice with HTML and CSS eventually finds itself deprecated or pushed into a niche. Maybe we’ll be proven wrong one day, but I don’t see any serious contenders for the top spot occupied by the democratically elected HTML+CSS duo right now. I’ve alluded to why approachability is one factor that determines the success of a web technology, but compatibility with HTML and CSS is equally important. And you don’t have to look very far for evidence – take the examples of jQuery and PHP, two broadly adopted technologies that are built on the premise of enhancing the most familiar programming model for web developers.

Are we going about it backwards? Is our collective vision for the web developer experience as it relates to RIAs myopic because of the precedent Java set back in the day? It’s not like we haven’t been wrong before on such a grand scale. I’m looking at you, WYSIWYG.

Write a comment and tell us what you think. Subscribe to our twitter feed if you want to stay in touch with us.

Follow the Conversation

7 comments so far. You should leave one, too.

Alan Churchill said on Feb 25, 2009

Bad blog software IMO.

Ok, on your article, the issue is that HTML/CSS/JavaScript were bad to start with. No, we shouldn''t be bound by their conventions and I would love to see a world w/o them in place.

In my attic is a stack of punchcards (nostalgia). Should we have held the world to those standards?

Don''t assume that HTML will be around forever because it won''t. Things change and so they should. HTML is horrible and has been abused beyond belief. Count CSS into that and JavaScript is one of the worst languages I have ever worked with. Goodbye as far as I am concerned.

Joshua Allen said on Feb 25, 2009

Hi Alan,

I''m intrigued. Can you elaborate? There are several reasons why HTML+CSS are dominant today, and Nishant''s article touches upon those reasons. And I believe that JavaScript has some really appealing characteristics.

But I am a sucker for iconoclasts. Are you arguing that "nothing lasts forever", or do you have some specific predictions about what will supplant HTML+CSS+JS, in your view? Specifically, what do you think would be *better*? It''s a fascinating conversation to have.

Nishant Kothary said on Feb 25, 2009

@Alan - I think you grossly misunderstood my blog post. I don''t really buy the blanket statements that HTML/CSS/JavaScript are horrible, and nor did I suggest that; yes, they have their shortcomings as do Flash, Silverlight, SPARC, Java and punch cards.

I''m with Joshua. I''d love a conversation about this if you''re up for it. I''ve watched this RIA thing unfold for a decade now and there''s a lot of rhetoric in the messaging around it. Let''s have a real conversation for a change.

Ian Muir said on Feb 25, 2009

I think that Nishant''s points are dead on, but they also exemplify some critical issues in the current state of the web. HTML isn''t horrible, but it''s getting there. It''s taken more than 10 years to develop the CSS3 standard and it''s still not official. HTML 5, SVG, ECMA and other open web standards are in the same boat.

As developers, were expected to innovate, but the standards we rely on came out when Netscape was top dog and I was in High School. So we cheat on the web standards. We spend a little time with Flash or Silverlight. We know it''s a little wrong, but they''re new and have some nice features.

I think that most web developers would love to have a real, in-browser solution. Unfortunately, the W3C model is broken. Vendors innovate, standards stagnate, and developers get stuck in the middle.

Nishant Kothary said on Feb 25, 2009

@Ian - I''m guilty of that, too (cheating on standards for nicer features). Your points are right on the money.

nerdstalker said on Feb 25, 2009

Nishant great post, I do appreciate the approach Microsoft has taken with XAML such that it plays better with the dom.

As for the html bit, my take is that html requires such a low barrier for entry, given that fact usage is dominant, it''s really that simple. I do wish companies would realize that simplicity and ease of use is of the most importance if you want your language/markup/solution to be widely adopted.

Nishant Kothary said on Feb 25, 2009

@nerdstalker - Great point. Literally anyone can create an HTML page using nothing more than notepad and that sets a pretty high (low?) bar in terms of evolving the developer experience. On one hand, you don''t want to restrict evolving the experience of writing code in a notepad-like environment, but on the other, you don''t want to be so far out there with the workflow that it becomes tedious to do the simplest of things. I think RIA development needs to be backward compatible with a text editor, i.e. I should be able to build it in Notepad if that''s all I have available.