sitepen getting there from here

Getting There From Here

Dylan SchiemannCEO, SitePen, Inc.April, 2009

1

© SitePen, Inc. 2009. All Rights Reserved

The Roadmap

Where do we want to go?

Where are we now?

What’s our rate-of-change?

Why?

What strategies can affect that rate?

What are the costs?

What should we do right now to get there?

2

Technology decisions are often made in the shadow of sunk-cost fallacies and perceptions that don’t accurately reflect reality. The goal of this talk is to help examine where the world of in-browser UI technology is at the moment and where, based on the evidence, we can expect it to be in the near future. Evolution of browsers over the next year or two. How do we evolve as a community


Web-delivered

Affordable to build

Useful and engaging

Benefits of desktop and web

Search

Link

Remix

Widgets

Mash-ups and Portals

We Want Apps That Are:

3

In short, the browser “won”. New applications are primarily deployed through the context of a web browser today, and so as applications migrate to the web, we continue to face the reality that the web makes some things easy and many things hard. The things that it makes easy are the things for which the web was initially adopted. Applications that have succeeded on the web have done so in part because of their natural affinity and compatibility with the perspective of applications that are searchable, distributed, and portable/survivable.

App authors have given up a lot to shoe-horn many apps into this view of the world, and there continues to be a natural tension between fidelity of experience and the other benefits that web apps provide.


Where Are We Now?

4

Before we can examine how things are going to change, we need to get square regarding our current situation. The reality of modern browser-based apps is at once heartening and depressing.


Well served:

Apps with static(ish) content

Document-oriented workflows

Text-based content creation

Not well served:

Everything else

It Depends

5


Enter URL or footnote here; delete if not required. Long text and/or URLs will wrap automatically for you.

http://flickr.com/photos/sonalandabe/519213371/

6

The web is very much the 4-lane highway of application delivery vehicles. Things which are designed to handle the reality of the road have the lowest incremental carrying costs, but the result is that many applications go completely un-served by that reality. Building RIA’s today is sort of like trying to build the mythical flying car...it’s perhaps a good idea, but the compromises that we’re forced into making (on any RIA technology) leave us with funky-looking hybrids which aspire to greatness in both directions (air and land), but may achieve neither. Regardless, the road (in this case browsers) continue their inevitable march to encompass ever more of the use-case landscape. The trick, then, is figuring out ways to work with the grain and not against it. This might mean building new kinds of vehicles that aren’t suited to city streets. The contract of a road is a suggestion, not an edict.

http://flickr.com/photos/senor_codo/352250460/



Doug Crockford

“We’re so far from the state of the art we can’t even see

the state of the art”

7

Browsers today are fundamentally incapable of taking advantage of most of the resources available to them. From ballsy GPU’s and CPU’s to local storage to even something as simple as bi-directional TCP-ish network connectivity, in-browser applications are hobbled in every way. But if we zoom in, we can see these barriers starting to come down. When, then, can we use these technologies in “street legal” applications? Some quantum of time after we demand it. The “permitting” process is unpredictable, but it’s not infinite.

video and photoshop on the web

© SitePen, Inc. 2009. All Rights Reservedhttp://flickr.com/photos/autanex/519742656/

<a href=”...”>

8

Links expose the structure of our data, but only in rendered views. This isn’t an existential problem as we have used “good enough” technologies to reduce the ambiguity and draw out the signal from the noise. Links aren’t added to documents for the benefit of 3rd-parties, though. They’re created to meet application goals. In this way, they have created a huge positive externality on the basis of a tiny, ubiquitous contract.

We’ll come back to this.




Now IdealWeb

Relative Rates of ChangeApp Strategy Cost Tactics

IE

9


Enter URL or footnote here; delete if not required. Long text and/or URLs will wrap automatically for you.


.dj_ie6 .giganticHack { ... }

10

