Jump to content

User:Pablo Grass (WMDE)/conferences/IJS2019 Munich/day1

From Wikitech

JavaScript Fullstack Day – from Zero to Hero. A freebie for everyone who did not book a specific workshop for the first day.

Language part. Hans-Christian Otto @muhdiekuh, Suora GmbH

  • short history of ECMA script
  • strength (example) compared to java & PHP - "expressiveness"
  • difference var, let, const
  • "fat arrow functions", implicit return
  • value of `this` in functions vs fat arrow functions, incl "surprising" `window` in in `this` in HTML document
  • value of `this` inside methods of an object (made from a class)
  • using "fat arrow functions" on an object property to achieve intuitive `this` binding (object scope)
  • built in toLocaleString, incl `style: currency`
  • asynchronous code. dream vs reality (back when). evolution: callback hell, promises, await
  • expressiveness of modern JS: iterating, filter, includes
  • modules: use of functionality from inside other files - export. difference between default and named.
  • type cast for value which is the result of a && - e.g. a && b, when a=true and b="Bar", then
  • quoting wikipedia on Typescript
  • "one of the best things which ever happened to javascript"
  • "moving run time errors to compile time or - to be more precise - to the time when you code in your IDE"
  • "would never go into an ECMA project without TS anymore", even if you have some legacy JS - configure TS right

todo

  • await vs error handling?

Tooling part. Elmar Burke @elmarburke, MessageBird

  • package managers, runnners, bundlers, compilers - most these things were not a thing in JS/web few years ago
  • package maangers: run from CLI, registries as source of truth
  • npm, yarn: speed differences pretty much a thing of the past
  • used "left-pad" as example on how to install...
  • compatiblility description through versioning patterns: semantic versioning
  • imporance of lock files
  • runners: repetitive tasks. examples: make, gulp, npm scripts
  • gulp example (less to css, js concat)
  • using "old module system" in his gulpfile example
  • bundlers: webpack, parcel
  • webpack: webpack-dev-server moves built files into RAM, saves your SSD from excess writes
  • parcel: "default config right most of the time (no need to change), 10x faster than webpack"
  • hot module replacement, code splitting, tree shaking
  • compilers: babel
  • babel: is able to remove TS annotations
  • eslint: recommends -config-airbnb or -config-react-app, incl accessibility checks
  • prettier to replace personal opinions about CS and enforce it

todo

  • tree shaking for commonjs file?
  • "babel is able to remove TS annotations" Is this still relevant once TS compiler is run?
  • try/apply prettier (= eslint --fix?)


Testing part. Tobias Struckmeier @tobmaster, Adesso AG

  • testing is insurance for ourself and to prove to our customer that we are doing quality work
  • product owner expectations:
    • reliable software,
    • expectations stay fulfilled during later dev
    • crucital part of the software, when changing - or even rewriting - a software later
  • developer experience is an important objective
    • own sanity
    • "stay friends with your colleagues"
    • avoid frustrations
  • "needs an all seeing eye", automated testing
    • compares it to manual testing (expects this to be the norm "today")
  • e2e tests are highest value, b/c you are testing on the real application ("premier league")
  • eco system can be a bit confusing: some libraries solve multiple tasks
  • it's important how they are executed: browser vs emulated dom (jsdom) - speed vs confidence that "it really works"
  • "lanuchers": jasmine, jest, karma
  • test organization is important: grammar and structure (describe, it)
  • "assertion framework": jasmine, jest, mocha/chai
  • page objects are an important pattern, avoid repetition/boiler plate
  • snapshot testing (jest is big in that): not TDD, but reduces the effort drastically
  • integration tests: deserve more attention even thought they are expensive to do, maintain
  • e2e: selenium/webdirver (yes, calls that e2e), protractor, puppeteer, nightwatch, test cafe
  • BDD as a way of engaging product owners to participate (at least verify) in testing
  • name dropping:
    • OWASP dependency anlyser
    • Faker to generate test data
    • sinon
    • visual regression testing (compare screenshots)


angular, Cornelia Rauch @rauchco, SOFTWAREarchitekt.at

  • about angular (i.e. the rewrite), not "angular JS"
  • back in the days: html, css
  • added: javascript, to dynamically change content
  • complexity creeped in
  • angular helps by introducing components: typscript file, html file
  • uses decorator in TS file to tell angular CLI that it's a component, which selector to mount on
  • growing demands: i18n, rounting, ...
  • testing allowed through: decoupling execution from construction
  • angular provides dependencies when seen in a constructor
  • angular cli is gateway
  • room for improvement:
    • breaking changes from "angular.js" -> implement release cycles
    • bundle size -> angular ivy (new compiler, may come with angular 9)
  • q: "what about SSR"; a: can be done but does not come by default


