In this episode of JavaScript Jabber the panelists and guest delve into the advantages of the shadow dom, transitioning from polymer js polyfills to native web components when moving for SAP UI to UI5, which works within React, Vue, Angular, and others.

 

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Peter Muessig.

DAN_SHAPPIR: Hi everybody and welcome to another episode of JavaScript Jabber. Today on our panel, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

DAN_SHAPPIR: We have AJ O'Neill who's making a lot of background noises. 

AJ_O’NEAL: Oh, am I right now? Sorry. Yo, yo, yo, coming at you live from the background noisosphere of Pleasant Grove, Utah, 

DAN_SHAPPIR: and we have Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

DAN_SHAPPIR: And today our guest is Peter Musig. Am I saying your name correct? 

PETER_MUESSIG: Yeah, that's good. Thank you. Hey there for having me today. 

DAN_SHAPPIR: Oh, you're very welcome. And I understand that you're here to speak with us about web components and in particular about web components at SAP. 

PETER_MUESSIG: Right. 

 

When it comes to test maintenance, the biggest complaint that teams have are flaky tests. Tyco is a Node.js library built to test modern web applications. It creates highly readable and maintainable JavaScript tests. Its simple API, smart selectors, and implicit weights all work together toward a single goal, fixing the underlying problem behind flaky tests to make browser automation reliable. Tyco is open source and free to use. Head to tyco.dev and get started. That's T-A-I-K-O.dev. 

 

DAN_SHAPPIR: So Peter, can you tell us, before we start discussing that topic, can you tell us a little bit about yourself and what it is that you do? 

PETER_MUESSIG: Okay, so I'm working now in the meanwhile since about 15 years for SAP. SAP is one of those big companies selling enterprise software. In the meantime, I'm working here as a UI framework architect. So I had the luck in the past in 2009 to be selected for a new project to develop a brand new JavaScript UI framework together with a lot of awesome people here. As this started in the beginning, I mainly worked on building a control framework here for SAP for providing at least the controls in a reusable asset. But this framework has been grown over the years in an application framework in the enterprise application framework. Today it's known as SAP UI5. And in the meantime, since 2013, also a long time ago, we have also open-sourced the core of UI5 as OpenUI5 publicly. Since 2017, my main job is now to really work on the innovation of this framework, its tooling, and the controls to align with the latest trends in web standards. And one pillar here is the renovation of our UI elements to move them towards web components. Well, basically, that's it. 

DAN_SHAPPIR: Okay. So you, you used a lot of words there, frameworks and components and controls and whatnot. So, so maybe in order to kind of disambiguate between all these terms, when you're talking about UI5 as a framework, what does that exactly mean? I mean, is it the framework, like when I say Angular or React, or is it something else when you say a framework? And what is a UI5 control? What does that mean? 

PETER_MUESSIG: Okay. So when you compare SAPUI5 or OpenUI5, so this one or other, I'd always used UI5 as a common term on that, about the UI5 framework. It's something which can be compared to that what Angular is. So it's a framework about building applications. You have capabilities like routing inside that framework. It comes with a concept of model view controller to design your UI assets and to define the logic. It also has capabilities to connect to web services. In our particular case, we are at SAP, mainly consuming. We have the OData service behind the scenes, and we have built a lot of helper stuff on top to easily consume these services. So I would say it can be compared on that level. And when people talk about the React part, they more talk about a library. And I heard that many people say, yeah, React is not a framework, it's a library. React basically does, if you don't use the extensions, this is something like what I would say it's on our side more a UI5 control. So you can build these UI5 controls. The UI5 control is a reusable UI element in the UI5 framework, which can like a button or like even a table and stuff like that. And they are built in a way that they can be shared with the application developers. What is also interesting from our point of view. From a UI framework point of view, UI5 framework point of view is that we somehow keep the people, the application developers away from writing HTML and CSS. So they really mainly work with our model view controller and UI control concepts to build their user interface. 

