Micro-services have been very popular on the backend for a while now. But can this architecture be applied to the front-end as well? Should it be applied to the front-end? Michael Geers, who literally wrote the book on micro-fronts ends, explains what they are and why they can be a powerful architectural pattern especially when implementing large-scale projects. He also describes how Web Components can be used to enable this type of application architecture.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Michael Geers.

Sponsored By:

DAN_SHAPPIR: Hi everybody and welcome to another episode of JavaScript Jabber, a post-election episode of JavaScript Jabber. On our show today, we have Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. Myself, Dan Shapir, coming to you from Tel Aviv. And our guest is Michael Gills. Hi, Michael. 

MICHAEL_GEERS: Hi, thanks for having me. 

DAN_SHAPPIR: You're welcome. I understand that you're coming to us from Germany, correct? 

MICHAEL_GEERS: Yes, I'm coming from cold northern Germany. 

DAN_SHAPPIR: You should come over to Israel. We have excellent weather over here. It's something like the eighties and sunny right now. Well, actually it's night already, but today was sunny so it's really pleasant weather. I understand that you're here today to speak with us about micro frontends, but before we start on that, maybe you can give us a little bit of a background about yourself. 

MICHAEL_GEERS: Yes, I'm Michael. I'm a fraud-ed developer and I'm doing fraud-ed work for, I guess, over 20 years now. Worked in several projects, smaller ones, larger ones. And in the last years, I primarily worked in projects that had multiple teams. Also in the front end that worked on the same front end. And this is where the topic micro front ends got into it. This is where I got in the topic of micro front ends and how to architect your front end in a way that multiple teams are able to work on it at the same time.

 

This episode is brought to you by Dexecure, a company that helps us developers optimize images, JS, HTML, fonts, videos on your own website automatically. With Dexecure, you no longer need to constantly chase new compression techniques. Let Dexecure do the work and you can focus on what you love doing, building products and features. By integrating Dexecure in 10 minutes, you'll get a lower CDN bill, increased website traffic, and faster website than your competitors. Visit dexecure.com slash JavaScript Java free trial, offering 20 GB CDN bandwidth and 110,000 optimization requests free every month. 

 

DAN_SHAPPIR: So you kind of introduced the topic that we are going to be talking about today, which is indeed micro frontends. I know that many people are familiar with microservices as a backend architecture. In fact, it's probably become the most favorite or common. I'm not sure if it's the most common, but it's certainly the most advocated, let's call it, back in architecture these days. But micro frontends, is that something similar? Is that something totally different? What is it? 

MICHAEL_GEERS: It depends on how you look at it. So I like to look at it as microservices, which also include a UI, also include a frontend. So extending the microservices you would normally build, but letting them include their own frontend. But other people also use micro-frontends in a way that's more similar to just doing smaller services, smaller components that assemble in the browser, so doing a more microservices-like approach in the browser? 

DAN_SHAPPIR: Well, I guess that componentization in the browser is kind of a done deal if you're doing any form of web application, let's say. I mean, if you're doing just a document website, then it's probably an overkill. But if your front-end has actual moving parts then undoubtedly you'd be using components. And indeed all the major frontend frameworks, React, Vue, Angular, et cetera, advocate some component model or another. But I guess this is something different, otherwise it wouldn't have a different name. So how are microfontends different from the components that are available in most frameworks? 

MICHAEL_GEERS: Yes, indeed. So the main difference is that a micro frontend is, you can look at the micro frontend like an isolated part of the frontend, which is built around a specific feature or a specific need. It's not a component in the React component way. It's more of a feature. Maybe a product detail page in an online shop can be one micro frontend. And maybe it includes another micro frontend from another team like a recommendation strip which includes not only the carousel image product component, but the recommendation script can be built by a separate team, which also implements the logic and everything that you need to expose recommendations, for example. So you can look at them at self-contained mini applications that are assembled in the browser. 

DAN_SHAPPIR: So basically you're saying that if I can kind of take the browser window, and draw lines across it that break it up not just into UI elements, but rather into actual self-contained, you'd call them mini-applications, those would be candidates for being micro-fronted. 

