DEV Community: JS Kongress

Thank You 🙏

JSKongress — Fri, 30 Oct 2020 17:53:38 +0000

In the current situation we don’t deem ourselves able to create a JSKongress as fun, as welcoming and an amazing experience that we always want to offer to YOU. Therefore we take a break. (If you had a ticket for the 2020 edition, you have received a refund note – please get in touch if you didn’t.)

First of all we want to THANK YOU: A lot of thanks for the great time we had together! Thanks to everyone involved, friends, guests, speakers, partners and volunteers. Thank you for joining us, each one of you has contributed to creating a wonderful experience. Any less would have been a missing piece of the puzzle. 🧩

Thank you for the priceless moments in breaks and in between talks. For the worthwhile chats and drinks on the parties. 🍻 For the table soccer games – won and lost. ⚽ For looking beyond our noses – in technical problems and every day questions. Thanks for letting us be ourselves. Thanks for our shared years of JSKongress and DeepTrack, for all the sessions included and all the sessions planned, all your preparation and time and heart invested. For every single session in sign language 🤟 and the corresponding applause in gestures. 👋 For the groovy music in between and in the evening. 🎸 For every drink, that we cheered with. Thank you for every cat and unicorn. 🐱 🦄

Today is not the end of time, we will return some time and are already looking forward to meeting you again ❤️

Your JSKongress Team

Béla, Jowe, Kerstin, Natalie, Marco E, Marco S and Robin … as well as Axel, Cornelia and Julia

Why do you “Servus” me?

JSKongress — Tue, 14 Jul 2020 18:16:44 +0000

Editing this week’s newsletter issue – by the way, subscribe here to get the updates first – I wonder if our Bavarian greeting leaves you wondering. So I decided to write this entry.

1. Servus? Servus! 👋

pronounced /ˈsɛrvus/ or /ˈzɛɐ̯vus/

Like the Italian “Ciao”, Servus can be used for “Hello” as well as for “Good bye” and is the ellipsis for “servus humillimus (Domine spectabilis)” or short “At your service”. And it’s used in many other places than only in Bavaria and Austria.

We Bavarians – I grew up in a small Bavarian town 100 km from Munich. Even rather a village with a population of 400. Please forgive me for not including all Southern-Germans as well as Austrians in each sentence, I am thinking of them as well … We Bavarians might not know the long form of the complete servus-term, but we are very aware that it’s more formal and friendly than saying “Hello”. And it’s suitable for everyone, a person older than you as well as someone you are connecting with in business relations. As well “Servus” is the perfect greeting for best friends, it suits everyone. Servus is honest, it’s warm and it’s inclusive – directly from the heart. 💙

So next time you meet someone, greet them with a warm Servus 🙂

Another greeting you might notice around here is “Gruess Gott!” (salute god). This is suitable for everyone as well and very respectful. Most young people wouldn’t greet their close friends like this, but I have been raised greeting all the people I meet in the street like this.

2. The statue in our design: the Bavaria

The Bavaria, or “Mama Bavaria” as we call her intimately, is situated right next to the Alte Kongresshalle, where JSKongress takes place in Munich. Find her placement on Google Maps. The Bavaria is the embodiment of our homeland Bavaria. She watches closely over us – as well as she does watch closely over the Oktoberfest, which takes place directly at her feet.

The JSKongress takes place in the “Alte Kongresshalle”, a landmark of Munich culture and a unique venue, which is why we chose it. This unique and spacious location, together with its inspiring surroundings, contribute to a pleasant atmosphere during the conference each and every year. See more of the venue itself on our website.

As such an iconic symbol, we included her in our design to transport the atmosphere of the location and venue of JSKongress. On a sunny day – and not just then, but then in particular – it’s awesome to visit Mama Bavaria and stroll through the Theresienwiese and Bavariapark.

3. JSKongress Munich

The conference grew out of MunichJS, one of the largest JavaScript user groups in Germany, also attended by people from Austria and Switzerland. Also JSKongress is located in an ICT hub: Munich is one of the most important ICT cities in Europe.

And Munich is as well known as “world city with heart”, or as it has been stated a couple of times: “Laptop and Lederhosen”. 😄

What did you think when receiving your first newsletter issue? Amazed by all this Bavaria cult? Or have you actually been a member of the MunichJS meetup before? Since when do you receive your newsletter? Do you remember your favorite issue? As well we are interested: Did you nearly un-subscribe some time? Would you like to read more about other stuff, which kind of?

Question after question.

———

Please let us know! ✉️ We’d like the bi-weekly JSKongress newsletter to be a fun couple of minutes of your day. So we want to design it for YOU!

Yours truly, Kerstin

———

Sources:

https://en.wiktionary.org/wiki/servus

https://en.wikipedia.org/wiki/Bavaria_statue

#jskongress meets #RxJS Core Team

JSKongress — Tue, 30 Jun 2020 13:48:01 +0000

> “Welcome to our 4th session with the RxJS core team.”

So just to give you a quick introduction, for the ones who are watching this live stream the first time [or reading this blog post tying up with it]. “JSKongress meets friends” is a format that we want to invite people and teams where we think that they can answer some quite interesting stories of some tools, maybe you’re using as well. And also like getting some more insights, which you can’t read on the blog posts. You’re also able to ask your question directly on twitter using the hashtag #JSKongress or on the YouTube live chat, where I already see a couple of people chatting around.

So welcome to this edition. I’m Johannes, I am the MC for today and one of the organizers behind JSKongress. And I’m happy to welcome Jan-Niklas, Tracy, Moshe, Ben and Nicholas.

Check-in

So I would like to start with a quick warm-up question. So Jan-Niklas, let’s start with you: Where are you currently located, how are you doing, and can you remember the first time you got in contact with RxJS?

Jan-Niklas: yes yes yes, okay so I am located in Krefeld in Germany. I’m still melting because it’s freaking hot here. And I’m definitely not able to handle heat properly, so I’m just dying and not properly or active in any way. What was the second question?

jowe: Can you remember your first time with RxJS?

Jan-Niklas: yes, actually quite funny. I’m not sure if the others know that, but the first time I worked with RxJS was in an Angular project, Angular 2, in the release candidate phase. And I worked for like half a year in that project, and I had no freaking clue about RxJS. I didn’t get anything. And then I got in contact with Tracy and started contributing to the docs. And that’s pretty much how everything started and before that I was using switch paper all over the place is pretty much and subjects like professional.

Jowe: That’s been a good transition to Tracy. 🙂 So Tracy, who are you, where’re you currently located, and can you remember the first time you get in contact with RxJS?

Tracy: yeah sure, my name is Tracy. You can follow me on Twitter @ladyleet and I am currently located in Atlanta, Georgia. So all those Southerners out there. 🙋 But my first contact with RxJS was actually – you know – I was just learning JavaScript and I knew Ben. Ben was a good friend already. And I said: Okay Ben, I got JavaScript down after my second week of JavaScript, and whatever’s in that fly export Ben was working. I said: ok, teach me RxJS! And then opened up, you know, opened up the code sandbox or whatever we were using. And he was like: okay, cool, here’s an observable bubble or whatever. And then shortly thereafter he’s like: Let’s take a step back, and why don’t we learn JavaScript first. So that was my first experience with RxJS. And obviously come a long way since then.

Jowe: Moshe, who are you, where you are currently located, and can you remember your first contact with RxJS?

Moshe: all right so my name is Moshe Kolodny. I am located in New York and my first contact with RxJS was when I joined the firebase team. We were working on the firebase console and it was an Angular 2 / Angular.js hybrid application. So my first contact with RxJS would probably be ngrx – with you know – the Redux version of Angular or the Angular version of Redux. So that was my first experience of it.

Jowe: Nicholas, can you tell us, where you currently located and what was your first contact with RxJS

Nicholas: sure, I’m Nicolas Jamieson, I’m located in Brisbane in Australia, and my first contact with RxJS would have been in the Angular 2 beta, fairly early beta. I’d used .NET versions of rx before and it’s Angular 2 and the beta in the pre-release. And all that sort of a saga was my introduction to RxJS.

jowe: so Ben, who are you, where are you currently located, and what was your first contact with RxJS?

Ben: oh well, my name is Ben Lesh, I’m currently in Austin, Texas. Just not but a year ago I was in the Bay Area at Google and before that Netflix, and my first contact with RxJS was at Netflix, where it was sort of -I don’t know – thrust upon me. And I was like “what is this like Lodash or why do we have this? So I’m the RxJS team lead now, and that started because while I was at Netflix there was an effort to rewrite RxJS, and I was tapped to do that. Despite some protests on my part that I was not qualified to do that. So but here I am, turns out I was qualified – I guess – and I’m still working on it five or six years later

jowe: so thanks for an introduction and for giving a quick introduction of you. So glad that you join this session, and let’s start kicking off the questions.

What is RxJS?

So I am pretty sure a couple of humans watching this episode of #jskongress meets friends [ov: “this stream”] are not so sure about what RxJS is. So can you give us a brief overview of: What is RxJS?

embrace a reactive mindset, get used to functional programming

Jan-Niklas: so the RxJS is the kind of default implementation for reactive programming for JavaScript. So it’s not really much about Rx particular. But for using that properly you need to embrace a reactive mindset like you need to get used to functional programming. And what this reactive programming is pretty much about is the propagation of change. So something is happening; some change is happening – how do I react to that? Instead of saying “okay please do that kind of change” and this is a fundamental way how to treat programs pretty much. And RxJS provides the observable entity to deal with those kinds of changes that’s like on a very high level what RxJS deals with – from my point of view. I see Ben nodding, so this is like agreement.

Advantages of RxJS

Jowe: right, and how does RxJS make the life of an engineer better like what are the advantages when I’m using it

Moshe: So RxJS is great for when you’re working with highly type of events that could change over time. So when you need to compose those events or do things with complex workflows and pipelines for different things, you have click events coming in, then you have transitions. And you have all these different user events, and page load events, and different things happening on the page at the same time. Coordinating all that becomes a nightmare if anyone’s done it manually. But you could create beautiful pipelines in RxJS to be able to manage that and you can build up, you can start simple and build up. So there’s no need to kind of go all out to start. So it’s if there’s a ramp up area, as well. So that’s a couple of ways to make things much easier to do

> Core Concepts of RxJS: oberservables, observers, operators

Jowe: mm-hm, and what are the core concepts behind RxJS?

Nicholas: yeah, there’s a handful of core concepts. And that is tangible and there’s an intangible one. I’d say that the core concepts are really observables, observers and operators:

Observables are sources of notifications.
Observers subscribe to those observables to receive the notifications.
And operators are functions that take them observable and return a different observable. So they’re able to change the notifications that come from a source and float the sync.

The easiest way to sort of explain those components, is to use an analogy:

So an observable is kind of like an event emitter. But an event emitter – just, event emits one type of event, whereas an observable has three types of notifications. It can give you a value notification, to give you a value. It can give you an error notification to tell you when errors occurred. And it can give you a complete notification to tell you that they’re only gonna be no further notifications from that observable. So it’s kind of like an event emitter but it does a lot more.

And observers are kind of like the listener for your event emitter. But instead of just receiving one type of event you receive the notifications from the observables.

Operators – the analogy for an operator would be something the the methods, that are on an array in JavaScript. You’ve got methods like map and filter that allow you to manipulate the elements of an array. Operators are kind of similar: They lay to manipulate the notifications that are coming from a source and being received. So they still do the operators used in location.

Some people sort of refer to our experiences of the Lodash for events. Now you can sort of fit those analogies together to – you know – explain that sort of terminology.

Cool concept: guarantees

But there is another sort of cool concept: It’s largely intangible and that’s the guarantees. RxJS gives you a bunch of guarantees. Behavioral guarantees for example. If you receive … an observer received an error notification from an observable, it’s guaranteed that it will receive no further notifications from that observable. Similarly if it receives a complete, it’s guaranteed not to receive any further notifications from the source. And combined with these guarantees, those core components observables, observers, and operators allow you to declaratively compose fairly complicated floats. That you wouldn’t be able to do if you didn’t have those guarantees. If you didn’t have the guarantees you’ve been doing the sorts of things you might have to do with an event emitter where you’d have all sorts of – you know – if-statements and things like “if this has happened and this has happened then do this”.