DAN_SHAPPIR: So based on your description, I gather that when you're talking about UI5 as a framework, you really mean that it's a framework. You were talking about a router and model view controller, so it's kind of comparable to, let's say, Angular or something like that. 

PETER_MUESSIG: Exactly. 

DAN_SHAPPIR: And is it also open source? 

PETER_MUESSIG: Yeah, the core of the framework is open source as OpenUI 5. You can look at that at openui5.org or it's in GitHub, github.com.sap.openui5. And there you can look into the framework parts, you can get started there and play around with that. 

DAN_SHAPPIR: I'm kind of curious, I don't know if that's a question you can answer, but I'm kind of curious as to why SAP has chosen to develop its own framework rather than to use one of the many, many, many frameworks that are out there. 

AIMEE_KNIGHT: Same question. 

PETER_MUESSIG: Yeah, when looking back when we started, so as I said, I'm now 15 years at SAP and since 11 years now I'm working for this UI5 team. I was one of the people in day one in the UI5 team. The main part why we developed one thing was that at around 2008 when we did our first POCs, there was no real framework available out there which we considered to use. So we looked at Dojo at that point of time, but it didn't have this capabilities what we expect. So the UI5 framework, what we want to have is, or what we are doing here is we're fulfilling the SAP. That's what we call here, things like supporting globalization, we are supporting security and we have accessibility features. And when we were looking at that point of time into Dojo, we couldn't find how we could more or less use that framework to make it possible. And then with that, we really started to build our own framework. We called it Phoenix at that point of time. And over the years, this framework has grown. So we have seen many, many other frameworks over the years. So we were, in the beginning, also compared with Dojo. And then JQuery was also at that point of time. We had a period where Censure or XJS was there. We had also a period when Angular and React came up, where we have compared. But all over these years, UI5 had been somehow available for our developers here. And we provide them support since these 10 years and mainly, I would say, in these 10 years, we try to be as compatible as possible that all the applications which have been built with UI5, they still continue to run with newer versions of UI5. And this is what we are also guaranteeing for our application developers. And this is also from an enterprise perspective, something that customers are paying for and what they expect. And this is also our somehow approach, what we do here. 

DAN_SHAPPIR: So does UI5 have any sort of dependencies on external libraries or other frameworks even or stuff like that or is it wholly self-contained? 

PETER_MUESSIG: No, no, it's not fully self-contained. It was in the beginning but at some point of time we decided to use Jake Viri as a kind of an abstraction layer. It's one of the famous examples what we have at the point of time when we did it. I think it was around 2010-2011. This was really something where the people were absolutely happy to have that inside. And there are also a few, it's a lot of other stuff as well used inside of UI5. So we are using many open source to do, for example, UI handling or handle bus was in as a templating engine. So we are really using open source and with a movement to make the UI5 framework also open source, we somehow make. Also the way back open that we also contribute back our stuff to the open source world. 

DAN_SHAPPIR: And one more question about UI5. I know that's not the main topic of discussion today, but still it's an interesting subject. What do you usually use as a backend when you use UI5 as a frontend? 

PETER_MUESSIG: So the main scenario what we have here at SAP is that we have, we call it a gateway system. It's an OData backend behind the scenes and we are connecting UI5 applications to it. But UI5 is not built exactly only for that use case. So it comes also with a simple JSON model. So you can connect at the end to any REST back end, whatever. But for the OData back end, we wrote a lot of helper functionality to make it easier to consume it. But it's not coupled to that. 

DAN_SHAPPIR: So basically, if I understand, what you're saying is that applications that are written with the UI5 frameworks, are mostly client-side rendered and they talk to backend services which provide data and then they render the content on the front-end side. E

PETER_MUESSIG: xactly. That's in short what it is. 

DAN_SHAPPIR: Okay. Anybody else has a question about this framework before we move over to Web Components? 

