Takeaways from dotJS 2019
We had the opportunity to attend dotJS Day 1 this year. Here is a sum up of the most remarkable takeaways and themes !
Accessibility Was the Most Recurrent Topic
Web accessibility is not something new, but it was a recurring topic this year and was mentioned by several speakers during the event as well as by developers from the audience.
Sara Vieira reminded us in her talk Make the Web Easier for All of Us that “form placeholders are not read by some assistive technologies.” When talking about how much we are overwhelmed by the demand, Chris Heilmann mentioned performance, security, and interoperability, but also accessibility.
Making the web accessible is not just about allowing people with disabilities to perceive and interact with it, but also allowing them to contribute to it — we often forgot that. It’s also about improving the experience on every device (mobile phones, smart watches, smart TVs, etc.) and slow connections.
Like a lot of things, developers expect accessibility to be a default. It is quite impossible, of course, because we are still responsible for our applications, but UI kits could — and should — help us with that. Unfortunately, they still have progress to make.
After the JS fatigue Came the “Migration Fatigue”
Angular bashing at dotJS is still a thing, but it has become less and less so. Last year’s dotJS was an opportunity for the audience to wake up each time a speaker was trolling (or simply talking about) Angular. This year, only one speaker tried to get a reaction, which was surprisingly small…
… Maybe because Igor Minar was there to give a speech in the afternoon.
He mentioned a “migration fatigue” in the world of the web. “Web platforms are ubiquitous, accessible, malleable, evolving, yet stable,” whereas the web ecosystem does not manage to be stable. While web is “evergreen,” libs are not. Well, except Angular (according to him).
Still, the migration of AngularJS 1.x to Angular was a good example of handling annoying breaking changes. He explains this by the cost of not having breaking changes on their side. Among other things: the burden of maintenance, payload size, and accumulation of API cruft.
But “Angular updates work now” — according to him — thanks to their efforts:
- Semantic versioning
- Time-based releases
- Deprecation policy and docs
- Testing at Google
- Static analyses
- Automated migrations
- Fixes of common anti-patterns
To beat the migration fatigue, developers still “must do their part of the work to ease migrations by updating more often.”
Progressive Enhancement Is Being Embraced, As Well as the “JAMstack“
Pushed by Google in particular a few years ago, progressive enhancement and Progressive Web Apps (PWA) are now technically embraced directly within the frameworks and have even become a selling point for both SEO and fast content displays.
Tim Neutkens mentioned the capabilities of pre-rendering in Next.js. He encouraged the audience to embrace SSR (Server Side Rendering) and SSG (Static Site Generation). Today, both React and Vue provide hydration, the process of turning static HTML from the server into interactive DOM that reacts to data changes, and that is very impressive.
Same point of view from Phil Hawksworth, DX at Netlify, during his talk Exploring a Server-Less Web. “Static first + enhancement if required” is now his go-to.
He used a word I had honestly never heard before: JAMstack or “JavaScript, APIs, and Markup” stack. It is a fancy word to refer to the way of working on static sites (sites without databases). The kinds of things you can easily do with static sites generator like Jekyll, Gatsby, or Hugo, but also with Nuxt and Next now.
Of course you cannot easily embrace a JAMstack in the real world with a SPA working on top of a monolith, but it is interesting to see the growing community, tools, and products around this. In particular, Netlify has built its business around it, and it seems to work well.
Inheritance Does Not Work Well with Components; Composition Does
During his talk State of Components, the infamous Evan You encouraged us to see components as “instantiable and stateful modules.” He stated that logic reuse could be challenging with classes, which are probably not the most natural fit for designing components. The language does not help a lot, as class fields and decorators are still respectively at stage 3 and 2 as of today.
The future of component development is written by the frameworks for now. Vue 3 is to be released for Q1 2020, and one of the most expected changes is the answer to React Hooks: The Composition API. It is a new function-based approach to writing components.
Just like React Hooks, the Composition API exposes mechanisms currently available through component properties into JS functions called compositions functions. For instance:
ref: Wraps a primitive and returns its reactive referencecomputed: Declares a computed propertyonMounted: Access to the mounted lifecycle hook
It allows you to encapsulate code logic and reuse it across components.
This is a new — and in some ways cleaner — solution for sharing code compared to what Vue currently has:
- Mixins, with which it is not easy to know what is added to the component.
- Scoped slots, only accessible from within the templates and only for the component where they are used.
We Have Become “Full Stackoverflow Developers”
It is Christian Heilmann that introduced us to this phenomenon. It refers to developers that often copy paste code from Stack Overflow without understanding what they are doing.
He recalled a time when developers used to learn before coding. Now we get caught in the rush of new things, overwhelmed by the demand, so we rely heavily on libraries, frameworks, and services that do things we cannot learn all by ourselves, hoping they will do well for us.
He admits he has no solution for all of these issues but that there is a natural approach he would like everyone to follow: learn while coding and debugging. Using context documentation through linting is one possible way.
Making Cross-Frameworks Design System Is Smart
Why should we pick a particular framework when developing a design system when the low-level component model is sufficient to build reliable components?
In his talk Architecting a Component Compiler, Adam Bradley explained why at Ionic they decided to stop using only Angular: large organizations of many teams often use different frameworks, which makes the UI consistency challenging.
That is why they created Stencil, a compiler that generates web components, which means they can natively run within any framework. Their built-time tools enhance the possibilities with Typescript, JSX, a tiny Virtual DOM layer, one-way data binding, asynchronous rendering pipeline, lazy-loading, etc.
Tests Are Often a Third User, and It Is Sad
Testing frontend is not an easy thing; false positive errors are common, and we sometimes have to spend time fixing the test instead of fixing the code.
This happens when tests are written as a third user (the first ones being customers and developers). Starting from this statement, Adrià Fontcuberta from Holaluz introduced us to testing-library. It helps us do tests the right way by following two principles:
1. Avoid relying on the implementation details and
2. Act as a user would act (using DOM interactions).
Of course, and as he said, what matters is following these principles, not specifically using testing-library.
What about Svelte?
Not that much.
Last year, the trendy topic of DotJS was TypeScript, which was not surprising. Now the language is used by every major framework and is widely adopted by developers.
We could have expected the 2019 edition to be the year of Svelte; it was not. Only one lightning talk was dedicated to it, and it was only briefly mentioned by Evan You and Tim Neutkens (who gave me the opportunity to hear about Sapper for the first time).
The thing is, Svelte is already in its third version, and yet it was not such a hot topic this year. This could be explained by the fact that we already have three major frameworks, and that’s already enough. Plus, Svelte is not a framework but a compiler, like Stencil, and people are not really used to this way of building components. Maybe next year… maybe not.
Some Cool Stuff to Discover
Final Thoughts
DotJS 2019 was overall a good conference, with some great talks throughout the day. The speakers came with very different topics and different ways of making websites along with a few specific — but very interesting — talks.
While we come out of this event having learned some new things and being inspired by the charisma and motivation of the speakers, we can also be confused by how people disagree about how to make websites and how it seems that the same topics and debates tend to disappear and then come back again and again without proper and unique solutions. But that is probably for the best.