But the fact that it gives you those three sort of core components and the guarantees means you can build all sorts of interesting things. It’s declarative.

RxJS for .NET?

jowe: I think I first got in contact with reactive extensions for Java a couple of years ago. So there is RxJava, Rx.NET. .NET for example can be used with JavaScript. Would it be better to use RxJS instead of Rx.NET?

Ben: So I mean, if you’re targeting JavaScript or TypeScript you’re probably better off using RxJS. Rx.NET – as far as I’m not even sure what you would do to use or accept it to target JavaScript. I’m assuming there’s some sort of compilation step, where it compiles the the C# into JavaScript or something like that. But that’s weirdly, that’s actually where RxJS was born. Like originally there was this project a long time ago called Microsoft project Volta which actually used the reactive X logo as its logo at Microsoft. The goal of it was to compile C# to JavaScript. And ultimately I believe it was axed because TypeScript became so popular and kind of fit that need better. But RxJS was originally developed as a compilation target for Rx.NET. So it had roughly the same shape. And when they built you know C# down to JavaScript they could use that library. But it’s the – to my knowledge – it’s the only surviving piece. I might have butchered some of that history. But I’m sure Matt will jump in at some point in comments and tell me where I was wrong [editor’s note: Matthew Podwysocki, RxJS alum].

But that’s the basic gist of it:

If you’re targeting JavaScript or TypeScript I would recommend using RxJS.

Jowe: yes, right, so we got a pretty good overview about what RxJS is. What are the concepts behind it. And what are the main advantages of using it.

Numbers and stats

So it would be interesting to see how widely it’s used. Do you track any numbers of downloads, like on npm? Because a lot of other libraries and frameworks are making use of RxJS. Would be interesting what kind of number if you have something.

Tracy: all right, RxJS right now – I believe last week it went about 19 million per week. So that number is consistently growing over time, which is awesome. You know RxJS is the only external dependency in Angular. So a lot of that … a lot of growth is in Angular. But actually RxJS exceeds the number of npm downloads from Angular. And that’s because a lot of folks are using RxJS whether it’s with Vanilla JavaScript or React or Vue. You know another thing is – I think it’s interesting to see the React adoption. So Ben and I run Rx workshops. And you know it’s great to see people from Angular, people from React, and people from Vue, all coming to these workshops to learn. As people are moving away from Redux we’re actually seeing more people use RxJS for cases where they want cancellation or streaming data that they want to compose. So the growth is very exciting. In fact Ben is actually doing React full-time now. He was previously on the Angular team but now he’s full-on React. And I think a lot of us are actually, I know Nicholas is too.

Report your usage of RxJS

Jowe: so regarding the numbers: Nicholas wrote a tool to anonymously report the usage of the RxJS API. How did the idea come up? And how does it work? Can you tell us about it, Nicholas?

Nicholas: oh okay, yeah that lastely came from a discussion that we had in the core team meetings, where we talked about just “how are people using the API”. So I wrote that on the weekend because it was related to some other code I’d been working on. I haven’t had a look at the actual reported stats this morning. I did have a look yesterday after I woke up. And disappointingly, they were 2 – two people had reported their usage stats. But I’ll have a look and see what’s there later today. One person did report a bug, which was cool! He reported a bug, he actually fixed the bug, and then he reported his stats. So that is awesome! But the main thing: I wanted to just give people a way of doing it where it’s completely anonymous and not automated.

I didn’t want to have something that ran in the background when you were installing RxJS.

Because it takes a bit of time. It’s also not something to be particularly comfortable doing sending information with someone’s computer when they’re just installing a package. But yeah not too many results reported yet. It’s promising and hopefully that will give us a good view of what people are using. Interesting in RxJS there are a couple of the things that were reported, did have a whole bunch of different versions of RxJS and in different versions of TypeScript installed so it’s obviously a mono-repo they’d run. Interesting from a number point of view.

Jowe: So I would like to report the usages in my projects as well. Where do I find this tool, and how can I enable it? Is a lot of configuration needed, like is it a lot of effort to do, or is it just like “at this dependency” and it runs out of the box?

Nicholas: you can add the dependency. I posted a blog post on Twitter the other day. It sort of explained how to do it in the blog post. So if anyone wants to use the tool I should have a look at that. If anyone’s using any of my packages, any of the packages that I’ve altered, I’ve added the tool as a dependency of the package. So if you’re using the ESLint rules that I’ve written, or the TSLint rules that I’ve written, you’ll have the tool installed. So all you need to do in that case is run npm rxjs-report-usage, and it will gather the usage. It will show you the usage, it will prompt you whether or not you actually want to send it to the Cortana. If you say “yes, send it” it’ll just post it to a Google Form, and we can go on and gather it later. So if you’re using either of the rules ESLint / TSLint or if using RxJS marbles or RxJS etc: you’ll already have the tool installed and you can just run it. Alternatively you could use npx, and run it directly which will download the script for you and run it. So you can run npx RxJS – report – usage, and it will gather the usage shown to you and prompt you to send it.

jowe: alright, so those who are interested Nicolas Twitter handle is @ncjamieson and I think it’s the first tweet, who is mentioning that tool and also gives you a link to the blog post. and yeah, how and why you can use it

Ben: it’s a big deal, so please do that if you’re listening to this! Because it will help us out a lot.

Motivation to get metrics

Jowe: so let’s continue with this question, this is not marked right now in the document [editor’s note: questions for the session that have been prepared beforehands, and from the live chat are accessible by all session participants in a share doc]. And I think that’s quite interesting: What’s the intention behind, like what are your expectations on getting more and more metrics on that? Is it about the usage that you’re tracking you already mentioned? Like the different versions, which are used outside, which RxJS versions, which TypeScript versions? Like what are your expectations about the metrics you’re gathering, are there any?

Ben: Oh RxJS itself has a huge API surface area. So one of the things that’s interesting that we can get out of this is, like some metrics on what parts of RxJS are being used frequently. And that’ll give us an idea if there’s anything that we could maybe deprecate and remove. Or anything that we should prioritize for performance reasons. Or that sort of thing like if we know that – you know – everyone is using the window and operator for some reason. Which is the polar opposite of reality. I don’t think a lot of people are using that. But if there’s a lot of people using it for some reason, then we know we don’t want to to deprecate it and remove it or something like that. So just things of that nature. It helps guide us with decisions if we have more knowledge about how people are using the library.

Evolution of RxJS

Jowe: RxJS has been public for a couple of years now. Would be interesting like getting a quick overview like how it’s evolved until now: regarding architecture, regarding the team size, regarding the processes you’re using. Can you give us a brief overview about that?

Ben: sure, so actually a lot of that. The team that you see before you, excluding Tracy, is fairly recent in the history of the team as far. It’s been the last year and a half or maybe a little longer that we’ve had these folks on. But the team evolved in that. So originally it was this kind of skunk works project at Netflix, where I was working with a guy named Paul Theo that worked with me at Netflix, who was the original kind of architect of a lot of the pieces of RxJS as it exists. And a guy named John Hussain, who’s on the TC39, who had the observable proposal in front of the TC39 on behalf of Netflix and I was steering the project even though I wasn’t the primary architect of a lot of the features for a while. And then Paul left Netflix and for then after that it was just me working on it. And OJ showed up, OJ Kwon, who’s not with us today, but he’s still on the core team. And he meets with us all the time. And he started reviewing my pull requests. Thank God because I have anyone to review my pull request because it was just me. And eventually, you know, I’d asked him just to join me because he was submitting his own PRS and that sort of thing. So then it was me and him. Andre Stults was with us to write documentation for a while. And then we had … David Driscoll joined us for some time. He’s mostly inactive but he’s still on the core team and we see him from time to time. And then just over time Tracy joins to help the project and help promote RxJS and that sort of thing. And then we have … Nicholas joined us to work on the docks. But I don’t know how Nicholas found us. Did Tracy find you or you volunteered for something Tracy was looking for?

Tracy: A lot of the team, the current team I came together with, just from the core team saying “hey, you know, we need help with the docs – like just come help out”. And you know, we’ve been so grateful that folks who were just working on docs and helping out, had kind of transitioned to actually being part of the core core team. So it’s just really nice to see. But yes, I think Nicholas started helping me on the docs. And you know, the rest is history.

Ben: Yeah so that as far as the ownership of the project goes. The original version of RxJS was a Microsoft open-source project, and there is agreement amongst folks in the reactive X community, which was not a Microsoft organization. That it should be moved under reactive X. Microsoft was okay with it, and so that’s why if you ever look at the license: The license is kind of strange, it says “copyright Microsoft, copyright Netflix, copyright Google, and contributors”. So, and that was just there. There were lawyers that were scary. They were involved with that. “let me get an email from a lawyer from one of these multi-billion dollar companies”. And you’re like “oh I’m gonna get one of these other lawyers from the company I work for to deal with this. Because I don’t know how to reply, or if I even should reply to this”. So that was the agreement that was laid out. And so now it’s a true open source project in all respects. It’s not behind anyone’s agreements or anything weird like that, like some of the corporate open source projects are. So the only thing that’s unique about it is: It was a Microsoft thing, that Microsoft allowed to go full-on open source. And it’s been following contributors wherever it goes, between jobs and that sort of thing.

Future RxJS

jowe: I’m pretty sure the next question you hear a lot of times, because we’re talking with people who are maintaining a cold ivory core framework. Anything with that high visibility, they’re telling me, the most common questions they get asked at conferences or on Twitter or wherever is: When is the next release coming around the corner? So it’s an honor to ask this question to you directly. So when is the next release of RxJS scheduled?

Tracy: We’ve been talking about it internally, and it’s any day now. I think there’s still a few pull requests happening. And version 7 right now is still in beta. And we’re hoping to get it out of beta very soon. A few things that we’ve been working on are mainly kind of resolving some typings issues, and figuring out what to do with the new animations frames API. So nothing too crazy. I think all of us are charging ahead and looking forward to our RxJS b, which has been in conversation. But obviously focus on making sure 7 gets out of beta first.

Ben: And to that end people are pressed. I would recommend people try the beta, or will probably publish another beta here very soon. There’s a couple issues that we’re waiting for peers to land on. And I think you landed them yesterday maybe. But I recommend people do try the beta and – just for reference – Google actually uses it. So the way that Google does Angular and uses. RxJS is different because Google has an internal mono repository that’s massive. It’s this super huge thing and they have one version of every library in their mono repository. So what they do to get the latest version of RxJS is, they literally pull it on occasion off of the master. And they see if it works internally. They give us feedback if we break something. So we know before we even publish our release. And then they actually use a version from master on our repository. So technically when you’re using things like YouTube or some of the other Google properties, you’re actually using something that’s using RxJS version 7 pre-publish in production. So if it weren’t stable we would know big-time by now. So it’s a pretty stable thing.

Marco Stipek: Obviously the master branch of rxjs is working, otherwise we weren’t able to stream here. Interesting

JSKongress: here is a good example presented at the last #jskongress: Dissecting a completely Functional-Reactive JavaScript app | Netta Bondy [watch the session in full length 22:59]
[from the live chat]

Right now the real thing is, we just want to try to settle some of the typings things. And that takes time and it takes time. Because a lot of people are used to these corporately backed open source projects that are big like Angular and React and that sort of thing or even Vue. It’s not corporately backed directly but they have dedicated full-time employees working on it. That are paid from various funds. We’re all doing this voluntarily. So the work that we get done on it is sporadic based on our day-job-workload and our personal lives. If one of us that works on it a lot has our parents home wiped out by a damn explosion or whatever that actually happened. There’s some work that stops for a little bit so these are things that I think are sometimes hard for people to swallow or hard for people to understand like why RxJS would take a while. Especially when I worked at Google people thought that it was my full-time job – there never ever was. So you know it’s just something to keep in mind when we are “oh yeah it’s any day now”. And you know two months go by. And then finally maybe we release another kind of thing. It’s because it’s all volunteer work stuff.

