Tes Engineering Blog

Musings of the Tes Engineering Team

BlogHow we workMeet the TeamOpen rolesWork with us

January 30, 2020

Notes from dotJS 2019:

by Federico Rampazzo

The future of JavaScript, delicious buttery croissants and cold, freezing Paris in December.

dotJS is part of dotConferences, an impressive series of tech conferences with the goal of bringing TED-like quality to the tech world.

DotJS conference

The ingredients for this succesful recipe are:

  • Amazing speakers
  • A single track program to keep everyone focused
  • No WiFi to waste time with
  • A massive and fancy theatre
  • French style catering

One of the benefits of being a member of Tes's Engineering Team is the training and conference budget, which I used to attend this conference. This enables us to stay in touch with the tech community and provides an opportunity to listen to new ideas. Once back home, we share the ideas we collected either through a presentation to the wider Engineering Team or a post on the blog (like the one you're reading now).

It all started with a struggle.

Pesky politicians in France were apparently messing with people more than usual and a general transportation strike was announced on the days of the conference. Going the extra mile, the dotJS organisers quickly prepared a network of replacement buses to get everyone to the conference. Maybe the past winters in London spoilt me, but I found Paris in December to be insufferably cold, so this was greatly appreciated.

On the way to the conference, we passed by massive tent cities and refugees burning tires to warm themselves up. We finally arrived at the fancy venue and entered the privileged doors of the tech world. The difference was striking.

Paris, please, get yourself together.

Venue of dotJS 2019

Several stands from different cool tech companies were present in the main hall, showcasing their products, giving demos and gadgets in exchange for developers referrals. Networking over croissants and fruit was pleasant; soon discussions started on whether React was better than Vue and on who copied who. Shortly after, we were welcomed in the theatre and the sessions started to roll in.

Frontend Day

What to expect from a modern web framework?

Tim Neutkens explained in his talk how useful frameworks can be in making developers life easier while providing performance benefits for the users.

This definitely felt like a "Why use next.js" talk, which speaks volumes of the qualities of next.js. Tim mentioned there is still room for improvements, with memory usage optimisation being something he's working on.

Modern Routing

Eduardo San Martin Morote took us for a ride on how the vue.js router solution works, digging into the History API quirks.

Eduardo also shed light on the dark side of Open Source and the challenge of being a OSS developer who is not working for a company; Patreon apparently takes a big cut of your donations while Github/Microsoft gives 100% of the donations to the developers (and matches up to 5,000$).

The Complexity in Simplicity

Sara Vieira launched herself in an ode to simplicity.

Her message is that accessibility is down to developers and accessibility is more than being barely readable by screen readers; people without disabilities forget about things that disappear from the page, they rely on translating websites, they may not be as familiar with the internet as developers are.

Would your parents be able to use your website? Take the burden so people won't have to. Pretty code won't make your users come back, good usability will.

Some more of her tips:

  • Forms' only goal should be to not make people cry
  • People travel: please use the navigator language property, don't try to guess my language based on my IP
  • Placeholders are not accessible by assistive readers, they can't be styled, they're not translated, they disappear when you start typing
  • You don't need a custom select which will probably behave worse than the native element
  • Don't ask which type of credit card I'm using, you can detect it with a regex and the first four digits

The pragmatic front-end tester

Adrià Fontcuberta showed us how to write effective front-end tests. He maintains Testing Library which works with most front-end frameworks.