MICHAEL_GEERS: Yes, and the division on how coarse or how fine you want to draw these lines, at least in our how you want the teams and the people working on it. So we have projects where we build an e-commerce system with two teams, for example, and then we have very big microphone and chunks that play together. For example, maybe you have the homepage, the listing page, the product detail page, all be developed by one team, but then you have the checkout page and all the subsequent pages of your e-commerce built by another team. But we also have projects where we have five or six teams and then the individual micro-frontends are much smaller. You have a team that only does recommendations stuff, for example, and all pages that contain recommendations get a fragment or a micro-frontend that can include from this team on their page, on the basket page, for example. 

DAN_SHAPPIR: Well, if the division is a division between pages, then I guess that from a technological perspective, it's fairly straightforward. I mean, I own this page, you own that page. If we can even make this application in multi-page application instead of a single page application, then well, more or less job done. I can simply work on my page and you can work on your page and I don't really care about what you do. But I guess this is such a trivus scenario that it hardly is worth discussing or maybe even writing a book about which I know that you did. So I guess that you're looking at the more challenging scenarios where multiple teams have to work together on certain components that reside simultaneously within the same page, correct? 

MICHAEL_GEERS: Yes. So the thing you described, so having two teams which own separate set of pages is I would also call this a microphone and setup, but yeah, it gets interesting or technically challenging when you want to deliver a screen which shows content for more than one team. So, a classical example is the navigation, for example. If you have multiple teams, you don't want every team to recreate the navigation if the navigation is a more complex item. So, maybe you have one team that owns the navigation and maybe the homepage, for example. And the other teams don't have to care about building a navigation. They just include, we call it a fragment, so an includable microphone at page and how this inclusion is done. There are different ways depending on your text stack, but this is the basic idea. 

DAN_SHAPPIR: So getting into the text stack, I mean, again, if we're all doing it using the same framework, for example, let's say we're all, all the teams decided to standardize on React, then it's essentially just building React components and using the React model for communicating between the various components and maybe also throwing in some state management solution. And again, my understanding is that you're talking about something which is different than that. 

MICHAEL_GEERS: Yes, so I think the key word here is self-contained. So one goal of doing the micro-frontend approach is that one thing is that teams should be able to develop a micro-frontend on its own, but should also be able to deploy, change it, and make adjustments to the micro frontend without having to coordinate with other teams. So if you are talking about plain React components, then you would need some kind of build process, for example. So having the team making a change to the header navigation and then having this header navigation being pushed to a central shared repository, which is then deployed as a frontend and the way we use this is that the team is able to deploy the micro-frontend on its own. So the combination of the micro-frontends happens in the browser at runtime. So if one team wants to ship a new feature, wants to change a logo, for example, it can do it on its own and ship it. And another technical advantage is that you don't have the drawbacks, a huge monolith, gains over time. So having code base, which is hard to upgrade, for example, with this microphone and scenario where all microphone ends are that separate applications, it's easy to do a migration from one version to another react version because each team is able to do the migration on its own for their own microphone and enroll them out step by step until everything is upgraded. 

DAN_SHAPPIR: Wait a minute. That means that every team has its own, if they're all using React, they're all using separate instances of React because what you're saying is that each one of them can upgrade their own React separately. Is that what you mean? That they bundle their own instance of React into their deliverable package? 

MICHAEL_GEERS: Yes, in the easiest form, this is right. So it would also be possible for one team to opt for a completely different solution, for example, if one team decided to not use React, go for vanilla JS or whatever, they could implement another stack as long as they are compatible with the integration pattern which has to be defined upfront. 

STEVE_EDWARDS: So how does that work then when you have different, completely different frameworks? Is it just a matter of, they go through individual build processes and then the final artifacts or what is combined on the page? 

MICHAEL_GEERS: And we usually go with a runtime approach. So if let's say we are building fully client side. The mechanism we use for doing the integration is wrapping the applications, the micro-fundance, in custom elements, so basically web components. So you have one team which owns the product page, for example, and they include the web component which is implemented, provided by the team who does the homepage, for example. And the team who does the homepage and the navigation, they provide documentation on how this custom element looks like, what parameters it takes, how it's named what it can do and the other team just has to include the HTML tag for this custom element at the right place. This would be a solution for a fully client-side rendered application. If you do a server-side rendered application, this would look different because then custom elements can't be used. And if you even want to build a universal application which renders on the server and on the client, then you also need another solution. 