We also suffer negative externalities. As we’ll see in a minute, choices made by users often do not encode the full costs to society (e.g., application developers) of those decisions. Sticking with IE 6 has a large cost not only to the user who’s on that browser, but also to everyone trying to service that user. In many cases, the incremental value of their business may be fully captured by the increase in development costs. But more distressingly, new capabilities and app functionality simply aren’t available to them. The opportunity costs may be enormous. It’s a hugely inefficient allocation of capital.

The speed of uptake of new browsers is now our Achilles' heel. If toolkits can fill in, how far can/should we expect them to go? Should we think of them as hybrid cars (a bridge to the future), or catalytic converters or scrubbers (band-aids that simply deal with the worst of the short-term effects)?




Doing interesting things in HTML is hard, but...

Devs know HTML

Systems produce HTML

Search engines understand HTML best

Many features can’t be attempted with HTML alone

Almost: advanced layout, 2D, offline/storage, Comet

No chance: Audio, video, 3D, image transforms

Many HTML advantages cannot be assumed in RIA scenarios (but toolkits may fill some gaps)

Costs and Externalities

11

Things in the “almost” category may move into the “can do” category for any particular browser, but since ubiquity is hard to achieve, they may stay in “almost” for a very long time. E.g.: XHR.


HTML

HTML + Ajax/Other

Pure JavaScript

Silverlight

Flash/Flex

The Contenders

12

So we want the benefits we outlined previously and we understand that things need to be “web delivered” (e.g., we’re not getting railroads back any time soon). We have some options, and they all have different sweet spots.


HTML

HTML + Ajax/Other

Pure JavaScript

Silverlight

Flash/Flex

Ubiquity + Capability Is The Game

The Contenders

12

So we want the benefits we outlined previously and we understand that things need to be “web delivered” (e.g., we’re not getting railroads back any time soon). We have some options, and they all have different sweet spots.


“Not the web I love”Joseph Smarr

Is It The Web If You Can’t “View Source”?

13

The web has evolved within its spectrum of capabilities from low to high (on average) at a blistering pace. It was only 15 years ago that it was being used for little more than research papers, whereas today it is the de-facto application deployment platform. A key enabler of this high rate of evolutionary change is the ability of web developers to understand what others have done in order to achiever a particular outcome and to copy that technique. We have been trained nearly our whole lives to think that copying is bad, but we know at some level that this is how we learn. A web that isn’t “view source”-able isn’t “the web”. We need to come to terms with the long-term costs of lowered productivity and higher incremental costs for any platform that doesn’t preserve the “view source” capability as a default property of the platform. We’re all reaping the benefits of decisions made 15 years ago, all the while discussing new technologies that endanger that value chain without a cogent discussion of the costs and benefits. We need to think hard about this.


Markup Code

14

The big difference between “view source-ability” and platforms that are closed by default is the ability to copy-and-paste from the app as it’s actually delivered and to tinker easily. HTML and lightweight Ajax frameworks often preserve this benefit as a side-effect of being markup-driven. Toolkits like Dojo that could default to sending code (something not grokable by most webdevs) need to work harder to preserve this advantage. On the other side of the spectrum are the “code all the way” options which throw “view source” under the bus in order to achieve some other goal. This make may them very well suited to their instantaneous environment, but it also leaves them ill-equipped from an evolutionary stand-point. No wonder, then, that many of them are growing view-source like properties as add-on features.


JavaScript-ish

15

Meta languagesHTML or JavaScript or some other language


Web-ish Desktop-ish

16

Users, however, only care about the instantaneous experience. The kinds of experiences that we can deliver are gated by the underlying capabilities of the platforms, and it’s here that closed options can excel.


Suck ?AlwaysWill Browsers

17

We feel most accutely the pain of the current crop of browsers, and in that pain it’s easy to lose sight of what is coming around the bend. Saying that something is bad defines a starting point, but not a vector. We need to pay attention to the related rates.


Suck?AlwaysWill Browsers

17