A few tips from his talk:

  • Focus on how much value the test is bringing
  • Make it cheap so you can run it often (don't load an entire browser to run tests)
  • Test what the user does, not implementation details

Develop, debug, learn

Chris Heilmann delivered an inspiring presentation on what we as developers are focussing on and what our environment is like.

We mostly depend on abstractions, we focus on creative solutions for our pleasure and not on end users. Too busy chasing the next shiny thing to justify expensive salaries - we became the bankers of the 80s. Getting into tech is not as easy as it could be, especially at a time when automation is taking away many manual jobs. There is not enough information on how to become a developer; we have massive dependencies and we have a hostile environment.

Moreover, despite all the solutions we built for ourselves, our environment is not great. Context switching between our code editor, the website we're building, the documentation we're writing and Stack Overflow kills our workflow. We need a holistic developer tool, we could have AI powered autocomplete sourcing the best patterns from the most popular projects. We could have documentation show up in the code editor so that we can learn while coding.

Data visualisation in the browser

Jana Beck gave an amazing presentation on data visualisation.

My main takeaways were:

  • UMAP.js is an interesting library to visualise big data
  • Don't be afraid to offload work to service workers
  • You can move server load to the client
  • You can use web workers and offscreen canvas to render massive computations in the browser and render them efficiently
  • Error handling is not great because you can't serialise errors properly
  • These days she uses individual d3 modules but render her applications in react

Architecting A Component Compiler

Adam Bradley presented the challenge recently faced by the Ionic Framework team:

Teams use different UI frameworks, how can Ionic maintain a single codebase and compile to all the different frameworks?

The answer is Stencil, a tool which is able to compile Web Components to components usable in React, Vue.js, etc. Impressively, it also features optimisations from static analysis, dead code removal and server side rendering.

His message: you can't go wrong when picking any of the popular frameworks, but if you want your components to be widely reusable, consider using a solution like Stencil.

Evergreen Libraries

Igor Minar talked about Angular's goal of being an evergreen library. The browser is a relatively stable platform, while the JS libraries tend to be instable.

Igor pointed out a few techniques to improve the situation:

  • Make responsible changes
  • Use semantic versioning
  • Use time based releases and release periodically
  • Setup a deprecation policy
  • Keep documentation up to date
  • Use the power of static analysis to warn developers of mistakes
  • The best migration is avoided, the second best is automated
  • Test on as many applications as possible (Angular being a Google project makes it easy to test the new frameworks on a really high number of projects)

Build static websites

Phil Hawksworth made a compelling point about rethinking your architecture to have static websites as much as possible.

The main concept behind this line of thinking is "Bake, don't fry", don't waste CPU power to render dynamic pages; you should use that CPU power once to generate pages, cache them and serve them many times.

This is not only about saving energy, it's also about:

  • Lowering deployment friction
  • Putting distance between logic and complexity
  • Decoupling build time and request time
  • Simple, easy to reason about systems

He drove his point home with a demo of a simple, scalable picture generator; the requirements were:

  • Users need to be able to come on the website and pick 3 colors
  • The website will generate the picture of a lollipop with the 3 colors chosen, available at a certain URL
  • Anyone visiting the URL will see the lollipop

Phil's answer:

  • He used a lambda function to pre-render static pages of all the lollipops from a database
  • He then added a small handler to insert the data provided by the user in the database
  • He then added a catch-all client side handler to display lollipops which are still being generated

State of Components

Evan You analysed the state of components in his talk.

Components are often implemented as classes, they accept inputs and manage lifecycle and side effects (such as callbacks called on actions); all of these are implicit contracts.

Classes have several problems:

  • Classes don't compose well and are challenging to split in terms of responsibilities
  • Inheritance is not very useful and rarely used for UI components
  • Components have overlapping behaviour

Hooks are a move in the right direction, as they compose well.

Evan also talked in favor of types, as they help with maintainability; Vue itself is trying Typescript.

Backend Day

JavaScript Saves the World

Asim Hussain advocated for more cloud usage in his talk.

Asim started by talking about all the green choices we're willing to make (making all the green parents envious, he even used cloth nappies with his son!). Why, then, are we not pursuing the green option when talking about deployment?

Idle servers consume energy, so businesses who underutilise their CPU are wasting energy. Using serverless, a centralised provider is pooling resources and can schedule the execution of your tasks in a more efficient way, hopefully getting closer to full utilisation.

If you're worried about getting a long cold start from your lambda function, Azure (where Asim works) has a flag to keep at least one hot server on (sacrificing some efficiency).

I can't help but wonder: If it's more efficient how come lambda functions are not priced as competitively as normal VMs? As one unsung hero put it: "Green is the color of money".

Exploring the hidden potential of sound data

Charlie Gerard impressed us with the hidden potential of sound data.

She trained a Tensorflow model to recognise sound and showed us how to detect different scenarios happening based only on audio from her microphone.

  • The first step consisted in splitting audio data in three dimensions: time, frequency and amplitude
  • She then fed quality samples to the model (which can get quite large)
  • The model is then able to recognise one activity at a time (like talking, clapping, brushing your teeth)

I don't think I've ever seen someone brushing their teeth on stage, but that definitely helped cement the memory of it.


Bert Belder talked about Deno, the node.js killer made by creators and core contributors of node.js.

Originally, the team behind Deno was trying to build an environment to bring machine learning to JavaScript. When Google released tensorflow.js they quickly pivoted to create a development platform.


  • is built on top of Rust's event manager library tokio and on top of v8
  • provides a runtime for JavaScript, TypeScript and WebAssembly
  • aims to fix problems with legacy node.js API which can't be changed for compatibility reasons (callbacks anyone?)
  • implements a security model based on permissions you're happy to grant to a script
  • removes NPM by letting you specify URLs as dependencies (like Go does)
  • doesn't have the myriad of tools which contribute to JavaScript fatigue
  • ims to provide a standard set of tools
  • exposes a low level API as a Rust crate

Before releasing a 1.0 version they plan to:

  • Improve WebAssembly support
  • Provide an option to compile a Deno application as a single executable
  • Improves Rust v8 binding

Apparently, fans in Japan made dinosaurs based books and illustrations about Deno.

A few thoughts after seeing this talk:

  • I'm curious to see how Deno will do in the future
  • It looks like Rust and its zero cost abstractions are becoming more and more commonplace in the web development world

Into WebAssembly

Vlad Filippov showed us the internals of WebAssembly.

WebAssembly is implemented in JS purely using Floats, Integers and Functions. There is a small interface to send data and receive data from WebAssembly, which is being worked on and improved. Ideally you would just call a C/C++ program with a require.

If you're afraid WebAssembly will kill JavaScript, fear not: Vlad assures us that WebAssembly needs JS for sandboxing.

But will developers be of the same opinion once they can pick any language to code within the browsers?

More WebAssembly in your JavaScript

Sven Sauleau recommended using WebAssembly once more.

You get better performance and you can run in the browser and in an increasingly larger pool of runtimes (Rust, Python, .NET, node.js, deno, etc).

It's also a W3C recommendation standard and it's ready to use.

A few leaving expert tips and considerations:

  • If you need to copy a lot of data from your main environment into WebAssembly, be careful
  • We need a killer app for WebAssembly (and possibly not more Cryptomining in my browser)

Performance in JS

Vladimir Agafonkin, the author of the beloved Leaflet, gave us a performance optimisation lesson.

If you write carefully and knowing the limits of V8, you can approach native speed.

  • Algorithmic complexity is key to unlock improvements of orders of magnitude
  • Remove unnecessary code if you can
  • Find a bottleneck, find out why it's slow, make it faster, repeat
  • Native methods are not free and they need to be accounted for when calculating algorithmic complexity
  • Profiling is much better than 2 years ago, so make the most of it
  • If you care about performance you need to forget readable functional methods; map keeps making allocations and throwing them away
  • Change your data structure so that you can do less work or drop your algorithmic complexity
  • Don't take established code for granted: just because it's there, it doesn't mean the person who wrote it thought about performance

Vladimir shared some very interesting thoughts about education, taken from his own experience:

  • You don't need a degree to learn about algorithms, you just need the will to go and learn how things work
  • Education gives you a tool but not a reason to learn; you need to find that reason or you won't learn

CRDTs for Mortals

James Long talked about offline first applications and how to make them using CRDTs.

Applications tend not to work offline, which is a huge usability fail. Unfortunately offline applications are part of a distributed system and doing syncing correctly is hard.

James implemented his syncing on top of SQLite and went through a series of syncing options with various drawbacks. He ended up with Conflict-Free Replicated Data Types, which means building your application on top of commutative idempotent data structures.

For example:

  • A map can be a CRDT if the last write always wins ( also called a LWW map)
  • A set can be a grow-only set (G set)

An SQLite table can be seen as a G set of LWW map, allowing developers to forget the complexity of syncing when developing their application.

This methodology has great potential for end to end encrypted applications.

MIDI, communications, and music in JavaScript

Kassian Wren prepared a musical performance using node.js to light up a guitar when one note is played.

She's using a complicated setup using an Ableton fork (to support the real music) a Raspberry PI and a node.js server.

Her talk was an invite to use node.js, outside of work, for fun and art.

Future of dates in JS

Maggie Johnson-Pint, the maintainer of Moment.js, went through all the problems of the Date object in JavaScript.

  • Date is an incomplete domain model
  • Date deals with absolute time, local time and timezones
  • Local time is not contiguous because of timezone support and, for example, DST

The solution which is being worked on by the TC39 consists of:

  • Having a single point in time being a timezone + absolute time
  • Providing modules to handle Date-only, Time-only and Duration

TC39: How we work, what we are working on, and how you can get involved

Daniel Ehrenberg presented how the TC39 works.

  • It has a yearly release cycle and spots at TC39 are filled in by companies or projects with interest in the development of JavaScript
  • It's responsible for the JavaScript and JSON specification
  • It operates on full consensus, a single person can withhold consensus. This forces people to play nice and give reasons when they don't like something and think carefully about the politics of getting your feature approved. All features need to work with all the delegates
  • Proposals are carried forward by champions who organise meetings and thread to discuss proposals
  • Meetings happen every 2-3 months and last 3 days at a physical location with people joining in remotely
  • The agenda for meetings is prepared 10 days in advance
  • Development happens outside of meetings on GitHub
  • As a general rule, only what can't be done in userland ends up in the JS specification
  • Babel starts implementing since things are still being discussed (Stage 1) and provides feedback from the community ahead of time
  • Maintainers of popular projects are invited to contribute and provide valuable input

There are 4 stages through which every feature passes:

  • Stage 1: We're talking about implementing a feature
  • Stage 2: We agreed on a specification for this feature
  • Stage 3: We're happy with this feature and it's likely getting implemented
  • Stage 4: We have implementation and tests and we're ready to ship it

Daniel presented a few upcoming features (you can check them out in the video above), among which dynamic imports, decorators, pipeline operators and BigDecimal.

As a closing remark, Daniel spoke about the culture at TC39. They're working on creating a transparent and inclusive environment by:

  • Inviting experts from outside the TC39
  • Providing accessible documentation on GitHub
  • Using discourse instead of a mailing list
  • Creating a code of conduct
  • Increasing the amount of surveys
  • Preferring practicality over perfection
  • Trying to be accessible to new developers
  • Adopting in incremental prototyping
  • Being open to contributions and feedback

Final Thoughts

I really enjoyed the conference and the quality talks - which translated to a ridiculous amount of notes!

I hope you'll be able to reap some of the good ideas reported here.

© Tes Engineering Team2020| All rights reserved
Follow @tes_engineering