DAN_SHAPPIR: Yeah, but before we go over to SSR, server-side rendering. I still want to talk about what you just described. So it does raise a couple of questions and even concerns on my part. Let's say I have a complicated web app and I have four teams. Actually before we even go into that, it's interesting for me that whenever I discuss architecture with different companies, organizations, or even teams, groups within companies, it seems that...You know, we all like to talk about architectures, but usually it's HR that, to an extent, drives architecture because it's say, okay, we have 18 people, let's organize them into three teams of six. Okay, then our architecture is going to be comprised of three components or micro-frontends or whatever. So it seems like that it's the organizational chart that's driving the architecture of the applications rather than the other way around in many cases. I don't know if that's been your experience as well, but it seems to me that that's kind of a recurring thing within our industry. But going back to what you described, so one concern that I have is simply about bundle size. I mean, if I'm going to be bundling three, let's say versions of React, and maybe three versions of Redux, and maybe some other things. It means that all this overhead is downloaded three times. Isn't that a concern? 

MICHAEL_GEERS: Yes, this definitely is. So there are different ways of dealing with it. So we have some projects where we implemented this but opted for not using quite large runtime library framework like React or Vue.js, but went with a much smaller framework. So we did a project with HyperApp, for example, which is one kilobyte in size, or Preact, for example. And these are so small that compared to the JavaScript and logic you would write on your own for your own features, the vendor code doesn't make a huge effect. So there's no need to do further optimization. But we also did other projects where we wanted to go for to provide the React version or multiple React versions in a central place. So having your own CDN-like public instance that the teams can refer to, they can link to. And if all three teams would use the same React version, you could, the browser only had to download it and pause it one time. If one team decided to upgrade, they would change their reference to the newer version. So two teams are on the old version, one team is on the new version when all teams upgraded, all teams are again back to one version. 

DAN_SHAPPIR: I understand. So that was one question that I had. Another question that I had is around the communication on the client side between the micro frontends. I mean, if they are totally self-contained, then great. But realistically, there's probably going to be some sort of intercommunication between them. Now, one advantage of using a framework is that most frameworks also provide you with mechanisms or with definitions of how or best practices, let's say, of how to best communicate between various components or elements on the page. But you probably need to do something else if you're using a micro front-end. What do you actually recommend using in such a case? 

MICHAEL_GEERS: Yeah. So the simplest form of if you want to call it communication is just to do it via the URL, for example. So you have the product list and the team that does the product list knows the URL pattern of the product detail page. And they link to the product detail page with the correct ID. And then the team of the product detail page knows to show which product. This is very basic and just using links as a communication. If you need communication inside OneView, the example I like to give is you have an e-commerce shop and you have an add to cart button on the product detail page. When this button is clicked, you want the basket to be updated in the background, maybe, but you also want the number in the navigation to increment by one, for example, in the mini basket. Let's assume the product page is built by one team. Add to Cart functionality and the basket itself is built by another team. And these can now communicate via the communication method we like to use is just going with the browser and using custom events in the browser. So the button could emit an event, which is called item is added to the basket. And the mini cart in the navigation can listen to this event and update itself accordingly. So this is very lightweight more notification style communication using native browser events, which is easy to use, even if you're building a React application or any other framework, because they all support dealing with native browser events. 

DAN_SHAPPIR: Okay, so you're saying something like this. If you want to notify other elements or microphone tends on a page, you kind of use PubSub model, which is built on top of custom browser events that let's say you just fire on the window object or something like that, and anybody can listen to them and do whatever they want to do with it. And then you can pass also data around as a payload if you need to do that. 

MICHAEL_GEERS: Yes. So regarding passing data, we try to avoid passing larger data structures. We try to avoid coupling these microphones too much to each other. So we try to keep the events as simple as possible. And the individual micro-frontends are responsible for data fetching when they talk to their own backend, for example. So we don't have a shared pool. We don't have a shared Redux instance or a mega global variable, which all teams can write through and other teams can read out from there. So like having multiple microservices in the backend, which all store the data in the same database. You wouldn't do this, for example, because then you you lose the autonomy of these microservices. And same is applicable to the micro frontends. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Raygun is awesome at this. They just added the performance monitoring, which is really slick and it works like a breeze. I just, I love it. I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grephing through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out Raygun. They are definitely gonna help you out. There are thousands of customer-centric, customer-focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14-day free trial. So you can go check that out at javascriptjabber.com slash raygun.

 