We feel most accutely the pain of the current crop of browsers, and in that pain it’s easy to lose sight of what is coming around the bend. Saying that something is bad defines a starting point, but not a vector. We need to pay attention to the related rates.


Can’t begin to handle the problem

No native capability

Uneven availability

Non-standard API

Too complex to be realistic

Ubiquitous, but buggy / uneven implementation

Requires too much code / too slow

Disambiguation: 2 Kind of “Suck”

18


“Competition Will Save Us!”

19

It may! Things have recently started to get much better on this front, thanks in large part to Mozilla, Apple, and Google. Microsoft has been forced to respond with IE7 and 8, and may yet again stop too long of the mark in their efforts to stanch the bleeding.


Firefox 3 and 3.5

Auto/forced upgrade

Safari 3 and 4

Pushed through Software Update

Opera 9.6

Upgrade notices

Chrome

Auto-upgrade system

Internet Explorer 8

It’s complicated

Getting New Stuff Faster

20

IE isn’t in a bad spot here, but its overwhelming market share makes its upgrade cycle representative of the slowness inherent in the upgrade process of the entire software ecosystem. Upgrading browsers == upgrading OSes, and people do it with similar trepidation, particularly at the enterprise level. This is not unwise.


0

25

50

75

100

‘93 ‘94 ‘95 ‘96 ‘97 ‘98 ‘99 ‘00 ‘01 ‘02 ‘03 ‘04 ‘05 ‘06 ‘07 ‘08 ‘09 ‘10

Netscape Usage Share

21

While we know that things are starting to move faster with regards to internal browser replacement rates, we need to be able to say something about who gets to be in control of the markets.

We’ve got a decade and a half of browser experience now, and it appears that the case for natural monopolies in the browser space is strong.


0

25

50

75

100

‘95 ‘96 ‘97 ‘98 ‘99 ‘00 ‘01 ‘02 ‘03 ‘04 ‘05 ‘06 ‘07 ‘08 ‘09 ‘10

1.5

2.0

1.0

3.0

4.0

5.0

5.5

6.0

7.0

M2

M2.1

M3

M4.0

M4.5

M5.0

(U3)

U4.0

U5.0 M5.2 8.0

IE Versions Over Time

22

Between ’95 and ’02 there were 16 major releases of IE across 4 platforms.

From ‘02-’08 we have 2 releases on 1 platform.

IE hit 90% market share in ’02.

Clearly, there is some force that keeps market winners in this space from moving once they’ve won. We suspect it’s a lack of competition.


Monocultures Reduce Costs In The Short Run

23

there is an asymmetric information problem which hopeful platforms like Flex and Silverlight are playing to: they hope to emerge in a dominant position by putting off the costs of monoculture until after they have “won”


But can be sexy!

Monocultures Reduce Costs In The Short Run

23

there is an asymmetric information problem which hopeful platforms like Flex and Silverlight are playing to: they hope to emerge in a dominant position by putting off the costs of monoculture until after they have “won”


Are Web Browsers Prone To Natural Monopolies?

24


How Would Our Attitudes Change If We Expected Monopolies?

Are Web Browsers Prone To Natural Monopolies?

24


Web-ish Desktop-ish

hostage to deployed browsers

25

monocultures have the benefit of not being hostage to the upgrade cycles of the collective set of browsers. By reducing the variables for upgrades and control of the platform experience, closed platforms are able to deliver new capabilities faster. At least so far.


Web-ish Desktop-ish

rev independently

26


Browser Economics: Standards

0% 25% 50% 75% 90% 100%

Cos

t*

Standards Compliance*Cost is an artificial number factoring in R&D and opportunity costs

27

there’s no advantage to being 100% standards compliant for any browser vendor except as a short-term cudgel browser vendors don’t make money on renderers...they make money on search. Investment in renderers (why developers care about a particular browser) aren’t justified by market share advances or monetary remuneration.

Standards are overrated... they don’t help us compete with innovations


Browser Economics: Standards

5%

95%

Search Renderer*Based on Mozilla revenues

28

