DotJS 2024: a day dedicated to Javascript

This year, the first Dotjs Conferences since Covid took place in Paris on June 27th: for those of you who have never heard about them, the dot conferences are a series of annual conferences started in 2012 on various topics/languages and put on hold from 2020 to this day due to Covid. Clearly, this edition's goal was to strengthen the Javascript community through various talks held at the Folies Bergères in Paris.

(Last time I was at the Folies Bergères was for the Drag Race France tour, needless to say the atmosphere was a bit different...)

As a former organizer of professional events myself (especially conferences) I can only praise the overall organization: the rhythm of the talks was very well thought out, with an alternation of 20-minute talks, 5-minute talks, and discussion time. Having a single track of talks was also particularly appreciable as it ultimately forces us to follow through the entire day and share a full experience of the conference together.

My goal is not to report on each talk individually. They are available on their YouTube channel, and I encourage you to watch them in full. This article aims to highlight, in a memo format, the elements that struck me the most and made me think, or want to delve deeper into certain topics. To be honest, it is is almost a literal transcription of my summary of the day to my developer partner (so it could be titled "fresh abstract from a tired but satisfied junior dev to a senior dev who no longer gives a shit about talks").

💖 My favorite talk

Two talks equally won me over: Ben Lesh's and Léa Verou's.

I can do both: Ben Lesh and how to see your code in a new light

Ben Lesh introduced the conference, and let’s be honest, his talk was a bit tough for beginners. Many thanks for the M&M’s metaphor, though, as it made your point much more accessible for novices like me. I truly think that’s what makes a good talk: everyone can get something out of it. It’s not jargon-heavy, so you understand the basics, but it’s also technically and conceptually sharp enough that any experienced developer can also learn from it (even if they don't necessarily agree).

Ben’s point started with quite a simple observation: in our code, there are “consumers” who “pull” and “producers” who “push.” Each line of code "pushes" or "pulls." The “consumer” receives the value. For example, in:

const value = getValue();
console.log(value);

value and console.log are the consumers because they receive the value and call the function. The producer here is getValue() for it provides the value.

Problem: "pull" - or consuming - is a synchronous action. "Pull" treats any information as its own pace, which definitely is a good point. But if the producer has no more information to provide (for example, the bag of M&Ms is empty, so sad), it will have to wait. "Push," on the other hand, is synchronous OR asynchronous. Pro: it can build a whole M&M’s factory if it runs out. Cons: if it goes too fast, its consumer will experience "back pressure" and eventually become overloaded.

The strength of Ben’s talk was to make us understand all this quite thoroughly using concrete cases with different functions (a for loop, a promise, etc.) to explicitly illustrate what "pushes" and what "pulls." He also presented us different types of "pull" (a function, an iterable) and different types of "push" (callback, promises, observable) with less simple cases to read, such as in async-await functions or iterable.forEach((value) => {/* ... */}) (forEach "pushes," everything in between "pulls").

Armed with these concepts, it is possible to change perspective on code and reread it to see which elements produce and which elements consume, but more importantly, how they are interconnected. The different articulations can, in turn, be typologized, as Ben did by emphasizing there isn’t only push and only pull, for you can also “do both.”

I came away with a new resource for reading code and concepts to explore further, such as signals and observables, which were also featured in many other talks throughout the day, such as Ruby Jane Cabagnot's.

Lea Verou: Aren't Developers Users Like Any Other?

Lea Verou's talk was on a completely different subject - API design - with a rather solid hypothesis: API design is design. This means applying all the rules that apply to general app design for particular users, except the users here are often developers. Isn't dev experience ultimately just like any user experience? Aren’t developers ultimately users looking for easy-to-use, efficient, and understandable tools?

For example, take the SVG API (what an idea, but why not, let’s do it): to get the radius of a circle object, you have to go through three different objects because the whole complexity of cases you might eventually, possibly encounter or need is provided... monolithically. BAM. Lea Veroux advocates for a simple design paradigm:

simple things should be easy, difficult things should be possible.

This implies revealing the complexity of an interface progressively and knowing the use cases of your API well enough to know what simple things should be easy to do and what more complex, but rarer, things should be possible.

Apart from not wanting to use the SVG API at all, this talk left me with a few useful tips for designing APIs:

1. to encapsulate complexity (and a good way to do this is by relying on a hierarchy of complexity),
2. no boilerplate,
3. layering,
4. testing (if testing for users, why not testing for developers, who are presumably users like any other).

🥞 Miscellaneous

Among the other talks of the day, Minko Gechev tried to convince me that Angular and React were similar, but I'm still not very sure about it (sure, Trump and I are both human beings, but are we the same, though…). James Quick and Jessica Sachs fed my passion for the history of JS, making me ever more certain that it’s important and quite fun to understand where we come from to know where we are going. Finally, even after seeing Alex Moulineuf's project for the thousandth time, I still found it amazing. He always succeeds in convincing us to work together.

🔒 Privacy and Responsibilities: There is No Privacy in Software if We Don’t Build It

The “big question” moment was beautiful, and I particularly appreciated the fact that speakers with divergent opinions could share the same stage, for instance about passkeys: the future of security according to Maud Nalpas, not as much to Eleanor McHugh. The latter demonstrated you could make a lasting impression in five short minutes: her political commitment to privacy and holding developers accountable on these issues is close to a public service mission.

Her work on this matter is huge and her talk showed that apart from teaching many things, a good talk points to the relevant resources to continue learning, discovering, and improving on our own. Thank you, Eleanor, for this moment; I will read your books and your work with great attention.