DAN_SHAPPIR: Okay, so that actually kind of goes to another question that I had, which was about state management and shared states and single source of truth. So effectively, if I understand what you're saying, you're saying that in a microservices architecture, you don't want single centralized state management type solution on the front end. Instead, your passing, let's call it IDs and stuff like that, between the or change notifications between the various components, which they use to sync with their own microservice on the backend. So effectively the backend is the single source of truth. 

MICHAEL_GEERS: Yes. And we also implement a model where you have a vertical slice. So having a front end, which also has its own dedicated backend which also has its own database. So we have cross-functional teams that have front-end developers, backend developers, and also capability to do their own data management and persistence. Doesn't the fact that you're kind of dependent on the backend to provide you with data. So, for example, if I understand correctly, if I'm adding, and if I'm the team that does the add to cart button,but some other team is actually showing the checkout list, then when changes are made in one, they have to like pass a notification, go back to your backend and update. Doesn't this kind of potentially create a more sluggish type of an interface or something like that? 

MICHAEL_GEERS: You mean because you...You modify the data and then you have to wait for the response from the backend before you can show the update. 

DAN_SHAPPIR: Yes. 

MICHAEL_GEERS: For our applications, this was never the issue. So that the having an extra API call in response to a user action is something where we had the feeling that we had had extra stuff and would let the user wait for more so you can of course use techniques like optimistic rendering or so on where you would add something to the basket, you increment the count immediately and then sync with the backend in parallel, for example. 

DAN_SHAPPIR: But that, yeah, you could definitely do that. But that would probably also mean that you have to pass a more complicated data structure on the event in order to know what to update optimistically to. 

MICHAEL_GEERS: Yeah, yeah, it's definitely you have to think about what you need to communicate and what you have want to fetch from your own backend.

DAN_SHAPPIR: You mentioned using web components as the mechanism to implement the separation of concerns, which I like a lot because it does let you work like a Lego and the whole concept of Shadow DOM reduces the risk of conflicts that say with CSS and other global stuff. But do you also use the HTML, the web components parameters in order to pass in information? Do you actually? In that type of an approach, you actually put web components inside web components? Or is this something that you try to kind of avoid? 

MICHAEL_GEERS: In general, we try to avoid having deep nesting. So one classical page where we do nesting is the header, for example. In the only example I said, okay, one team does the header. But when you look at a header in an e-commerce system, there's a lot of things going on there. So you have the mini basket, which might be built by another team. You have the lock-in status of the customer, which also might be made and built by another team. So we allow nesting, but we keep a close eye on how deep we want to nest stuff because this can lead to dependency trees and rendering and load time issues. 

DAN_SHAPPIR: Understood. And now going back to something that you mentioned before. We extolled the benefits of web components, but you mentioned that web components are not actually compatible with server-side rendering. Can you elaborate on that? 

MICHAEL_GEERS: Yes. As of right now, it's not really possible to do declarative shadow DOMs. So server-side generates a shadow DOM, so the internals of a rendered web component, ship it to the browser, and then have the browser pick up from there. 

DAN_SHAPPIR: Michael, I'm going to interrupt you for a minute because we've been throwing around this concept of web components and custom elements. And I don't know, maybe some of our listeners may not be familiar with this technology. So I do think there's actually a benefit, if slightly late, to give a brief explanation, at least of what these actually are. 

MICHAEL_GEERS: Yes, I can do that. So that component is the umbrella term of having a browser native component system, which everyone can use. And it's made up of three parts. So you have the web component as the umbrella term, which does not, you have the web component as the umbrella term. And one part is having a custom element. So custom element is basically giving you as a developer, the ability to make up your own HTML element. So you can make up an element which is called my team dash header, for example. And then you can provide JavaScript class, which is called whenever the browser comes across the element which is called your team name slash dash header, for example. And every time the browser finds such an element, it calls your JavaScript and you have a lifecycle message like created and connected callback. And you get notified when the element was found, when it's removed from the DOM, and when someone edited attributes on this element, for example. This is custom elements. And then the second part is Shadow DOM. And Shadow DOM defines a virtual boundary where styles are not able to leak out, for example. So you have...

 

