Welcome to the first part of my JSWorld Conference 2022 summary series, in which I share a summary of all the talks in four parts with you.

After this part which contains the first three talks, you can read the second part here, the third part here, and the last part here, where I summarized the rest of the talks.

(Recurring) Introduction

After two and a half years, JSWorld and Vue Amsterdam Conference were back in Theater Amsterdam between 1 and 3 June, and I had the chance to attend this conference for the first time. I learned many things, met many wonderful people, spoke with great developers, and had a great time. On the first day the JSWorld Conference was held, and on the second and third days, the Vue Amsterdam.

The conference was full of information with great speakers, each of whom taught me something valuable. They all wanted to share their knowledge and information with other developers. So I thought it would be great if I could continue to share it and help others use it.

At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. so I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them

Since I’m trying to include all the important points, I have to split each day into three, four, or maybe five parts to prevent the article from getting too long.

A very important point

Everything you read during these few articles is the result of the effort and time of the speaker itself, and I have only tried to learn them so that I can turn them into these articles. Even many of the sentences written in these articles are exactly what they said or what they wrote in Slides. This means if you learn something new, it is because of their efforts. (So if you see some misinformation blame them, not me, right? xD)

Last but not least, I don’t dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin.Here you can find the program of the conference:

Table of Content

• State of Deno 2022: Colin Ihrin — Engineer at Deno
• CSS Houdini: Negar Jamalifard — Software Developer at Lightspeed Commerce
• My Sweet Stack: Dexter (Alexander Essleink) — Senior Frontend Engineer at Passionate People

TL;DR

• First Talk: Colin talks about the state of Deno in 2022, compares Deno with Node.js, and gives us a taste of working with Deno.
• Second Talk: Negar talks about how browsers render CSS, and then introduces us to CSS Houdini, which is a set of low-level APIs that exposes parts of the CSS engine.
• Third Talk: Dexter goes over his “perfect” stack, using graphQL, SvelteKit, Docker, and Github.

---

State of Deno 2022

- Engineer at Deno

Deno is a simple, modern, and secure runtime for JavaScript and TypeScript similar to Node.js that uses V8 and is built in Rust. It is created by Ryan Dahl, the original inventor of Node.js, who talked about JSConf EU in 2018, where he talks about .

Some of the topics he talked about were module resolution through node_modules, the lack of attention to security, and various deviations from how browser’s worked. and he set out to fix all these mistakes in Deno.

In this talk, Colin will explore Deno’s tech stack that allows the project to move fast, why Deno is betting on browser compatibility, and how they intend to provide compatibility with the existing JavaScript ecosystem.

Background

Node.js has been around since 2009, predates much of modern JavaScript like CommonJS vs. ECMAScript Modules and Callbacks vs. Promises, and does have a huge ecosystem with a lot of legacy code that can slow progress and standards compliance. The goal of Deno was to address some of the shortcomings of Node.

Timeline

June 2018: Deno introduced at JSConf EU

August 2018: Deno v0.1.0 released, rewritten in Rust — previously written in Golang.

Having to garbage collected languages inside the same process might not be the best thing.

May 2020: Deno v1.0.0 released

March 2021: The Deno company was announced

June 2021: Deno Deploy announced

Q3 2022: Deno Deploy reaches GA

Growth

Deno has caught up with node rapidly in terms of Github starts:

• Node.js: 88k
• Deno: 82.8k

Core Technology comparison

	Deno	Node.js
JavaScript Engine	V8	V8
Native Language	Rust	C++
Async I/O	Tokio	libuv
TLS and Crypto	Rustls	OpenSSL
HTTP	hyper and reqwest	llhttp
DNS	Trust-DNS	c-ares

Deno Core Architecture

Deno is built from Rust crates. deno_core includes rusty_v8 and deno_ops.V8 is a C++ project, so they came up with a layer surrounding that called rusty_v8, and now everything outside of v8 itself is Rust code. There is also a layer called deno_ops which provides an API for performing operations with rusty-v8.

Deno Runtime Architecture

deno_runtime includes deno_core mentioned above plus deno_console, deno_crypto, deno_fetch, deno_web, Tokio, etc.

Deno CLI