How to support RxJS

Jowe: So, what would be a good way to start supporting the project? Do you have regular meetings? Can I just pick up an issue on GitHub? What would be a good approach? What would you recommend to someone who is interested, but for example hasn’t contributed to an open-source project so far?

Jan-Niklas: So apparently contributing to the docs is very valuable and takes a lot of work for me. So I really appreciate anyone who wants to contribute to the docs – especially as it’s far easier than contributing to the extra code base without any block then. So if anyone wants to contribute, honestly I think, the first thing that would be my go-to is: Reach out to me! So that we can figure out how to contribute on the docs. If someone is really super passionate – and I don’t want to force anyone to do docs-work if you don’t want to. But for other work he probably needs to reach out to one of those guys – at least not me.

Ben: I’ll just assign the coding side of things that is doc related. One of the things people ask for all the time are more realistic examples for the docs. So that’s legit writing code, and the code has to work. But you know it’s for documentation and it’s a big deal because, I would say that the documentation code probably has more effect on people’s day-to-day lives using RxJS than the actual internals do. So I would definitely recommend it if you see it really done as a simplistic example, and you can think of a real-world one that you can stuff in a stack blitz or whatever. Then by all means contribute that because that would be a big help.

To those who are interested in supporting the project. Please get in touch!

jowe: Take a look at the repository, or ping someone of the people here in the livestream: @ladyleet, @ncjamieson, @BenLesh, @mkldny, @niklas_wortmann. I’m pretty sure everyone is happy to get some support.

Start with RxJS

So we talked right now about what RxJS is in general, about the history, and the future. Let’s talk about the presence. What’s a good way to start actually with RxJS? Would you recommend just reading through the docs? Are there any boilerplate projects I can reuse? What would you recommend?

RxJS docs

Jan-Niklas: So even though the docs are obviously amazing and there’s like brilliant content in there. Everything is super clear. 😂 I would probably rather recommend – so the thing I mentioned before is that you don’t really need to learn about all the operators if you start off with RxJS that’s not really interesting.

get the “RxJS mindset”

What you need to do is like getting this different mindset. This is actually the difficult task to achieve. As soon as you got this like “how is this observable working and what is it therefore”. After that you will notice that operators and all this nasty stuff is way easier. So honestly what I figured out is the basis just like building stupid stuff with RxJS. And therefore I would personally recommend: You’re already using whatever technology. Just try to add RxJS and maybe build a feature that you already have implemented with RxJS. Or if there’s nothing right now coming out of your head, maybe implement the type-ahead search drag-and-drop caruso. Those kind of event oriented things, these are really good for ideas. And will really help you also to figure out where the strengths of RxJS are, and what the benefit of using it is. So this would probably go with you.

Learning resources: Learn RxJS and reactive how

There are some good resources that I like to recommend and one is Learn RxJS and one is reactive how.

Learn RxJS has this approach of having things like “here’s an example use case” and “we use these operators for that”. And the other one is reactive how, for this you already have to be kind of familiar with RxJS because it’s showing the differences between operators. But the animations are beautiful and it’s really helpful if you’re struggling like “okay, what’s the difference between switch map and merge map” for example. So these would be my other two go-to-resources and the docs for sure.

RxJS making web development even better

Jowe: So let’s assume I already started. And I’m getting more and more into RxJS. I want to use it more and more and more in my daily routines during work development. How is making RxJS web development even better as it is right now?

Moshe: So a lot of the things with RxJS dealing with values that change over time and that are going and passing by over time. If you try to do that manually – and I remember the early days of jQuery having event emitters and trying to wire things together, it becomes a mess – an absolute nightmare. 🙈 To be able to manage all the different things happening, keeping track of state is a monster. You know, you pretty much have to write a state machine with all these different permutations of every variable that could happen. Because of the big guarantees – that Nicholas was mentioning before – provides some sanity around a lot of the structure on that. So you know that as these events happen. I have an operator that tells, that will stop this stream of events if something else happens. And I could repeat it on a different stream. And I could have an interval on doing it a certain amount of times or in certain combinations of permutations of events. That happens pretty much – the sky’s the limit. So if trying to do that by hand is – for all things of purpose – impossible unless you are a superhuman. So having a well tested, well-documented, understood library doing all that nitty-gritty plumbing for you, just makes everything so much easier.

Redux, React, RxJS – working together?

Jowe: Alright so you just mentioned state management as well. This brings me to Redux: Redux, React, RxJS, all of them are digging around with states. Besides React like Redux is the main supporting library therefore. But let’s talk about Redux and RxJS: Can they be used together? Do they make each other redundant? What is your experience on that and your recommendation?

Nicholas: Yeah, you can definitely use Redux and RxJS there. They solve different problems. You can use React, Redux and RxJS all together at the same time. There’s a Redux observable package that does just that. Whether or not you should, really depends upon how familiar you are with each of the individual pieces. If you’re familiar with React, and you’re familiar with Redux, and you’re familiar with RxJS, you might want to use something like Redux-observable to solve the problem. Basically those things do different things. RxJS in that sense is managing asynchronous effects that are actually happening inside of Redux. Whereas Redux is providing a global store with action based changes. So they certainly don’t make each other redundant, you can definitely use both. It just really depends upon what you’re trying to do, and the problem that you’re trying to solve. And if it fits with the problem that you’re going to try to solve, then definitely use all three.

An example of a situation where it might make sense to use those: If you have a large application, and you have not all backends. Ideal from a frontend perspective. So you often have to deal with backends that are fragmented. And when something happens on the frontend you might have multiple requests going off to the backend. Anytime you need to coordinate those sorts of things RxJS is a good candidate. So if you do have a large Redux application and you have a fragmented backend, and you want to organize a bunch of backend requests when actions are occurring. It would make sense to use RxJS and Redux to solve that problem.

But I’d breach it in that way I’d look at the problems you’d need to solve. Look at the tools that you have. Look at how they solve problems. And figure out whether or not they’re appropriate for your application. But they’re definitely different. It neither makes the other redundant. And you can definitely combine the two, or the three.

Insights

Jowe: Let’s go to the next section, which is about the insights. I’m curious! I see you folks at a lot of conferences, I’ve seen you in the past, not right now. I’m interested. How do you receive feedback from the developer community, from the community who is using RxJS, from the different people? Where do you get your feedback about, which features can be added, which features need to be optimized?

GitHub and Stack Overflow

Jan-Niklas: So they are for sure like the obvious platform of GitHub. We receive issues, pull requests, and stuff like that. Also every one of us is fairly active on Twitter. So people are reaching out to us like “okay, I have this problem, what’s the matter”. And from those kinds of things we can see, maybe this is too complicated or needs some adaptation. The same goes for Stack Overflow: So every one of us is fairly active on Stack Overflow. We have a GitHub channel, where some of us sometimes pop in to help out. But also in general the community is fairly active and turns there. We have Slack, which is not that actively used from the community but we use it to organize our work. Yeah, and for sure every one of us is going to conferences, speaking to people, doing talks, goes to meetups, stuff like that. I think these are pretty much like the main things. And actually a funny thing: the animation frame observable was pretty much for RxJS Live [editor’s note: THE event for RxJS] last year. We’ve kind of forgotten that feature enormously. From seeing the talks it was like “oh no, that can’t be the proper solution for that.”

> RxJS core team = volunteers with day jobs

Ben: There’s another distinct difference between like our team and a lot of say like the corp like framework teams. And it’s partially born out of the fact that we’re all volunteer workers on this. But when I am not the Angular team – I was on the Angular team – everyone that I worked with was amazing super-smart wonderful people. But their heads down working on Angular the whole time, right. So that means that they aren’t spending most of their day using Angular the same way that other people would. They use it but they use it in kind of like when you’re writing testing. Your work on the Angular team. You write up these contrived tests that are to test specific parts of the framework, as opposed to dealing with very very large apps. Now sometimes we would get called to help somebody in the rest of Google or something, and help them with an actual app. But most of the work there – in the Angular team, and I’m sure it’s the same way for the React team, and maybe to a lesser degree for the Vue team – but you’re working on the framework, in the library. And it’s all conceptual, like how it’s being used. Where every single one of us has a regular day job. And at least I assume everybody else here is using RxJS all the time at work. You get a pretty good idea of things that you would like to see changed or fixed. Things that I don’t even know if I’ve ever documented, but I’ll look at things like group by and it’s got the arguments. And I really wish it was a configuration object that was passed. So I knew what the arguments were because I don’t always remember the arguments. And I wrote the darn thing.

So like there’s things like that that we encounter when we’re working with things. Or even small bugs that get caught by the folks in the team. And I think those obviously will get fast attention from us because we’re the ones that found it. But there’s also GitHub issues and that sort of thing. Sometimes when I find an issue myself, I’ll go and I’ll look on GitHub and nobody else has ever reported it, which is always shocking to me. And then there’s other times where I’ll find it, I’ll see somebody reported it – I didn’t – who isn’t able to reproduce at that time or whatever, and it got closed. But, oh yeah, we all use it all the time. So I think that’s another big source of where we find out what hurts the community.

Jowe: So it’s a kind of eating your own dog’s food.

Ben: oh yeah

Technical debt

Jowe: all right. So we’ve talked about all the contributions and issues. One thing, I think everyone in IT is affected, it’s the topic “technical debt”. What’s your strategy to deal with technical debts?

Ben: So I’m assuming you’re asking as a tech debt that you’re asking about technical debt. Yeah, so the technical debt is difficult on a library. This is widely used. Just what we have for example … look, there’s a couple parts of this one. We have a lot of tests over the entire breadth of everything that we’re doing. So if there’s tech debt within this utility library, which – it exists – but it’s fairly minimal. Ideally we can refactor something without having to change any tests. And if the tests still pass then we know that we didn’t break anything. So there’s that side of it. But the biggest and most important thing is making sure that whatever tech debt that we’re trying to fix is done in such a way that we’re not releasing a patch that’s going to break a million projects.

don’t break a million projects

Or something that, for example recently we had some tech debt on subject, which is one of the major types within RxJS. And what it was, we started working in RxJS or I started working on RxJS but way back when – I think – TypeScript 1.8 was the most popular version of TypeScript out, and TypeScript 2 or 2.1 was just being released. And it didn’t support certain features. So if you made a subject of void in order to call next, you had to pass undefined to it. And that made it unergonomic for some of Angular’s use cases. So we made the next … the value to next optional, even though it’s not actually optional. It was optional in TypeScript. It said “you don’t have to pass value here”. So if you made a subjective number, TypeScript will allow you to this day and version 6 to call next with no number passed to it.

And that’s actually incorrect. You can cause bugs, and you shouldn’t be able to do that. But it was a bit of tech debt. And it was tech debt because we had to wait for TypeScript to get to the point where … if you had a subjective void it automatically allowed you to call next without an argument, which it does now. So we had to go through, and we had to fix that. We had to fix it in a major version because if we were to fix that – even though it’s a bug in our types – if we were to fix that and publish it in a patch for version 6, or even a minor for version 6. Even though it’s a bug-fix, it would break so many people and so many builds that it would be untenable as a patch. So we had to make sure that we consider how many people are using this. Because it’s downloaded so many times per week and how many people will break. So it varies a little bit if it was my own personal project that I … oh no only, I see only like 12 downloads on. You know fine, we can publish a patch for the type change. And if it breaks all of 12 people. And maybe I get a nasty gram at some point.

getting up at 1 in the morning …

But if we publish something that breaks a lot of people. And I’ve done this in the past. Before any of these folks I think we’re even here. Like I start getting texts and messages and pinging at 1 in the morning from people who are noticing that their continuous integration bills are broken and they don’t know why. And then they figure out it’s RxJS. And then I have a meltdown. So if you need to make sure that we carefully consider every change that we make, especially those that we think are just tech debt or bug fixes. Because it’s such a widely used project it also means we have to move a lot slower. Because it’s used by so many folks.