gives you as the developer the ability to do encapsulation inside of your custom element, inside of your web component. You can think of it as having somewhat integrated version of an iframe, but in your browser itself. And these are the two most important concepts of to understand web components, I guess. 

DAN_SHAPPIR: Yeah, if I could add to that, I would say that most frameworks that are used today provide some sort of a mechanism or another to define your own elements. But these elements actually don't make it all the way to the HTML. So if you're using React and you're using, and you're creating React components and in the JSX, you give them whatever name that you want. And it seems like you've created your own HTML tag. When you look at the actual HTML that gets rendered by React, there's no trace of those custom tags. React has replaced all of them with standard HTML tags. With web components and custom elements, you are in actuality extending the browser and adding tags, new types of tags to the HTML. So it's an API provided by the browser as part of the DOM that as you explained makes it possible to create these custom HTML tags using JavaScript based API. So that's one thing. And the other thing which you mentioned is the Shadow DOM. The only thing I would kind of add to that is that in a way, the browsers kind of let you use a mechanism that existed before for actual HTML elements or standard tags in the browser. So if you would have looked at some of the more sophisticated tags. Like for example, I don't know, let's say a date picker. The date picker internally might actually be implemented using simpler, basic HTML elements, but that's kind of internal to how the browser works. You don't see those elements. They're segregated, they're separate. You can't inspect that part of the DOM. And Shadow DOM literally lets you do the same sort of a thing. So to the outside there's just this new tag inside that new tag is implemented using whatever DOM elements it needs. And that DOM is separate. And like you said, a CSS doesn't leak in or out, and it's totally distinct in that way. Like you exactly gave an example, similar to how iframes create a separation between documents. I think that was a really good comparison. So getting back to what we were talking about before. You mentioned that web components don't work well with server-side rendering. So, and I kind of cut you off when you were just starting this explanation. 

MICHAEL_GEERS: Yes. So up until now, there's no really good way to produce server-side markup for a web component and then shipping the web components to the with pre-rendered content. So there are ways to do this. So you can just come up with your own way to pre-fill your custom element with the content you generated on the server using React SSR or whatever you did. But there's no standard way to define Shadow DOM in a way that also creates and maintains this boundary we just talked about. And a few weeks ago, developer of Preact, Jason Miller, posted a tweet where he said that Chrome now has a version of doing server-side rendering together with custom elements. So having a declarative Shadow DOM approach coming to Chrome in the next release. So I've posted, we'll post a link to this tweet in the show notes and then you can look at how you can define Shadow DOM inside of custom element. But it's currently behind an experimental flag. So it's nothing we can use in the coming month or weeks. 

DAN_SHAPPIR: This sounds really, really interesting. You made me really curious. I look into it because there are whole issues there about how to do hydration, whether you need to effectively re-render the entire content of the web component, or you can somehow reuse the DOM structure that was delivered from the server. It will be interesting to see. But that's a really interesting development. Thank you for sharing that. So if you don't use web components in those scenarios currently that require server-side rendering, what do you do instead? 

MICHAEL_GEERS: So, yeah, we do. So it depends on the application you're building. So we have some applications which are mainly server-side rendered and they don't have a lot going on on the server. So we use assembly technique, which assembles the markup from the different micro-frontends completely on the server and the end user just receives the finished markup from all of the micro-frontends within it. But when we have applications, for example, we have a project where we did two universal React applications, and we needed both integration mechanisms. So the first page load should deliver a completely rendered server-side rendered page because it had to load fast. And subsequent requests and calls should be handled completely client-side and there we mixed two integration techniques. So we did the custom elements for doing the client-side notification and talking to each other and changing properties, for example. And we pre-filled these custom elements with server rendered content, but not use the shadow DOM feature, for example. So we all did it in the light DOM. So in the DOM, which doesn't give you the isolation, the iframe-like isolation, then we had to work with having namespaces and being careful that you don't specify CSS, which can harmfully overwrite other parts of the page. 