STEVE_EDWARDS: So I'm looking at one of your pages here and you've got some sample applications for how to integrate UI5 into React and Vue and Angular. So it looks to me like, in just browsing through the view sample app, it looks like you can basically take app using one of these other frameworks and just integrate the particular tools from UI5 that you want. You can sort of pick and choose, you know, if you want like date pickers or various other types of components provided by UI5. Is that correct? 

PETER_MUESSIG: What you are looking right now, Steve, is it's the UI5 web components part. So the UI5 framework as such. It's more on a level like Angular. It has been built as somehow a framework where you can build a UI5 application with, and it's not built in a way that it can be used by other frameworks. So that's what we are driving since about one, one and a half, two years now, since we are doing the UI5 evolution project, which is my main project here, to modernize UI5. The old UI5 was built in a monolithic way, so we could not reuse parts of that for other frameworks. And with the innovation of the framework, we want to shift UI5 into a universal toolbox. So that's stuff what we build like helper functionality for using formatting functionality and stuff like that. But this can be also shared with other frameworks that you can really benefit that also for not only UI5. The other thing what we are doing is the modernization of the rendering and controls layer. And this is now something which leads me to the UI5 web components. And they have been built in a way.

 

that they are built close to web standards. So on the web components, web standards, we build it in a way that they can be easily reused with any frameworks. They are built in an agnostic way. And they should be also integrated back and will be integrated back into the UI5, OpenUI5, sub-UI5 world. 

AIMEE_KNIGHT: OK, so I do have a quick question before we move on. So you had mentioned that it's using MVC. Is that something that you all are sticking with, or will you be changing that direction as part of modernizing things. 

PETER_MUESSIG: So this might be something also to be considered to be changed. At the moment it's our way of how you build the UI5 applications for UI5 web components. We don't assume anything. So UI5 web components are really the UI controls or UI elements to be precise, not to mix controls here and components. For them we really want to make them really low-level, they should be just reusable UI elements which align with our designs. So we have our themes, they align with our concept how you can more or less integrate these controls then. And what we did mainly with the UI55 components is that they have been built up really on top of these standards from today like we use custom elements, we use Shadow DOM, we use ES6 modules and all that stuff, that they can be easily integrated also with any framework. And this is what is our key asset in moving our UI element definition layer really one level down into the standards world. 

DAN_SHAPPIR: I actually think it's a really smart move on your part to move from your own proprietary framework, which kind of by definition, you're playing in a very crowded field right now, and you're not in the leadership position because, obviously, I think more people are familiar with React and Angular. I think that having a really powerful web component library at this point in time that can, in fact, be used from any framework, essentially, is something that can be really, really useful for the community. So I think that's a really good move on your part. So just to understand how you went about it, can you describe the process that took you from having those controls that are tied to your proprietary framework and decoupling them and transforming them into web components. 

PETER_MUESSIG: In our company, you have to see in SAP, things are changing also. We acquired also a lot of companies over the last year. In our early days, it was not so complicated. We could give the framework away. Many applications have been newly built. And now with the acquisition, it's vice versa. So the apps are not built completely from scratch anymore. There are applications which are existing. What we really thought about is how we can make sure that we can provide our UI elements, how we expect them to be built from a SAP perspective, also to our acquisitions, that they can reuse all this standard behavior and also the look and feel of the application, of the controls, sorry, of the components. With this move then to the web components, we thought this might be really the best and optimal way. Since what we have here now is we have really a standardized API. So we have the custom elements where you can have it packed and more or less. And behind the tag, we really shield the behavior and the visualization of that control. And we can give that completely to our acquisitions and also to others to embed that in their application and to render these tech. And then they also get then a functionality like this date picker control. If you look into our entry page, SAP GitHub IO slash UI5 Web Components, there you see also on the start screen one example with the date picker control. So this date picker, what you have there, it's completely globalized. So it can support multiple different calendar types like our Gregorian, like Islamic calendar and stuff like that. All this logic is really behind the scenes. And the only thing what you as an application developer or HTML developer is seeing is that you have this custom tag and this is the thing you put into your page. In addition, you need to require the controller to import this year's six module and with that you are done. And yeah, you know, this really looked in a way really the best optimal way how we can make sure to share our knowledge, what we have in this framework or control development area, with all others who are more on the consumer level of that. 