react, Elmar Burke @elmarburke, MessageBird

  • "react is mainly the view layer", a library rather than a full-blown framework (the template language with hooks for state management)
  • it's easy to reason about how and when the view is rendered
  • mentions ease to incorporate state into the _one_ component responsible for each part of the DOM
  • "declarative programming pattern" rather than "imparative"
  • "the UI is a function of the state", i.e. easily tested, easy to reason about
  • colocate the same concern even if in different technologies (HTML, CSS and JS)
  • shows "CSS in JS"
  • react on the server is a first class citizen
  • SSR is fast "if you have the right caching parts in between"
  • elm frontend example "will make you a better JS dev"
  • what you don't get
    • a guide how to structure your app (component size)
    • routing
    • tiny bundle sizes ("preact" could help mitigate this)
  • "unidirectional data flow" data always flows from the root to the leafs (components)
  • events are sent upward
  • should i use it?
    • great for bigger teams
    • enforces ui patterns (as compared to e.g. jquery); "`componetized` is the today and the tomorrow of the web"
    • no real need if team already knows some other modern framework (steep learning curve)
    • need to support (very) old browser (<IE11)
    • not if you don't need a framework to begin with (limited complexity)


todo

  • link to elm frontend example
  • vue enable tree shaking

Learnings

  • children are passed to the "component function" as constructor parameter

vue. Hans-Christian Otto @muhdiekuh, Suora GmbH

  • comparing to angular and react - vue is in the middle between the two (angular has "charged batteries included", react has none whatsoever)
  • vuejs is "incrementally adoptable" i.e. "_could have been the next jQuery"
  • has many extra libs and the most important are "officially supported"
  • vue "comes with form handling"
  • basically allows you to "progressively enhance a static html file to a SPA"
  • fractal of components
  • naming of "props" is a give-away that some ideas were copied from react
  • vue with web components is eased as it does not wrap the browser events
  • stronger differences between vue and react:
  • apparently until recently the react devs (facebook) did not us redux themself (do in instagram now), while vuex is from core vue people
  • vue dev tools know about vuex which is not the case for angular and react - feels like everything is from one vendor
  • highlights wizard in vue-cli helping in setting up
  • vue = simplicity of react, combined with the power of the angular eco system

todo

e2e testing, Tobias Struckmeier @tobmaster, Adesso AG

  • protractor was created to bridge the gap between modern js frameworks and "old" server concepts
  • challenges
    • async handling
    • infrastructure (APIs)
    • aching dev machines
    • maintaining testdata (getting it from prod system, ...)
    • tools involved is about as long of a tool chain as it gets
  • hope on the horizon: cypress - "tries to twist the testing pyramid" (looks like competition for supertest + nock)
    • impressive output (report of e.g. what exact interactions were done before something broke in CI)

todo

  • pitch for cypress sounded interesting. example (with vue)?


Architectures for modern web front ends, Lucas Dohmen @moonbeamlabs, INNOQ

  • after more than one round of re-implementing the same application in different frameworks, is an advocate of clear architecture
  • move towards SPA
    • first move rendering only (needs JSON client & API),
    • then routing,
    • store "some" app state in the URI
  • need for pre-rendering arises
    • "everyone has no JS until it is downloaded" paraphrasing Jake Archibald
  • somehow got into (re)hydrating SSR mark-up
  • a result of isomorphic rendering in both server and client
  • test on low-cost (30$) devices, do not rely on emulators!
  • presents how an pseudo-infinite loop blocks all interaction, then plays all events at once
  • "rage clicks" (naming akamai) are a result of this: interaction btw. onload and interactive
  • showing seemingly "real" page but uninteractive can be more frustrating than a white page/loading indicator
  • for every content we should reflect if it needs to be "one big JS app"
    • keep the component approach however, no matter what the decision
    • check if combining traditional SSR content and tiny components is not more useful
  • is our focus very happy developers or best value for the customer? vet the reasons to chose a technology


node.js, Nils Mehlhorn @n_mehlhorn, freelance consultant

  • blocking IO is generally the nature of the JS language: one thread only
  • non-blocking IO (e.g. readFile instead of readFileSync) with a callback should be considered whenever using such capabilities
  • read "what the heck is the event loop anyway?"
  • express presented as "the library" to do SSR in node
  • shows (w/ minimum express.get entrypoint) "ejs" as a view engine for simple html pages
  • shows infamous "todo" example with tasks coming from express json endpoint, and config for REST with HTTP verbs
  • nestJS as a good example of neat architecture
  • another example (right size) image generation from huge raw images, via a thin service outsourcing the real work to some c++ bin


CI/CD w/ docker, Bastian Hofmann @BastianHofmann, SysEleven

  • explains service isolation of containerization
  • explains standardized k8s API no matter how k8s itself is provided (laptop to managed k8s)
  • shows creating multi step dockerfile to build node and then use the static files inside nginx to host
  • .dockerignore is important as it decreases size
  • explains pots in k8s and how its concepts help
  • example deployment
  • shows ingress controllers to use one LB for all your apps (saving IPs) incl TLS (cert-manager against letsencrypt) for dynamically created staging urls
  • uses cypress to smoke test applications after k8s setup in the individual stages
  • uses prometheus to monitor his k8s-hosted services incl grafana to visualize metrics
  • shows linkerd which uses a little proxy to collect data on communication between services

todo

  • do we have good .dockerignore files in place?

Learnings

  • k8s ingress, cert-manager and dynamic TLS
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=User:Pablo_Grass_(WMDE)/conferences/IJS2019_Munich/day1&oldid=1842549"