Sitepen Getting There From Here

Getting There From Here

Dylan Schiemann
CEO, SitePen, Inc.
April, 2009

1

The Roadmap
Where do we want to go?
Where are we now?
What’s our rate-of-change?
Why?
What strategies can aﬀect that rate?
What are the costs?
What should we do right now to get there?

© SitePen, Inc. 2009. All Rights Reserved

2

Technology decisions are often made in the shadow of sunk-cost fallacies and perceptions
that don’t accurately reﬂect 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

We Want Apps That Are:

Web-delivered
Affordable to build
Useful and engaging
Benefits of desktop and web
Search
Link
Remix
Widgets
Mash-ups and Portals


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.

It Depends

Well served:
Apps with static(ish) content
Document-oriented workﬂows
Text-based content creation
Not well served:
Everything else


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.

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

Doug Crockford


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 inﬁnite.

video and photoshop on the web

<a href=”...”>
http://ﬂickr.com/photos/autanex/519742656/

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 beneﬁt 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.

Relative Rates of Change
App Strategy Cost Tactics

IE
Web
Now Ideal

9

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

© http://ﬂickr.com/photos/senor_codo/352250460/
SitePen, Inc. 2009. All Rights Reserved

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 ﬁll 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)?

Costs and Externalities
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, oﬄine/storage, Comet
No chance: Audio, video, 3D, image transforms
Many HTML advantages cannot be assumed in RIA
scenarios (but toolkits may ﬁll some gaps)


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.

The Contenders
HTML
HTML + Ajax/Other
Pure JavaScript
Silverlight
Flash/Flex


12

So we want the beneﬁts 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.

The Contenders
HTML
HTML + Ajax/Other
Pure JavaScript
Silverlight
Flash/Flex

Ubiquity + Capability Is The Game


12

So we want the beneﬁts 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.

Is It The Web If You
Can’t “View Source”?
“Not the web I love”
Joseph Smarr


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 beneﬁts 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 beneﬁts. 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 beneﬁt 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 languages
HTML 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.

Always
Will Browsers Suck ?


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 deﬁnes a starting
point, but not a vector. We need to pay attention to the related rates.

Will Browsers Always Suck ?


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 deﬁnes a starting
point, but not a vector. We need to pay attention to the related rates.

Disambiguation: 2 Kind of “Suck”
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


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.

Getting New Stuﬀ Faster
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


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.

Netscape Usage Share
100

75

50

25

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

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.

IE Versions Over Time
100

U5.0 M5.2 8.0
75
U4.0 M5.0 7.0
(U3) M4.5 6.0
M4.0 5.5
50 M3 5.0
M2.1 4.0
3.0
M2
25
2.0
1.5
1.0
0
‘95 ‘96 ‘97 ‘98 ‘99 ‘00 ‘01 ‘02 ‘03 ‘04 ‘05 ‘06 ‘07 ‘08 ‘09 ‘10


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”

Monocultures Reduce
Costs In The Short Run

But can be sexy!


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

Are Web Browsers Prone To
Natural Monopolies?
How Would Our Attitudes Change
If We Expected Monopolies?


24

hostage to deployed browsers

Web-ish Desktop-ish


25

monocultures have the beneﬁt 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.

rev independently

Web-ish Desktop-ish


26

Browser Economics: Standards
Cost*

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

Standards Compliance
*Cost is an artiﬁcial 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
justiﬁed 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 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 justiﬁed 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.ﬂickr.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

Open Questions
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?


34

Now What?
HTML 5?
JavaScript? ES4?
Future of “Ajax” and toolkits?
Technology choices?
What about mobile?


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 ﬁxes
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:
Squirrelﬁsh (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://ﬂickr.com/photos/jalex_photo/390896449/

39

The Enterprise Perspective
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 “ﬂushed out” by mid-2010?
Gears/YBP likely to have more impact than FF/Opera/
Chrome/Safari
Primary choices: Ajax Toolkits or Flex/Silverlight


40

What Should We Expect From Ajax?
Toolkits play to least common denominator
Looming performance diﬀerential
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 performance
Different dev costs

CSS (D)Evolution
CSS 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

Mobile and Rich App Technologies
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-speciﬁc for next
several years at the high-end


47

The Long View
IE will not hold
High-performance alternatives will replace it
“Open Web” plugin
The growing disparity presents a huge ﬁnancial 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 dylan@sitepen.com


49

Thank You


50

Sitepen Getting There From Here

More Related Content

What's hot (19)

Similar to Sitepen Getting There From Here (20)

More from George Ang (20)

Recently uploaded (20)

Sitepen Getting There From Here