DAN_SHAPPIR: So just to make sure that I understood the process, what you're basically saying is this. You're saying previously all the web applications were kind of done by teams within SAP, so we could control what they were using from day one. So we gave them a framework that was most appropriate for our own use cases. And that was the easiest way for us to work. But now because of all these acquisitions, we have existing, let's say, web applications or websites that were built with a variety of frameworks. We want to give them a common, let's say, user experience, look and feel and whatnot. So we wanted to create, to transform what we have into something that can be integrated into any kind of framework or any kind of web application and make it possible for them to kind of reuse and provide the common, let's say, SAP look across the entire line of all our products. Is that correct? 

PETER_MUESSIG: Yeah. 

DAN_SHAPPIR: OK. Amy, I think you had a question about web components in general, though, right? 

AIMEE_KNIGHT: Yeah. So, oh, god, my voice. I've been sick for like two weeks. Oh my gosh. So I'm going to actual talking about web components. So one thing that we've been looking at at work is kind of the whole like micro front end thing. I know that's super buzzwordy, but we are looking to do it with React. One thing in like researching this that I've come across is like a lot of people talk about this in the web component space. So I was curious, in your opinion, why you think that this is something that people in web components have really picked up on, but other communities are slower adoption. I know we talked about it a little bit before the episode started and what you were saying made sense. So figure share it with the rest. 

PETER_MUESSIG: Yeah, the microphone and stuff is mainly something which, which has the benefit when looking into the web components because a web component as such, with its capabilities of having the shadow DOM, you could more or less encapsulate the HTML and the CSS completely in the shadow DOM. If you bring something like a reusable UI together on a screen and putting that into a, yeah, call it micro front-end web component, then you can ensure that the HTML and CSS of this UI part is then completely isolated and it doesn't affect the other things on the screen. This is more or less what I see where the micro frontend is then really supported by this Web Components concept. 

AIMEE_KNIGHT: And maybe, I guess we probably should clarify micro frontends because I kind of had this question when I was first digging into it like the difference between reusable components and micro front-end. So to me, and I'm curious what other people think, because there might be maybe different distinctions, but to me, like micro front-end is independently deployable, whereas these components are just things that you would build, but you need kind of like the parent application to include them. Is that the same thing with the web component space or is it a little bit different? 

PETER_MUESSIG: You can, if you would build your application completely in a way that it can integrated in such or rendered in such a micro frontend web component, then you would have the same aspect. Yeah, right. So at the end, you would have something like an application by way of defining, then you have individual parts of that. And these parts, these complete standalone applications that would be rendered with a with a micro frontend part and inside of your complete application container there.

DAN_SHAPPIR: My approach is perhaps slightly contrarian. From my perspective, a web component is there, let's put it this way. There is an HTML standard for web components. So if you use certain DOM APIs, if you structure your files in a certain way, if you utilize certain technologies, then that's kind of the definition of a web component. So web components are certain technology or standard implemented in the context of the web. Micro-frontends are kind of supposed to be a paradigm, so they're not particularly specifically tied to a particular technology. It's, from my understanding, it's kind of the concept that rather than using some sort of a holistic approach across my entire frontend, let's say of Angular application or something, I construct my frontend from entities that can be wholly distinct and consequently use separate technologies. So theoretically, I could have in one part of my page, I could be using React, and another part of my page I might be using Vue or Angular or maybe all three, kind of modeled after the concept of microservices on the backend. I find this concept to be really problematic because at the end of the day, we need to download all this stuff. So if I'm going to be downloading not just React, but now React and Angular in Vue, just so that I can have this sort of separation of concerns on the front end, I find that to be well, kind of too extreme and wasteful, but maybe somebody else has a different definition. 

