FrankenJS Meetup June 14th 2018 @ Zollhof

[Image source: FrankenJS]

Monetising Your App with Payment Request API – Christian Liebel, Thinktecture AG, Karlsruhe

Goodbye, app store! Progressive Web Apps (PWA) is an application model that empowers web applications to use “native” features such as offline capability or push notifications. PWAs can be installed on the device by simply adding them to the home screen. With Google, Apple and Microsoft on board, PWA are here to stay. But how do app developers and vendors make money in a post-app store age? Fortunately, there’s an answer to that: The Payment Request API. This feature allows online shops, websites and apps to display a convenient, consistent user interface for online payments. Thinktecture’s Christian Liebel (@christianliebel) shows what you can do with Payment Request API.

Follow Chris:



Progressing Web Apps means no app stores and users can use “Add to home screen”. These apps are just a website which can use native features, are backward compatible and the developer has a free choice of which technology to use.

Some of the advantages include writing cross platform apps. PWAs are supported by Apple, Google and Microsoft. iOS only supports Apple Pay!

We are on the road to PWA but we are not there yet. There are constraints and restrictions for devices, marketing and features.

So if there is no app store, does it mean no money? One way to earn money with PWAs are using the checkout form but this is repetitive, tedious and sometimes not touch friendly. The other solution is the Payment Request API which has to advantages that is it consistent UI and the user agent provides the data. It is important to note that the API does not perform the actual request!

Regarding browser support, Internet 11 and Firefox does not support it but Edge, Safari and Chrome does.

PRA Flow:

  • is JavaScript enabled?
  • Is Payment Request supported?
  • Can make payment?
  • Fallback

Always use HTTPS for payments!

if ('PaymentRequest' in window)
else redirect to checkout


  • methodData: payment methods
  • details
  • displayItems
  • shippingOptions

The API does not calculate the total amount!


  • shippingoptionchange
  • shippingaddresschange
let request = new PaymentRequest(...)

The study by Mobify in 2018 shows that the abandonment rate with PRA dropped from 45% to 20%.

Web rendering – How markup becomes pixel – Martin Splitt, Google, Zurich

We all want fast-loading, beautiful websites with silky-smooth animations.
But getting there isn’t always easy or obvious. In this talk we will shed a light on the lower-level processes for rendering a website and what we can do to make it fast and smooth.

Follow Martin:

How does it get from source code to pixels?

Parse – Layout – Paint

The markup is transformed into a DOM tree and layouting is performed. Layouting is how everything fits together on the page. Avoid relayouting, e.g. calculation power on the mobile which is battery power.

Pixels are stores as arrays in RGB values.

screen = array
1 pixel = 3 numbers (R, G, B)

Painting means filling the array but this array can be quite large, e.g. 1920 x 1080 x 3 = 6220800 bytes for only 1 frame! Imagine the 60 FPS performance. In order to fix this we have several options.


Compositing means re-drawing only a certain region using the Compositor which is a part of the browser. This will result in a list of numbers that are images of those regions.


Shaders are pixels out and pixels in, with 1 GPU/pixel. Shaders run parallel on the GPU which means that JavaScript can run while shaders run. Shaders can move (transformation), scale, opacity => perform animations by running on the GPU and not blocking JavaScript. But not all browsers behave the same, e.g. Firefox repaint. You can observe this using the Dev Tools => Rendering => flashing rectangle and also the Performance Monitor.

Y u no composite?

The browser could decide to just create one gigantic image so if the region changes then the big image is repainted. Compositing requires layers which means that image pops out of the image. This occurs for <video>, <canvas>, 3D transformations, transform-only and keyframe animations, in these cases the browser creates the layer.

Do not make everything into layers, but only what makes sense.

Conclusions: Measure! Avoid (re)layouting and paint! Do not over-engineer, e.g. layers!

Other important areas:

  • CSS will-change property
  • CSS contain property
  • CSS Houdini proposals

The evolution of software – Christoph Martens, & inventor of LycheeJS, Berlin

This talk will show you how to use generative models and coevolutionary AI concepts to evolve software in order to solve given problems. Step by step we will dig into the underlying architecture and discuss code, having a beer while the AI does all the work.

Follow Chris:


AI concepts to generate code using evolutionary algorithms.

Genetic programming:

  • Represent data as DNA
  • DNA = array of values
  • Weights of neural networks can be values

Three phases of evolution:

  1. Training
  2. Evaluation
  3. Breeding

After each cycle the population is killed and replaced, mutants and survivors remain.

This is a multi-agent system which is competitive, agents get rewarded or punished and it has fitness as status, the fittest agent breeds/multiplies.

NEAT = Neuro Evolution of Augmenting Topologies

MEAT is adaptive neural network algorithms that build neural networks from scratch. It is an unsupervised system that adapts to new problems and remembers solutions in for of DNA.

Example: MarI/O – ML for Video Games

In practice NEAT can be used for:

  • Expling search space
  • Finding unknown solutions
  • Combinations of existing knowledge
  • Decision tree automation
  • Unit tests and behavioral tests