Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Source: @mieky and @AnttiLoponen @kaplas

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

LEAN SERVICE CREATION Core diagram Core Enablers The rest @kaplas

Slide 11

Slide 11 text

LEAN SERVICE CREATION Software project? @kaplas

Slide 12

Slide 12 text

LEAN SERVICE CREATION Software project Core Enablers The rest @kaplas

Slide 13

Slide 13 text

LEAN SERVICE CREATION Software business Core Enablers The rest @kaplas

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

LEAN SERVICE CREATION Core diagram Core Enablers The rest @kaplas

Slide 22

Slide 22 text

LEAN SERVICE CREATION Core diagram Core The rest @kaplas

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

LEAN SERVICE CREATION ALL VERY IMPORTANT! Importance @kaplas

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

LEAN SERVICE CREATION Unsufficient architecture leads to refactoring needs @kaplas

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

LEAN SERVICE CREATION Core The rest Less abstractions (more room to evolve) The level of abstractions does not matter Framework needs (1/2) @kaplas

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

LEAN SERVICE CREATION Changes @kaplas

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

LEAN SERVICE CREATION Compile-2-JS languages CoffeeScript, ClojureScript, Elm, TypeScript, etc. •  You really do not know about their long-term support •  Avoid @kaplas

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

The web platform will be just fine Just pay some attention to it Photo “Derelict fishing platform” by blinking idiot CC Attribution license @kaplas

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

That’s it. Jouni Kaplas @kaplas kaplas.net/blog Did you like this? Please, help your friends and share this presentation with them. Thanx!