AJ_O’NEAL: Welcome to the internet. 

PETER_MUESSIG: When you see a zoo of different technologies, this is really one thing where you see also how that it could be in relation to the performance of such applications. So it's a good thing to harmonize on different technologies. But yeah, at the end, allowing a possibility to build this kind of micro-fundance in a way that you build the service and the UI together, bringing that together in some kind of a container, but maybe at the end have some kind of governance on the technologies being used. This might be I think the best opportunity in bringing the pieces together. 

DAN_SHAPPIR: So with the web components that you built, did you guys build them directly over JavaScript, CSS, and HTML? Or inside of them, are you using third-party libraries? And if so, which? 

PETER_MUESSIG: Our web components really built blame on the HTML element. So when we started, some years back in 2017, looking really into these web components. There were not so many things we could really reuse. So we looked into this Polymer project. At the end, reusing the polyfills, this was already one great starting point. But what we internally use are techniques like, for example, using LitHTML, so one of these nice templating mechanisms, to really update the Shadow DOM or render the Shadow DOM content inside the web component. But basically, most of the pieces are there is built by us. So we have a UI5 element as a base class for the Web Component. This provides some capabilities like all, let's say, major other Web Component base classes provide some kind of definition of a metadata, like which properties you have, which slots are there, what are the events. Then this base class also manages the lifecycle, like doing the rendering. And what we have maybe as one of technical assets is, that we somehow also abstracted the rendering engine from the web component. So we are using a format like a handlebars format to define our HTML of the web component. And then this format is being used by our lead renderer then to, or we convert that in a lead renderer. And then with that, we inject then, or create the markup for the shadow DOM. All the outer components which are then nested inside, they are using slotting mechanisms elements inside the Web Component. 

DAN_SHAPPIR: So how big are these Web Components usually? 

PETER_MUESSIG: When I remember right, having a label plus the base framework was around 13 kilobytes. So adding then one more control is like, let's say, what else was in the label was, and the button increases the size then for four more kilobytes of the basic bundle. So you have to see that in our base framework. We are mainly taking care about this abstraction, about the metadata parts and stuff like that. And so the elements, let's say, are around four to five kilobytes, I would say, the base elements. 

DAN_SHAPPIR: And can you kind of give like a quick list of some of the main web components that you have, that you provide? 

PETER_MUESSIG: So at the moment we have, let's say, around 35 of these web components available and built from our site. Basic things like a button, link, label, input are in. But then we have also a bit more sophisticated controls or components like the table control. We have a concept like cards, which are some assets, some kind of, let's say, micro UI elements you have on the screen providing some data and they can show up different things. And there is this, let's say, famous date picker controls with all these calendar types, which is also one of these examples where we showcase about our approach of globalization and stuff like that, that we have provided our control then for these enterprise applications. Then we have also a bit more things. So we have in UI5 this Fiori design which is our SAP design for this enterprise applications. And this Fiori design has some special concepts and patterns like we call it a shell bar. This is the header of a page where you see then the application name and you see then also control like a product switcher inside. And these parts, they are really built in from our perspective as web components. And we are increasing this step by step. 

DAN_SHAPPIR: So obviously like you know if you're looking at the sophisticated component like the what was the last one that you talked about with the bar at the top? 

PETER_MUESSIG: The shell bar. 

DAN_SHAPPIR: So if you're talking about something like the shell bar obviously HTML itself is not going to provide you something like that but you also mentioned some lower level components like a label and a button and these are and obviously there's a label tag in HTML and there's a button tag in HTML and so on so why would I want to use a web component button rather than the built-in HTML button? 