DAN_SHAPPIR: Understood. One more thing that I wanted to ask. So you kind of described this whole micro front-end architecture as something that is best suited, I guess, right? Maybe it's my interpretation. When there's a relatively large group that's comprised of multiple teams working on the same web application. Can you give some sort of a cutoff point? I mean, at what complexity of project complexity should I start looking or considering micro front-end as the go-to architecture for my project? 

MICHAEL_GEERS: Yeah, it's definitely a model which plays its strings when there are many people involved. So it solves organizational issues more than technical issues. I would say it creates technical issues because this thing we talked about before, so having to think about how to upgrade different micro-frontends in a way that not three instances of React are loaded at the same time. These are problems you don't have when you don't implement micro-frontends. But we go with the micro-frontend approach in this project where we have a lot of people that need to work together and where it's more efficient to have smaller teams which can work on their isolated part of the project and ship and release independently. So if I had to say a number, I would say, okay, when you have less than 10 people, I think implementing a microphone as architecture might be overkill for you. And when you are a developer, which works on its own, so it's no option. I wouldn't do it for my personal projects. For example, it's a concept which helps have scaling projects in a way that makes the teams be able to move fast and have their own slice of the system and responsible end to end. 

DAN_SHAPPIR: I believe, you know, we were talking about this topic and before we started, you mentioned that you've actually written a book about this whole micro-frontends thing. Can you tell us about it? 

MICHAEL_GEERS: Yes, I can. So, over the last year, I've written a book which is called Microphone in Action and it was published in September by Manning Publications. So I think we provide a link to this book in the show notes and in this book, I introduce the concept and the benefits and why you want to use or implement Microphone Lens and when you wouldn't want to use Microphone Lens. But it also has a lot of practical parts where I go through different types of applications, so server-rendered, client-rendered, universally rendered, and provide examples and patterns how you can solve a specific issue, for example. If you're interested, you should definitely check out the book. If you're interested in more of the code side, you can also go to the Tractor, the-tractor.store, which is a page I created while I have written this book. And this page shows all of the example code in an interactive way. So you can click through the mini applications in your browser, but you can also go jump to the code on GitHub and look at how it is done, how you do the loading of multiple React versions without stepping on each other's toes, for example.

 

DAN_SHAPPIR: Oh, that's really great. I really look up to people who actually set aside the time and the effort required to actually write a book about a topic that they're really interested in. It's really quite an undertaking, I guess, I assume. 

MICHAEL_GEERS: Yeah, definitely is. So I'm not a big reader. So I'm more of an audio podcast guy. So I'm huge listener of shows like JavaScript, Java and other ones. And when I got the opportunity to write the book, I was tempted to say no, writing is not my style. And to say no, we don't do it. Yeah, but I took the opportunity and in retrospect, I'm very happy that I said a lot of that I said in retrospect, I'm very happy that I did it. So I pulled through writing all of these chapters. Yeah, and was very interesting experience. So you learn a lot when you have to write a book about many things. 

DAN_SHAPPIR: Yeah, I've often said that the best way to actually learn a topic and to truly understand that topic is to try to teach it or to explain it to somebody else. I've not like I said, I've yet to write a book, but I've given talks and understand that you have as well. And often, and often the I learned the most about the topic when I'm preparing to give a talk about the subject or write a blog post about the subject. So I can only imagine that if you actually have to write a whole book about the subject, you definitely become an expert in that area. And you also mentioned, I think that you have coupon codes for our listeners in case they are looking to purchase that book or other books by Manning and can get it at a certain discount, I guess.

MICHAEL_GEERS: Yes. So we have a 40% discount code for all books at the Manning Store, including Microfontents in Action. And I guess we put the promo code in the show notes so you can, yeah, pick it up from there. 

DAN_SHAPPIR: Excellent. Anything else that you would like to say about Microfontents that we've not mentioned so far? 

MICHAEL_GEERS: No, I think I don't. 

DAN_SHAPPIR: Okay. Well, in that case, I guess we can push us towards Picks. 

 