Includes deno_runtime and also an integrated toolchain. This is what you download and run — on Linux, macOS, and Windows — and it is distributed as a single executable file. Everything you need to run Deno programs is included.

The idea is that Deno is pretty much battery included compare to historically Node.js which was not.

Standard Library

Modules maintained by the core team for fs, http, streams, uuid, wasi, etc. It is similar to Core modules in Node.js, and it’s guaranteed to be maintained and work with Deno.

It is recommended to pin a version because there may be breaking changes with new versions. Example:

import { copy } from "//deno.land/[email protected]/fs/mod.ts";

await copy("source.txt", "destination.txt");

Dependency Management

It works like in a browser, there is no CommonJS and it’s ESM, and there is no package.json, node_modules, or index.js.

Runtime fetches, caches, and compiles automatically, so there is no separate npm install or things like that.

is a hosting service for Deno scripts.

Release Schedule

• Weekly patch releases
• Monthly semver minor releases
• Releases normally happen on Thursdays
• Occasional semver major releases, but there is no set schedule yet.
• No LTS schedule yet

Hello World: Example in Deno

import { serve } from "//deno.land/[email protected]/http/server.ts";

function handler(_req: Request): Response {
	return new Response("Hello, Wolrd!");
}
serve(handler);

// deno run --allow-net server.ts

Notable Features

Focus on web platform compatibility

Deno prefers web platform APIs when possible. A number of the APIs that are supported: URL, FormData, fetch, Blob, console, File, TextEncoder, WebSocket, WebGPU, Local Storage, etc.

Integrated toolchain

Deno does have these tools out of the box in comparison to Node.js that doesn't have, like Linter, Formatter, Version Manager, Documentation Gen., Task Runner, Bundler, Packager, and TypeScript.

	Deno	Node.js
Linter	deno lint	ESLint
Formatter	deno fmt	Prettier
Version Manager	deno upgrade	nvm
Documentation Gen.	deno doc	TypeDoc
Task Runner	deno task	gulp
Bundler	deno bundle	webpack
Test Runner	deno test	node —test
Packager	deno compile	pkg
TypeScript	deno run	ts-node

You can see all subcommands with  deno -help

TypeScript support

Deno does support TypeScript out of the box, caches transpired files for future use and The TypeScript compiler is snapshotted onto Deno.

SWC is used for transpilation and bundling which is:

20x faster in single threaded app execution and up to 70x faster in multi threaded than babel.

Permission system

Deno cannot access the outside world by default and Permission must be explicitly granted. Some of Permissions CLI Flags: —alow-env, —allow-hrtime, —allow-net, —allow-ffi, —allow-read, —allow-run, —allow-write, —allow-all/ -A, etc.

Node.js compatibility mode

createRequire(...) is provided to create a require function for loading CJS modules. It also sets supported globals.

import { createRequire } from "//deno.land/[email protected]/node/module.ts";

const require = createRequire(import.meta.url);
// Loads native module polyfill.
const path = require("path");
// Loads extensionless module.
const cjsModule = require("./my_mod");
// Visits node_modules.
const leftPad = require("left-pad");

// deno run —compat —unstable —alow-read ./node-code.mjs

Recent Changes

up to date V8, Web crypto, reportError API, Mocking utilities, Snapshot testing, etc.

WinterCG

There is a new W3C Community Group called Web-interoperable Runtimes Community Group also known as WinterCG, which is a Collaboration between non-browser JavaScript runtimes.

This group is not aiming to create new APIs, but give a voice to server side runtimes at the table where all the discussions about specifications happen.

Deno Deploy

is essentially a globally distributed JavaScript VM, basically a V8 isolate cloud. It’s something similar to lambda functions but at the Edge (We will talk about Edge) and is currently available in over 30 regions globally and still growing. It is Built on the same open-source web APIs but with some tweaks for the cloud, also is integrated with netlify functions and supabase functions.

---

CSS Houdini

- Software Developer at Lightspeed Commerce

CSS Houdini is one of the most recent changes in the CSS world that could change a lot of our old methods for updating CSS.