there’s no advantage to being 100% standards compliant for any browser vendor except as a short-term cudgelbrowser vendors don’t make money on renderers...they make money on search. Investment in renderers (why developers care about a particular browser) aren’t justified by market share advances or monetary remuneration.

We need to ask more out of browser vendors


Other Options?

29

Since we know that the upgrade cycles of browsers are somewhat out of our hands, how do we get to world where the economic interests are aligned? The browser guys aren’t on the hunt...so what next?


Gears?!

http://www.flickr.com/photos/jeffk/2459512927/

30

Google Gears (and to a lesser extent, Yahoo Browser Plus) point to a possible structural solution: systems that are developed by organizations invested in content but which have leverage over the entire ecosystem of deployed browsers. Not handing this type of control over to closed vendors is also critically important to the future of a low-cost platform, and so an Open Source system that can hot-patch browsers may be our best path forward.




AIR? Titanium?

31

Proprietary but great. Open but less mature.


32

Systems like Gears, today, cannot affect markup but can add new JavaScript API’s. This leads to a potential distortionary effect where new APIs don’t come in the from of tags and developers may consider progress to only be acceptable in guise of APIs and not tags. Given that markup is the lifeblood of the web development and that the progress of markup liberates features from the realms of programmers and gives them to mere mortals, what should we make of this? Not necessarily about right or wrong, but how much it costs (programmers vs. web developers).


Will It Be Enough?

33


What is the role of semantics in apps vs. pages?

What happens if a single vendor owns the plugin platform too?

Does routing around browsers also throw the W3C under the bus?

What should developers advocate for to browser vendors?

Open Questions

34


HTML 5?

JavaScript? ES4?

Future of “Ajax” and toolkits?

Technology choices?

What about mobile?

Now What?

35


HTML 5

Not done yet!

Adds semantics for many common cases

tables/grids, video, audio, form repeating, “data templates”, ad-hoc attributes

Standardizes error recovery in parsing

XML is the bug that HTML 5 fixes

Largely silent on layout

Depends on CSS for new capabilities... and CSS 3 is dead on arrival

36


What If JavaScript Got A Lot Better?

37



Good news! It’s getting much better

37




Bad-ish news: just not in the ways most people expected

37




Bad-ish news: just not in the ways most people expected

JavaScript 2, aka: ECMAScript 4, aka: ActionScript 3

Not happening

ES 3.1 splinter group broke off from WG in early ’08

Harmony announcement in August

Java-like class semantics likely never to appear

Or at least not without some unification with prototypes

Packages, namespaces now off the table

37


The Buried Lead

JavaScript is already a pretty good language

JavaScript doesn’t need traditional classes to go faster

New bumper crop of high-performance JS VM’s:

Squirrelfish (Apple)

TraceMonkey (Mozilla/Adobe)

v8 (Google)

SunSpider (Opera)

JIT, DFA, tracing and trace tree folding no longer “exotic” or “research”

Microsoft notably absent from the performance party

38


The Enterprise Perspective

http://flickr.com/photos/jalex_photo/390896449/

39




Enterprise support and training investments in IE

Managed upgrade paths

Accelerated rollouts of IE 8 can alleviate much pain

External users may be on old browsers for 4+yrs

IE 6 to be “flushed out” by mid-2010?

Gears/YBP likely to have more impact than FF/Opera/Chrome/Safari

Primary choices: Ajax Toolkits or Flex/Silverlight

The Enterprise Perspective

40


What Should We Expect From Ajax?Toolkits play to least common denominator

Looming performance differential

Widening gap in quality of user experience between new browsers and old

More Flash/Gears-as-fallback branching, creating implicit dependency on plugins

Increasingly, new features may simply not work or may not be usable on down-rev, un-augmented browsers

Toolkits will preview component models and provide bridges to better performing APIs

41

