Single page apps and the web of tomorrow
•Télécharger en tant que PPTX, PDF•
1 j'aime•4,850 vues
Review of the history of web development and trends that indicate where the future of webdev is going. Slides for a talk I gave at BarCamp Saskatoon - please refer to the notes for the actual slide content
Recommandé
Contenu connexe
En vedette
En vedette (14)
Plus de RTigger
Dernier
Dernier (20)
Single page apps and the web of tomorrow
- 1. THE WEB APPS OF TOMORROW! Chad McCallum @ChadEmm www.rtigger.com
- 2. WWW v0.1
- 3. WWW v1.0
- 4. WWW v1.1
- 5. WWW v1.2
- 6. WWW v1.5
- 7. WWW v1.9
- 8. WWW v2.0
- 9. WWW v2.1
- 10. WWW v2.2
- 11. WWW v2.3
- 12. WWW vNext?
- 13. JavaScript MVC
- 14. The Cloud!
- 15. HTML5
- 16. Mobile Web
- 17. The Web Of Tomorrow!
Notes de l'éditeur
- The web started as static documents. Sure, there were links between those static documents, but for all intents and purposes you were essentially playing “choose your own adventure”. But this was still awesome.This is the first page on the internet ever. Created by Tim Berners-Lee while working at CERN.
- Then, we decided that collecting information was a good idea as well. So web forms were created. These let the end users send information back to the server! A huge leap forward!In the worst case scenario, this was sending an email to someone with the form’s contents. In the best case scenario, it was firing up a CGI script, probably perl.As bad as that sounds, this was a huge step forward – all of a sudden we had programmatic access to a database. This meant recording user information, paging through data, user-based content, and so many more things that became the foundation for all web applications as we know them today. This was truly the start of the web application.
- But it still kind of sucked. We used perl! It was basically a shell scripting language with above average string manipulation capabilities, it wasn’t a web language.So then PHP came along (1994). And ASP (1998). And JSP (1999). And so many more to fill the gap in web software development that Perl was temporarily filling.Their main focus was to make generating HTML on the server easier, and a lot of them achieved this using inline code annotations, like PHP’s <? Or ASP’s <%
- All this was well and good, and definitely decreased the time required to push out a proper web application, but it was all on the server side. Until the v4 family of Netscape and IE, where JavaScript really came into its own on the client.Before v4, JavaScript really didn’t do much more than client-side form validation (which was valuable, saved expensive trips to the server), image rollovers (also important, improved the usability of the web), and annoying alert messages (no value at all)With v4, the Document Object Model / Dynamic HTML was introduced. All of a sudden the elements of a web page could be added to, removed, and modified, without requiring a complete page refresh and round trip from the web server back to the client. This was the technology that moved the web from static documents to actual applications… although not yet.
- JavaScript kind of sucked back in the v4 days. While we did have this great new DOM/DHTML technology, we faced two entirely different implementations. As a result it was really time-consuming (read: expensive) to create a true client-side application that worked decently in all major browsers. This, and other reasons, really held back adoption of DOM/DHTML.For the same reasons, a little platform called Flash really started catching on. It was really the only way to provide any sort of experience above image rollovers in a consistent way. Consistency was the key – a dev could make one flash app and be relatively confident that it will perform the same in everyone’s browser, as long as they had flash installed. And who didn’t have flash installed by then?
- Flash really pointed out a serious flaw in web development – a lack of consistency. It did this by simply fixing the problem itself. By providing that consistency on the development and design side, it really showed how powerful web applications could be.But then… enter the javascript library. Libraries like prototype, jquery, mootools, dojo, and more offered the one thing that everyone was looking for: cross-browser interoperability. By removing the need to write browser-checks and “lowest common denominator” code, developers could focus on application features and usability.
- That’s not all thejavascript libraries brought… around the same time that the libraries really started to mature, the browsers released something called the XHttpRequest. Better known as Ajax, most web devs will say this is the single biggest thing to happen to web apps since the web form. The one biggest usability beef with the web – the complete page refresh with every server request – was finally addressed with Ajax.Now web devs and designers could create near-complete app experiences without reminding the end user that they’re on a website. And although each browser’s implementation of ajax was a little different, the libraries that devs were already used to using included cross-browser ajax capabilities. This further cemented javascript’s role in web development, as well as the dependencies on the javascript libraries.
- As a side effect of all this javascript library development, browsers increased their support and performance for client-side development. Things that would’ve been impossible in v4 browsers were now commonplace on the new ajax-enabled web. Browsers stepped up their game by releasing vastly improved javascript engines, DOM debuggers, CSS manipulators, performance monitoring tools, and more.New browsers were released, like FireFox and Chrome, while other browsers like internet explorer, opera, and safari did their best to keep up to the competition.
- Even though we had AJAX, developers were still used to generating HTML on the server, and that’s what a lot of them did. Server-side languages started developing ajax-enabling experiences such as ASP.NET’s UpdatePanel, which really were hacks to try to shoehorn traditional server-side techniques into this new and scary client-side ajax model.Meanwhile, a lot of Model-View-Controller patterns started to take center stage. MVC makes web development better by defining a clear separation of concerns between the model (database), view (HTML), and controller (input/output). Ruby on Rails, CakePHP, ASP.NET MVC, and many other server-side frameworks were created and enhanced to take advantage of this up-and-coming design pattern.
- While all these great things in web development were going on, another use for the web started to emerge – web services. Web services provided a way for organizations to provide access to their data and services using a common communication protocol – HTTP, the web.The great thing about web services was that consumers of the service don’t need to know anything about the platform, object model, or programming language on the server – they just need to know how to HTTP, which almost every major programming language knows how to do.
- So here we are today. There’s a few common themes we can draw from all this history. These include:Cross-platform is key. If a developer has to go out of their way to develop for your platform, either the platform is going to die or the toolset is going to die. This has been demonstrated in several forms, from DHTML adoption, the prevalence of Flash in the early web, and how JavaScript was basically ignored as a serious language until the js libraries came along.Separation of concerns is key. Adoption of the MVC design pattern by almost every major web development platform shows how separating the view logic from the data has improved both the quality of web applications, as well as the speed at which they can be developed.User experience is key. Most of the great new technologies in web development focus around and enable user experience in web applications – flash, ajax, js libraries, browser enhancements.Keeping these things in mind, what can we predict the future holds for the web application? I’ve got a few ideas on that I’d like to share.
- MVC provides great benefit to your codebase, but it still keeps everything on the server. But as web devs we have really powerful browsers at our disposal. So a few smart people asked, “Why are we wasting server CPU cycles on generating HTML when we can make the browser do it?”Enter javascript MVC. Javascript MVC takes all the responsibility of handling the HTML and input/output and puts it on the client, leaving your web server responsible for one of two things – serving static content (html, js, css, media, etc.), and serving data through web services.All the traditional components of web MVC are there – there are template views, routes, ways to handle form submission and input events, and separation of the model from the view logic. The best part is this all happens on the browser; the software who’s primary responsibility is to show and manipulate the document object model.So then your web server is left serving static content, like the template HTML and your application’s javascript, and hosting web services that are responsible for all the create/recall/update/delete operations on your data. And a pleasant side effect of this is you have a web service! Creating a website using javascript MVC means you have an API that you can easily tack a mobile web / native app / desktop app to without having to rewrite any of your backend.
- Another thing to note is hosting-as-a-service platforms that are emerging. There has been a real shift in the last year or two from hosted virtual servers and manually managed LAMP (linux apache mysqlphp) or IIS hosts to “automated” hosting solutions. One of my favorites is Heroku, a cloud-based PAAS platform that basically just asks for your code and deploys it for you. But Heroku isn’t the newest player to the game by any means. Amazon has been in the cloud-hosting space for awhile now, Microsoft’s Azure offerings are becoming much more usable and affordable for the average developer. There are several PAAS services for node.js, asp.net, ruby on rails, and other platforms as well. These services basically remove the need for server maintenance from a developer perspective, allowing devs to just focus on the app instead of the installation of the app.The best thing is these platforms easily scale and perform, based on your application’s requirements, on the fly with little to no input from you, the developer. If your web app suddenly goes viral, in most cases it’s as easy as adjusting a dial to requisition another server to handle the increased load.
- Of course, we can’t talk about web apps without mentioning “HTML5”. Some of the “up and coming” features of this platform will really take web apps to the next level, once browsers can decide on a standard way of implementing them.Key features of HTML5 that will take apps to the next level include web workers (a way of running async processes on the browser), canvas (a GPU-powered blank slate, used by many online games), local storage (a way for apps to store data locally in better ways than cookies ever provided), geolocation (figuring out where the user currently is on earth to provide location-based services), and web sockets (socket-based communication after a web page has loaded)While a few of these things are still a little flakey in some browsers, the best part is the community has created “polyfills” for most of them – ways to substitute browser functionality with javascript plugins, flash, or other tools to get the same functionality with the same API. Once the browsers finally decide on a standard, you can simply remove the polyfill (or not, it will automatically use the browser) and not have to rewrite your code (for the most part)
- And of course, mobile web. With the proliferation of smartphones with web browsing capabilities, it has become increasingly important to customize web applications to be “mobile-friendly”. Luckily, a lot of frameworks and tools have stepped in to fill this gap.To start with, CSS and HTML themselves have come along way with media queries and mobile specific web elements. I have to say once the mobile web browser took off, that’s possibly the fastest I’ve ever seen something become standard in CSS or HTML. You can use things like media queries to style your web app a specific way based on mobile format or layout, insert HTML meta elements to control how a mobile browser will interact with the page, and create mobile-friendly form elements to easy data entry from a virtual keyboard.On top of that, as mobile browsers have become more advanced, so have javascript frameworks to take advantage of them. Libraries like jQuery Mobile, Titanium, PhoneGap, and Sencha Touch provide mobile web app developers ways to create cross-device consistent apps and also a way to interact with the hardware as well.
- In conclusion, there’s a lot of exciting things going on in the web app space, and it’s not going to slow down anytime soon. With new tools focused around making app development and deployment easier, and new functionality to improve the user experience of web apps.