Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Browser and the Future of Applications

Cymen Vig
February 08, 2014

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.

Cymen Vig

February 08, 2014
Tweet

More Decks by Cymen Vig

Other Decks in Business

Transcript

  1. overview • terminology • why • past • present -

    rise of browser as a platform • web applications • future • a small demo (+ heckle at will, seriously)
  2. why • cost of application development • deployment of traditional

    desktop applications • support • expectations of a traditional desktop application user
  3. 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
  4. past • custom internal terminal/GUI applications • client-server • responsiveness

    • correctness - what happens when there is a bug? • profit - how are applications sold?
  5. 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
  6. 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?
  7. present cycle • write software • create release • sell

    on app store/website • no box/media • downloadable upgrades and fixes • still need to provide installation support
  8. 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
  9. web applications • horizon — if it isn’t here already,

    it’s coming • latency • expectations • correctness • profit • clean code/implementation
  10. 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
  11. 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
  12. 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”)
  13. 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?
  14. 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.
  15. 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