Jowe: What’s been the situation and like the task? How did you resolve the meltdown you just mentioned? Why did you jump out at 1:00 in the morning? Coordinate like who is jumping on investigating, fixing the bug? How was this situation for you?

Ben: At that particular moment in time, honestly, it was no different than “what would happen if you’re on call at any other job”, right. I saw, oh my gosh, all the stuff happening. And basically I got up, washed my face, and went to a computer. And figured out what the issue was. Resolved it. And published another patch that fixed the bug. But it was embarrassing and difficult. And that stuff has happened early on. It happened a few times. But it hasn’t happened in a long time since.

Wonderful support net

Now we have wonderful folks that are helping us. So Michael-James Parsons and Christine Leg are at Google, Moshe also used to do this at Google, and I did it myself. I started this group at Google before I left. That are actually the people responsible for pulling in what’s an RxJS master into Google. And that means it gets run against thousands of targets. And we see if we broke anything. Where we broke people’s tests, or broke functionality. Or we broke people’s builds. And we get feedback about it before we publish a version to npm. So that’s been a big stopgap for preventing these sort of things from happening again.

Staying updated on RxJS

Jowe: So it’s already time I’m asking the last question. So the last question is from me and I’m interested like: What is your recommended resource when I want to keep updated on what’s going on with RxJS? About ongoing discussions, new releases. Would be the best source GitHub, the website, Twitter? What’s your recommendation, Tracy?

Tracy: What’s my recommendation for getting started?

Jowe: Just for getting and keep getting updated. Like a source of “I am interested in”: What are ongoing discussions? What’s discussed in the process right now? When are new releases happening?

Interested in contributing

Tracy: That’s difficult, a lot of these things are happening internally, right? For those people, who are interested in contributing … I don’t know if any of you guys else can. But you can always ping me on Twitter @ladyleet. And I can give you access to the Slack channel. The Slack channel is mainly for contributors. So if you’re really interested in contributing, and you kind of want to be able to start conversations about the contributions, then that is a great place to be. I think, for issues as well it’s a great place to be. We’ll randomly tweet out updates on Twitter as well. I don’t know if anybody else has any other suggestions.

Follow on Twitter + get in touch

Ben: One of the things I would suggest is following all these other folks you see here, who are not me (@ladyleet, @ncjamieson, @mkldny, @niklas_wortmann), on Twitter. I know that this is seriously everyone. Everyone here but me actually outputs a lot more content that’s RxJS related. As far as: What’s happening now? or like: What are new tools or different techniques? And that sort of thing. I think maybe I used to, and then got caught up with all sorts of other things or whatever. But that’s not the point. The point is that these other folks that are on this call, they output a tremendous amount of great material for you to follow. I will occasionally tweet something, like I’ll put up some issue or some pull requests. Some ideas that I have and ask for feedback, kind of thing. But I do that very rarely. And even actually going into this talk, I really really wanted to make sure that everybody heard from the brilliant folks on this team. Because frequently I feel like, whenever we do RxJS talks I end up blathering on for quite a bit about my perspectives on things. But everybody else here is putting out a phenomenal amount of material about this. Or they know where a lot of this amazing material is. So I would definitely follow them on Twitter and pay close attention to the things in the medium articles and the things that they put out on their blogs.

Tracy: Everybody’s pretty welcoming here. Reach out! We’re always happy to point you in the right direction. Or whatever level of contribution. So don’t stress.

Finale

Jowe: Right. Just hear some voices in my ear. Right now we’re a bit over time.

I would like to say thank you a lot to you Tracy, Nicholas, Moshe, and Ben, and Jan-Niklas for joining us from around the world. It’s been a pleasure!

I’m looking forward to watching the stream again, more focused on the answers. Because it’s pretty tough like having the document following up on the next questions, having the timings, and the voice in the ears.

Thank you very much! And yeah to all the others outside: Have a great day or night or a good morning! Bye-bye

Tracy: thank you for having us

Ben: Thank you!

Please support #RxJS by anonymously reporting your usage (click here to read how)!

JSK meets friends #3: Reboot & Recruiting

JSKongress — Mon, 11 May 2020 13:42:24 +0000

Here is the 3rd episode of #jskongress meets friends: We are excited to announce the guests for our next episode.

Join us live on Tuesday, May 12th, starting 5:30 pm (CEST) on our channel youtube.com/jskongress

We are so grateful, that Felicitas, Kristina and Aileen will discuss with us: the recruiting process in these challenging times, and which opportunities they developed from the crisis.

First of all, everyone – attendee, speaker, sponsor and volunteer, as well as the team members – at the JS Kongress, have to agree to the Code of Conduct. You agree to comply by attending. Also, the organizers will enforce this code throughout the event. Finally, we are expecting cooperation from all involved parties to ensure a safe environment for everybody. In detail on https://js-kongress.com/code-of-conduct/

JSK meets DevTools-Team

JSKongress — Wed, 06 May 2020 10:47:58 +0000

Welcome to the 2nd Episode of JSKongress meets Friends! 👬👫👭

Live-Chat: Ah, a JS Kongress meetup you can watch in your pyjamas, if you have pyjamas! 🛋️ #StayAtHome 🏠

This time we're talking about the Chrome DevTools and beyond, where we cover different topics from

Architecture & History
Workflow & Quality
Team & Feedback
Design & Accessibility and
WebAssembly Debugging

I'm Johannes and your host for this episode. Sending you a warm welcome ❤️ from rainy Munich! ☔

The idea behind #JSKongress meets friends is to invite people and teams, where we think they can provide some inspiring insights. You may find some inspirations, which you can apply to your routines.

For getting the questions, we've collected them upfront on the various social media channels.

I'm happy to welcome Kim, Peter, Mathias and Paul from the Chrome DevTools Team in this episode! [editor’s note: Kim Anh Tran (WebAssembly SWE), Mathias Bynens (Design & Accessibility TL), Paul Lewis (Architecture & Testing TL), Peter Mueller (UX lead)]

alert("Hello, World!");

Johannes I’d like to start with a brief warm-up question: Who are you, what are you doing, and how is it going in the home office for you?

Kim I recently joined the Chrome DevTools team. I was an intern on the Wasm runtime team before. And I work on Wasm debugging right now.

I'm doing well. Juggling between taking care of my child and working in between.

Mathias hey I'm Mathias, I used to work on V8, and now I work on Chrome DevTools here in Munich where it's still raining indeed. For DevTools I lead the efforts on Design & Accessibility. And I also work on Puppeteer, which is something we could talk about later.

As to how it's going in my home office, I'm kind of an introvert so in normal circumstances I don't feel the need to go out all the time. But now that I kind of don't even have the option anymore it sucks, so yeah I can't wait for this thing to be over.

Paul Hi, as you said, I’m Paul, I am based in London unlike everybody else. You'll be pleased to hear it is also rainy. I used to be in developer relations and then I moved to working on the DevTools team, something like a year ago, nine months ago, something like that. And I work on the architecture and testing particularly, that's my main focus with a couple of folks in London particularly.

How's it going? Well, my house is actually 🏗️ a building site right now. We decided to do some building work right before the pandemic hit, and we haven't been able to make progress for a while. So it's been weird living on a building site, and yeah I don't recommend it. But there you go, that's just life in it.

Johannes Peter, how is it going in the most colorful Home Office? 🌱🌴🌵

Peter yes, so hi I'm Peter, and Design Lead on DevTools. So previously I come from a visual design background, and then just transitioned into UX design at Google.

How’s it going at home? So as you see I'm working in a greenhouse. I decorated with as many plants as possible, so it’s going good!

Johannes all right; thanks for the quick introduction round. I would say let's kick it off, and start with the questions we've collected.

Architecture & History

Johannes the first topic is about architecture and history, so the first question is directed to Paul: Can you please give us a brief overview about what DevTools are and how they can help engineers.

Paul okay, so the DevTools is a web app primarily that is embedded with Chrome. It comes with the Chrome binary, and it allows you to inspect the current page. So it helps developers by giving them insights about

what elements are in the page,
what the JavaScript is doing,
the performance,
the accessibility,
what styles are applied to the page.

It gives them all that insight just by right-clicking on the page and saying “inspect element” and give them all that at their fingertips.

So that's what it's there to do: It’s there to help people build web apps really on sites.

Johannes I just got notification that the first 2 minutes have been without audio so I would like to ask the first question again. This is directed to you, Paul: Can you give us a brief overview of what the DevTools are and about how they can help engineers? [editor’s note: We are giving you both versions here, because it might help to understand it easily.]

Paul yeah, absolutely let's do that one again, I would 've said. I think I said nice things about DevTools 😂. So DevTools is a web app that we ship with the Chrome binary. So actually it's a surprise to a lot of people that it is a web app. When you open the DevTools front-end you are looking at a web app. So you can actually inspect DevTools with DevTools, which is always a fun thing – like Mattias is and rightly so 😃. So it's there, and it speaks to the various back-ends that we have in Chrome for like v8 and for Blink. And it's requesting information about the page that's being inspected. So if you're building a web app or you're building the website, and you want to know

what elements you've got,
which styles are in place,
what the JavaScript’s doing,
what your performance looks like,
and your accessibility:

We have tools in the DevTools that are designed to help you through that process. To understand your web app, and to help you through the process of building it, and making the best possible app or site that you can.

Johannes alright, thanks for answering the first question

The next question is: Do you know how the idea came up to ship Chrome with native DevTools? Some keywords like, I think, Firebug was one of the first things I remember in my times. But I'd be curious about the history behind it, how it came up.

Mathias

The reason Chrome had DevTools from the very first version is because it's a fork of the WebKit project – at least the Chromium project is.

So it used to be that Google and Apple were working together on WebKit, and at some point they realized that they had different visions for the project. So they decided the best way to fix that issue is by forking and then WebKit and Blink became two separate projects. And so basically in Chromium we inherited the WebKit inspector code, which was the DevTools at the time in WebKit. There are still the very early versions of the Safari inspector right now. And also the DevTools codebase is still based on that, so this is a code base that is 14 to 15 years old right now.

And that's how DevTools ended up being in Chrome.

But I think the question you're getting at is: How did DevTools become a thing in browsers / that ships with browsers, right?

And I actually remember those days before this happened.

I remember having Internet Explorer 4 open, going to my page, and then typing javascript:alert(somethingSomething)

just to get something to appear, or like to interact with the page in some way. Because that was the only way I knew, other than viewing the source directly, which I still do too these days, actually.

And I think yeah, Firebug indeed was a big boon. It was a browser plugin that was created by developers to fix some of these issues and to make it possible to, at least, interact with the page a little bit more closely.

And there was another extension that I remember using: I think it was the Web Developer Toolbar by Chris Pederick. It had all these cool keyboard shortcuts that I remember using. And so I think what happened is that a lot of experimentation happened in these browser add-ons, these optional plugins that people could install. And based on that, browser developers were like: 💡 “yeah, what if we took some of these ideas, and shipped them with the browser. That we could actually do some of these things in a more efficient way that is not possible in an extension” and I think that's what happened.

Johannes I'm a software engineer and I'm all the time super curious about the architecture behind. Can you give a quick overview about the high level architecture? Because like there are so many things, which can be done in DevTools from the inspector. I think everybody needs the performance measurements to so many other things so:

What's the high level architecture of the DevTools?

Kim DevTools is a web app as Paul has already mentioned. The DevTools front-end, that the developer is normally interacting with, is talking to various back-ends in order to accomplish various tasks.

So one back-end, for example, is the v8 back-end. The v8 back-end is basically everything that answers to JavaScript and WebAssembly. If you are typing in an expression that you want to evaluate, it's the v8 back-end that we are talking to.

Between the front-end at the back-end there's the CDP, it's the Chrome DevTools Protocol. The CDP is specifying the methods, requests and responses that can be used in order to communicate between them.

And the DevTools front-end is not the only one that can actually use CDP in order to control Chrome. One example that was already mentioned before by Mathias is Puppeteer. And Puppeteer allows you to write end-to-end tests in JavaScript by controlling a Chrome browsing instance, for example.

