Will your JavaScript app work in 2030?

Will your JavaScript app work in 2030?

Navigating the JavaScript world is not an easy business nowadays. The speed of things is just mind-boggling. What if, as a participant of this Formula One race, you would be required to develop something that has to work for 15 years? Our project team had that very requirement. We had no other possibility than to start to explore what we should do to our codebase to ensure that long lifespan.

In this presentation I'll explore if it's even possible for a JavaScript app to technically work in 2030. And then if it is, what should we do to our codebase to ensure that it won't become legacy just in a matter of years?

If you think some of your friends could use the tips from this presentation, please share this with them at Twitter or at Facebook. Thanx a million!

E6cd4de769537b3b4a6a954b5ef62cea?s=128

Jouni Kaplas

August 28, 2015
Tweet

Transcript

  1. Will your JavaScript app work in 2030? Jouni Kaplas @kaplas

    kaplas.net/blog Front in Amsterdam presentation 28th of August 2015 Photo “Back to the Future Delorean dashboard” by The Conmunity - Pop Culture Geek CC Attribution license; edited
  2. Source: @mieky and @AnttiLoponen @kaplas

  3. LEAN SERVICE CREATION If it is, what should I do

    for my app? Two questions: Is it possible for a JavaScript app to work in 2030? @kaplas
  4. LEAN SERVICE CREATION Is it possible for a JavaScript app

    to work in 2030? @kaplas
  5. LEAN SERVICE CREATION Is it possible for an app to

    work in 2030? Oh yeah! X Window System (1983) GNU Emacs (1984) Perl (1987) GNU C compiler (1987) GNU C Library (1988) Linux (1991) Python (1991) PHP (1995) Counter-Strike (1999) Windows XP (2001) WordPress (2003) Banking software… Portals… Industrial applications… Source: http://www.zdnet.com/article/the-10-oldest-significant-open-source-programs/ & Wikipedia @kaplas
  6. LEAN SERVICE CREATION Will there be web browsers in 2030?

    Probably @kaplas
  7. LEAN SERVICE CREATION Will there be browser engines in 2030?

    Hopefully @kaplas
  8. LEAN SERVICE CREATION Will there be JavaScript engines in 2030?

    Looks like it @kaplas
  9. LEAN SERVICE CREATION Where do browser vendors get their $$$?

    Supports bigger strategy (“mobile first, cloud first”) Search engines (ie. advertising), device licenses Open source (contributions) Supports bigger strategy (device business) Search engines (ie. advertising) Supports bigger strategy (advertising) @kaplas
  10. LEAN SERVICE CREATION Core diagram Core Enablers The rest @kaplas

  11. LEAN SERVICE CREATION Software project? @kaplas

  12. LEAN SERVICE CREATION Software project Core Enablers The rest @kaplas

  13. LEAN SERVICE CREATION Software business Core Enablers The rest @kaplas

  14. LEAN SERVICE CREATION Browser vendor business Browser is not actually

    in the very core of business for most browser vendors. Ie. we have our platform as long as web is a good business for there companies. Worrying @kaplas
  15. LEAN SERVICE CREATION EcmaScript No worries! Their policies from their

    FAQ page: •  No breaking changes, ever •  No deprecating features, ever •  No opt-in versioning, ever Source: http://tc39wiki.calculist.org/about/faq/ @kaplas
  16. LEAN SERVICE CREATION So, Is it possible for a JavaScript

    app to work in 2030? ✓ @kaplas
  17. LEAN SERVICE CREATION If it is, what should I do

    for my app? Two questions: Is it possible for a JavaScript app to work in 2030? ✓ @kaplas
  18. Source: @mieky and @AnttiLoponen WHAT SHOULD I DO? @kaplas

  19. LEAN SERVICE CREATION What makes a codebase “legacy”? •  Outdated

    platform •  Outdated frameworks •  Outdated libraries •  Outdated technologies •  Outdated tools •  No comments •  No documentation •  No tests •  Incoherent style @kaplas
  20. Photo “Fencing duel” by uwdigitalcollections CC Attribution license @kaplas

  21. LEAN SERVICE CREATION Core diagram Core Enablers The rest @kaplas

  22. LEAN SERVICE CREATION Core diagram Core The rest @kaplas

  23. LEAN SERVICE CREATION Core The rest Very important Less important

    Importance @kaplas
  24. LEAN SERVICE CREATION ALL VERY IMPORTANT! Importance @kaplas

  25. LEAN SERVICE CREATION Core The rest Very important Less important

    Importance @kaplas
  26. LEAN SERVICE CREATION Core The rest Always DIY Off-the-shelf solutions,

    Outsourced work Who implements? @kaplas
  27. LEAN SERVICE CREATION Core The rest Mostly unknown Mostly unknown

    Business requirements @kaplas
  28. LEAN SERVICE CREATION Unknown biz reqs lead to unsufficient architecture

    @kaplas
  29. LEAN SERVICE CREATION Unsufficient architecture leads to refactoring needs @kaplas

  30. LEAN SERVICE CREATION Core The rest Refactor (ie. evolve) Rewrite

    (ie. replace) Refactoring style @kaplas
  31. LEAN SERVICE CREATION Core The rest Less abstractions (more room

    to evolve) The level of abstractions does not matter Framework needs (1/2) @kaplas
  32. LEAN SERVICE CREATION Core The rest Avoid vendor lock-in, Ensure

    long-term support Vendor lock-in does not matter; short-term support is just fine Framework needs (2/2) @kaplas
  33. LEAN SERVICE CREATION “We can use anything we like, as

    long as it does not come from Microsoft, Google or Facebook.” - Our product owner, a year ago @kaplas
  34. LEAN SERVICE CREATION Framework needs Core The rest Abstractions Less

    Doesn’t matter Vendor lock-in Avoid Doesn’t matter Support Long-term Short-term Examples @kaplas
  35. LEAN SERVICE CREATION Core The rest Lightweight toolbelts Full-featured solutions

    Library needs (1/4) @kaplas
  36. LEAN SERVICE CREATION Core The rest Easily replaceable or maintainable

    Somehow replaceable or maintainable Library needs (2/4) @kaplas
  37. LEAN SERVICE CREATION Core The rest Have to work in

    your context “A gazillion GitHub stars is enough” Library needs (3/4) @kaplas
  38. LEAN SERVICE CREATION Core The rest Licenses have to be

    recursively OK Licenses have to be recursively OK Library needs (4/4) @kaplas
  39. LEAN SERVICE CREATION Library needs Core The rest Type Lightweight

    toolbelts Full-featured solutions Replaceable / Maintainable Yes Yes? Is this good? Your context General concensus Licenses Always check Always check Examples @kaplas
  40. LEAN SERVICE CREATION What makes a codebase “legacy”? •  Outdated

    platform •  Outdated frameworks •  Outdated libraries •  Outdated technologies •  Outdated tools •  No comments •  No documentation •  No tests •  Incoherent style @kaplas
  41. LEAN SERVICE CREATION Technologies In our context: EcmaScript, DOM, Canvas,

    Form Inputs, Proxies •  Refactor often •  Always bet on native APIs @kaplas
  42. LEAN SERVICE CREATION Changes @kaplas

  43. LEAN SERVICE CREATION Changes Try to adapt to technological changes

    ASAP •  Do not refactor things just because something new came up •  Find out how the new APIs/libs/techs can help you in your context •  And then start refactoring @kaplas
  44. LEAN SERVICE CREATION Compile-2-JS languages CoffeeScript, ClojureScript, Elm, TypeScript, etc.

    •  You really do not know about their long-term support •  Avoid @kaplas
  45. LEAN SERVICE CREATION Tools In our context: Grunt, Gulp, ESlint,

    JSCS, Browserify, SASS, Vagrant… •  Use the tools that fit your project (avoid overengineering) •  Update the tools regularly •  Do not change just for the sake of changing •  Combine •  Generally speaking, tools do not cause “legaciness” so much @kaplas
  46. LEAN SERVICE CREATION Comments •  In the beginning of the

    project, agree on commenting style •  Use peer reviews (eg. pull requests) •  From the very beginning, foster an environment where individuals are encouraged to mention about comments, and to reject PRs based on the lack of those •  Some tools may help (YUIdoc, etc.) @kaplas
  47. LEAN SERVICE CREATION Documentation •  The very same as comments:

    •  Agreement •  Pull requests •  An environment where a PR can be rejected because of a lack of documentation @kaplas
  48. LEAN SERVICE CREATION What makes a codebase “legacy”? •  Outdated

    platform •  Outdated frameworks •  Outdated libraries •  Outdated technologies •  Outdated tools •  No comments •  No documentation •  No tests •  Incoherent style @kaplas
  49. LEAN SERVICE CREATION Testing (1/3) With limited resources, what should

    you test? •  Unit tests? •  Integration tests? •  End-to-end slices? •  Just UI tests? @kaplas
  50. LEAN SERVICE CREATION Core The rest A lot of tests

    Less tests Testing (2/3) The technical type of tests is not so important! @kaplas
  51. LEAN SERVICE CREATION Testing (3/3) There’s no silver bullet, but…

    •  Facilitate testing as quickly as possible •  Use the CI, Luke, from the day one •  Peer reviews / Pull requests •  No-one will ever add tests later on! @kaplas
  52. LEAN SERVICE CREATION Code style (1/2) Code style is not

    a matter of opinion @kaplas
  53. LEAN SERVICE CREATION Code style (2/2) •  Agree with a

    set of rules (use the ready-made ones if possible) •  Automate style check and static analysis (ESlint, JSCS) •  Use your CI to check code against your rules •  Add new rules when necessary @kaplas
  54. So, will your JS app work in 2030? Ie. conclusions

    Photo “Sunset splendor” by Rachel Kramer CC Attribution license @kaplas
  55. The web platform will be just fine Just pay some

    attention to it Photo “Derelict fishing platform” by blinking idiot CC Attribution license @kaplas
  56. Photo “Opinion” by Transformer18; Edited; CC Attribution license Your codebase

    will also be fine, as long as you change your thinking… @kaplas
  57. Photo “Opinion” by Transformer18; Edited; CC Attribution license from everything

    to only important @kaplas
  58. Photo “Opinion” by Transformer18; Edited; CC Attribution license from just

    features to refactoring @kaplas
  59. Photo “Opinion” by Transformer18; Edited; CC Attribution license from solutions

    to abstractions @kaplas
  60. Photo “Opinion” by Transformer18; Edited; CC Attribution license from GitHub

    stars to your context @kaplas
  61. Photo “Opinion” by Transformer18; Edited; CC Attribution license from npm

    install to maintainability @kaplas
  62. Photo “Opinion” by Transformer18; Edited; CC Attribution license from hype

    to support @kaplas
  63. Photo “Opinion” by Transformer18; Edited; CC Attribution license from opinions

    to agreements @kaplas
  64. Photo “Opinion” by Transformer18; Edited; CC Attribution license from constant

    to changing @kaplas
  65. Photo “Opinion” by Transformer18; Edited; CC Attribution license from today

    to tomorrow @kaplas
  66. That’s it. Jouni Kaplas @kaplas kaplas.net/blog Did you like this?

    Please, help your friends and share this presentation with them. Thanx!