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

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!

Jouni Kaplas

August 28, 2015
Tweet

More Decks by Jouni Kaplas

Other Decks in Technology

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