Johannes So DevTools is not only for web apps as we know. We can debug our Node.js applications as well. What's the history behind extending the DevTools or making use of Node.js debugging?

Mathias okay I guess I'll take this question. So as Kim explained, there's this Chrome DevTools Protocol, and there's really no reason why only DevTools should be able to send these commands to the backend -- anyone can do it. That's why we also have Puppeteer as a library, which is a wrapper on top of the Chrome DevTools protocol that makes it very easy to use this, and to drive a Chrome instance from within Node.js using a very nice and modern API.

The same thing applies to Node.js: Once you know about this protocol, and specifically for Node.js, you probably mostly care about the JavaScript part of the protocol. So things like setting breakpoints in your code and evaluating a snippet of JavaScript, you can have the same possibilities that DevTools already supports within Node.js, as well. So through this protocol, it's now possible to use the DevTools UI to debug your Node.js code instead of the web apps that you're usually inspecting. It's just a matter of sending the proper commands and interacting in the right way that is described by the protocol.

Johannes Are there any numbers? Do you have any numbers about the usage, how the DevTools are used for debugging node and for debugging web apps? Do you collect any numbers?

Mathias I mean Chrome has this. Chrome can collect some telemetry if people actively opt into this in an anonymized fashion. So we do have some measurements. But I don't think we have a metric specifically for this, in fact the metrics that we have from within DevTools are fairly limited as far as I know. And this is actually one area, where I think we can improve a little bit. Because if we have more fine-grained details about which panels are the most popular, we can figure out where to invest more of our time.

Johannes Is there an API I can use to automatically use DevTools features on a given Chrome?

Mathias oh yeah, so this goes back to Puppeteer a little bit. Because many of the features you would find in DevTools are things like: I want to preview what the page would look like with print styles instead of my screen media. There is a setting in DevTools in the Renderer panel that lets you do this and so because it might be useful to try to do this kind of thing as part of an automated test. There's also a Puppeteer API that behind-the-scenes just sends the same Chrome DevTools protocol commands so that you can now write a Puppeteer script that says “okay, open the browser, navigate to this URL, emulate print styles, and then take a screenshot and save it somewhere for me, and that script would just be four lines of JavaScript. The same thing goes for many of the features that you will find in DevTools: if we deem it useful as part of this automated testing scenario or maybe even for other use cases like creating web pages then we will add an Puppeteer API on top of the CDP API so that developers can easily use it.

Johannes okay, so when I'm using Puppeteer for my end-to-end tests I can make use of not all but some of them, and automate them as well – that's pretty cool

Mathias exactly, and you actually can use the whole protocol. You can also send raw protocol commands but it's just not very nice to do so. It's nicer if there's a dedicated first-class Puppeteer API because yeah doing it the other way it doesn't feel very JavaScript-y.

Johannes We started the first question with the architecture and the history behind. So when it comes to architecture: Architecture is like living all the time. How has the DevTools architecture evolved all the last years? And what are some of the main pain points in the past or currently?

Paul Depending on how you look at it. Some of that's been around for up to 10 to 15 years and that means that the code that you have … The code that would have been written 10-15 years ago in web is very different to the code you'd write today because best practices change, new patterns, you sort of evolve, and it's just they say:

Architecture is a living thing.

Now the size of the DevTools front-end in particular. We're talking about an awful lot of JavaScript that's in play, and so it's not just a case. In fact one of the words that we try to avoid in my team, is the word “just”. Because of the size of the code base we're talking about, there is no “just”. And I'll give you one example: So recently the web got ES modules, so that we could do imports and exports around the place. Before that, there wasn't a way really to do on the platform anything that looked like modules. And one of the things we wanted to do is move the code base to ES modules. Because it's a good thing for us to have the two links that support visual studio code – it understands it really well.

But there is no “just”, so we can't just migrate to ES modules. There's a lot of things that need to change like the tool-chain. The actual code itself is written in a way that was before ES modules, and expects certain things to be in certain places. And so the largest pain point we typically have is migration. So my team is particularly tasked with keeping the architecture and the testing in a good shape. And we decided there's this new platform primitive that would help us here, would make the software better. We have to migrate everybody across to that without breaking DevTools. And that applies to the people using DevTools everyday, which obviously is incredibly important. But also the rest of the team. Because if the rest of the team is trying to work on the DevTools code base and we're busy just changing the architecture, we could break their patches, and we could break their workflow. So we have to be very careful about how we do it. And we have to do it at the scale of a very very large web app so it's constantly evolving.

As you said, it's challenging to make sure that we make decisions as well that will have a long lifespan. Because at the scale we're doing them, when the time scales it takes to get them done. But what we don't want to do is make a quick decision that though we would have to undo later on. So we sort of constantly try to understand how much a technology would give us, if we returned it to use it. And then as we migrate people, to make sure that we don't break anybody, which is always a challenge.

Johannes migrating in architecture – that's a good keyword for the last question for this topic. In my team the last weeks, technical debt is more and more a topic. I'm curious: How does your team handle technical debt in this scale and for this lifespan?

Paul it's a constant question. I think that's the way it goes because the best practice today can be tomorrow's tech debt. And I don't mean that rudely. Doesn't mean anybody is coding badly at that point. It's just that things change, and things do get better. And you can look at tech debtors “oh somebody made a mistake”. But often that's not what it is – often it's the constraints they had at the time. And sometimes the platform didn't support the thing they wanted to do. So in our case – sort of to repeat myself I suppose a little bit – we try and take a very tactical view on it. Is that thing just different, or is it actually bad in some way? As in, if somebody's had to code around a problem, that the platform didn't do something. And is it worth fixing that or is it worth delaying that until some other things are in place?

So we're forever having conversations, and that's actually the main thing I think we've just hit time and time and again. It's so much about the conversation, about making sure that people both understand the trade-off and the trades that you're making back and forth. Like “we're not going to fix that now, because we'd like to do this instead” or “we think we should fix that next” or “we should change that over there”. And then trying to just make sure, as I say, that you do it in a considerate and thoughtful way so that you don't break anything. But there is no sense in which you're going to go “right, we're done”. Because while the platform moves you're gonna have new things to try, new tools that you need to add. If you're us we're adding things to the product, we're trying better ways of working. And that just means that inevitably there's always going to be some form of change that you need to manage.

Workflow & Quality

Johannes One of the most interesting questions, I think a lot of people are having, is: How do you build the UI of the DevTools? And are you using any libraries therefore?

Paul I'm fortunate you are hearing quite a lot from me, so I can only apologize to everybody that you’re getting a lot of Paul-time [Live-Chat: “We love Paul-time ❤️”]. My team was probably gonna nod along and like “yeah we hear from him a lot” but:

How we're building the UI? Well, I think our constraints are not unique. But they are probably unusual in the sense that the DevTools front-end is a long-standing web app. And that means that we need to pick technologies that we feel have the same the next 10 years in them or more. And so our preferences are normally to use the platform primitives where they're available because

the platform moves at a slower rate than libraries and frameworks

And anybody who's worked on the web for a while knows that the rate of change in the web is extremely high. And that means that if you were to pick a library or a framework that's popular today in a year, two years, five years, you might find that it's not. And at the scale that we were talking about before in terms of tech debt and change, that would be perhaps an unwise technical decision. So that's the kind of the background philosophy or most that we have.

The second thing that we want to do is, we want to maintain control in the sense that we need the flexibility to do certain things at certain times, and know that we're going to do certain tasks at certain times. And so if you find that a piece of software – say a framework – is going to invert the control, so that it calls you rather than you call it, then there's a potential problem there. So we do libraries and we do want to use libraries, and we do make the best use of libraries where we can – generally speaking. But the idea has to be, that not only is it that we think it's maintainable for the long term. Secondarily, if we need to replace it with something else, that we can. And thirdly, it allows us to maintain control over the life cycle of the application, so that we can call into it, it will do the task, and it will come back. And if there's a problem with it, we can swap it out and so on. I hope that answers the question.

You can look through the DevTools code base if you want to see the kinds of libraries that we are looking at.

Johannes Regarding quality and workflow: How does your Q&A look? Which actions are you taking in order to ensure you ship the best possible quality?

Paul this is another one for me isn't it? Well, testing… I mean, this is not the most exciting answer that you could imagine, but it is the most sort of truthful – I suppose:

if you don't write tests you don't know what your software is doing

And that means that writing high-quality testing, and investing in your testing and infrastructure and your architecture and those kinds of things, are the long-term best play that you have. Now we also happen to have a wonderful community of developers [❤️] generally, who give us good feedback. And that's actually really helpful for us. So we can speak to framework people. We can speak to web developers in all kinds of walks of life. And that gives us a fairly good signal on what they are struggling with, what they care about. So we can use that in combination with the fact that we're trying to build high-quality software with good testing and infrastructure that supports us. That sort of hopefully comes together into something that genuinely adds value to everybody every day.

Johannes The discussions and the feedback you're collecting: Where is this communicated? Do you communicate that on github as well, where the whole source code is available?

Paul how do we communicate with the framework people, with the library people in order to collect the feedback? It tends to be a lot more ad hoc. So we will tend to set up calls with people if that makes sense. Or sometimes we will just simply look at what they're creating. I mean, there are some wonderful tools for Vue and React in particular that augment the DevTools. And that gives us a fair idea of “hey, what are these people trying to get done, what things make sense in their world”. So it's a fairly informal thing, I would say.

Johannes When you add new features to the DevTools, what's the workflow behind? Who is structuring the issues or the feature? Who is taking care of the requirements? Who is doing the UI and the UX? Is there a big testing ongoing? How do you handle new features like the rough workflow from the idea until it gets shipped?

Peter that sounds like a question for me. Okay, so I'd say, the design process and DevTools, or the process from idea to productions for the unit. So it's definitely not like the traditional process, a top-down design team, and that created designs, and having enough developers. And at some point it's unstable. So it's rather more on the opposite way around, looks like from the bottom up. So you can't develop such a super complex tool just by your own. Probably not even a team alone has enough knowledge to cover everything. So you constantly need to collaborate with experts, not only at Google but also other companies, other browsers even.

So really interesting, well so we have like a tool internally to make this collaboration happen just called “the design docs”. It's basically just a Google Doc and after a certain four hours format. So everybody can start such a design doc and just write like a basic outline, what your future might look like. And we use this a lot to collaborate with experts on different topics because usually it gets so technical we really need expertise outside of our team. Even or especially if it's about security and so on. So everybody can come up with such a design work. Ao there's not like a single person that sets up the roadmap but you can already imagine there is a lot of stuff coming up. It's like everybody is fighting feature requests and like that. Some days there are so many design docs just popping up I can't even read them all. So you need some workflow to focus, and we also have this in place. So we define our focus area for each year. We want to improve that to it. So for example in this year's design and accessibility or WebAssembly is like a huge topic, we want to focus on them. And if we find a feature that plays into one of those areas, we prioritize it higher, and we spend a little bit more time on this. Ao it doesn't mean that we neglect everything else but we have like all photons. So in a lot of features, in general all, ourselves happening under the hood.

So not everything is involving UI but sometimes, my job is just to take a loop, and find out in which part of the workflow makes sense to service something. Where we can actually be useful for the developer, not intrusive. So sometimes it's really just about making sense of things. And this all happens in design docs so. But yeah this all doesn't end in production. So eventually the design doc hits. One of those focus groups is “develop and relent and Canaries”. So “canary” is like our free beta build. Everybody can try out, and we test functionality in canary. So it's like a safe playground for us to get early feedback from the community. So the user group is large enough that it's meaningful feedback, but also it’s not that stable. One won't break everybody's browsing experience and monitor all the feedback from canary really closely and start iterating on and on to ensure that it's stable. So yeah, I'd say this is like a rough outline of our “feature comes to production”.

Right, and for people, who really want to try out what stuff will burn and look in the next upcoming versions

Johannes Are you making use of any workflow related KPIs? Are you measuring the team performances and if so, what's your model of measuring it?

Kim yeah, KPIs and these Objective Key Results are set for the quarter for example. These are the ones that we want to achieve until then, and that's exactly what we use in order to measure the performance.

