Large-scale Web Application Development: Client Side. Tancred Lindholm D.Sc. tancred(a.)google.com

Transcription

1 Large-scale Web Application Development: Client Side Tancred Lindholm D.Sc. tancred(a.)google.com

2 Contents Recap: Web Applications The browser as application container Javascript "Garage" vs. industry practices The XHR mechanism for RPC UI aka Application Chrome HTML, CSS Building a better browser

3 Web Application Overview (recap) Here: Web Application = interactive web page that closely resembles a traditional application (UI-wise) Architecture = Client/Server (it's back from the 90s...) Client in user's browser Server in data center Client-Server communication using HTTP Client-side heavily guided -- constrained by W3C stack HTML/XML for structure CSS for styling Javascript for programming Javascript "libraries": XHR, DOM Topic for next week

4 The Web Browser: Past Original purpose: to display and facilitate navigation between linked documents (HTML = text+pictures+hyperlinks)

5 The Web Browser: Present Today: Interactive, dynamic, widgets The browser as application container is rather absurd! Programming in scripting language on top of HTML doc Next to no standard libraries (containers? algorithms?) Remote calls built on client-initiated document requests Display/UI = formatted text document with images Significant differences between implementations Lack of speed (recently improved) No threads App easily requires 4 languages (JS,CSS,HTML,Java) Why? features added as extensions to basic browser in reaction to popular demand no overall plan to become a platform

6 The Browser vs Java (and similar) Sun (among others) recognized the need for a cross-platform application container with on-demand fetch of code = Java JDK 1.0 had a well-defined language, widgets, libraries, reasonably cross-platform... so why are we not browsing Java apps (or Flex or.net)? Good question? Required large plugin download? Startup time? Ugly widgets? My theory: inertia + copycat: seemed easy to add just one more feature to existing pages than to switch gears Everyone else is doing it (without Java) The story about how to boil a frog comes to mind...

7 Javascript in a "real" software project Dynamically typed, weak object support, great for quick glue logic on an HTML form etc. Larger piece of software (>10kloc) Weak typing introduces hard to catch typing errors Lack of decent standard library means reinvent your own Lack of canonical high-level modularization (objects, packages) mean reinvent your own Bad and uneven performance across browsers Different browser behavior = conditional code, much testing, need for wrapper libraries (you need to make) We put our faith in W3C to standardize Public comliance tests + Wall of Fame/Shame (e.g. Acid 2/3 test for CSS)

8 Dynamic typing woes Typical error example var shoppingcartitemslist = ['a1'];... (5000 lines later)...shoppingcartitemlist.append ('b' + 2); One solution: Closure Compiler Parses your JS code an outputs condensed JS code Supports strong typing (-> typing errors found) through special comments preceding a declaration {number} */var itemcount;/** Map of string key to node in the document tree. *@type {Object.<string, Node> */var nodesbyid = {}

9 Dynamic typing woes Open source implementation at com/closure/compiler/ Maybe also something in this direction from standards bodies (ECMAScript) There are a lot of opinions which way to go: JS4 was abandoned

10 Standard Library JS standard library is pretty much DOM = API for manipulating (host) HTML document A handful of string, math, regexp functions No basic data structures etc. The Closure Library Open-source library with fundamental functionality Uniform object paradigm; inheritance etc. Basic data structures Wrappers & helpers for DOM manipulation (eliminating some cross-browser issues) Is any standardization body working on this?!

11 Performance Issues Traditionally interpreted, sluggish performance Google released Chrome with justin-time JS compiler nowadays speed is improving (but old browsers still used) DOM manipulation still a bottleneck JS size & parsing a bottleneck on app startup Closure compiler condenses & removes dead code E.g. rename using shorter names (myvariable -> xg) Source: ZDNET, 2009

12 RPCs How would you design a RPC mechanism? Endpoint identifiers (target of RPC, e.g. DNS name) Over-the-wire data format (method, parameters, results) E.g., Java RMI, IIOP (Corba), SunRPC Web 1.0: browser view updated with server data when page reloaded Web 1.9: Hidden-Iframe-RPC Create a hidden frame (HTML document within master document) Set URL of frame to string encoding the request Wait for frame content to load, content = reply Why do you need a document for an RPC?!

13 The XmlHttpRequest (XHR) for RPC Iframe method a hack that nonetheless widely used Microsoft introduced the XmlHttpRequest object in Javascript Initiate request to URL, wait for response content & status No need for a hidden subdocument Nowadays supported accross browsers What about data encoding? Initially just custom strings, regexps to split on client Nowadays JSON = Javascript Object Notation quite popular JSON data evaluates to a JS data structure...so XMLHttpRequest not really used for XML... Only client can be initiator (no server->browser RPC) Can be emulated with NOP client request "hanging open" Browserchannel in Closure

14 Building an UI with HTML and CSS Purpose of HTML + CSS = logical markup + formatting of text, inlined bitmap images For a GUI framework (e.g. Qt, AWT, Swing) you need A bitmap drawing surface (in browsers? No) 2D/3D graphics functions (No) Text drawing (sort of) Input events (sort of) Building a GUI with HTML + CSS + <img>s rather absurd Screen updates go through HTML parse (optional) and browser page renderer -- very inefficient Lots of hacks like page elements at negative coordinates holding parts of the UI Rarely pixel-precise positioning Good point: UI usually scales/zooms

15 Building a Better Browser Recent JS speed improvements have made a huge difference HTML 5 (being rolled out in new browsers) "Canvas" HTML element + Javascript functions for drawing/bitmaps Client-side persistent storage (JS can store data in browser) Video support without plugins Drag and Drop Web Application APIs being standardized in W3C Web Applications Working Group org/2008/webapps/ Even more goodies: web sockets, web workers (threads) etc.