PETER_MUESSIG: What we did on our side is we added additional requirements from our side to this button. So the native button is not properly built in a way that for our accessibility requirements, it's sufficient. So we require a nested structure inside HTML structure and that to be properly recognized. And there are also other aspects like showing up an icon, what we have in our icon library, inside the button and to really provide these capabilities we decided to build our own UI5 button web component which also brings together these capabilities. 

DA: You mentioned accessibility, can you elaborate a little bit about how UI5 web components are like their relationship to accessibility, how accessible are they? 

PETER_MUESSIG: So when we build in UI5 applications, we need to build them in a way that they are accessible. So this is one of our products and that's what we have here. So it means that we have a dedicated setup like using JAWS and Chrome as a browser to make it possible that the applications are read properly for people who are not able to see the screen. In order to support that, we are enhancing that controls for having a proper ARIA support. So we are using the ARIA standard here more or less to make it possible. And we tested with the web components like this combination, Jaws and Chrome on Windows, but we are using also the Mac, VoiceOver and Safari for that. 

DAN_SHAPPIR: Can you also describe how data flows in and out of web components? You know anybody who's used one of the other frameworks, you know, that don't look at each component individually, but rather as like, you know, controls within that framework and the model of the framework, that the framework usually defines a data flow. So how does data flow work for web components or for your web components? 

PETER_MUESSIG: So I would say it works like also for other standard HTML elements. So when you think them in any of these major frameworks, like React, Angular, Vue. You are more or less importing the web components as a ES6 module. And for example, in React, you write in JSX the tag of the web component. And then you connect the attributes with that. So for example, if you have an input, you connect then the value attribute with that what you want to display there. Then in case of changes are happening, React is informed and it updates then on its own. So we more or less. Don't assume that we are managing this data binding. We are only taking care if an attribute is set on a web component that we put it in the Shadow DOM in the correct place, either via a slotting mechanism or via updating them and re-rendering them, the Shadow DOM. 

DAN_SHAPPIR: So you're saying that data moving in is basically just attributes and properties, like with regular HTML elements. And I assume that data moving out is via events. 

PETER_MUESSIG: Events, correctly. 

DAN_SHAPPIR: And suppose I have some sort of a cross-cutting concern, like localization, where I want to use the same language across all the components. I need to pass the language as an attribute to each and every one of the components? 

PETER_MUESSIG: No. So we have some global configuration for the web components. There is a tag you can put into the head, which defines the config. And this is a JSON configuration, more or less, where you specify the language. And with that language, you influence then, for example, let's say in the table control, you would then also see some hovering texts, which are coming from the component that is internationalized properly. So by default, maybe one thing to mention, our web components are running in English. So we, by default, put in English text here and if you require additional texts you can include the additional assets for them and then if you would switch to German it would then display the German text. 

DAN_SHAPPIR: And how does deployment work? How are the assets downloaded down? Do you usually package them up like let's say with Webpack or is every one of them distributed individually? How does it is how is it usually deployed? 

PETER_MUESSIG: If you build an application with that. By default, it's sufficient if you are just needing English, then to require the auto import the button or the table, whatever. And then it will use your favorite tool of your framework, be it Webpack, be it Rollup, be it Parcel or whatever, to package the bundle for you. If you need an additional language like the other assets, you can also import these assets as ES6 dependency and with that Webpack and Rollup will also take care to bundle them. 

DAN_SHAPPIR: Anybody else has any questions? I'm kind of hogging the conversation, not that I mind, I usually hog conversation. 

STEVE_EDWARDS: Yeah, we're used to it. 

DAN_SHAPPIR: Yeah, everybody is, except my wife. So anything else you would like to tell us about the UI5 components?