Johannes How do you involve the developer community's needs and wishes when it comes to new products features and involvement?

Peter I mean it's pretty difficult. It feels like such a huge user base to really go down to the individual. But we always try to be really close to our user base. So what helps us to demonstrate are people and dev relations positions. They really foster relationships with their community. And help to understand the opinion that’s out there. And what's really bugging people. And what's really in demand right now. And make it actionable for us. So we don't need to go through one gazillion Twitter feed to really filter out. But in general the whole team has a close look on Twitter. And the general vote comes into the factory post in the Chrome box. So this is generally how it will be written so it is monitored closely.

Johannes another question regarding the team and the feedback: Do you stay in regular contact with the engineers, with the product managers, and people who are working on other browsers’ tech tools?

Peter well, actually yes we do. I think this might come like a surprise to some people. But it should be like in regular contact with most big browser vendors. So especially if we like to develop a new feature for something lately we had experts like engineers from Firefox, and with us in it, we had UX experts and engineers from Microsoft in there as well. So yeah definitely something like DevTools doesn't happen in a vacuum. And we are very well-connected with others.

Design & Accessibility

Johannes Layout debugging has been one of the weak spots in Chrome's DevTools, and in particular Firefox DevTools have done a better job here. Do you have plans to tackle that?

Peter yeah it's definitely true. I mean Firefox did a great job doing this. I especially like the great implemented fkex interpretation. But I think I mentioned earlier, design is one of the key areas. And we have been working really closely with Microsoft over the last month. Actually on written documentation, which is actually pretty cool. Tomorrow [editor’s note: April 29th] we will demo our first preview of CSS grid. So if you want to see it you should really take a close to our account, because people demo it tomorrow.

Mathias the team’s Twitter account is @ChromeDevTools

Johannes Take a look on Twitter if interested in the twitter handles from Peter, Kim, Paul, and Mathias.

So the next question is also design and accessibility related: You recently shipped support for color vision deficiency emulation as a means to improve accessibility support. Can you provide some details here?

Mathias DevTools help to optimize your websites to pick a color palette that is accessible. And so by adding this new functionality to DevTools, where you can almost put yourself a little bit closer to being in the shoes of a person, who suffers from such a thing. You can now visually see what is going on and how they might experience the colors that you choose. And so by doing this and by simulating several of these color vision deficiencies you can ensure that what you design is accessible for everyone. Not just for people with perfect vision.

Johannes there is one question specifically to Peter: What or how you think you can improve the Chrome DevTools UI?

Peter right, so at the moment how we are approaching this is, we are refactoring a lot of features that fills your eyes. So it's like what happens to evolve portraits: At one moment, you will edit features but you're really reluctant to remove them. Because we will abandon doing this, using it like every program; like Photoshop, the Excels, the After Effects. They all have been there at one point. So it would be like actually thinking about it. It's not so much like improving the style of like next elements but rather refactoring the UI. But so, one example is that we want to declutter the console a lot. Because right now the console's full of messages, which are not really actionable. So we want in the future to come up with a new panel: The “issues panel” actually gives you all the issues with your website and a really nice actionable format. So those are the things we have at the moment.

WebAssembly Debugging

Johannes WebAssembly launched back in 2017 but there was only very basic debugging support until recently. What is the timeline here? And what can we expect here?

Kim yeah, so what we want to do is to make sure that debugging raw Wasm actually comes along with an environment that makes sense for Wasm. So this means changing the views that are already existing, for example a scope view that makes sense for Wasm. Then, using consistent Wasm text across all our views and having a better memory view. But also to make it possible to set breakpoints across threads and allow for seamless profiling. Some of these features will already be available in Chrome 84 but others will continue to ship by the end of the year. But we also want to go a step further: We want to introduce a language server using C++ DWARF symbols. The idea behind this is that we don't only want to have access to static information but also to dynamic information. So you don't only see the C++ source code when you're debugging in C++ using Wasm. But you also have the possibility to evaluate expressions, which is very valuable when actually debugging an application. And then we want to support large-scale applications in C++ with this language server. And the plan to ship on this side is that we want to have the basic support for a symbol server with capabilities to step in C++ by the end of June from Chrome 85. But we want to introduce that with life expression support and a scope view here in Chrome 86 / 87, which is August / October. So the big difference to the current source map-based debugging approach is that the source maps only give the source location. It doesn't work within inlining, and you cannot evaluate expressions. And that's exactly what the new symbol server will be.

Johannes Ingvar announced an improved solution at Chrome Dev Summit (CDS) that uses native DWARF debugging debugging information. Is this an extension of that?

Kim no, it's not an extension. So the solution that Ingvar presented at the Chrome Dev Summit was rather a proof of concept that we can actually use DWARF information to debug. The symbol server is a new solution that we want to present. It gives you all the features that I've been talking about: with the dynamic information. And the solution scales with large applications. Because the solution that was presented before, was actually running in the DevTools front-end itself. And just handling that massive amount of DWARF data wouldn't be scalable in DevTools itself.

Johannes by the way “scalable”: Google Earth recently announced that they made the switch to WebAssembly. Debugging a large code base like that probably comes with different challenges than toy examples, I suppose?

Kim yeah, big applications also means a lot of DWARF data. And a lot of DWARF data needs to be parsed, needs to be read, needs to be found in order to find the symbol names that were used for debugging. And this is especially difficult if, for example, the data is not indexed. So that you can actually … you have to actually read through everything. We also need better mechanisms for stepping and showing big scopes. Because now that you actually have a large application, you have a huge scope. And we need to find out how to show the scope in a way that is accessible to the developer. And then there’s also profiling. Profiling with big data is also difficult.

Questions from the Live Chat

Johannes we got some questions now from the people, who are watching the live stream. Let's start with one of the first, which is: DevTools are getting more and more IDE features like editing files, mapping to the local file system, changing things in the code directly without going to the IDE. What do you think, how will this develop? I think the question is directed to you, Paul.

Paul 🔇 [muted; find answer below]

Paul … then we would look at those features at that time. So if it sounds like I'm avoiding the answer, it is a little bit because we tend to respond and think through before we commit ourselves to one particular path. And that's just how it works really.

Johannes Paul, I have to re-ask you again to answer a question because I got the feedback that audio was unavailable, when you answered the question about the DevTools and the IDE features; for getting more and more IDE features, like editing files, a good listing, to know how you think that will continue and develop.

Paul that's actually kind of good, cuz I was thinking as my answer came out: There are other ways that I could answer this. But I'll give it another shot. 🤔

Johannes different answer, let's go

Paul no, I had a completely different answer that doesn't sound like the first one.

No, the first answer I think is the actual truth, which is when we try, and like I said before if you look at something like code editors, they've changed: People were using Sublime or whatever before, and then everybody seemed to move to VScode and that so the world of web development changes an awful lot and very quickly. And so the way that we integrate with it changes fairly quickly as well, and so it's not necessarily a case of saying “uh, this is our known path, this is the path we're going to go down”. Because a lot of the time we're looking at the trends and we're looking at – like Peter said earlier – we look at Twitter, we also go to conferences, and we also just try, and have conversations with lots of different types of developers and different walks of life.

And that hopefully gives us a sense of what the needs are and if the needs take us in a certain direction. Then that's the direction in which we will go. So while it is very tempting to say “oh yes, we should definitely add this feature or that feature or the other”, it's a lot of engineering time to put to something if it's not actually what the developer community needs. So I think, all I would say is, if we're always trying to be open to the feedback to iterate on DevTools, it hopefully goes in the direction that it needs to. I think again:

if you rewind the clock five years 🕰️: Would you have expected that the Chrome DevTools would look like they would today?

No, they probably wouldn't but at the same time, we try and walk a line between responding to people and also trying to make sure that we have features in there – even before lots of sites have them. I'll give you an example of that one: Progressive Web Apps. We knew that PWAs were a thing that we were keen to support, and those features were probably in DevTools – I would imagine – much before the browser support was there. And that was partly because you have a chicken-and-egg problem 🐓🥚🐣. Sometimes with these things, if you can't debug the technology then it's harder for developers to use that technology. So they tend not to use the technology, right? But on the other side, you want to make sure that you don't over-invest in tooling for a technology if it's not actually the right fit for your developers.

So again I'm saying a lot of words. But what I'm trying to say is that we're walking a fine line of trying to respond to user needs, and also make provision for the things that we think are going to be necessary and popular. And that just means it's very difficult for us to say: Well in 6 months, that's exactly what we're going to do. Because sometimes we just have to play it a little bit and see what happens, which is why it's important that we have all those things about experiments and extensions, and all those other ways of trying things out.

Paul did they have the audio this time? 🙉

Johannes yep, I haven't heard otherwise 👍

Johannes Let's go to the next question from the audience: It's WebAssembly related: What features can we expect for WebAssembly in DevTools? Will there be any special support for various languages and for Wasm?

Kim so regarding the features, I guess I've talked about that before. Regarding various languages: When we previously talked about the symbol server we talked – or I talked – about the C++ symbol server. So that is our focus for this year. We want to focus on C++ this year because we want to concentrate on large high performance applications. After this year we were thinking about also adding support for other languages, but let's see. It's not on our agenda. Other than that we don't know yet.

Johannes There is another question directed to Peter: Do you test new tools with outside users? And if so: How do you choose the users to try out new features for UX tweaks and so on?

Peter actually that's a good question. So at the moment, actually it's not so much testing happening with outside users. And it's definitely like negotiating at the moment. So it's quite difficult to find the appropriate testing users. You ask a huge group of developers “hey Ruth, you might want one to test me features”. You will get this super Pro users usually, and you will get feedback that's usually very very pro focused. And right now we're trying to find ways to find user segments to test free features. For example also non-developers because Devtools is also used by non-developers, right? So we want to actually see how those people – like other designers – use that to achieve certain stuff. And right now we're figuring out how we can set up something that's scalable and gives good insights for us.

Mathias From another angle, we also have these Experiments within DevTools so if there's a feature where we say: okay we're just trying something out, we're not sure if we're gonna keep this, or if it's even the right tool or if it's useful, then we can still build it and add it behind a flag so that it doesn't appear in DevTools by default. But developers can go to their DevTools, open the settings, and then go to Experiments and opt into the experiment first. So it's not exactly A/B-testing or anything like that but it gives the developers a way to play around with new ideas that we're trying out, and to give early feedback. And one of my favorite examples of such experiments is actually the CSS Overview that Paul implemented recently. Yeah, everyone watching the live stream should really just go and check it out, because there's no way to explain it in words that does justice to what you would see. It analyzes your page's styles and gives you an overview of all the different colors that you're using, all the different font sizes, all the media queries that appear in your page, and this kind of thing is really useful if you have something like a style guide that you want to adhere to. Maybe you're using a slightly wrong shade of blue on one line of your CSS but everything else is fine and this tool will help you figure that out. So try the experiment!

Paul yet another angle for you: When you look at something like lighthouse, which we ship as part of the DevTools. Now, that didn't start out inside of DevTools, that started out life in a separate repo. It was an extension and CLI that Paul Irish and I started with it. And then it sort of rapidly changed and grew. And we started to see, developers were actually using it, and giving us feedback and thoughts, and so on. And eventually it made sense to integrate that into the audit panel. So that was another path, where that grew organically. And then we integrated it into the DevTools later. So yeah, that's another take on it as well.

Johannes so, it's already more than 45 minutes passed. So let’s get a last question [editor’s note: from the chat], which is a good open question I think. To all of you: What do you think has been the most and the hardest challenging task building and maintaining in DevTools?

Kim, Peter, Paul, Mathias who do you want to answer first? I think you should nominate people.

Johannes okay let's go for you Mathias

Mathias oh okay now I need to think :) Now for me what is simultaneously the most interesting but also the most challenging about working on DevTools is that depending on the feature that you want to implement you might end up interfacing with all kinds of different parts of Chrome. DevTools is really where everything else in Chrome comes together. It could be that you need to fix a bug in DevTools or add a new feature and you end up working on V8, or you end up working on the Blink Renderer. That happened with color vision deficiency simulation, for example: I had never touched the Blink Renderer code before, but there you go! You have to implement the feature there now. So that is really challenging but also super interesting because you learn about all these little corners within Chromium that you otherwise would never touch.

