Makers of the Web
Download as KEY, PDF1 like3,326 views
The document discusses the history and evolution of web technologies. It notes that the web is still young, and that early technologies like Perl, C/C++, and TCL/Tk were used to build the first websites and applications. It emphasizes that users only care if websites work well, not which specific technologies were used. The document also outlines how web technologies are organized in layers and standards like HTML, CSS, JSON, Atom and RSS have enabled interoperability across the layers.
Makers of the Web
- 1. MAKERS OF THE WEB
- 2. MAKERS OF THE WEB #webnotwar
- 4. THE WEB IS STILL A CHILD
- 12. <blink></blink>
- 14. Page
- 15. Markup Page Content
- 18. WE BUILD
- 19. OTHERS CONSUME
- 30. Users don’t care what technologies were used to build the applications they love.
- 31. They only care that it works. And that it works well.
- 32. PRAGMATISM
- 33. Or, the often overlooked fact that your users don’t care.
- 42. Technology moves fast. Especially on the web.
- 57. LAYERS Operating System Persistent Storage Webserver Browser
- 58. LAYERS OS OS OS DB1 DB2 DB3 Webserver Webserver Browser
- 59. LAYERS OS OS OS DB DB DB OS OS OS OS OS Web Web Web Web Web OS OS OS OS Proxy Proxy Proxy Proxy Desktop Browsers Mobile Browsers
- 60. LAYERS OS OS OS DB DB DB OS OS OS OS OS Web Web Web Web Web OS OS OS OS Proxy Proxy Proxy Proxy Desktop Browsers Mobile Browsers
- 61. OPEN STANDARDS
- 62. OPEN STANDARDS HTML
- 63. OPEN STANDARDS HTML CSS
- 64. OPEN STANDARDS HTML CSS JSON
- 65. OPEN STANDARDS HTML CSS JSON Atom
- 66. OPEN STANDARDS HTML CSS JSON Atom RSS
- 67. OPEN STANDARDS HTML CSS JSON Atom RSS WSDL
- 71. Interoperability is not a feature. It’s a requirement.
- 73. PHOTO CREDITS Arduino LCD chipset: http://www.flickr.com/photos/spikenzie/ Compact Muon Solenoid, LHC: http://www.flickr.com/photos/muriel_vd Leatherman Fuse: http://www.flickr.com/photos/origomi Evil Java: http://www.coderjournal.com/2007/05/java-for-evil-masterminds/ Printing Press: http://www.flickr.com/photos/kokjebalder Checkmark: http://en.wikipedia.org/wiki/File:Checkmark.png All language/browser/framework logos are copyright of their respective owners. All photographs used in this presentation are licensed under the Creative Commons or in the public domain.
Editor's Notes
- #2: As developers, we possess the ability to shape and make the web of tomorrow. While the role of 'web developer' is relatively new in the grand scheme of things, the infancy of our profession has not hindered the rapid pace of development. In a short amount of time we have created languages, tools and methodologies that have allowed us to develop ever increasingly complex applications used by hundreds of millions of people around the world. These tools, however, are only building blocks towards a goal that all developers share: to make the web a more informative, interactive and useful place. Now more than ever, the interoperability between various application and data layers is of utmost importance, and increasingly more effort is being put forth in this endeavour by individuals and corporations alike, including Microsoft.
- #3: The web is still a child. No matter how much ajax, html5 or other buzzwords you throw around, we're still not very sure about what it is we're doing, and what goals we're trying to attain. In the late nineties we were poking around in the dark, getting a feel for what this new 'web' could do. Now, we've got a little flashlight that helps us navigate, but we still don't see the big picture. But we're getting there.
- #4: The tools of our trade have evolved.
- #6: We've come a long way from tiny Perl and C/C++ CGI scripts for counting page views and providing an in-page guestbook, and times where the only 'dynamic' part of a web site (because the term 'web application' didn't really apply) was the overzealous use of the <blink> tag
- #7: We've come a long way from tiny Perl and C/C++ CGI scripts for counting page views and providing an in-page guestbook, and times where the only 'dynamic' part of a web site (because the term 'web application' didn't really apply) was the overzealous use of the <blink> tag
- #8: We've come a long way from tiny Perl and C/C++ CGI scripts for counting page views and providing an in-page guestbook, and times where the only 'dynamic' part of a web site (because the term 'web application' didn't really apply) was the overzealous use of the <blink> tag
- #10: We learned that it was best to separate design and layout from markup and content
- #11: We learned that it was best to separate design and layout from markup and content
- #13: We learned that Java Applets were a neat trick. And then we learned that we needed some new and colourful curse words for sites that had these applets.
- #14: But, no matter how advanced (or simplistic) our tools become, we need to remember one vital fact: The web that we build is one that is made to be consumed by others. We might be the _makers_ of the web, but we are not it's target audience.
- #16: We didn't build Flickr,
- #17: or Facebook,
- #18: or LinkedIn, for people like you and I - we built them for people who don't know the difference between HTML and CSS. And that's not a bad thing.
- #19: Think of all the non-web-based media that you and I consume on a daily basis: should we know _how_ a liquid crystal display works in order to enjoy our favourite TV show?
- #20: Should I need to know the fundamentals of offset lithography in order to read the newspaper? The answers to these questions are, of course, categorically no.
- #21: As a direct corollary to this, we can conclude that the end users of the web don't care at all about the tools that were used to build the applications they love. And why should they? The end-user (our target audience), experiences the end product of our labours - the rendered content and the interactive features that our Javascript and/or Flash chops are able to produce.
- #22: They don't care how it's done; hand-coded Javascript, MooTools, HAML, PHP, Ruby, C#, it's all the same (and it's all gibberish) to them. The 'average' web user is, in fact, the most pragmatic person you will ever meet: they don't care _how_ it works, they only care that it _works_ and that it _works _well_.
- #23: And because of that, we web developers have a hard job. A really hard job. A job that requires us to dedicate hours of time each week just to discover and learn about the technologies and techniques that were developed the week prior. With this ever-changing landscape of tools and tech, we as a profession have grown to not only expect, but to _require_ interoperability between the various layers that make up today's web applications. This allows us to select the best tool for the job at hand, regardless of our choice of platform or operating system.
- #29: Some examples of how users shouldn&#x2019;t care: browsers. Gone are the days where we would use tags like &#x2018;Best viewed in Netscape 4.1&#x2019;
- #30: End users have plethora of browsers at our disposal - Firefox,
- #31: Safari,
- #32: Internet Explorer
- #33: Chrome - many of which run on several operating systems.
- #34: We also have runtimes like Silverlight
- #35: and Adobe Air, which allow us to develop desktop applications using the web technologies we are familiar with.
- #36: If we go down a layer, we have the various Javascript frameworks that abstract away the common functionality needed for highly interactive, rich applications - jQuery, MooTools, YUI, Dojo make our lives as developers easier by providing a consistent and fluid API for interoperating with the various browsers' idiosyncrasies.
- #37: If we go down a layer, we have the various Javascript frameworks that abstract away the common functionality needed for highly interactive, rich applications - jQuery, MooTools, YUI, Dojo make our lives as developers easier by providing a consistent and fluid API for interoperating with the various browsers' idiosyncrasies.
- #38: If we go down a layer, we have the various Javascript frameworks that abstract away the common functionality needed for highly interactive, rich applications - jQuery, MooTools, YUI, Dojo make our lives as developers easier by providing a consistent and fluid API for interoperating with the various browsers' idiosyncrasies.
- #39: If we go down a layer, we have the various Javascript frameworks that abstract away the common functionality needed for highly interactive, rich applications - jQuery, MooTools, YUI, Dojo make our lives as developers easier by providing a consistent and fluid API for interoperating with the various browsers' idiosyncrasies.
- #40: The web pages that get served to the browsers are generated by a webserver - Apache, IIS, nginx, lighty, mongrel, etc., all of which attempt to adhere to a common standard for processing HTTP requests. Going further, we then have our choice of languages for the application middle-tier: PHP, Ruby, Python, C#, Java, SmallTalk, Erlang, Clojure... a virtual cornucopia of choice. And the meat of most web applications, the persistent storage, is no different - there are more relational databases, cloud-based storage solutions, map/reduce clusters, document stores, column stores and XML (sadly) persistent storage engines out there than any one person could ever hope to understand them all.
- #43: And the real crazy part of all this: I can use them all. Actually, not only can I use all of the above technologies for my application, but for the most part I can mix and match to my heart's desire. PHP over IIS with jQuery for some snazzy visual effects on the front-end and CouchDB as my persistent document store? Check. Ruby with Apache as the webserver, Cassandra as my column store and Dojo for my online store? Check. Gone are the days where software was written to work on one specific hardware specification. Platform and technology agnosticism is the new black, and I think it's here to stay.
- #44: And a lot of that is due to open, public specifications and standards.
- #45: And a lot of that is due to open, public specifications and standards.
- #46: And a lot of that is due to open, public specifications and standards.
- #47: And a lot of that is due to open, public specifications and standards.
- #48: And a lot of that is due to open, public specifications and standards.
- #49: And a lot of that is due to open, public specifications and standards.
- #52: Interoperability is no longer a 'feature' - it's a necessity. It's a real wonder any of us got into this profession at all - long hours, difficult clients, apathetic end-users, not to mention the endless shift and movement of the underlying technologies that we make our living using and developing.