A Business Case for Ajax with Google Web Toolkit Bruce

A Business Case for Ajax with Google Web Toolkit Bruce Johnson Google Defining our goal • Deliver great products to users • Tons of debate about web technology – JavaScript on the server! Lisp on the client! Ruby everywhere! Browsers suck! Browsers rock! • Yet user happiness never seems to figure in as a primary decision criterion How we’re gonna roll today • • • • Ajax is very buzzword-ish at the moment Easy to get caught up in fads and FUD The only solution: just say no to the noise Think for yourself, question authority – (Especially self-proclaimed authorities) Don’t believe everything you think • • • • We can’t trust ourselves, either Software is part logic and engineering… …and part zealous chest-thumping Decisions are all too often influenced by intellectual bullying, jumping to conclusions, profit motives, expediency, inertia, and fear Example: The slippery slope • • • • • • • We need Web 2.0 features to compete! Where are places we can put some script? Let’s make it really cool and dynamic! Why are our pages so slow to load now? Why don’t fonts resize correctly now? Our users are complaining… Oh, we’ll just optimize it…wait…uh… Working backwards • Let’s start from our goal • No presupposed solution • Let’s take a walk from Z to A – Yell if we mis-step • Deliver great products to users What makes a product great? • We developers can’t assert it • Great: users love using it • Some key attributes: – Easy to learn through experimentation – Powerful enough to reward you for learning it – Users remember extremes, bad and good – It’s easier to remember the bad things What doesn’t make a product great • It has nothing to do with your source code – Elegance, maintainability? Irrelevant – How much fun it is to develop? Irrelevant – Choice of programming languages? Irrelevant • Do you buy a car based on the CAD system used to design it? – If it gets 7 MPG, does the manufacturer say, “But our CAD system makes us efficient!” Exactly who are these users, anyway? • • • • • • • For web apps, lots of things vary… Language, grammar, RTL, character sets, … Cultural norms for icons, colors, … Interaction aids (IMEs, screen readers, …) Hardware/OS (Mac, Windows, Linux, …) RAM and CPU speed (+mobile) Screen resolution (+mobile) Exactly who are these users, anyway? • Things that vary by user, continued… • Network characteristics (dial-up, DSL, cable, satellite, cell, …) • Tolerance for responsiveness, reliability, and UI complexity • Browsers (FF, IE, Safari, WebKit, +mobile)… And then there are the commonalities • • • • Slow apps are annoying Crashy apps are annoying Slow, crashy apps are not worth using Truly great apps should at least know where they stand on all of the above issues – It’s exhausting just thinking about it – Easy to fixate on the aspects you can wrap your head around: staring at code in a vacuum Simplifying principles • The need for applications crosses all borders • You don't need to be at your desk to need access to an application • Minimize usability compromises due to implementation challenges • “Fast is better than slow” is an understatement when switching costs are low The GWT Mission Statement To radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise Ajax for any modern browser Tech prereq: Why a compiler? • Vital to separate the maintainability of the source code from the effectiveness of the executable • Handwritten JavaScript has a conflict of interest – Long, useful identifiers = bigger, slower apps – Nice formatting = bigger, slower apps – Comments = bigger, slower apps • The solution isn’t to try to strike a balance in handwritten JavaScript, it’s to create a level of indirection, so that you compromise neither Example: Type tightening • Eliminating runtime costs of polymorphism Shape s = new Square(2); // side length of 2 int a = s.getArea(); – can become Square s = new Square(2); int a = (s.length * s.length); – which, if the constructor has no side effects, can become int a = 4; • Uses type information across the entire app • Smaller script/faster execution are often complementary, which is really fun Tech prereq: Deferred binding • “No-compromise” means we must use all conceivable optimizations • “Portable” is the opposite of optimized – Must avoid least-common-denominator syndrome – Yet, abstractions are vital to effective development • Solution: GWT deferred binding • Using polymorphism as a permutation axis • Fully optimize each permutation separately Your Code FireFox 1.0.x en_US Download exactly what you need in a single, optimized, can't-go-wrong chunk Your Code IE 6 en_UK … 1D04ADDA.cache.html … Single Java Code Base 15F361BB.cache.html Your Code Safari 2.0.x fr_FR Your Code Opera 9 … 7EFE4D24.cache.html Then cache it on the client until the sun explodes fr_CA … D415D917.cache.html Java implementation in GWT source: class Button { public void setText(String text) { DOM.setInnerText(getElement(), text); }} Safari version: class DOMImpl { public native void setInnerText(Element elem, String text) /*-{ // Remove all children first. while (elem.firstChild) { elem.removeChild(elem.firstChild); } // Add a new text node. if (text != null) { elem.appendChild($doc.createTextNode(text)); } }-*/; } Internet Explorer version: class DOMImplIE6 { public native void setInnerText(Element elem, String text) /*-{ elem.innerText = text || ''; }-*/; } Java call site in GWT source: b.setText(”Click Me!"); Compiled Javascript (Safari): $setInnerText(b.element, 'Click Me!’); Compiled Javascript (IE): b.element.innerText = ’Click Me!'; function $setInnerText(elem, text) { while (elem.firstChild) { elem.removeChild(elem.firstChild); } if (text != null) { elem.appendChild($doc.createTextNode(text)); } } Bottom-line: Faster-than-possible Firefox Typical portable setInnerText() textContent innerText Speedup 2876 ms 2477 Safari 1276 ms 908 918 Opera 2053 ms 1386 1520 IE 4078 ms 2469 14% 29% 32% 39% The need for applications crosses all borders • • • • • • • • Internationalization (i18n) isn’t just strings “Constants” for locale-specific values and settings “Messages” for localized strings with arguments “Localizable” for locale-sensitive algorithms “DateTimeFormat” for parsing/formatting “NumberFormat” for parsing/formatting All client-side, no round-trips (for speed) Statically checkable (for correctness) Messages: Maximally-efficient I18N • Interfaces define type-safe template methods interface ErrorMessages extends Messages { String accessDenied(int errorCode, String username); } • Corresponding localized properties files accessDenied=Error {0}:{1} cannot access {2} • Connected via compile-time code generation Window.alert(msgs.accessDenied(515, user)) • The above wouldn’t compile :-) Messages: The code that executes • Message references get inlined • This Java source String s = msgs.accessDenied(42, user, ftr)) • Compiles into this JavaScript source (per locale) var s = "Error 42:" + user + " cannot access " + ftr • Zero-cost abstractions make I18N easier to use and perfectly affordable at runtime I18N Wrap-up • • • • Good I18N must be infused throughout your app Must be easy enough to be approachable… …and efficient enough to be affordable Coming soon: RTL layout, ARIA accessibility, more keyboard support Onward! You don't need to be at your desk… • This fact alone justifies the choice of web apps vs. locally-installed apps • Lots of other implications of web apps • Direct collaboration – Far better than emailing application data files around – Hard to design apps that support live collaboration – Need MVC-like architecture and good RPC – On the web, you can’t not think about it Additional implications of web apps • Multiple browsers used, even by the same user – Mobile only adds complexity – Mobile is happening • Do you really want to depend on plug-ins? – At the least, apps should gracefully degrade • Speed matters even here – Users need to think of your app as at-the-ready… – Not something with a “high activation energy” Did I mention mobile? Very complicating Screen resolutions Touchscreen vs. not Crazy-different network characteristics Net: Need fast, small code tailored for each device’s form-factor and capabilities • GWT can help here • • • • • Only pay for what you use Reuse without sacrificing efficiency Shared client-side application logic Desktop UI Mobile UI #1 Mobile UI #2 Minimize usability compromises… • Easy to make little concessions to implementation concerns throughout • At a technical level, deferred binding lets you create specializations easily • But the more subtle point is how you design your app in the first place • And, of course, this all costs time and money Minimize usability compromises… History & Back is hard Minimize usability compromises… Don’t refresh ! we’ll charge you twice Usability fundamentals • • • • • • • Focus on the basics Prefer native UI elements Support keyboard-only use Honor font size preferences User in control of browser at all times Speed is vital, especially at startup The ideal: feels like a traditional web app, just better Ask users • • • • User feedback and usability testing are vital You will never get it right the first N times Being able to iterate quickly is key Developers need tools and libraries with lots of leverage Things developers shouldn’t have to worry about early • JavaScript funkiness – spelling bugs – “null” vs. “undefined” vs. “false” vs. “” (empty) – speed • Cross-browser support • Memory leaks • And… Framework-itis Nice abstractions are for later JavaScript => difficulty in refactoring Refactoring difficulty => maintenance worry Maintenance worry => the need to “get it right” from the beginning: framework-itis • But you don’t know what “it” is until you’ve done several iterations of user testing • Worse than wasteful: creates bad inertia • • • • Get residual value from prototype code • User testing implies lots of prototype code • Face it: you’re going to try to reuse it anyway • GWT gives you enough leverage to build real, working prototypes for usability testing – Reduces the distance between “mock” and “real” – Prevents paper features that users love but can’t be implemented in reality • Ability to refactor makes all the difference Modularizing your Ajax code • “Obviously” you factor out JS library scripts – Include only the ones you need using