Ajaxworld March 2008 - Jeff Haynie Keynote - Appcelerator

15,717 views
11,216 views

Published on

This was my opening keynote presentation for Ajaxworld March 2008 in NYC.

Published in: Economy & Finance, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,717
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
111
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Ajaxworld March 2008 - Jeff Haynie Keynote - Appcelerator

  1. AJAX WORLD March 2008
  2. Jeff Haynie Co-founder & CEO [email_address] blog.jeffhaynie.us twitter.com/jhaynie linkedin.com/in/jhaynie
  3. how did we get here?
  4. 1991
  5. Dave Litwack Mitchell Kertzman
  6. Powersoft
  7. Powerbuilder
  8. client / server
  9. proprietary
  10. rapid app dev
  11. database integration
  12. $5.2M (6 months from 1.0)
  13. Profitable: year one
  14. IPO Feb. 1993 (~3 years)
  15. $57M 1993
  16. suits came knocking
  17.  
  18. $900M - 1995
  19. Oops (sybase fabricated sales figures)
  20. revolutionized the way we built apps
  21. focus on the app (and ultimately, our business requirements)
  22.  
  23. 1991
  24. Comdex (Atlanta)
  25.  
  26.  
  27. client / server
  28. easy to build apps
  29. event driven
  30. integration to DB
  31. last release: 1996 (vb6)
  32.  
  33. March 31, 2005 (extended to March 2008 - better hurry up and replace)
  34. focus on the app
  35. 2-tier architecture
  36. client = application
  37. <ul><li>rapid app creation </li></ul>
  38. <ul><li>productivity </li></ul>
  39. <ul><li>ease of use </li></ul>
  40. distribution
  41. security
  42. programming model
  43. client/server was proliferating, something else was happening
  44. 1989
  45.  
  46. tim berners-lee
  47. CERN (europe)
  48. world wide web
  49. www
  50. web
  51. hyper text transfer protocol
  52. http
  53. http://www.example.com (if you don’t know this you’re in the wrong presentation)
  54. directory (browsing)
  55. sharing content (research)
  56. primary display was text
  57. network of connected computers
  58. killer app = information
  59. 1992
  60.  
  61. marc andreessen
  62. student at univ of illinois
  63. mosaic “web browser”
  64.  
  65.  
  66. 1994
  67.  
  68. Mosaic Communications Corporation
  69. Netscape Communications
  70. Netscape Communicator
  71.  
  72. IPO 1995
  73. browser wars (1995)
  74. massive adoption
  75. web sites were slow internet was slow
  76. almost all initial web sites were content-based
  77. the “web” initially competed with consumer info services like AOL, Compuserve and Prodigy
  78. primarily still web content you “browsed”
  79.  
  80. distributed free (brilliant and bold move)
  81. bundled win95 (plus! pack)
  82. (isn’t it great being a monopoly?)
  83. based on spyglass mosaic (remember Netscape?)
  84. MASSIVE ADOPTION
  85. January 1998
  86. mozilla open source
  87. (kick butt release party)
  88.  
  89. microsoft had 2 primary killer advantages:
  90. Operating System platform
  91. Developer Community
  92. May 1998
  93. DOJ ruled MSFT violated anti-trust
  94. (too late, game was pretty much over)
  95. November 1998
  96. $4.2 BILLION
  97.  
  98. web browser changed the way we think about apps
  99. distribution of apps
  100. programming model
  101. development of software
  102. web 1.0
  103. three-tier architecture
  104. server is the brain
  105. client is for display (doesn’t that sound like the mainframe architecture?)
  106. the way we built apps changed based on “the web”
  107. common gateway interface (CGI)
  108. netscape API (nsapi)
  109. web servers
  110. app servers
  111. database servers
  112. caching servers
  113. web pages
  114. web apps
  115. massive new way of thinking about the web and apps (a lot was fueled by dot.com bubble)
  116. 1995
  117.  
  118. James Gosling
  119.  
  120. Java
  121. Write once, Run anywhere
  122. Browser
  123. Applets
  124. Java Web Start (some years later after applets failed)
  125. slow
  126. big
  127. UI differences
  128. web app?
  129. native app? (sure didn’t look like one)
  130. programming model
  131. browser plugin
  132. java language was great!
  133. but … apparent java would not be deployed in browser environment
  134. java did change the way we built web sites (and it still continues today)
  135. why the web?
  136. web programming model
  137. distributed
  138. easy to program
  139. UI simple to layout
  140. cross-browser differences
  141. open source emerging rapidly with Internet
  142. standards-based
  143. 1994
  144.  
  145. tim berners-lee (remember, he created the web?)
  146. preserve, promote web standards
  147. “ ensure compatibility among vendors”
  148. (are we there yet?)
  149. HTML
  150. CSS
  151. XML
  152. DOM
  153. CGI
  154. VoiceXML / CCXML
  155. (too many more to list)
  156. HTML 1.0 – 1993 (IETF WD)
  157. HTML 2.0 – 1995 (IETF RFC)
  158. HTML 3.0/3.2 (W3C)
  159. HTML 4.0 (1997)
  160. (XHTML came along the way)
  161. HTML 5.0 (Jan 2008 - WD) 11 years!
  162. Client-side data storage
  163. video
  164. cross document messaging
  165. remoting
  166. (continuing to expand idea of what a web app is)
  167. XHTML or HTML?
  168. most innovation has been on the server
  169. servlets
  170. JSP pages
  171. ASP pages
  172. tag libaries
  173. PHP pages
  174. (and lots of embedded sql)
  175. cold fusion (so many other great server-side web frameworks)
  176. server-driven UI
  177. model-view-controller (MVC)
  178. (server-assisted MVC)
  179. server generates UI
  180. UI is a template page
  181. same HTML (almost always)
  182. not very environmentally friendly 
  183. age of server-side infrastructure
  184. application servers
  185. “ middleware”
  186. new app complexities on the server side
  187. cache business objects
  188. cache page templates
  189. cache SQL queries
  190. session state
  191. stored application state
  192. (we used to call it application state)
  193. session clustering
  194. sticky sessions (optimize load balancing)
  195. clustering not linear
  196. middleware wars
  197. hundreds of app servers
  198. lots of server-side frameworks
  199. lots of big companies rolled their own initially
  200. IBM
  201. Sun
  202. BEA (weblogic)
  203. organized around J2EE specification
  204. community-based (Sun JCP)
  205. heavy weight
  206. overly complex
  207. too many specs to keep up with
  208. widely adopted
  209. clustering
  210. fail-over
  211. high-availability
  212. Microsoft .NET
  213. wasn’t J2EE (not necessarily a bad thing)
  214. wasn’t even java (of course not)
  215. 2000 – Microsoft C# (feels a lot like Java)
  216. part of Microsoft .NET
  217. web-programming model
  218. (for Microsoft platform)
  219. 1999
  220.  
  221. (not flavor flav)
  222.  
  223. (marc fleury)
  224. JBoss
  225. Java application server (and eventually J2EE)
  226. FREE! (well, almost)
  227. open source
  228. J2EE programming model (and it almost made J2EE fun)
  229. 2001 (JBoss, LLC)
  230. innovation primarily driven by server-side infrastructure
  231. apps not much different (1999)
  232. server-assisted MVC
  233. service oriented architecture
  234. middleware = SOA
  235. service federations
  236. distributed registries
  237. service composition
  238. service orchestration
  239. portals
  240. ESB
  241. $60B Market (at least they say it was)
  242. But business applications still function the same
  243. Jesse James Garrett “AJAX” 2005
  244. Microsoft & Netscape
  245. early inter-applet techniques
  246. applets to slow to start
  247. IE5 – MSFT created XHR
  248. Microsoft Outlook Web (Microsoft was innovating!)
  249. Web 1.5
  250. MVC + Ajax
  251. round peg square hole
  252. page driven paradigm with async behavior
  253. look Ma – no page refresh
  254. cool, but. . .
  255. it’s only “pimp my web 1.0”
  256.  
  257. but lots of startups and innovative web companies thinking big
  258. web 2.0
  259. starting to think about apps again
  260. networks are faster
  261. hardware is cheap
  262. software is moving to open source
  263. and everyone is wired and on the web
  264. user experience
  265.  
  266.  
  267. richer apps
  268. dynamic info
  269. web is the platform
  270.  
  271.  
  272.  
  273. (you can do that?)
  274.  
  275.  
  276.  
  277. (my enterprise apps need that)
  278. (but, how?)
  279. <ul><li>different solutions </li></ul>(we’re innovating again)
  280. different approaches (and some feel like déjà vu)
  281. Sun doing something similar as before (as best we can tell)
  282.  
  283. (yawn…)
  284. MSFT doing something similar as before (it’s great being on top)
  285.  
  286. (surprise!)
  287. Adobe has an innovative approach that leverages Flash
  288.  
  289. wonderful product
  290. open source (kind of)
  291. “ Web 2.0” is overloaded
  292. Web 2.0 = rich client
  293. rich client = client programming
  294. rich client != UI code in server
  295. okay, but how?
  296. Javascript
  297. (and lots of it)
  298. simple login form example
  299. <html> <head> <title>Simple Ajax Login Example</title> <script language=&quot;Javascript&quot;> function xmlhttpPost(strURL) { var xmlHttpReq = false; var self = this; // Mozilla/Safari if (window.XMLHttpRequest) { self.xmlHttpReq = new XMLHttpRequest(); } // IE else if (window.ActiveXObject) { self.xmlHttpReq = new ActiveXObject(&quot;Microsoft.XMLHTTP&quot;); } self.xmlHttpReq.open('POST', strURL, true); self.xmlHttpReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); self.xmlHttpReq.onreadystatechange = function() { if (self.xmlHttpReq.readyState == 4) { updatepage(self.xmlHttpReq.responseText); } } self.xmlHttpReq.send(getquerystring()); } function getquerystring() { var form = document.forms['f1']; var username = form.username.value; var password = form.password.value; qstr = ‘username=' + escape(username) + ‘&password=‘ + password; return qstr; } function updatepage(str){ document.getElementById(&quot;result&quot;).innerHTML = str; } </script> </head> <body> <form name=&quot;f1&quot;> <p>username: </p> <input name=”username&quot; type=&quot;text”/> <p>password: </p> <input name=”password&quot; type=&quot;text”/> <input value=”login&quot; type=&quot;button&quot; onclick='JavaScript:xmlhttpPost(&quot;/cgi-bin/simple-ajax-example.cgi&quot;)'></p> <div id=&quot;result&quot;></div> </form> </body> </html>
  300. (Yikes!!!)
  301. 25+ lines of Javascript
  302. for one simple login form
  303. rich client = mountains of JS?
  304. mountains of JS = nightmare
  305. (crap. now what?)
  306. open standards + open source (to the rescue)
  307. Javascript libraries
  308. and lots of them
  309. <ul><li>widget libraries </li></ul>
  310. <ul><li>Ajax libraries </li></ul>
  311. <ul><li>effect libraries </li></ul>
  312. (here’s just a few)
  313. Prototype
  314. Scriptaculous
  315. JQuery
  316. Dojo
  317. ExtJS
  318. Yahoo YUI
  319. Mootools
  320. Open Rico
  321. Qooxdoo
  322. MochiKit
  323. Lightbox
  324. Greybox
  325. Lightbox Plus
  326. Nifty Corners
  327. (okay to breathe)
  328. (you get the point)
  329. all great libraries!
  330. how do I keep up with them all?
  331. multiple versions, bug fixes
  332. integration issues, glue code namespace issues
  333. (but I thought that was the platform vendor’s job!)
  334. with chaos comes opportunity
  335. <ul><li>open standards </li></ul>
  336. <ul><li>open source (the entire bits) </li></ul>
  337. <ul><li>open developer community </li></ul>
  338. <ul><li>integrated RIA programming model (HTML, CSS and Javascript) </li></ul>
  339. what does that mean?
  340. well, what does an RIA programmer do?
  341. event handling, Ajax, DHTML
  342. (Got it!)
  343. login form revisited
  344. <html> <head> <title>Hello World 2.0</title> <script src=&quot;javascripts/appcelerator.js&quot; type=&quot;text/javascript&quot;></script> </head> <body> <div on=“r:login.request then show or r:login.response then hide” style=“display:none”> <img src=“images/indicator.gif” /> processing login… </div> Username: <input type=“text id=“username” fieldset=“login”/> Password: <input type=“password id=“password fieldset=“login”/> <input type=“button” value=“login” fieldset=“login” on=“click then r:login.request” /> </body> </html>
  345. on=“r:login.request then show”
  346. (what is that?)
  347. event handling + Ajax + DHTML one simple expression language
  348. it’s an integrated RIA programming model
  349. that leverages standards (like HTML, CSS and Javascript)
  350. it codes Javascript so you don’t have to
  351. (Web Expression Language)
  352. cool, but what about widgets?
  353. (good question)
  354. <ul><li>I want to be able to create new widgets </li></ul>
  355. <ul><li>leverage all of the great existing widgets </li></ul>
  356. <ul><li>I want one single integrated way to use them ALL </li></ul>
  357.  
  358. how about this:
  359. <!– ExtJS Grid --> <app:ext_grid on=&quot;l:show.user.response then execute&quot; property=&quot;rows&quot; width=&quot;390&quot; title=”Users”> <column property=”first” >First Name</column> <column property=”last”>Last Name</column> <column property=”phone”>Phone</column> </app:ext_grid> <!– Yahoo Calendar --> <app:calendar on=&quot;l:show.calendar then execute&quot; title=”My Calendar&quot; inputId=”date”> </app:calendar> <input type=“text” id=“date”/> <img src=“images/calendar.png” on=“click then l:show.calendar”/>
  360. ExtJS and YUI in one widget framework?
  361. (yes, and any others you want)
  362. including Flex widgets!
  363. (and you can easily create your own)
  364.  
  365. okay, calm down Sally
  366. let’s recap
  367. Web Expression Language + Unified Widget Framework + Open Standards + Open Source =
  368. fully integrated RIA platform
  369.  
  370. RIA is good but what about my services?
  371. (and that $60B investment in SOA?)
  372. you want to mix your RIA with your SOA
  373. RIA + SOA
  374. full decoupling of the rich client from its services
  375. they share only one thing
  376. a lightweight message contract (aren’t they services?)
  377. (need a picture?)
  378. Rich Client Service r:login.request {‘username’:’joe’, ‘password’:’****’} r:login.response {‘success’:true}
  379. Contract = message name
  380. login.request and login.response
  381. plus input and output data
  382. (that’s it!)
  383. if the contract is message-based
  384. why does the service programming language matter?
  385. good question.
  386. (it doesn’t)
  387. with a message-based contract you can create services in any programming language!
  388. we call these SOA Integration Points
  389. and we have them for Java, Ruby, PHP, .NET, Python and Perl
  390. how does that work?
  391. let’s look at Java
  392. take a plain Java object (POJO)
  393. and add a single annotation
  394. @Service(request = ”my.request&quot;, response = ”my.response&quot;)
  395. to a Java method – like so:
  396. package org.appcelerator.service; import org.appcelerator.annotation.Service; import org.appcelerator.messaging.Message; public class MyService { @Service(request = ”my.request&quot;, response = ”my.response&quot;) protected void myRequest(Message request, Message response) throws Exception { // service logic here } }
  397. (that’s it!) really….
  398. each SOA Integration Point
  399. <ul><li>service routing </li></ul>
  400. <ul><li>data marshalling </li></ul>
  401. (what does that mean?)
  402. it means you can place a native object or array of objects into the response
  403. and we’ll take care of the rest.
  404. the result is:
  405. you focus on what you do best: BUILD APPLICATIONS!
  406. instead of playing the role of platform vendor
  407. that’s our job!
  408.  
  409. we are the RIA + SOA company
  410. RIA + SOA – that’s good but what about prototyping?
  411. (glad you asked)
  412. remember our message-based contract?
  413. it enables location independence for services
  414. meaning mock services can reside in the RIA
  415. meaning you can build fully functional RIA prototypes
  416. without a single line of service code (or even web server)
  417. with 100% reusability!
  418. we call them Interactive Use Cases
  419. build your application while you build your requirements
  420. no more server-focused development
  421. no more 100-page requirements documents (that never matches the end application)
  422. it’s technology-enabled Agile development
  423. <ul><li>quick iterations </li></ul>
  424. <ul><li>fully functional (at every point) </li></ul>
  425. <ul><li>makes it easy to gather feedback from key stakeholders </li></ul>
  426. product managers
  427. service developers
  428. documentation team
  429. QA
  430. sales team
  431. and even customers
  432. after incorporating feedback
  433. you have two key deliverables:
  434. <ul><li>fully functional RIA prototype (100% reusable) </li></ul>
  435. 2. fully defined message contracts
  436. (makes service development and integration a snap)
  437.  
  438. fully integrated RIA+SOA platform
  439. an entirely new and better way to build the next generation of web applications
  440. help us build the best RIA+SOA open source developer community www.appcelerator.org
  441.  

×