1 / 30

An Idiosyncratic History of Web-Page Generation

This article explores the history of web page generation, from the early days of HTML to the introduction of scripting, stylesheets, applets, and finally AJAX. It discusses the key features and downsides of each generation and looks at the future of web page development.

martinjoseph
Download Presentation

An Idiosyncratic History of Web-Page Generation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Idiosyncratic History of Web-Page Generation Denise Draper Dev Manager Webdata XML Microsoft

  2. Outline • First generation: scripting and stylesheets • Second generation: DHTML and Applets • Third generation(?): AJAX • Where next?

  3. In the beginning was HTML • Beginnings around 1990, derived from SGML • <HTML> <TITLE> A sample HTML instance </TITLE> <H1> An Example of Structure </H1> Here's a typical paragraph. <P> <UL> <LI> Item one has an <A HREF="http://info.cern.ch/..."> anchor </A> <LI> Here's item two. </UL></HTML>

  4. In the beginning was HTML • Key features: • Easier than SGML to parse and render • Open format: run on any HW & OS • Text base made editing easy • HTTP for linking • Downsides: • Hard to find stuff… Yahoo to the rescue • Pages are static: no interactivity

  5. Which quickly begat scripting • Server-side scripting was first: • CGI scripts • Forms in HTML passed parameters via URL query notation • Many languages used, especially Perl • Example: http://www.census.gov/cgi-bin/gazetteer

  6. Which quickly begat scripting • Key features: • Parameters made it possible to generate custom web pages • Downsides: • Downloading the same boilerplate for all pages started to get annoying.

  7. And Stylesheets • Originally designed to simplify web pages by separating content from style • Separation of stylesheets allowed controlling common formatting for a whole web site • The use of display=none was used as a way to separate content from control

  8. Mimeviewer: a side-bar in history • Stylesheets taken to the limit: • Stylesheet as a transformation program (XSL) • Content is sent as XML • Still used in some places, e.g. for localization

  9. Checkpoint: what’s what click=HTTP request url+params HTTP Response=HTML Browser: Renders HTML pages Understands stylesheets User experience: Click = page load some pages customized Server: Serves static HTML pages or creates w/ CGI scripts (Approx 1995, Netscape 3, IE 3)

  10. Wouldn’t it be cool if • The page could really be a tiny program that ran on the client? • Java applets • Microsoft ActiveX controls • The page could be updated in place to change it’s content? • Mimeviewer + Data Islands • DHTML = HTML 4.0/CSS + javascript • … And thus we have Netscape/IE 4

  11. Java Applets: run code in the browser • <APPLET> tag introduces applet content • Applet • Runs in its own sandboxed process • Keeps its own state • Has full rendering capabilities • Is fully interactive (responds to events and can generate its own behavior)

  12. Applet Example

  13. ActiveX • Same idea, but: • Windows specific • Uses components installed in OS • Execution not sandboxed • …thus both powerful and the source of many security concerns

  14. Applets/ActiveX • Key features: • Arbitrary code (java or windows) • Complete interactivity • Downsides: • Slow to download • Have to write code • Programming model tricky (especially state management)

  15. DHTML keeps the focus on HTML • The D stands for dynamic, which really means self-modifying • In memory representation (DOM) of page • Individual elements can be identified by id: <p id="intro">… • DOM is modified by client-side scripts <script language="JavaScript"> document.getElementbyID("intro").color=red </script> • Scripts are triggered by events • Page is re-rendered as it changes

  16. DHTML Example

  17. DHTML • Key features: • Modify parts of pages without reload • Downsides: • Slow • Programming model tricky (mixing server & client-side scripting) • Hard to make it look good

  18. Advanced demo: OWA

  19. Checkpoint: what’s what mouse action etc=event HTTP request post Response=HTML or download Browser: Renders HTML pages; Understands stylesheets; Provides execution context for code; Presents drawing surface for code; Manages in-memory DOM for pages; Provides event management User experience: Local interactivity; Some pages “page-like” (DHTML) Some pages or regions completely “rich client”; Slow download times Server: Serves/creates HTML pages containing client-side script; Serves applets or activeX (Approx 1997, Netscape 4, IE 4)

  20. Then nothing happened for awhile • Continuing innovation 1991-1997 • Relative calm 1998-2003 • In fact, lots of cool ideas fell by the wayside • Why?

  21. Why? • Not enough bandwidth • New technologies not broadly supported; web designers went for least common denominator • Change of focus • Push technologies “channels” (sorta like RSS), died • Then Web services, J2EE, .NET and the .com boom/bubble

  22. Then came AJAX • Asynchronous Javascript and XML • Mostly just putting the pieces together: • Client-side script or code running in thread • Manipulating the DHTML DOM • And using HTTP request to get bits of data to feed into page • Asynchronously: don’t wait for response • Google Suggest the quintessential example: http://www.google.com/webhp?complete=1&hl=en This is the key point!

  23. AJAX Example

  24. Checkpoint: what’s what mouse action etc=event HTTP request post Response=HTML or download No Changes (Approx 2004)

  25. Why now? • Well somebody gave it a name… • Seriously: • Critical capability (XMLHTTPRequest) supported by all major browsers • Everybody has broadband • Web services re-applied to browser applications

  26. So what’s next? • Factors: • Rich media everywhere • Devices everywhere • Shared data “in the cloud” • In the home: personalization, sharing • In enterprise: manpower the dominant cost

  27. What’s next? • Blur the line between rich client and web client • Interaction models: indistinguishable • Deployment model: indistinguishable? • If the cloud is the master, and your device simply caches some stuff… • Applies both to bits (the executable) and state (your data) • Microsoft projects: Avalon

  28. So what’s next? • Creating the client application • Code is still too complicated • State management, multi-threading • Systems like Ruby on Rails make lots of built in assumptions to simplify development • Many form factors • Separating data from presentation (again) • web services for data • personalized & device-dependent styles • Support for development and debugging

  29. Credits + References • Derek Denny-Brown • Saw lots of history in Microsoft • Useful web pages for history: • http://www.livinginternet.com/ • http://www.dejavu.org/ • Useful web pages for AJAX • http://en.wikipedia.org/wiki/AJAX • http://www.xml.com/pub/a/2005/02/09/xml-http-request.html • Tutorial (JSP): http://www-128.ibm.com/developerworks/edu/wa-dw-wa-ajax-i.html?S_TACT=105AGX59&S_CMP=HP&dgr-lnxw09AJAXapps

  30. The End Questions?

More Related