Houdini is a set of low-level APIs that exposes parts of the CSS engine, giving developers the power to extend CSS by hooking into the styling and layout process of a browser’s rendering engine. Houdini is a group of APIs that give developers direct access to the CSS Object Model (CSSOM), enabling developers to write code the browser can parse as CSS, thereby creating new CSS features without waiting for them to be implemented natively in browsers. —

In this talk, she started with the basics of how browsers normally render CSS and then got to the point that how it would be different with the upcoming changes in CSS.

Rendering in Browsers

How Do Browsers Render CSS?

One of the important parts of the browsers are rendering engines, for example:

• Blink in Chromium-based browsers
• Gecko in Firefox
• Webkit in Safari

  
  

All of These browsers go through the same set of flow from the point that they receive an initial CSS file to the point that they can actually render something on the screen.

1. Parsing Whenever the rendering engine encounters a link to a CSS file in an HTML file, it will download the CSS file in the background and then go through this process: Bytes → Characters → Tokens → Nodes → Object Model and it will generate two Object Models:

   
   

   • DOM (Document Object Model)
   • CSSOM (CSS Object Model) At this stage, the browser has all the information about the data structure of the page and the styling of the page, but to be able to render something on the screen, it needs to merge these two pieces of information. That’s what happens in the next step:

     
     

2. Render tree Render tree is another tree-like structure of all the visible elements that suppose to be rendered on the screen.

3. Layout At this stage, the browser tries to find the geometry and coordination of each element within the viewport and basically draws some sort of map for itself to know where the elements should go.

   
   

4. Paint It paints Backgrounds, border colors, etc. and at this point, we see something on the screen.

5. 
   

Within all of these Phases, there are only two points that developers have access to an API: DOM and some parts of CSSOM.

CSS Houdini

A couple of years ago a group of people from W3C and other web communities agreed on a manifesto called Extensible Web Manifesto. The main idea of this manifesto is to move the focus from creating high-level APIs to providing low-level APIs and exposing the underlying layers. As result, a lot of changes and new APIs came onto the web, and the name of all these new APIs in the CSS world is CSS Houdini and it is going to enable developers to have access to every phase of the rendering process and extend its behavior.

Typed OM

Typed OM is an upgraded enhanced version of the CSSOM. It will add types to CSS values in the form of JavaScript objects. On top of that, it will provide a set of semantic APIs that makes working with CSS in JavaScript more pleasant.

• With CSSOM:

const fontSize = getComputedStyle(box).getPropertyValue("font-size");
// 16px (string)

• With the new Typed OM

const fontSize = box.computedStyleMap().get("font-size")

• Setting a transform

const x = CSS.percent(-50);
const y = CSS.percent(-50);

const translation = new CSSTranslate(x, y);

box.attributeStyleMap.set(
	"transform",
	new CSSTransformValue([translation])
);

Properties and Values API

Custom property or also known as CSS Variables was a cool feature, but it had some downsides. For example, the browser didn’t know how to animate them, because it didn’t have enough information about these properties to animate them. With all the information that we can provide to the browsers through this API, they can now apply transitions and animations to these custom properties.

• JavaScript

CSS.registerProperty({
	name: '--my-color',
	syntax: '<color>',
	inherits: false,
	initialValue: 'pink',
});

• CSS

@property --my-color {
	syntax: '<color>';
	inherits: false;
	initialValue: 'pink';
}

Paint API

We can now write scripts and pass them to the rendering engine and the rendering engine run it on a specific rendering phase, but we can not write those script in the main javascript body for two reasons:

1. These scripts should not have access to the DOM environment, because when a rendering engine is for example at the layout phase, it assumes that DOM is not going to change.

   
   

2. The rendering engine should be able to run these scripts on other threads than the main thread.

   
   

The Solution is a Woklet. Worklets (pretty much like web workers) are independent scripts that run during the rendering process. They are run by the rendering engine and are thread-agnostic.

Houdini has introduced three worklets:

• Paint Worklet or Paint API
• Animation Worklet or Animation API
• Layout Worklet or Layout API

  
  

and that’s how we use it:

1. Register the worklet by a name using registerPaint
2. Add the script module in HTML or JS file

CSS.paintWorklet.addModule('worklet.js')

3. Use it in CSS withbackground: paint(worklet_name)