Johannes so Paul, what do you think as the second one? You had some time to think about

Paul I'm just gonna say “Mathias stole my answer”. He didn't really. Although if I had to pick, I would have actually said that it’s a thing more close to home for me. It is a bit about what I touched on earlier: That we are looking at a code base, a big code base. And even with the best tools in the world, you do have a lot of change in that code base. And it has to be managed well, and that's not just about the code. There are people, whose lives are affected when you go and change a product like DevTools or Chrome. And it's just about making sure that you do the decent thing, and the right, and the responsible thing.

But I guess Mathias was saying the same thing.

That the most challenging things are actually the most rewarding things, as well in some ways.

Because when you get it right, you know that you're actually making somebody's day better. You're building tools that they love. You're building tools that they value. And that's an incredibly rewarding thing. Even if you have to sometimes just kind of get a bigger perspective. Or do something that you're a bit uncomfortable with in terms of “I don't know this code. I'm not as comfortable in this space. I have to go and learn about what this means.” You know, those are all challenges and they add to your day. But then you come out at the other side of it, and actually you've grown an awful lot. And hopefully you brought maybe one or two other people with you on that journey, as well. And that's just hugely rewarding.

Johannes so I nominate as next Peter: From the UX perspective, I am curious about your answer about the hardest and most challenging tasks building and containing the DevTools.

Peter yeah so definitely everything security-related is like super hard from UX perspective. First of all, understanding yourself, because it's so incredibly complicated. And then the next problem is web-surfaced. Often when something security-related happens, like something that's pulled off, like an iframe, a cookie, or maybe like even a window you open. And you mean, are you open, you don't really know what is happening, it was pretty security policies. You just get a “null” return and the developer working on this, also normally does not know this happens. And this is incredibly difficult to communicate, because the underlying concepts are very hard to understand. It's like you wouldn't go one page explanation, and it's also hard to detect when this happens, and to be useful in this moment, and to explain to the developer “hey this is happening because of a new security policy from users”. I think it's really hard, this gives me headaches sometimes.

Johannes Kim, what do you think? What's your opinion and in your perspective: What has been the most challenging and hardest part of living and maintaining the DevTools?

Kim this also relates to Mathias and Paul with front-end and back-end. So basically I am pretty new to the team and for me it's not only looking at the front-end but also at the back-end when I actually debug bugs. That comes up during Wasm debugging. So I have to first understand what's happening in the front-end but then I have to see what's happening CDP what is sent back and forth, and then I have to see where it's happening in the back-end, and what is going wrong in the back-end or in the front-end. So it's actually a lot of different things to consider together in order to be able to catch that bug 🐞 and to write a test for that.

Johannes Paul, I'm having another question to you, it's audio related. 😂 No, we've got the feedback from Kerstin “perfect audio quality on Paul's last question” ❤️

Paul I didn't realize I was gonna be such a problematic person today “hope you could repeat the answer to that because we had no sound”, that's today

Johannes sometimes it happens, yeah …

Johannes Let's close it out. Thank you very much, Kim, Peter, Mathias and Paul for your time, for answering the questions! I'm curious about your feedback as well.

And to all the ones, who watched the live stream and will watch the video later on: This is like the 2nd episode of the so called “JSKongress meets friends” series and we want to improve based on your feedback.

So I think, compared to the first episode, it's been better from the quality, from the technical descriptions, we did some technical deep-dive, which was one of the feedback you wished. So please, leave a comment on Twitter and comments and that's it for today.

Thank you very much!

Kim, Peter, Paul, Mathias thanks for having us! thank you!

DevTools and beyond — JSK meets friends #2

JSKongress — Mon, 27 Apr 2020 06:57:55 +0000

JSKongress meets Paul Lewis, Kim Anh Tran, Mathias Bynens, Peter Müller on Tuesday, 28th April, 5:30 pm (CEST)

Here is the second episode of #jskongress meets friends: We are excited to announce the guests for our next episode.

Join us live on Tuesday, April 28th, starting 5:30 pm (CEST) on our channel youtube.com/jskongress

We are so grateful, that these four amazing people from the Chrome DevTools Team will join us:

Kim Anh Tran (WebAssembly SWE)
Mathias Bynens (Design & Accessibility TL)
Paul Lewis (Architecture & Testing TL)
Peter Müller (UX lead)

We will discuss Chrome DevTools, especially History and Architecture, Quality & Workflows, Team Organization, Design & Accessibility, WebAssembly Debugging , and further questions that have been proposed by the community.

Send us your questions until Monday, April 27th — comment here or via mail to hello[at]js-kongress.com

The post DevTools and beyond — JSK meets friends #2 appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

Live: JS Kongress meets Keerthana Krishnan & Robin Böhm

JSKongress — Sat, 11 Apr 2020 14:38:06 +0000

JSKongress meets Geeky Purple Unicorn and Robin Böhm live on Tuesday, April 14th, 5:30 pm

All our lives are affected by #covid19 as #JSKongress is as well. We are separated physically by #StayAtHome , but socially we are united.

JSKongress meets friends is a new online format with friends of JS Kongress! Everyone is welcome to join us, exchange thoughts, motivation, experiences and knowledge.

Let’s share thoughts and approaches to create a positive vibe for the future out of the crisis. If you have someone in mind you want to see in this format, let us know, ping us with your suggestion

In the first episode we are joined by Geeky Purple Unicorn and Robin Böhm, it will be live on Tuesday, April 14th on 5:30 pm CEST. Now available on demand:

“Better be safe than sorry” — thanks to Keerthana a.k.a. KK for the positive vibe in the current situation

Next episode: join us as well on Wednesday April, 28th — Which topics and guests would you like to have for the next episodes? We are interested in your ideas!

Don’t miss an episode, we will be live regularly: Subscribe to our channel https://www.youtube.com/jskongress

The post Live: JS Kongress meets Keerthana Krishnan & Robin Böhm appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

9 Reasons that Convince Your Boss

JSKongress — Thu, 09 Jan 2020 14:31:01 +0000

Want to attend JS Kongress 2020, but not sure how to bring it up with your boss? We’ve created this email to help you explain why it’s important to attend.

Dear [Name of your Manager],

I’d like to attend JS Kongress 2020 taking place on April 15–16 in Munich, Germany. I’ve researched many conferences, and this is THE conference for gathering developers to share learnings, highlight innovation and discuss the future of JavaScript, including scaling, massive platforms, data-driven architectures, and modern APIs.

With growth , the pain of scaling is added for every company and project. And scaling problems are hard problems. Scaling affects everyone : frontend, backend, architects and teams. JS Kongress 2020 is on the various areas of scaling: questions and optimization approaches will be discussed on and off stage. Attendees will leave ready for the future, equipped to master what’s to come. [reason 1]

Over 500 of the most talented individuals in the industry gather together for this event making it a great place to network with industry professionals and learn from the top JavaScript experts.

Here is some data from JS Kongress in 2019 to give you an idea of who attends and why:

• For 66% of attendees, this was their first JS Kongress making it a great place to learn for newcomers to the JavaScript community. [reason 2]

• The top two reasons that people attended JS Kongress were for the talks (56%) and networking (24%).

• The huge majority of participants (82%) have more than 3 years of experience in JavaScript, only 4% don’t (yet) have a technical position. The focus of the program is clearly technical. [reason 3]

• The 33 countries of origin of attendees are located around the world, 25 % of them come from European countries. The conference is an excellent opportunity to expand my intercultural skills. [reason 4]

To get a feel for what the conference is all about, check out this mood video from 2019.

Here’s how I envision my attendance at JS Kongress 2020 strengthening our company:

JS Kongress Munich offers 2 days full of sessions including technical sessions, deep-dives, case studies, and more. Attending these sessions will allow me to build my knowledge of best practices and new trends in the rapidly evolving JavaScript ecosystem. [reason 5]
The partner stands at JS Kongress Munich will allow me to meet technology and business leaders to collaborate on the technological challenges and implementations we’re working on while creating strategic partnerships that will benefit our company. [reason 6]
In the #DeepTrack the premier vendor-neutral JavaScript event brings together the industry’s most respected experts and key maintainers behind the most popular projects in the JavaScript ecosystem. This will allow me to gain insight into the roadmap of these projects and how we can utilize them in our software stack. [reason 7]
All of the speakers of JS Kongress Munich are working professionals , who are juggling current projects and handle real clients. Thus they are fully aware of the challenges that we are facing in our daily work. I am expecting to learn the most useful and practical JavaScript tips and tricks, which can be put straight into the action. [reason 8]
How about using this event to help us solve current and recurring issues , that our team is confronted with? A special focus of JS Kongress Munich is on socializing and exchange of knowledge. Beforehand in our team, we can prepare a list of questions to bring to the conference and to discuss with the community. I will be able to bring home a new way of looking at things as well as new ideas and solutions. [reason 9]

Even better than sharing is creating a shared experience among the team. Therefore JS Kongress offers group tickets (with 10 % discount). We can meet potential collaborators, experts in the field and maybe a new colleague.

You can learn more about the conference here and view last year’s keynotes and all sessions here.

If I register before January 15 , the fee is only EUR 329. Included in the registration fee is access to all keynotes and sessions, a number of co-located events, coffee breaks and hot lunch, and other evening networking events.

Not included but special offers are available for traveling to Munich by train with the fixed-price event ticket and staying overnight with a hotel contingent. As well, the ICT-hub Munich offers excellent connections for international travel.

I would be happy to write a post-conference report and share with other members of the team what I’ve learned and how we can implement these JavaScript tools and techniques into our business strategy.

Thanks,

[Your Name]

Have to meet some specific requirements of your company to be able to attend? Get in touch via hello[at]js-kongress.com, we are happy to assist you!

Tickets are available in our ticket shop : Early Bird for 329 € until January 15, Regular Tickets for 429 € until March 15, afterward Late Bird Tickets for 529 €. Groups of 3 or more are entitled to a 10 % discount. Student Tickets are available at a special rate.

It might be interesting for your manager as well: All sponsoring packages include tickets. Interested to position your brand in this positive atmosphere? Get in touch via partner[at]js-kongress.com.

The post 9 Reasons that Convince Your Boss appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

A week full of JavaScript, IT and Community

JSKongress — Thu, 14 Nov 2019 12:01:02 +0000

… taking place in April 2020 in Munich, Germany

We and our events stand for Diversity — not just in Tech, A balance between professional work, fun, and community, Bias for Action, Thinking one step ahead, A connection to open source and community-driven projects, Party hard with the community

We have been very inspired by the community effort to bring even more JS into the week of JS Kongress. We thought about it for a long time to bring together not only 2 days, not 3, not 4 but a whole week of #JSCommunity in Munich.

So we thought about, what we can do to support the community and these are the very first results:

we offer a shared coordination sheet, where you can put your proposals and ideas into
we will include the Meetups and community-driven events in a special section of our program and website
we will help to reach out to people who could be interested
we will include your actives in our social media communication
if you need any assistance e.g.regarding location scouting, we will try to support you

So let’s make a #JSCommunity week full of JavaScipt in Munich around JSKongress. Our many domestic and international guests and speakers can join these activities and have a greater stay in Munich.

Subscribe to our Newsletterto stay up-to-date …

… and follow us to stay in touch:

jskongress on Twitter, LinkedIn, Instagram, YouTube, Facebook

The post A week full of JavaScript, IT and Community appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

#JSKongressGoesGhana — community all year long

JSKongress — Mon, 28 Oct 2019 12:50:02 +0000

#JSKongressGoesGhana: JS Kongress Munich X Facebook Developer Circle: Accra joint meetup with a lot of great community people

For JS Kongress in March 2019, Oliver (picture above: first row middle, white shirt) couldn’t join us due to visa issues. The thought originated and the idea grew: “If you cannot join us, then we’ll come to you”. #JSKongressGoesGhana has been born.