The yawning gap in performance between IE 6/7 and the latest versions of Chrome and WebKit creates a gigantic range of potential experiences for users on equivalent (modern) hardware but with slightly different software. In this environment, the role of toolkits will switch from papering over differences in capability to providing shims for tools like Gears and Flash to augment the native experience.


Ajax Toolkits In Perspective

jQuery, Prototype, Moo, Dojo Base:

“Core” libraries for extension ecosystems...most easily replaced by browser innovation

Dojo+Dijit, YUI, jQuery UI, Ext, Sprout Core:

Comprehensive UI and plumbing frameworks. Will need to change in the face of browser evolution but also stand to gain most

GWT, Other compilers:

Orthogonal to, but gated by, browser evolution. Self-selected developer audiences.

42

Ajax toolkits all hit a particular niche, and the sweet spot for a toolkit like Dojo is in “HTML++” type applications which are still page-oriented and developed by people with web-app construction backgrounds. For “pure webdevs” who don’t know much programming, the state of the art will improve fastest based on native browser capabilities. Everyone else is likely to see large improvements, but continually mediated by toolkits.


The Average Will Improve, Albeit Unevenly

43

Not ubiquitous performanceDifferent dev costs


CSS (D)EvolutionCSS 3 recommendation process deeply broken

More reliance on JavaScript for layout

Layout primitives, ease-of-use key toolkit differentiators

Markup or code? Or both?

Forward compatibility with proposed specs

Unsure future of CSS

Standardize on an Ajax toolkit for the foreseeable future.

Until the platform forces agreement, ROI is based on localized knowledge re-use.

Performance concerns

44

It’s hard to say what will happen here. Either JavaScript toolkits will take it upon themselves to attempt to fix the layout primitives, relying on ever-better execution engines to help lessen the blow, or single browsers will race ahead and potentially fork/define a spec which the CSS WG will eventually (grudgingly) ratify. Many features need to be culled from SVG, and Firefox is already on the scent. The evolutionary path here has much risk.


What About Flex/Silverlight?

Responsive, affordable option in the short-term

Reasonable choices for one-off and RAD situations

Transparent platform plays... with an upside

Stiff competition likely to drive quick improvements until market is settled

If a single winner emerges, expect another “IE winter”

Single vendor control by any other name...

Adobe and MSFT are learning how to arbitrage the brand of Open Source (not just “standards”)

Breaks text and indexability

45

Flex/Silverlight represent great short-term choices, and their long-term problem is in building and keeping trust. In large part, this is due to the organizations that have produced them and the tooling revenue models they are attached to.


The Abiding Sorrow Of Mobile

46


Flash/Silverlight mobile experience is app-oriented, not browsing-oriented

Mobile is where browsers improve fastest

Apps (not static content) require re-development for mobile regardless of rendering tech

UX, not technology, requires rethink

“Web” not a be-all, end-all container on mobile

Mobile apps will be roughly OS/browser-specific for next several years at the high-end

Mobile and Rich App Technologies

47


The Long View

IE will not hold

High-performance alternatives will replace it

“Open Web” plugin

The growing disparity presents a huge financial loss

Open development model likely to depend on Ajax/JavaScript in RIA space for the foreseeable future

Flex/Silverlight likely to make inroads, but will be curtailed by (rational) mistrust of Adobe and MSFT

The next 2 years will tell if codec licensing is RIA endgame

48

The race for high-performance open web browsers is once again “on”. Given that IE is evolving, there will continue to be huge pressure on the IE team to either support the killer apps which better browsers enable or will be forcibly augmented.


Questions and Key URLs

SitePen sitepen.com

Dojo Toolkit dojotoolkit.org

Dojo Foundation dojofoundation.org

Dijit dojotoolkit.org

Dojo Campus dojocampus.org

Comet cometd.com

Comet Daily cometdaily.com

Dylan Schiemann [email protected]

49

mailto:[email protected]

mailto:[email protected]


Thank You

50

sitepen getting there from here

Technology

asymmetric

market share

monocultures

rights reserved

web browsers

view source

arent justied

browser vendor