Hey folks. I don't know if you've noticed, but I've been working a lot on figuring out how to help people become the most valuable developers on their teams, or becoming the top 5% of developers in the field. If you're looking to level up, figure out how to contribute more, get the career you want, get the career that you want that will support the lifestyle you want, then you should check out the Most Valuable Dev Summit. I've invited some of my friends across the community, people that you've heard of, people that have worked on systems that you use on a daily basis people who have invented new ways of doing things over the years in programming, and I've asked them one question, and that question is, how do you become a top 5% developer? How do you become one in 20 of the best developers out there? And so we're gonna go ahead and have that conversation with them in interviews on the Most Valuable Dev Summit, and you can find that at summit.mostvaluable.dev.

 

DAN_SHAPPIR: as well I scrambled together a pick of my own. 

STEVE_EDWARDS: Actually, I come prepared with one today. So going down the movie route, look, as I have been here recently, going to pick one that's a little more recent than some of the Humphrey Bogart ones I've done in the past and watch this one on Saturday. And it's I think 2017. It's The Greatest Showman about P.T. Barnum with Hugh Jackman and Zach Efron and Zendaya and some other people really, really fantastic music. I know that the soundtrack is pretty well known. It's a pretty good song. The movie was fairly good too. It's about two hours long, but I really just enjoyed the music and how it was integrated into the movie. It's an original musical as compared to a stage musical that was adapted for the screen. But really enjoyable watching and listening to the soundtrack. 

DAN_SHAPPIR: Excellent. Well, my pick, this show is recorded this episode is recorded after the US elections. And obviously, I'm not going to get into the whole political thing about, you know, who won, who lost, who should have won, who should have lost. I obviously have my opinions, but the fact that I'm not US citizen myself, then I'm just not going to talk about that. I will say this though, and that's the fact that you guys need to remember that you will need to keep on living together in the same country after these elections are over. So I understand that emotions are really raw right now, especially since this thing is not quite over yet. But just remember, tomorrow is another day and you're going to be seeing your neighbors' faces even if they voted for the other side. So just take that into account. Certainly, I imagine it can even be inside families. So just a reminder that part of living in a democracy, like the US is or like Israel is and like Germany is, is the fact that different people vote for different parties and you still have to kind of live together within the same society afterwards. So that's my pick for today. Michael, what about you? Do you have any picks or pick for us? 

MICHAEL_GEERS: Yeah, I think I have two things. So, or maybe it's the same. I want to pick learning software and having well crafted interactive learning solutions in general. So we are currently at our company teaching a CSS class for backend people. So making backend developers more comfortable with doing stuff in the front end. And we do classical teaching and exercises and so on. But we also have games from time to time. So there are great games like Flexbox, Froggy or GridGuard. And I will post some links in the show notes, which are very fun ways to learn about very dry concepts like how to write a CSS selector or how Flexbox works and why these properties are named in a strange way. 

STEVE_EDWARDS: Well, that's funny. I have Flexbox Froggy up right now because I heard somebody talking about it on another podcast. So yeah. 

MICHAEL_GEERS: Perfect. And the other one is also a training and interactive learning thing. And it's a project by, developed by Google, which is some experiment side project from Google, which is Morse code typing trainer. And my kids love this, this application. So it's a website where you can learn to, to, yeah, convert. You can learn to Morse. So you have a small dot and a large, a large dot, and you can make a short noise and a long noise. And this Cliping trainer shows you images. So they have an image of an arrow, for example, and they put the dots and the lines over the images and they have an image for each dot combination. And this makes the Morse codes very easy to remember and how the app is built and how the website is built is very playful. So it's, yeah, my six-year-old, this is one of his favorite things he can do is learning to Morse. And you see that over time he really gets better at, yeah with learning to moss. 

DAN_SHAPPIR: Well, excellent life skill. Serve him well in his life. Before we finish, Michael, if people want to reach out to you, get in touch with you, what would be the best way to go about it? 

MICHAEL_GEERS: Yeah, you can find me on Twitter under Nal Tartis. And there's also Microfondance in Action, which is a site I built where I explain Microfondance. Yeah, and I think from there you can find other stuff I made. 

DAN_SHAPPIR: Excellent. Well, in that case, I think that's a wrap for our show for today. So thank you all for listening and thank you, Michael, for joining us. And see you all. See you guys or talk to you guys next time. Bye. 

STEVE_EDWARDS: Adios. 

MICHAEL_GEERS: Thanks for having me. 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.