Half a year later, Jowe and Marco S from the JS Kongress Orga-Team set off from Munich, Germany to Accra, Ghana 7233 km away to meet Oliver and the local community.

Their time in Ghana started with a cozy community dinner, where they met some community leaders.

Then, the big day came, on Saturday, October 26 the joint meetup JS Kongress Munich X Facebook Developer Circle: Accra took place.

In the afternoon, there has been a room full of passion and interest , a welcoming and vibrant community. Thank you all for joining and participating!

Thanks to all speakers and panelists: @KiddBubu, @silentworks, @gideonaduku, @codeprophet, @yamoateng, @jowe, @Schnapumpel13

A gift from our MunichJS community member and JS Kongress speaker Axel Rauschmayer: JavaScript for impatient programmers — you can find the digital and printed version of his book on https://exploringjs.com/impatient-js/

More photo highlights by @KhoPhiPhotog are available online.

Find his channel “KhoPhi — Tech. Every Week” on YouTube and the great series “23.3 Questions” interviewing social entrepreneurs, community leaders, creatives and other inspiring people from Ghana.

@nkansahrexford (KhoPhiPhotography) caught working

Thanks for the other photos to @nkansahrexford, @nedu63, @OliverMensahDev, @Schnapumpel13, @Dext_OUATTARA, @codeprophet, and @jowe.

Update: On 2019–10–29 we had an appointment at the German embassy, and the great opportunity to discuss the collaboration of Ghana and Germany (especially in the IT sector). Read more in this Tweet

Join our community — stay up to date with our newsletter

The post #JSKongressGoesGhana — community all year long appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

Diversity Scholarship Program of JS Kongress 2020

JSKongress — Thu, 17 Oct 2019 12:56:02 +0000

Scaling JS — Pushing the Limits!

It’s our main goal for the JS Kongress 2020 (April 15–16) to have an inclusive event with a welcoming atmosphere where everybody feels welcome, so that people can connect, hang out, make friends — and all of this while learning about JavaScript and seeing beyond their own noses.

Why are we doing this?

Diversity Tickets give us the possibility to support someone who otherwise can’t be a part of the JS Kongress community. We are happy to have the opportunity to give a helping hand, as we have seen diversity tickets change the lives and careers of people in the community.

We believe that a more diverse crowd makes for a better event and community. If you agree, we invite you to become a Diversity Supporter by reserving your own seat and supporting another attendee with a share of 25%, 50%, 75% or a complete ticket (100%). Support Tickets are available in our ticket shop >>

If you want to offer support on a larger scale, please get in touch to become a Diversity Sponsor. Send a mail to partner@js-kongress.com >>

What is a Diversity Ticket

These tickets are made available for applicants either from underrepresented groups in tech or who do not have the means to finance the trip and participation. This includes, but is not limited to following examples: If you are a woman, or you are a person of color, or part of the LGBTQIA+ community, or you are a refugee, or you have any kind of handicap, or you are facing economic hardships — we want to invite you to be part of JS Kongress 2020.

To make that easier for you, we provide a limited number of free Diversity Tickets — funded by Support Tickets that are available in our ticket shop as well as Diversity Sponsors. Diversity Tickets are available in 2 versions: with or without travel support. The number of awarded tickets and options depends on the volume of the #jskongress Diversity Fund.

These tickets are available through an application procedure. Along with some information about who they are, we ask applicants a few questions about what they do in tech, and their motivation to be part of the JS Kongress community. These answers are for the jury, who will evaluate the applications and award the tickets.

Apply for a Diversity Ticket here >>

The #jskongress Diversity Fund is composed of Diversity Sponsors and Support Tickets, that are available in our ticket shop.

Important dates:

– Deadline for application: 2019–11–15

– Notification of applicants: 2019–11–25

The sanctity of applicant information

Applicant details and submission information will be shared exclusively with JS Kongress organizers for the purpose of the invitation. Diversity Sponsors and buyers of Support Tickets will not have access to applicant information.

How are fellows determined?

A limited number of tickets will be available (depending on the fund volume). The jury will thoroughly test each application to ensure it satisfies all requirements of the scholarship program before being added to a pool. Diversity Tickets will then be awarded via a lottery system. One submission per applicant is sufficient to maintain eligibility.

What does a Diversity Ticket include?

Diversity Tickets are full conference tickets, they include:

entrance to #jskongress 2020, April 15–16 in Munich, Germany
attending the complete main stage program
participation in #DeepTrack, the unconference where all participants create the program
food and drinks during the event (breakfast, hot lunch, coffee breaks, party on the first evening)
admission to the parties organized for the conference attendees, speakers, partners and staff
optional / depending on fund volume: support for travel and accommodation (up to €300)

Apply for a Diversity Ticket here >>

Want to support this Diversity Program?

We are currently opening the #jskongress Diversity Fund — tickets will be awarded at the end of November 2020.

Diversity Sponsorship is not money for a party, nor for fancy catering, or a nice booth. It is a chance for someone. Therefore a Diversity Sponsoring does only include your logo being added to the list of sponsors. Interested? Get in touch with us >>

Your consideration and contribution to helping our creative community to grow and to evolve will be recognized. Diversity Sponsors’ company logos will be added to our Sponsors & Partners section, and sponsors will receive special recognition during the conference.

Your second option to support diversity on #jskongress is by buying a Support Ticket by adding a fee of 25%, 50%, 75% to the value of your own ticket or even buying a second full ticket to support another person. Support Tickets are available in our ticket shop >>

A huge “thank you” goes to our first Diversity Sponsors for their support!

Peerigon supports diversity on #jskongress

Code of Conduct

First of all, everyone — attendee, speaker, sponsor, and volunteer, as well as the team members — at the JS Kongress, have to agree to the Code of Conduct. You agree to comply by purchasing a ticket as well as by attending. Also, the organizers will enforce this code throughout the event. Finally, we are expecting cooperation from all involved parties to ensure a safe environment for everybody.

The post Diversity Scholarship Program of JS Kongress 2020 appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..

Double Agent: Jowe from the Orga-Team “spies” the Program Committee

JSKongress — Fri, 04 Oct 2019 13:11:09 +0000

Johannes Weber: Jowe is an adviser and developer in the field of web technologies spotlighted on JS.
In his free time, he loves to bring people together. He (co)-organizes
the AngularJS and ReactJS Munich Meetup Groups.

Being the 8th member, Jowe completes the Program Committee, which is now ready for the start of the evaluation phase of the #jskongress Call for Papers on October 16.

Also a part of the Orga-Team, he performs 2 functions–that are completely separated: During this stage, he doesn’t have full admin access for sessionize so that the anonymity of the evaluation won’t be comprised. Read more about our scheduling tool >>

Let’s welcome Jowe, who will give you some insight into the machinery behind #jskongress.

As a member of the #jskongress Orga Team and Program Committee at the same time, you have one vote as an equal member in the scheduling process. Why are you looking forward to #jskongress?

I’m looking forward to the third edition of JS Kongress which has evolved over each edition. For me, the realization that we, the Orga-Team, put something valuable out into the world is the most joyful thing. We aim for creating a technical and social impact by taking action on different topics.

I’m looking forward to seeing new ideas we tried out going into practice and make everyone feel that unique experience when attending the JS Kongress.

One of those ideas is the so-called #DeepTrack. Besides the main conference track, the DeepTrack is about sharing knowledge, discussing and working on all kinds of topics around JavaScript. It’s about having fun with like-minded people in a safe environment where the participants create the program! The overall idea is to have a creative space, to share ideas, work together, discuss and listen to each other — face to face.

I’m looking forward to all the joyful moments, meeting old friends and making new friends and get to know a lot of exciting and inspiring people.

What’s your vision for the program?

My vision is to create a program full of humans who will push you to think about the JavaScript landscape in new and valuable ways. It should cover JavaScript and the surrounding area every engineer has to deal with. Like tooling, deployment strategies, optimizations, organizing large projects, going at scale, distributed architectures, new approaches, etc.

It should be a pleasant experience for the different experience levels, so everyone can get inspirations and takeaways. Besides that, I think bringing the different experience levels together is the most valuable you can get out of the JS Kongress. It’s about learning from each other, sharing and discovering new ideas.

Do you remember, when you got in touch with JS for the very first time? What was the reason for it, or who?

I precisely remember this time. It was at a time where IE6 was the major browser. My friends and I wanted to exchange some pictures of the activities we did at that time. We’ve been annoyed by sharing them on CDs and doing that physically. There has been no facebook or another popular platform to share pictures at that time, so I came up with the idea to create a website for that. Taking action on that, I played around with applications like Dreamweaver and FrontPage. It was okay in the beginning, I was stunned how easy that was. Inserting GIFs, creating the typical Framesets and so on. But when going more individual, it got challenging. I wanted to click on a link to open two different pages in two different frames.

Since this was not easily doable out of the box, I started researching about it. I found a lot of approaches and started reading the first time “you can do it with JavaScript”. That was the time when I went deeper into the subject to get the opportunity to click on one link and achieve two different goals. After a few days of playing around and seeing a lot of JavaScript error alerts, I got it working. This sparked my interest in JavaScript, and I spent more and more time familiarizing myself with it. In the end, it helped me get this website done. My friends and I had a website to see our latest pictures and we’re even able to communicate on that site (by using a hosted guestbook solution, embedded around fancy gifs ). Last but not least, it changed the industry I was working at. It caused my interest to focus more and more on engineering, so there was a point when I moved from the interior design industry to the IT industry.

Do you have some motivation for all speakers and everyone who thinks about submitting their idea for a talk?

If you are playing with the idea of submitting a talk, I recommend that you push yourself out of the comfort zone and do so. Speaking publicly is a skill you’ll use for the rest of your life. And you already did it: Every time you explain something to a group of people, you are, in fact, speaking publicly. Give it a try and extend your audience. It’s an excellent opportunity to share your passion and the story about your learnings and pitfalls. This creates an impact by motivating others to help them avoid the pitfalls you had on a topic, share your passion about something and engage with the audience. I personally see speaking public as an open-source activity. It’s about giving something back to the community by sharing approaches and challenges you’ve discovered, and you’re proud of.

No one is a born master — for those who are thinking about giving a talk but never did it before we offer a first-time speaker mentorship program. Our First Time Speaker Support Team provides individual support for first-time speakers. Beginning from finding a topic, defining the story, writing the abstract, giving feedback on the presentation skills until the moment when going on and off stage. Stay tuned, we will share more information on that soon!

You are living and working in Munich. Do you have some secret tips for everyone participating JS Kongress, what they need to see, where to eat, or beautiful spots to have a walk (or others)?

There are plenty of things to do in Munich. From a walk through the old town of Munich, which can be done regardless of the weather, to a relaxed stroll along the Isar. If the weather allows I recommend going to one of the traditional beer gardens and enjoy the yummy Bavarian food. For more extended stays, the surrounding area around Munich is joyful as well. There are many mountains to hike and lakes in the immediate vicinity of Munich. For the evenings I recommend the smaller and fancy bars in Westend, Neuhausen or Schwabing. What I enjoy the most is bringing all that together: Starting with a walking tour in the city center, throughout the English garden, crossing the Surfers Wave at the Eisbach and continuing the way along the Isar with a stop in between at a beer garden.

If you want to get in contact with the local community, check if some meetups are happening when you stay in Munich. There are usually a lot, and it’s a good chance of meeting new (and mostly local) people.

The Call for Papers of #jskongress 2020 is open until October 15 — we are looking forward to reading your ideas on https://sessionize.com/js-kongress-2020

Find the FAQ on our Call for Papers on https://medium.com/@jskongress/cfp-faq-first-members-join-program-committee-8fec626a1ce0

As well we are looking for your idea for the #DeepTrack. Everyone with a ticket can participate, all attendees create the program together: https://github.com/JSKongress/JS-Kongress-Munich-Deep-Track

The post Double Agent: Jowe from the Orga-Team “spies” the Program Committee appeared first on JS KONGRESS 2020: Scaling JS – Pushing the Limits: Massive Platforms, Data-Driven Architectures, and Modern APIs..