A paint Worklet:

class ImagePainter {
  static get inputProperties() { return ["--myVariable"]; }
  static get inputArguments() { return ["<color>"]; }
  static get contextOptions() { return {alpha: true}; }

	// The only mandatory method
  paint(
      ctx, // CanvasRenderingContext2D
      size, // The geometry of the painting area
      properties, // List of custom propertes
      args // List of arguments passed to paint(..)
  ) {
    
      // Painting logic
      
  }
}

// Register our class under a specific name
registerPaint('my-image', ImagePainter);

Writing a paint Worklet is very much like writing canvas, but what makes it super interesting is that from now on the creative developers can build these pain Worklets and then share them as npm packages and then lazy developers like me can just go ahead and install them in our apps and as easy as that you have new possibilities in your css, its like having plugins in your css.

Useful Links:

---

My Sweet Stack

- Senior Frontend Engineer at Passionate People As a developer with a passion for those sweet fresh stacks who likes to play around new technologies, Dexter goes over his "perfect" stack, using graphQL, SvelteKit, Docker, and Github. He likes to control the things that he makes to be able to understand all the parts to know how to fix and change them.

I've been honing this stack for many projects, and it's a dream.

In the developing I like to be in the flow state when you not really get in to the details. It allows me to keep creating new things and to keep playing around with those things.

Server

A simple VPS dunning Debian.

I do some things with the clouds, but mostly i just like to run on my own server with the versions i control and i got to choose who accesses my systems.

Docker

He uses containers to separate parts and docker-compose to control the bits.

Postgres

He believes this is:

The one database to rule them all, its Powerful, “scaleable” and functional.

API

to manage the data in Postgres:

• Hasura, which gives you instant GraphQL & REST APIs on new & existing data sources and accelerates API development.
• Supabase, which is an open-source Firebase alternative. You can start your project with a Postgres Database, Authentication, instant APIs, Realtime subscriptions, and Storage.

Framework

Svelte

I like how easy it is to get started and to make some components and to get growing with it.

Continuous Development

Gitlab or Github CI Then he shows some example projects and how these Tech stack works, which is hard to summarize in this article, but let me know if you want me to dive deeper into it in another post. In the end, he talks about serverless and the reason why he is not a fan of that:

Because you are not in control of where your software is running, your file system calls, what api limit you have or what access control there is.

He believes often it’s not necessary to worry about the scalability that serverless gives you because “You are not Google”.

The most of the projects we build are not necessary to be in google scale. Its just simple things for 100 or 1000 people, a simple website with less traffic, And then if you are being successful its always easier to scale than to scale primilarly, to learn about all the details and limits.. If you control all the parts or make all the parts really simple it would be much easier and you can be much more creative.

---

End of Part I

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can read the second part here, the third part here, and the last part here, where I summarized the rest of the talks which are about:

• Fourth Talk: Gift begins with how servers have been managed in the past, continues with how it got better over time with serverless, and what can we expect with Cloudflare Edge services.
• Fifth Talk: Stacy talks about creating a personal brand (blog), using Angular, TypeScript, and static web apps in Azure, and eating the elephant one bite at a time.
• Sixth Talk: Sendil’s talk is about performance and why it matters. He gives some great tips to improve the performance of your app.
• Seventh Talk: Natalia talks about a new provisioning experience in Azure Developer CLI which goes Public preview at end of June.
• Eighth Talk: Max shares lessons he learned after dealing for 4 years with Micro-Frontend at DAZN.
• Ninth Talk: Eleftheria talks about UX and UI from the perspective of both users and developers and why you should care as a developer.
• Tenth Talk: Jemima takes a look at the humble beginnings of JS and how it exploded into the chimaera of frameworks and libraries that we have today
• Eleventh Talk: Gert Talks about upcoming Storybook 6.4, 6.5, and 7.0.
• Twelfth Talk: Wim’s talk is about the problems or difficulties that must be overcome to allow our app to move freely to the phones of our end users and give ourselves the necessities to keep this app running.
• Last Talk: Samuel’s talk is mostly about experience. What is the best developer experience? Are the answers in SDKs, Relations, Love, or Thunder?

Also published .