Kapten @ DotJS 2019
Last December - we once again had the great opportunity to attend the DotJS in Paris, two days dedicated to the current state of front-end and back-end development in Javascript, gathering people from around the world with top-notch speakers.
Here is an overview of what we consider to be the main topics that came out of those two days.
State of Components — Vue.JS
by Evan You
Evan You — creator and lead maintainer of Vue.JS — raised the point in his talk that we see a new trend to define UI component — something different from what we were used to — which was a recurring subject during the conference. Not so long ago, most of the frontend frameworks were using classes to define a new component, but as Evan pointed out during his talk, «Classes are not bad… But maybe they are not the most natural fit for UI components either». He highlighted that inheritance does not work well for UI components, mixins have their fair share of problem, and that services classes are isolated from the component API.
Now we will rather extract stateful logic from the main component and encapsulate it into “composition functions.” These functions can be tested independently and reused across components.
Evan also gave his pros and cons between the different frameworks that follow this new way (React with his Hooks — Svelte 3 and more recently Vue¹ with his new composition API).
Another topic that came out a lot during the talks was that TS is used widely for front-end technologies. The codebase of Vue 3 is written in Typescript, and Evan You mentioned that using it internally does not affect the user but helps him understand the library a lot better. Adding an excellent support for auto-completion and type information from most IDEs — it proves to be the go-to language for front-end developers.
Typescript comes from Microsoft; if you go on its Github repository, you can see many starter templates for libraries and frameworks such as Vue, React, Node, React-native, to name of few. It also happens to be the primary language for Angular application development.
Denoland
by Bert Belder
Bert Belder — co-creator and NodeJS core developer — gave a fascinating talk on a new Javascript runtime called Deno, that he developed among others, with Ryan Dahl — co-creator of NodeJS.
Node now being a matured technology, Bert and Ryan looked back at how it was created and developed. They realized that its current implementation and architecture had some limitations and would need improvements. Having that in mind, they decided to work on this new runtime with the aim of creating a real alternative to NodeJS.
When it comes to performances, Bert explained that Node implemented promises to replace callbacks, but as they were removed not long after, it resulted in hard maintenance of the code. The GYP build system used to implement C/C++ add-ons was also a pain point, as it was hard to use and maintain. That is why Deno’s runtime is based on Rust and not C/C++, so it would not use GYP anymore.
It will implement Tokio — an equivalent of libuv for Rust — to handle the event-loop workflow.
Another interesting key difference is how dependencies are handled. Every Node project has a package.json file, a package manager (npm|yarn), and node_modules with tons of files, resulting in a hell of module algorithm resolution. This makes Node highly bounded to npm, whereas there is no need for it to be. That is where Deno comes in with a major difference; it uses ES Modules to import dependencies. No need for a package.json file anymore. You can now import any module directly using a URL specifying where the module is stored.
This difference raises questions about resiliency and availability. Deno has an integrated cache system storing every module that you depend on. If we take a situation where the server handling dependencies is down, you would still be able to install your dependencies from this cache.
On a security side, one of the main issues with Node is that it has access to everything outside its “sandbox.” Every module or your code can access files, networks, or environments. You can think about Deno as a black box with absolutely no doors from the outside world, which makes it really secure by default. If you need to get permission, Deno comes in with CLI flags. That way, you are enabling access to any external resource you need for your project.
Deno, like Node, is built on top of V8, supports Typescript natively, and was initially written in Go but has been rewritten in Rust.
Two other talks also mentioned Rust, both on WASM, one by Sven Sauleau, working at Cloudflare and core maintainer of Babel, and the other by Vlad Filippov, working at Mozilla. It promises excellent performances and a more straightforward implementation. It is interesting to see how years after years Rust is taking more and more space in the web development universe.
However, please don’t rush into Deno yet, it still has many bugs and a beta should come out beginning of this year.
At @Kapten, we love to give a try to new exciting technologies with strong potentials. We recently used Nest.js — a new backend framework — on a proof of concept, and we think Deno could be the next one when it is more mature. As a reminder, Deno doesn’t want to be a substitute for Node but an alternative!
JS saves the world, one line at a time
by Asim Hussain
Can we reduce our impact on the environment to fight climate change?
Asim Hussain’s talk raises the point on what does this question mean for the tech industry. How — as developers — can we make our applications greener and help fighting the climate emergency we currently find ourselves in.
Electricity is responsible for 30% of the greenhouse gas pollution, and on average, 80% of the world’s energy is produced from the burning of fossil fuels, so why not try making our apps use less electricity?
When it comes to carbon costs related to using a web app, servers are on top of the list. They run 24/7. Most of them need constant temperature to operate. And cooling can compromise a considerable amount of electricity usage in data centers.
Giving some figures, such as 470kg CO2e per year — the average waste of a single idle server per year — Asim made his point on the energy consumption impact of data centers.
As more and more web applications are running on the cloud, cloud providers have an essential role to play in this fight. Asim shared some interesting points on the 3 leading players that are Google Cloud, Microsoft Azure, and Amazon Web Services.
Interesting was the fact that GCloud and MS Azure are carbon neutral companies, as well as their data centers. As for AWS, it turns out that it is, globally, not carbon neutral, with the exceptions of the Dublin, Frankfurt, Oregon, and Canada regions. GCloud is 100% relying on renewable energy to run its data centers. MS Azure will reach 60% next year. AWS wasn’t mentioned, but after some research, it seems that they are on similar levels as Microsoft.
One of the main points of his talk was to consider serverless more, in particular, through the use of service functions, such as AWS Lambda, Google Functions, and Azure Functions.
The underlying point is that cloud providers are experts in optimizing server resources to be the most efficient possible, which in the end has a massive impact on energy consumption. So in relying more on their services, we will be able to run our apps in a greener way by avoiding wasting unnecessary computing resources, which could be used more efficiently.
To conclude his talk, Asim introduced us to climateaction.tech, a global community of tech professionals with a mission to empower people working in the tech industry to join forces by meeting, discussing, and taking climate change actions. Ready to be part of the movement?
What TC39 is doing?
The closing talk was by Daniel Ehrenberg, former Google now working at Igalia — a free software cooperative — who has been working on V8 and web standards, he is a TC39 core member.
Daniel presented TC39 organization workflow and culture and how its committee manages it. It was interesting to hear more about the behind the scene on how its members — who are from different parts of the world — get together to define new versions of the language.
He also presented the 4 different stages a feature has to go through to be part of the language new version, a process that can take months up to years, with a strong focus on community decisions.
This talk was also the occasion to give a snippet of interesting features proposals that currently are in the pipe at different stages.
Here is our selection:
Private methods and fields
This proposal is about something JS lacks, which is addressing the fact that while classes have been available since ES2015, they do not handle privacy on fields and methods.
Daniel explained that there were some disagreements within the committee members, especially on the syntax to use. They finally adopted the tag operator # as a way to specify privacy within a class. Currently, in stage 3!
Pipelines
Functional programming feature inspired by languages such as OCaml and Elm, is-as described on its Github page — “a backward-compatible way of streamlining chained function calls in a more functional manner.”
It is in stage 1 — so under construction — as the syntax is unsettled with two competing proposals under consideration.
Temporal
This proposal was presented in another interesting talk by Maggie Johnson Pint — also a TC39 core member.
It aims to provide standard objects and functions for working with dates and times.
Basically, it would be a new implementation of the Date class. Some key differences would be that it would use a domain model — something Date lacks — and objects would be immutable.
The focus is to make the use of dates and times less painful than it is at the moment (no pun intended 😉).
You can find all the implementation details here. It is currently in stage 2 and is being reviewed to go to stage 3!
To conclude, Daniel discussed how the organization and people from the committee would like to grow TC39 community to make it more inclusive, open, and accessible to people wanting to participate in the Javascript evolution.
This dotJS was again a huge success — from the top-level organization to the fantastic keynotes — and confirms years after years to be the JS event not to be missed.
We cannot wait to be back next year!
P.S.: If you’re excited about working on some of these subjects or just interested in tackling European urban mobility challenges on an evergrowing platform, we have various openings! Check it out: https://www.kapten.com/uk/careers/engineering/.
Article written by Amélie Tamisier, Rémy Gouello, and Florent Violin.
¹ Official release planned in Q1 2020
