- 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
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
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 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,
- 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).
- 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 —
Speaking of “it works”: I gotta get back to it, so thanks for reading and happy coding!
PS: Check out the official photo gallery.