PETER_MUESSIG: Basically, these UEFI web components are built directly as an open source. So compared to our old UEFI framework, we really started as an open-source project here. Last year, exactly one year back on 11th February, the beta has arrived on the GitHub. So we have now today one year anniversary of the web components, which I'm really happy be finally released. We are missing still a few parts on the web components to finally release them. So we want to especially make use of the theming concepts. So in UI5 for the classic framework and for the web components, there is a tool like the theme designer available, which customers can use to create a custom visualization of the UI5 applications. And these integration parts, we are about to finalize now. So I hope soon that we are ready with the final release of the web components to make them something out there which can be really used officially. So things like contributing web components are open and stuff like that, that we are about to standardize the way how the UI5 web components are being written. So this should be also final the next weeks. And then I hope that more and more people also look into the way how we write the web components and also contribute to that or use it to build their own web components with that. That would be cool. 

DAN_SHAPPIR: So I shared a link to your project on GitHub. So how open source are you? I mean, like if I go to your project and I'm using one of the components and I run into problems, can I report issues? Can I create PRs? Yeah, create GitHub issues. 

PETER_MUESSIG: If there are issues with the web components, please create GitHub issues for that. The people and I are looking into that. We need your feedback on that. If you really have some ideas on how to improve the project, please also submit pull requests if you are on that. So we are open to that. We review them. And if it makes sense, we also really integrate them. 

DAN_SHAPPIR: Cool. I think we are more or less finished, unless anybody has anything to add before we move on into Picks. 

AJ_O’NEAL: Thank you for creating a multi-combo box.

PETER_MUESSIG: I will forward that to the colleague, definitely. He will be happy. 

DAN_SHAPPIR: Definitely components that are missing from the built-in, the standard HTML with regards to forms and stuff like that, which is kind of surprising after all these years, but still. 

AJ_O’NEAL: Well, it's so much that you got to do to get a combo box. 

PETER_MUESSIG: I know. When we really started with UI5 really 11 years back. This was really a dream of mine and of the other colleagues, that there is something standard available in the web, which you can use to build the components to enhance the vocabulary of the browser. And now with the web components being that far, and if you followed that, what happened over the last two years with the browsers evolving and all that, this is so great to see how this ecosystem evolved and how we can now make use of these standards to really create stuff from our side. But we maybe have some history in creating these controls and share them also with everyone. So I am really happy that we can do that and that SAP also supports that. 

 

Hey folks, this is Charles Maxwood and I just launched my book, The Max Coders Guide to Finding Your Dream Developer Job. It's up on Amazon. We self-published it. I would love your support. If you want to go check it out, you can find it there the Max Cotters guide to finding your dream developer job. Have a good one. Max out. 

 

DAN_SHAPPIR: And with this positive summary of the topic, I think we can move on into, into picks. Amy, I know that you're a bit rushed. Do you want to give your picks? 

AIMEE_KNIGHT: There I can go and hold on. I literally just had to move over my mic. And so I'm speaking through my laptop now instead of my mic, but I'm going to go with someone in the Nashville community, Johnson and Kramer. He has started, there's so many flat communities out there, but the stuff that they're doing is pretty cool. And so I figured I would share this as one to join because I also think it kind of falls in line with what we're talking about today. So it's called DivOps. So because this is kind of a little bit of like, we're talking about web components, but we're talking about in front of architecture and that kind of stuff. So this is going to be my pick. And that's it for me. 

DAN_SHAPPIR: Bye Amy. So Steve, do you have your picks?

STEVE_EDWARDS: Yeah, I have a pick. I'm going to go with a cartoon, a comic, actually. For years, I always had my trusty Dilbert desk calendar that I always liked to read. But over the past few years, I've really gotten into one called Pearls Before Swine. That's my annual desk calendar anymore. The guy's got a killer sense of humor. And I think the thing that, or the thing that is sort of unique about this comic is that the artist, Stephen Pastis, he puts himself into the comics quite a bit. In particular, it's usually when he spends a whole strip making it the host of a whole elaborate pun and at the end he shows his characters wanting to beat him over the head with it because it's so bad. He's got a really great sense of humor and pretty unique. So that's my pick for today. 

DAN_SHAPPIR: Great. AJ, how about you? 

