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 , , and , where I summarized the rest of the talks. the second part here the third part here the last part here (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 and I have only tried to learn them so that I can turn them into these articles. Even 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) Everything you read during these few articles is the result of the effort and time of the speaker itself, many of the sentences written in these articles are exactly what they said or what they wrote in Slides. 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: JSWORLD 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 Colin Ihrin 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 . 10 Things he regrets about node.js 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. Deno - A modern runtime for JavaScript and TypeScript 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 Deno introduced at JSConf EU June 2018: Deno v0.1.0 released, rewritten in Rust — previously written in Golang. August 2018: Having to garbage collected languages inside the same process might not be the best thing. Deno v1.0.0 released May 2020: The Deno company was announced March 2021: Deno Deploy announced June 2021: Deno Deploy reaches GA Q3 2022: 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. Deno CLI The idea is that Deno is pretty much battery included compare to historically Node.js which was not. Standard Library Deno - A modern runtime for JavaScript and TypeScript https://github.com/denoland/deno_std 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 "https://deno.land/std@0.141.0/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. deno.land/x 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 "https://deno.land/std@0.141.0/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 is provided to create a function for loading CJS modules. It also sets supported globals. createRequire(...) require import { createRequire } from "https://deno.land/std@0.140.0/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 Announcing the Web-interoperable Runtimes Community Group 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. Deno Deploy CSS Houdini - Software Developer at Lightspeed Commerce Negar Jamalifard 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. — [MDN] 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. CSS Houdini - CSS: Cascading Style Sheets | MDN 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. 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: Render tree Render tree is another tree-like structure of all the visible elements that suppose to be rendered on the screen. 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. Paint It paints Backgrounds, border colors, etc. and at this point, we see something on the screen. 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: 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. 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: Register the worklet by a name using registerPaint Add the script module in HTML or JS file CSS.paintWorklet.addModule('worklet.js') 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: houdini.how CSS Houdini Experiments Is Houdini Ready Yet? A CSS Houdini library My Sweet Stack - Senior Frontend Engineer at Passionate People Dexter (Alexander Essleink) 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 , , and , where I summarized the rest of the talks which are about: the second part here the third part here the last part here 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 . here
