dotJS 2018 — Retrospective
Last week, dotJS welcomed over 1500 JavaScript enthusiasts to Paris — enpit sent Janis Krasemann and me along with them. The crowd was eager to listen to some of the industry’s most influential people talk about what we all love: JavaScript. A whole day of JS-goodness was in store for us and the dotJS team had done a fantastic job of curating a day with high-quality talks about different topics — from type systems to Minecraft, from framework-hell to dancing robots.
JavaScript in the field
What are the interesting things that some of us do with JavaScript? How do we use it and what are technologies that we find intriguing?
The day started off with Sacha Greif (@SachaGreif) presenting the results of the 2018 edition of his State of JavaScript survey. The full results will be published soon, but some of the takeaways from a quick look at some of the most popular JS technologies were that:
- React is going strong with high usage numbers and high developer satisfaction,
- developers use Angular a lot, but are not quite so satisfied with their experience,
- Vue is on a great trajectory with a lot of interest from developers who are currently not yet using it, but hope to do so in the future
- GraphQL became more popular over the last two years, and while developers are definitely interested, it is not yet widely used
Besides the big contenders like Angular and React, new libraries and frameworks seem to pop up every day. The abundance of these has become so ridiculous that it has become a running gag in the scene. So how to actually choose a JavaScript framework? You can argue a lot about a framework’s number of stars on GitHub, available plugins, documentation, its pros and cons in various, and all of that is fine. But when talking to a couple of people from different framework camps, John Papa (@john_papa) found a common theme in their explanation of why they enjoy a certain framework: “It feels good”. John made the point that our productivity and enjoyment with a framework is subjective to us and we should not feel insecure about our framework of choice, when it feels right to us.
This question of feeling might very much apply to another technology — not a framework in this case — that seems to be more and more commonplace in the JS community.
Not my type
One of the technologies that, according to the State of JS survey, is seeing a growth in developers using it, is TypeScript.
Oh, no! Another technology! Why would I need this?!
Two separate talks made a strong case in favor of using TypeScript: By Lauren Tan, who approached the topic by giving a theoretical motivation for using type systems in general, and by the inventor of TypeScript himself, Anders Heijlsberg. Lauren (@sugarpirate_) framed the topic in a smart way: By constraining the domain of the values in your code, you limit the possibility space for unexpected behavior. Of course it helps, that type systems correspond to algebraic models and proof theory, which provide solutions for analyzing such systems. In a sense, type annotations are propositions and code is proof, which allows algorithms to verify these propositions. The knowledge about our code that those algorithms gather, can help you and your IDE catch a lot of mistakes early, and reduce the number of ways that your program can fail.
In the JS environment there are two famous implementations of static type checking, one of them being TypeScript. Anders Heijlsberg (@aheijlsberg), of Turbo Pascal- and C#-fame, created TypeScript at Microsoft and seems to work closely with the Visual Studio Code team to integrate TypeScript support into the editor. He demonstrated a bunch of things that the TypeScript compiler can do for us — even if we are not even writing TypeScript! Two of the main features, that might make TypeScript appealing even to opponents of strongly typed languages are:
- A strong focus on type inference, so that we don’t have to be overly verbose with our type annotations, and
- structural typing, which basically means that the compiler will happily duck-type objects that are nominally of different types, but structurally compatible — that kind of flexibility is, afterall, why we enjoy writing JavaScript so much, isn’t it?
Technologies of Tomorrow?
TypeScript is neat and all, but what is even better are fast websites! And a technology that promises to make the web faster is HTTP/2. But much to Tara Z. Manicsic’s (@tzmanics) dismay, developers don’t seem to appreciate this new standard. Tara tried to take our fear by explaining how the implementations of HTTP/2 have matured since its initial standardization… and in which aspects they haven’t.
Maybe we software developers are just not enough server-admin types to figure this stuff out. We want nitty-gritty programming language features like top-level await. A moderately big question mark since the introduction of async/await in JavaScript has been, how that feature could ever play nice with the module system. Gladly for us, Myles Borins (@MylesBorins) is on the case and involved in the standardization of top-level await by TC39. He talked about the status of the proposal and explained the different semantics that are possible to resolve dependencies involving async modules.
It’s the little things
The regular speaking sessions were loosened up by slots for lightning talks. And while I don’t want to make this article even longer than it already is, I have to mention the high-quality talks featuring:
- Jeremias Menichelli (@jeremenichelli) about asynchronously loading webfonts,
- Tim Pietrusky (@TimPietrusky) about using WebUSB to talk to an Arduino,
- Roy Derks (@gethackteam) about the downsides to boilerplate,
- Sam Wray (@_2xAA) about better render performance with off-screen canvas,
- Adam Weeks (@AdamWeeks) about debugging JavaScript code,
- Mael Nison (@arcanis) about Yarn and locating modules,
- Kashyap Kondamudi (@kgrz) about composing promises,
- Tejas Kumar (@_TejasKumar) about WebAssembly,
- Olivier Loverde (@loverdeolivier) about the CQRS pattern, and finally
- Joost Lubach (@joostlubach) with an incredibly entertaining visualization of asynchronous program execution.
So shoutout to these guys. And while we’re at it: For this awesome event we have to thank the great team behind it, including Sylvain Zimmer (@sylvinus), Ferdinand Boas (@ferdinandboas), Dorothée Hachez (@doh1313) and Vincent Zimmer (@vinczimmer), and of course the glamorous host Christophe Porteneuve (@porteneuve).
JavaScript Everywhere
JavaScript on the desktop has a bad rep, according to Felix Rieseberg (@felixrieseberg) — and he’s right. A huge number of Electron apps, one more sluggish and memory-hogging than the last, keeps being released. But it doesn’t have to be that way! Felix gave some great tips and tricks as to how we can make our desktop JavaScript code more performant. The caveats he pointed out were to
- mind your modules: Think about what the runtime has to load before the UI gets displayed. Do you really need that npm module?
- respect the re-renders: When part of your UI state changes, make sure to not repaint other components unnecessarily.
- leverage lifecycle methods: Use a component’s lifecycle methods to your advantage by properly registering — and even more importantly —
de-registering callbacks.
If you do it right, your users won’t even notice that an application uses JavaScript. After all, nobody complained about the JavaScript in Battlefield One, although the ingame UI is rendered via React!
Speaking of games: Tobias Ahlin (@tobiasahlin) from Mojang, the creators of Minecraft, shared interesting insights into their current efforts to create the future Minecraft UI using JavaScript. They use an optimized JS engine that runs on virtually all platforms to interpret their code, so that they can deliver a performant result on all the devices that run Minecraft today. The new UI is not yet publicly released and still a work-in-progress, but according to Tobias, the convenient tooling and workflows that JS developers are used to, were a welcome surprise for the game devs. They are now able to iterate over new ideas faster — and to tap into the market of millions of JavaScript developers when it comes to hiring.
Ok, apparently you can build AAA games using JavaScript. But surely JavaScript has its limits and you couldn’t use it for, say, high-performance use-cases like a CDN. Well, yes you can. Or at least, Kurt Mackey (@mrkurt) can. He is tweaking the V8 engine itself to get the performance necessary, that let’s his users define rules for his CDN fly.io using JavaScript. This enables them to easily provide functionality on top of their application, that they can deliver as close to their customers as possible.
We write a lot of JavaScript code for the web, the desktop or for mobile. But JavaScript is truly everywhere!
And if you want to give yourself the special treat and let your robots dance to the beat of some music, you better ask Devon Lindsay (@devonbl). She not only defined dance-routines for their robot squad, but figured out how to push these routines to the bots over Bluetooth. And while JavaScript is not particularly known for its applications in real-time scenarios, the three little robots performing a choreography in sync — of course live in front of the dotJS audience — showed us: It works!
Speaking of “it works”: I gotta get back to it, so thanks for reading and happy coding!
PS: Check out the official photo gallery.