AJ_O’NEAL: Yeah. So for Christmas, well, let me pull my mic back towards me here. So for Christmas, my youngest brother got me a vinyl clock that is a depiction of a, it's a Zelda theme with Link and Epona. And yeah, just kind of galloping across Hyrule field it looks like. And you can get them that are like Disney or Final Fantasy. You can get them on Amazon. You can get them on Etsy. I think Etsy is probably the big place where you get them. But it's just kind of a nice little decoration piece if you got a home office and want to make the piece, the place feel a little bit more. Homie, I'd recommend taking a look and see if you find something that suits your style because it's kind of a unique thing. And of course you will also need a stand for it or you'd pin it to the wall, but it looks much cooler on a stand. So I'm going to include a link to an acrylic stand as well that I use. 

STEVE_EDWARDS: Is it less than $1,000 for the stand or is that just Apple? 

AJ_O’NEAL: Oh yeah, you know what? Yeah, because it's like $20 for the vinyl, but the stand is $1,000.

STEVE_EDWARDS: Well, it's all important. It's important to make sure you're holding it up strongly enough. You know? 

AJ_O’NEAL: Yeah. It does look very nice though. Yeah. Those of us here that can actually see it. It's really nice. Oh, you know, I'll put a link to my YouTube channel as well so that if anybody wants to see it, they can see it behind me and my, my YouTube videos. I'm also doing kind of F programmer FAQ, mostly pre-programmer FAQ. So if anybody's got some questions like. You want to know about a topic and you want a five minute blurb on it, feel free to hit me up because I'm looking to do those, those style of videos and I'll link to my channel in which you can, you can see like the past six I've done where my, my clock is behind me. 

DAN_SHAPPIR: Just five minutes. You, you, you managed to like, hold yourself back to just talk for five minutes. 

AJ_O’NEAL: Dan, you should, you should take a look at my videos. They're, they're like the longest ones, eight minutes. It's amazing. I don't know how I did it. 

DAN_SHAPPIR: I actually did look at one. And I'll make sure to look at the others as well and then see if I can come up with questions to stump you. 

AJ_O’NEAL: Oh, sure. Yeah, go ahead. Stump me. Just don't ask me something like, like about web components. I don't know anything about that. Ask me, ask me something different than that. 

DAN_SHAPPIR: I'd ask you about social justice. Anyway. 

AJ_O’NEAL: Ooh, that'd be a great one. 

DAN_SHAPPIR: Anyway. Yeah. Anyway. So I actually originally did not prepare a pick. But since we're hosting a guest from Germany, it turns out that the name of the company that I work for, Wix, has an interesting meaning in German. And since we couldn't escape it, we actually decided to kind of make fun of about it. So I'm actually going to post a link to two videos that our marketing department made about how people react to the name of our company in Germany. It's really amusing. It's a, it might be the reactions might be a slightly, maybe not safe for work, but it's just talk. It's not pictures or anything. So it's, it's, I think they're fairly amusing. So I'm putting in the, the, the links to, to the videos and those are my picks. So Peter, how about you? Do you have any picks you would like to share with us?

PETER_MUESSIG: Yeah, it's hard. I thought about what, what I should share with you as a pick. So at the end, for me, it was a great experience to have, to have me here in this podcast, so I, I don't have any other pick, but I can just recommend to look into the German meaning of that. What you, what you found out. So this is, 

AJ_O’NEAL: don't do it. 

PETER_MUESSIG: Really for German speaker. It's really a funny meaning. 

DAN_SHAPPIR: Yeah. So your pick is JavaScript Jabber basically the podcast. 

PETER_MUESSIG: And I was really happy to be invited here. Yeah. Thanks for having me here. 

DAN_SHAPPIR: For sure. It was our pleasure to have you on. So everybody, I'm going to wrap up this episode. Thank you, everybody, for joining us. And make sure to join us next time. Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.