Openwebdylanqconbeijing 090423091545-phpapp01

564 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
564
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Openwebdylanqconbeijing 090423091545-phpapp01

  1. 1. Getting There From HereDylan SchiemannCEO, SitePen, Inc.April, 2009 1
  2. 2. 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?© SitePen, Inc. 2009. All Rights Reserved 2Technology decisions are often made in the shadow of sunk-cost fallacies and perceptionsthat don’t accurately reflect reality. The goal of this talk is to help examine where the worldof in-browser UI technology is at the moment and where, based on the evidence, we canexpect it to be in the near future. Evolution of browsers over the next year or two. How dowe evolve as a community
  3. 3. 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© SitePen, Inc. 2009. All Rights Reserved 3In short, the browser “won”. New applications are primarily deployed through the context of aweb browser today, and so as applications migrate to the web, we continue to face the realitythat the web makes some things easy and many things hard. The things that it makes easyare the things for which the web was initially adopted. Applications that have succeeded onthe web have done so in part because of their natural affinity and compatibility with theperspective 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, andthere continues to be a natural tension between fidelity of experience and the other benefitsthat web apps provide.
  4. 4. Where Are We Now?© SitePen, Inc. 2009. All Rights Reserved 4Before we can examine how things are going to change, we need to get square regarding ourcurrent situation. The reality of modern browser-based apps is at once heartening anddepressing.
  5. 5. It Depends Well served: Apps with static(ish) content Document-oriented workflows Text-based content creation Not well served: Everything else© SitePen, Inc. 2009. All Rights Reserved 5
  6. 6. Enter URL or footnote here; delete if not required. Long text and/or URLs will wrap automatically for you.© SitePen, Inc. 2009. All Rights Reserved http://flickr.com/photos/sonalandabe/519213371/ 6The web is very much the 4-lane highway of application delivery vehicles. Things which aredesigned to handle the reality of the road have the lowest incremental carrying costs, but theresult is that many applications go completely un-served by that reality. Building RIA’s todayis sort of like trying to build the mythical flying car...it’s perhaps a good idea, but thecompromises 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 achieveneither. Regardless, the road (in this case browsers) continue their inevitable march toencompass ever more of the use-case landscape. The trick, then, is figuring out ways to workwith the grain and not against it. This might mean building new kinds of vehicles that aren’tsuited to city streets. The contract of a road is a suggestion, not an edict.
  7. 7. “We’re so far from the state of the art we can’t even see the state of the art” Doug Crockford© SitePen, Inc. 2009. All Rights Reserved 7Browsers today are fundamentally incapable of taking advantage of most of the resourcesavailable to them. From ballsy GPU’s and CPU’s to local storage to even something as simpleas bi-directional TCP-ish network connectivity, in-browser applications are hobbled in everyway. But if we zoom in, we can see these barriers starting to come down. When, then, can weuse these technologies in “street legal” applications? Some quantum of time after we demandit. The “permitting” process is unpredictable, but it’s not infinite.video and photoshop on the web
  8. 8. <a href=”...”>© SitePen, Inc. 2009. All Rights Reservedhttp://flickr.com/photos/autanex/519742656/ 8Links expose the structure of our data, but only in rendered views. This isn’t an existentialproblem as we have used “good enough” technologies to reduce the ambiguity and draw outthe 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 hugepositive externality on the basis of a tiny, ubiquitous contract.We’ll come back to this.
  9. 9. Relative Rates of Change App Strategy Cost Tactics IE Web Now Ideal© SitePen, Inc. 2009. All Rights Reserved 9
  10. 10. .dj_ie6 .giganticHack { ... } Enter URL or footnote here; delete if not required. Long text and/or URLs will wrap automatically for you.© http://flickr.com/photos/senor_codo/352250460/ SitePen, Inc. 2009. All Rights Reserved 10We also suffer negative externalities. As we’ll see in a minute, choices made by users oftendo 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 toeveryone trying to service that user. In many cases, the incremental value of their businessmay be fully captured by the increase in development costs. But more distressingly, newcapabilities and app functionality simply aren’t available to them. The opportunity costs maybe 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 farcan/should we expect them to go? Should we think of them as hybrid cars (a bridge to thefuture), or catalytic converters or scrubbers (band-aids that simply deal with the worst of theshort-term effects)?
  11. 11. 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, 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)© SitePen, Inc. 2009. All Rights Reserved 11Things in the “almost” category may move into the “can do” category for any particularbrowser, but since ubiquity is hard to achieve, they may stay in “almost” for a very long time.E.g.: XHR.
  12. 12. The Contenders HTML HTML + Ajax/Other Pure JavaScript Silverlight Flash/Flex© SitePen, Inc. 2009. All Rights Reserved 12So 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.
  13. 13. The Contenders HTML HTML + Ajax/Other Pure JavaScript Silverlight Flash/Flex Ubiquity + Capability Is The Game© SitePen, Inc. 2009. All Rights Reserved 12So 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.
  14. 14. Is It The Web If You Can’t “View Source”? “Not the web I love” Joseph Smarr© SitePen, Inc. 2009. All Rights Reserved 13The web has evolved within its spectrum of capabilities from low to high (on average) at ablistering pace. It was only 15 years ago that it was being used for little more than researchpapers, whereas today it is the de-facto application deployment platform. A key enabler ofthis high rate of evolutionary change is the ability of web developers to understand whatothers have done in order to achiever a particular outcome and to copy that technique. Wehave been trained nearly our whole lives to think that copying is bad, but we know at somelevel that this is how we learn. A web that isn’t “view source”-able isn’t “the web”. We need tocome to terms with the long-term costs of lowered productivity and higher incremental costsfor any platform that doesn’t preserve the “view source” capability as a default property ofthe platform. We’re all reaping the benefits of decisions made 15 years ago, all the whilediscussing new technologies that endanger that value chain without a cogent discussion ofthe costs and benefits. We need to think hard about this.
  15. 15. Markup Code© SitePen, Inc. 2009. All Rights Reserved 14The big difference between “view source-ability” and platforms that are closed by default isthe 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 beingmarkup-driven. Toolkits like Dojo that could default to sending code (something notgrokable by most webdevs) need to work harder to preserve this advantage. On the otherside of the spectrum are the “code all the way” options which throw “view source” under thebus in order to achieve some other goal. This make may them very well suited to theirinstantaneous 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.
  16. 16. JavaScript-ish© SitePen, Inc. 2009. All Rights Reserved 15Meta languagesHTML or JavaScript or some other language
  17. 17. Web-ish Desktop-ish© SitePen, Inc. 2009. All Rights Reserved 16Users, however, only care about the instantaneous experience. The kinds of experiences thatwe can deliver are gated by the underlying capabilities of the platforms, and it’s here thatclosed options can excel.
  18. 18. Always Will Browsers Suck ?© SitePen, Inc. 2009. All Rights Reserved 17We feel most accutely the pain of the current crop of browsers, and in that pain it’s easy tolose sight of what is coming around the bend. Saying that something is bad defines a startingpoint, but not a vector. We need to pay attention to the related rates.
  19. 19. Will Browsers Always Suck ?© SitePen, Inc. 2009. All Rights Reserved 17We feel most accutely the pain of the current crop of browsers, and in that pain it’s easy tolose sight of what is coming around the bend. Saying that something is bad defines a startingpoint, but not a vector. We need to pay attention to the related rates.
  20. 20. 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© SitePen, Inc. 2009. All Rights Reserved 18
  21. 21. “Competition Will Save Us!”© SitePen, Inc. 2009. All Rights Reserved 19It may! Things have recently started to get much better on this front, thanks in large part toMozilla, Apple, and Google. Microsoft has been forced to respond with IE7 and 8, and may yetagain stop too long of the mark in their efforts to stanch the bleeding.
  22. 22. Getting New Stuff 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© SitePen, Inc. 2009. All Rights Reserved 20IE isn’t in a bad spot here, but its overwhelming market share makes its upgrade cyclerepresentative of the slowness inherent in the upgrade process of the entire softwareecosystem. Upgrading browsers == upgrading OSes, and people do it with similartrepidation, particularly at the enterprise level. This is not unwise.
  23. 23. 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© SitePen, Inc. 2009. All Rights Reserved 21While we know that things are starting to move faster with regards to internal browserreplacement rates, we need to be able to say something about who gets to be in control ofthe markets.We’ve got a decade and a half of browser experience now, and it appears that the case fornatural monopolies in the browser space is strong.
  24. 24. 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© SitePen, Inc. 2009. All Rights Reserved 22Between ’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 oncethey’ve won. We suspect it’s a lack of competition.
  25. 25. 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© SitePen, Inc. 2009. All Rights Reserved 22Between ’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 oncethey’ve won. We suspect it’s a lack of competition.
  26. 26. Monocultures Reduce Costs In The Short Run© SitePen, Inc. 2009. All Rights Reserved 23there is an asymmetric information problem which hopeful platforms like Flex and Silverlightare playing to: they hope to emerge in a dominant position by putting off the costs ofmonoculture until after they have “won”
  27. 27. Monocultures Reduce Costs In The Short Run But can be sexy!© SitePen, Inc. 2009. All Rights Reserved 23there is an asymmetric information problem which hopeful platforms like Flex and Silverlightare playing to: they hope to emerge in a dominant position by putting off the costs ofmonoculture until after they have “won”
  28. 28. Are Web Browsers Prone To Natural Monopolies?© SitePen, Inc. 2009. All Rights Reserved 24
  29. 29. Are Web Browsers Prone To Natural Monopolies? How Would Our Attitudes Change If We Expected Monopolies?© SitePen, Inc. 2009. All Rights Reserved 24
  30. 30. hostage to deployed browsers Web-ish Desktop-ish© SitePen, Inc. 2009. All Rights Reserved 25monocultures have the benefit of not being hostage to the upgrade cycles of the collectiveset of browsers. By reducing the variables for upgrades and control of the platformexperience, closed platforms are able to deliver new capabilities faster. At least so far.
  31. 31. rev independently Web-ish Desktop-ish© SitePen, Inc. 2009. All Rights Reserved 26
  32. 32. Browser Economics: Standards Cost* 0% 25% 50% 75% 90% 100% Standards Compliance *Cost is an artificial number factoring in R&D and opportunity costs© SitePen, Inc. 2009. All Rights Reserved 27there’s no advantage to being 100% standards compliant for any browser vendor except as ashort-term cudgel browser vendors don’t make money on renderers...they make money onsearch. Investment in renderers (why developers care about a particular browser) aren’tjustified by market share advances or monetary remuneration.Standards are overrated... they don’t help us compete with innovations
  33. 33. Browser Economics: Standards 5% 95% Search Renderer *Based on Mozilla revenues© SitePen, Inc. 2009. All Rights Reserved 28there’s no advantage to being 100% standards compliant for any browser vendor except as ashort-term cudgelbrowser vendors don’t make money on renderers...they make money on search. Investmentin renderers (why developers care about a particular browser) aren’t justified by market shareadvances or monetary remuneration.We need to ask more out of browser vendors
  34. 34. Other Options?© SitePen, Inc. 2009. All Rights Reserved 29Since we know that the upgrade cycles of browsers are somewhat out of our hands, how dowe get to world where the economic interests are aligned? The browser guys aren’t on thehunt...so what next?
  35. 35. Gears?! © SitePen, Inc. 2009. All Rights Reservedhttp://www.flickr.com/photos/jeffk/2459512927/ 30Google Gears (and to a lesser extent, Yahoo Browser Plus) point to a possible structuralsolution: systems that are developed by organizations invested in content but which haveleverage over the entire ecosystem of deployed browsers. Not handing this type of controlover to closed vendors is also critically important to the future of a low-cost platform, and soan Open Source system that can hot-patch browsers may be our best path forward.
  36. 36. AIR? Titanium?© SitePen, Inc. 2009. All Rights Reserved 31Proprietary but great. Open but less mature.
  37. 37. © SitePen, Inc. 2009. All Rights Reserved 32Systems like Gears, today, cannot affect markup but can add new JavaScript API’s. This leadsto a potential distortionary effect where new APIs don’t come in the from of tags anddevelopers may consider progress to only be acceptable in guise of APIs and not tags. Giventhat markup is the lifeblood of the web development and that the progress of markupliberates features from the realms of programmers and gives them to mere mortals, whatshould we make of this? Not necessarily about right or wrong, but how much it costs(programmers vs. web developers).
  38. 38. Will It Be Enough?© SitePen, Inc. 2009. All Rights Reserved 33
  39. 39. 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?© SitePen, Inc. 2009. All Rights Reserved 34
  40. 40. Now What? HTML 5? JavaScript? ES4? Future of “Ajax” and toolkits? Technology choices? What about mobile?© SitePen, Inc. 2009. All Rights Reserved 35
  41. 41. 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© SitePen, Inc. 2009. All Rights Reserved 36
  42. 42. What If JavaScript Got A Lot Better?© SitePen, Inc. 2009. All Rights Reserved 37
  43. 43. What If JavaScript Got A Lot Better? Good news! It’s getting much better© SitePen, Inc. 2009. All Rights Reserved 37
  44. 44. What If JavaScript Got A Lot Better? Good news! It’s getting much better Bad-ish news: just not in the ways most people expected© SitePen, Inc. 2009. All Rights Reserved 37
  45. 45. What If JavaScript Got A Lot Better? Good news! It’s getting much better 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© SitePen, Inc. 2009. All Rights Reserved 37
  46. 46. 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© SitePen, Inc. 2009. All Rights Reserved 38
  47. 47. The Enterprise Perspective © SitePen, Inc. 2009. All Rights Reservedhttp://flickr.com/photos/jalex_photo/390896449/ 39
  48. 48. 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 “flushed out” by mid-2010? Gears/YBP likely to have more impact than FF/Opera/ Chrome/Safari Primary choices: Ajax Toolkits or Flex/Silverlight© SitePen, Inc. 2009. All Rights Reserved 40
  49. 49. 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© SitePen, Inc. 2009. All Rights Reserved 41The yawning gap in performance between IE 6/7 and the latest versions of Chrome andWebKit 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 willswitch from papering over differences in capability to providing shims for tools like Gears andFlash to augment the native experience.
  50. 50. 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.© SitePen, Inc. 2009. All Rights Reserved 42Ajax 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-appconstruction backgrounds. For “pure webdevs” who don’t know much programming, the stateof the art will improve fastest based on native browser capabilities. Everyone else is likely tosee large improvements, but continually mediated by toolkits.
  51. 51. The Average Will Improve, Albeit Unevenly© SitePen, Inc. 2009. All Rights Reserved 43Not ubiquitous performanceDifferent dev costs
  52. 52. 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© SitePen, Inc. 2009. All Rights Reserved 44It’s hard to say what will happen here. Either JavaScript toolkits will take it upon themselvesto attempt to fix the layout primitives, relying on ever-better execution engines to helplessen the blow, or single browsers will race ahead and potentially fork/define a spec whichthe CSS WG will eventually (grudgingly) ratify. Many features need to be culled from SVG, andFirefox is already on the scent. The evolutionary path here has much risk.
  53. 53. 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© SitePen, Inc. 2009. All Rights Reserved 45Flex/Silverlight represent great short-term choices, and their long-term problem is inbuilding and keeping trust. In large part, this is due to the organizations that have producedthem and the tooling revenue models they are attached to.
  54. 54. The Abiding Sorrow Of Mobile© SitePen, Inc. 2009. All Rights Reserved 46
  55. 55. 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-specific for next several years at the high-end© SitePen, Inc. 2009. All Rights Reserved 47
  56. 56. 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© SitePen, Inc. 2009. All Rights Reserved 48The race for high-performance open web browsers is once again “on”. Given that IE isevolving, there will continue to be huge pressure on the IE team to either support the killerapps which better browsers enable or will be forcibly augmented.
  57. 57. 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© SitePen, Inc. 2009. All Rights Reserved 49
  58. 58. Thank You© SitePen, Inc. 2009. All Rights Reserved 50

×