The Browser and the Future of Applications

The browser is not just a way to view content, but a platform for applications beyond the way it is used today.

Transcript

1. The Browser and the Future of Applications Cymen Vig 8th Light
2. overview • terminology • why • past • present - rise of browser as a platform • web applications • future • a small demo (+ heckle at will, seriously)
3. terminology • website • application • web application • latency and responsive user interfaces (later)
4. why • cost of application development • deployment of traditional desktop applications • support • expectations of a traditional desktop application user
5. why not • JavaScript is hard • complex process to assemble many HTML/CSS/JS pieces • difficult to work with for designers & programmers • rapid changing landscape in terms of new approaches and libraries/frameworks
6. past • custom internal terminal/GUI applications • client-server • responsiveness • correctness - what happens when there is a bug? • profit - how are applications sold?
7. past cycle • write software • create release • ship it to packaging company (box, floppies, CD) • ship it to store • provide support for installation problems • ship floppy/CD for upgrade/fixes or repeat for v2
8. present • progressive enhancement and fragmentation • not quite an application but web-based • terminal/GUI applications? mobile applications? • web applications - GMail, Google Docs, internal • slow user interfaces • correctness - what happens when there is a bug?
9. present cycle • write software • create release • sell on app store/website • no box/media • downloadable upgrades and fixes • still need to provide installation support
10. browser as a platform • saying no to progressive enhancement • simple server - no views on server • simple data format (JSON, etc) • expectations and latency • compiling to JavaScript
11. web applications • horizon — if it isn’t here already, it’s coming • latency • expectations • correctness • profit • clean code/implementation
12. website vs web application • with website, server does almost everything • with web application, client handles almost everything but uses server for state via defined API • website synchronous, web application async • apply Uncle Bob’s canon on separating application from database and screaming/clean architecture to separating client implementation from server
13. web application cycle • write software • create releases • deploy to server • potential to use same server endpoints for mobile applications, different user interfaces (screen readers), etc
14. increased bandwidth helps initial “application start” latency but…
15. responsive user interfaces • “0.1 second is about the limit for having the user feel that the system is reacting instantaneously…” • “1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.” (Source: Jakob Nielsen’s "Response Times: The 3 Important Limits”)
16. this must die
17. future • “the server” • latency - cloud in your hand, in your living room, fiber • immense potential as replacement for consumer applications, professional applications, and custom internal corporate applications • next gold rush?
18. but really why for you? • JavaScript is a language practically written to prove the point of TDD • Yes, it is hard. That is the point. That is why it won’t happen without craftsmanship. • Because it is going to be demanded by the market • Because the bar is being raised — the teen in the basement can build a rails app.
19. points • browser is a platform • difficulty of creating web applications is an opportunity • JavaScript is a first class citizen • you have 100ms and no spinner
20. demo time