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!

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
   

   View Slide

2. Source: @mieky and @AnttiLoponen
   @kaplas
   

   View Slide

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
   

   View Slide

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

   View Slide

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
   

   View Slide

6. LEAN SERVICE CREATION
   Will there be web
   browsers in 2030? Probably
   @kaplas
   

   View Slide

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

   View Slide

8. LEAN SERVICE CREATION
   Will there be JavaScript
   engines in 2030? Looks like it
   @kaplas
   

   View Slide

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
   

   View Slide

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

    View Slide

11. LEAN SERVICE CREATION
    Software project? @kaplas
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

16. LEAN SERVICE CREATION
    So,
    Is it possible for a JavaScript
    app to work in 2030?
    ✓
    @kaplas
    

    View Slide

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
    

    View Slide

18. Source: @mieky and @AnttiLoponen
    WHAT SHOULD I DO?
    @kaplas
    

    View Slide

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
    

    View Slide

20. Photo “Fencing duel” by uwdigitalcollections
    CC Attribution license
    @kaplas
    

    View Slide

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

    View Slide

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

    View Slide

23. LEAN SERVICE CREATION
    Core
    The rest
    Very important
    Less important
    Importance @kaplas
    

    View Slide

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

    View Slide

25. LEAN SERVICE CREATION
    Core
    The rest
    Very important
    Less important
    Importance @kaplas
    

    View Slide

26. LEAN SERVICE CREATION
    Core
    The rest
    Always DIY
    Off-the-shelf solutions,
    Outsourced work
    Who implements? @kaplas
    

    View Slide

27. LEAN SERVICE CREATION
    Core
    The rest
    Mostly unknown
    Mostly unknown
    Business requirements @kaplas
    

    View Slide

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

    View Slide

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

    View Slide

30. LEAN SERVICE CREATION
    Core
    The rest
    Refactor (ie. evolve)
    Rewrite (ie. replace)
    Refactoring style @kaplas
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

35. LEAN SERVICE CREATION
    Core
    The rest
    Lightweight toolbelts
    Full-featured solutions
    Library needs (1/4) @kaplas
    

    View Slide

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

    View Slide

37. LEAN SERVICE CREATION
    Core
    The rest
    Have to work in your
    context
    “A gazillion GitHub stars
    is enough”
    Library needs (3/4) @kaplas
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

41. LEAN SERVICE CREATION
    Technologies
    In our context: EcmaScript, DOM, Canvas, Form Inputs, Proxies
    •  Refactor often
    •  Always bet on native APIs
    @kaplas
    

    View Slide

42. LEAN SERVICE CREATION
    Changes
    @kaplas
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

52. LEAN SERVICE CREATION
    Code style (1/2)
    Code style is not a
    matter of opinion
    @kaplas
    

    View Slide

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
    

    View Slide

54. So, will your JS
    app work in 2030?
    Ie. conclusions
    Photo “Sunset splendor” by Rachel Kramer
    CC Attribution license
    @kaplas
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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!
    

    View Slide