Speaker 1: Welcome to React Roundup, the podcast where we keep you
Speaker 1: updated on all things React related. This show is brought
Speaker 1: to you by Void and top End Devs. Unvoid provides
Speaker 1: high quality design and software development services on a client
Speaker 1: friendly business model. Unlike all other software agencies, Unvoid allows
Speaker 1: clients to only pay after the work is delivered and approved.
Speaker 1: Visit unvoid dot com to learn more and reach out.
Speaker 1: If you know a company that needs more professionals to
Speaker 1: help with design and software development, that's u n void
Speaker 1: dot com and top end Davs helps you stay up
Speaker 1: to date with cutting edge technologies like JavaScript, Ruby, Elixir,
Speaker 1: and AI. Visit topandevs dot com to join their AIDV
Speaker 1: boot camp, weekly community meetups and access expert tutorials. I'm
Speaker 1: Lucas Paganini, founder of Onvoid and host of this podcast.
Speaker 1: Thank you for tuning in. Let's jump into the episode.
Speaker 2: Hey everyone, welcome to another episode of React Round Up.
Speaker 2: I am your host to Dave Paige nee Gringhouse, and
Speaker 2: I am joined by our panel as TJ Vantol everybody,
Speaker 2: and our special guest today is Florian Raffle.
Speaker 3: Welcome.
Speaker 2: Hi, So Florian, tell our audience a little bit about yourself.
Speaker 3: And why you're famous.
Speaker 4: Oh, I would say I'm famous, but yeah, thanks for
Speaker 4: fine words. Yeah, my name is John. I'm a solution
Speaker 4: architect from Unique, Germany. If you know me, you may
Speaker 4: know me from my work in the web community, specially typescript, React,
Speaker 4: microphone and these days especially you may also maybe know
Speaker 4: me because of my work in the dotnet t shop community.
Speaker 4: I am a Microsoft MVP since and more than ten
Speaker 4: years now now dependsen say what they do with accounting.
Speaker 4: Then let's say of ceremony there it was always a
Speaker 4: full year and it's now i'd say in the mid
Speaker 4: of the years, so they always make it let's say
Speaker 4: four years. I don't know, but anyway, it should be
Speaker 4: ten years now either way. So this is also where
Speaker 4: I spend, of course, most of my time. I write articles,
Speaker 4: I write blog posts. I wrote a book recently, so
Speaker 4: it was a big achievement for me. So a lot
Speaker 4: of work shouldn't be underestimated. And I'm very happy that
Speaker 4: finally got released. I guess the 'll talk a little
Speaker 4: bit about that too, And yeah, decides that I'm contributing
Speaker 4: to open source and on my professional work, I always
Speaker 4: do well architecture review a lot of implementation work and
Speaker 4: working together which is a lot of different themes and
Speaker 4: a lot of different clients, and always having fun, just
Speaker 4: staying on top of the say, technology advancements. And it's
Speaker 4: quite some interesting time that you're living in. So let's
Speaker 4: me in a natcha so to speak.
Speaker 2: Wow, that's quite a list of items. I'm not sure
Speaker 2: when you find the time to sleep with everything that
Speaker 2: sounds like you've got going on.
Speaker 4: Yeah, my rings are Yeah. The good thing is, I
Speaker 4: mean I have two little daughters, so sleep is pretty
Speaker 4: much off the table anyway. So and then yeah, I
Speaker 4: mean it just always goes yeah, one step further, one
Speaker 4: step further. And since it's all so much fun, let's say,
Speaker 4: writing all these these great react projects, working with microphone
Speaker 4: and always of course being interested and everything that's happening
Speaker 4: out there, it's just well all too exciting to sleep,
Speaker 4: I would say. Yeah. Sometimes. The rest, of course, let's
Speaker 4: called vacation is the vacation with kids' date, I guess,
Speaker 4: but at least so they're growing older. The vacation days
Speaker 4: are also, my experience, a little bit expanding, right, So
Speaker 4: starting with zero, now we are maybe a week of
Speaker 4: vacation per year, accumulated.
Speaker 3: I love the enthusiasm.
Speaker 2: So one article that really caught our eye was one
Speaker 2: that you wrote for log Rocket, which we will link
Speaker 2: to in the show notes, and it's called react as
Speaker 2: a black box. And why does this matter? Do you
Speaker 2: think that you could give our audience, if they haven't
Speaker 2: read it, a little bit of insight into it and
Speaker 2: your opinion on that.
Speaker 4: Sure? Yeah, I mean, please read the article everyone, but
Speaker 4: let's say summarize it in two or three sentences. If
Speaker 4: you're using reacts, you're mostly well not using it very
Speaker 4: much directly. Of course, you're writing let's say react components
Speaker 4: and all that, which are pretty much only functions these days.
Speaker 4: Most of the things that does for you, it does
Speaker 4: under the hooks, which means you don't explicitly interact with
Speaker 4: its API. And it's really just a black box. So
Speaker 4: you just throw something in and you expect it to work.
Speaker 4: Your components being efficient, re rendering just happening very fast.
Speaker 4: We have a lot of stuff going on, but you
Speaker 4: just expected to work, right, and there, of course pros
Speaker 4: and constant is approach there. I mean, there's a reason
Speaker 4: why react is successful, and one of that reasons is
Speaker 4: certainly that the black box. You don't need to care
Speaker 4: about what makes the decisions or what really goes on
Speaker 4: behind the curtain. But on the other hand, of course,
Speaker 4: sometimes you're wondering, why is my component slow? Why is
Speaker 4: it not really behaving the way I think it is?
Speaker 4: And this is where the black box really comes from
Speaker 4: the other side, right in terts you because you can't
Speaker 4: really see what's going on and debugging this can be
Speaker 4: I mean, I don't know how much time I spent
Speaker 4: debugging real components that don't behave the way I imagine
Speaker 4: they should behave. And personally, of course, I mean you
Speaker 4: can already see that I have both sides. In the years,
Speaker 4: I'm a little bit torn apart. I think, I mean,
Speaker 4: the really great achievement and what makes functional programming also
Speaker 4: created that the run time is doing a lot of
Speaker 4: stuff for you, and you get a lot of guarantees
Speaker 4: and on your let's say programer side that you don't
Speaker 4: need to take care of, right, you just say, okay,
Speaker 4: I always have my state here. I can be that
Speaker 4: no one else is filing the step because it's immutable
Speaker 4: for instance, and all that, and you just work with
Speaker 4: it and you say, well, all these that say what
Speaker 4: makes the decisions is under the hood and it just works.
Speaker 4: And I think there will always be this straight off
Speaker 4: so it shouldn't be too problematic in react case. And
Speaker 4: my personal point of view is, well, you can't have
Speaker 4: the let's say perfect thing here that just does everything
Speaker 4: for you and you will never complain about it. There
Speaker 4: will always be these educses and you will then of
Speaker 4: course pay the price in some debugging let's say, sessions
Speaker 4: that you would have wanted to avoid. But yeah, that's
Speaker 4: a surprice we pay. Doesn't mean it's perfect, doesn't mean
Speaker 4: we shouldn't try to improve it, and doesn't mean we
Speaker 4: can't criticize it. It just means that I think it's
Speaker 4: a good model after all, but we should be aware
Speaker 4: of it. And that's that's my personal point of view.
Speaker 5: Yeah, it's it's interesting in a way.
Speaker 6: This is like the classical software paradigm, like how much
Speaker 6: you trust a black box versus how much you control
Speaker 6: on your own. I feel like it's somewhat at least
Speaker 6: somewhat new to the front end world, at least because
Speaker 6: back in the day, I feel like the jQuery days
Speaker 6: like Jquerry. I mean, obviously it's a bit of a
Speaker 6: black box, it's got APIs that abstract things for you,
Speaker 6: but you could sort of fundamentally know what JQuery's doing
Speaker 6: under the hood, Like the code get a little bit gnarly,
Speaker 6: but you know they're like abstracting browser APIs for you.
Speaker 6: They're doing some basic things. And if jQuery didn't do
Speaker 6: exactly what you wanted, it's like, okay, you at least
Speaker 6: had a rough idea of what was wrong or how
Speaker 6: to work around it. Whereas I feel like nowadays with
Speaker 6: stuff like React, and this isn't really specific to React,
Speaker 6: because you could make the same argument for other frameworks
Speaker 6: as well, but there really is a lot more magic
Speaker 6: going on than there used to be. So if something
Speaker 6: went wrong in Jquerry, like I could probably go into
Speaker 6: the domin at least get a high level over you
Speaker 6: of what's going wrong. But if like reacts doesn't reconcile
Speaker 6: my JSX like correctly in some situations, I mean, I
Speaker 6: certainly ran into and this is rare, but sometimes I've
Speaker 6: run into React situations where it's like, oh man, like
Speaker 6: unless I unless I google it and find somebody that
Speaker 6: ran into the same problem that has like some ideas
Speaker 6: of what I can do, Like it can be I
Speaker 6: can be at a loss because it's just there's a
Speaker 6: lot more complexity in the front end world than there
Speaker 6: used to be.
Speaker 2: And there's just some use cases that React doesn't have
Speaker 2: a solve for. And this I think this came about
Speaker 2: earlier and reacts life cycles, like when it was still
Speaker 2: using a lot of class based components. But there were
Speaker 2: some situations where if you, like you wanted a model,
Speaker 2: for instance, to just pop out and sit on top
Speaker 2: of everything else that you could then either interact with
Speaker 2: or just close and go back, it was really really
Speaker 2: hard or darn near impossible to make that happen in
Speaker 2: a way that made sense or was as easy as
Speaker 2: some of the other JavaScript frameworks like Angular made it.
Speaker 2: So there was a lot of at least for me
Speaker 2: when I was getting familiar with React and starting to learn,
Speaker 2: but there were a lot of really frustrating moments where
Speaker 2: I couldn't do things that I would have been able
Speaker 2: to do pretty easily in other JavaScript frameworks. But at
Speaker 2: the same time, it's funny that you make that comparison
Speaker 2: of it being a black box, because that's almost something
Speaker 2: that I haven't heard React described as in a very
Speaker 2: long time. It seems like Angular really took that and
Speaker 2: got hammered a lot with it because of all their
Speaker 2: specific syntax and components and the way that they wanted
Speaker 2: everything built and styled. But everybody's like, oh, react, you
Speaker 2: can do anything with it. But you're very right in
Speaker 2: that if it's something under the hood that we don't
Speaker 2: have either access to or any understanding of that's in
Speaker 2: their source code, yeah, we're limited in that regard.
Speaker 4: I mean the Angle that example is a good one,
Speaker 4: because that is I mean, if you look at angle
Speaker 4: and that's right, it a couple of times saying I mean.
Speaker 4: There may be some folks in the audience who completely
Speaker 4: disagree with me, but for me though, it felt wrong
Speaker 4: because they pretty much reinvented everything and you couldn't even
Speaker 4: use other stuff from you, I mean the plane JavaScript ecosystem,
Speaker 4: because I mean you first had to wrap it in
Speaker 4: some angle, a specific notion of a service or you know,
Speaker 4: following all their terminology and what they I mean that
Speaker 4: they made a great thing, but it was in my
Speaker 4: opinion always why do you need to re engineer that
Speaker 4: that's already there? Browdlary ships? Is that why? But you
Speaker 4: need to wrap it just to bring it to your framework,
Speaker 4: and so I mean Angler maybe on the run time,
Speaker 4: people may disagree with me, less complex, and then what reacted.
Speaker 4: Certainly there are other areas like injection for instance of
Speaker 4: what it does with me that day, the reflection and
Speaker 4: song where it is certainly more complex. But if you
Speaker 4: look at the chorretit right, the reconciliation algorithm. Here what
Speaker 4: really makes reacts special. So this is a lot of
Speaker 4: complexity that's completely hidden from you doing let's say your work.
Speaker 4: Usually whereas Reacted, Angler was always on this change detection
Speaker 4: algorithm and so in this case a little bit more
Speaker 4: lads weight. But then it brought all these complexity also
Speaker 4: in form of all what you could call a black box,
Speaker 4: because it was also just throwing terminology at you and
Speaker 4: use everything from our framework and we then do something
Speaker 4: under the hood which goes back to basic browser APIs right,
Speaker 4: So you could look at it from two angles, and
Speaker 4: certainly in some perspective Reacted was very open and Angler
Speaker 4: was a black box. But from other perspective and this
Speaker 4: is really where we look at the core run time,
Speaker 4: it's the other way around. And then of course you
Speaker 4: can ask, well, what is the better way personally, I mean, hey, already,
Speaker 4: I guess we gave enough things. I think the React
Speaker 4: way is quite good, even though, and this is great
Speaker 4: that you mentioned the model. React always tried to then,
Speaker 4: let's say find solutions. So they introduced from the portal API,
Speaker 4: which is a great API in my opinion. But in
Speaker 4: the last two three four years we got a lot
Speaker 4: of new APIs. I mean, starting with hooks. You've got
Speaker 4: all these things that you certainly now use from Reactor.
Speaker 4: Previously we're only using i mean create elements unknowingly, but
Speaker 4: the class component knowingly. And now it's it's really a
Speaker 4: lot of things like lazy you should use I guess
Speaker 4: all the hooks of course, because they're awesome, even though
Speaker 4: highly debated. And so now you have this whole zoo
Speaker 4: and I'm not even starting the strict mode and all
Speaker 4: that stuff, so that they also should know. So also here,
Speaker 4: I mean suddenly complexity goes into the API comes that
Speaker 4: the user and you now need to make decisions. So
Speaker 4: it's it's not as severe as the Angular but it
Speaker 4: starts also to shift. Here are the worst cases. Of course,
Speaker 4: if you have the API complexity like angular class, you
Speaker 4: have the internal complexity because suddenly you need to know
Speaker 4: a lot of things to use it, and then you
Speaker 4: need to look to know to know a lot of
Speaker 4: things to debug it. And it's just like, oh, I
Speaker 4: don't know. I mean, let's hope it doesn't go in
Speaker 4: that way. If it goes X will not be as
Speaker 4: successful anymore. I suppose, I don't know.
Speaker 6: I'm serious, Like, based off this, like what advice you
Speaker 6: have for like the just the average React developer, like
Speaker 6: building their their apps. Is this something you think people
Speaker 6: should just be aware of? Is this a reason to
Speaker 6: like avoid React or use it only when you need it?
Speaker 6: And I'm curious what advice you to have people?
Speaker 3: Do you still reach for it?
Speaker 4: I mean I always reach for it even though I'm
Speaker 4: very let's say open for alternatives. There are these days,
Speaker 4: I mean a lot of what I would call lightweight
Speaker 4: alternatives to React, things like solid chats, for instance, which say, okay,
Speaker 4: what React brought to the table, how you write components?
Speaker 4: This is really great, but maybe what other frameworks bring
Speaker 4: to the table. Let's pick for instance, swells Swelter in
Speaker 4: my opinion, also an awesome framework, is also good. So
Speaker 4: how can we combine these to make for instance, the
Speaker 4: amount of JavaScript that we ship to the user. Yeah,
Speaker 4: less heavy, and I mean this was always one concern
Speaker 4: with these let's say more bloaded frameworks, I mean React.
Speaker 4: It is certainly not in that when when Angler started,
Speaker 4: I don't really want to that they bash Angler, and
Speaker 4: please forgive me for always mentioning it. I'm just an Angler,
Speaker 4: and you always think of theven I thought so anyway,
Speaker 4: I was always shipping. I saw at least the guy
Speaker 4: shipping for Hello worlds six hundred and seven and eight
Speaker 4: hundred kilobytes of JavaScript Mini Fight. Of course, jesuits a
Speaker 4: little bit less, but nevertheless, it's nearly a megabyte. And
Speaker 4: all you did was I don't know, using HTP service
Speaker 4: in there, and it really some elementary stuff but not
Speaker 4: really a lot of pages, just you know, one one
Speaker 4: simple page. It was just fetching something. And of course
Speaker 4: in reactually could have that a lot more lightweight, but
Speaker 4: you still would ship I don't know, one hundred fifty
Speaker 4: one hundred and twenty something. That's that still three digits
Speaker 4: amount of javascripts for all you do is catch maybe
Speaker 4: one resource and display a little string on the on
Speaker 4: the screen. Now, of course, one could argue, I mean
Speaker 4: this is not what REEC was built for. You should
Speaker 4: then build a real single page application, and suddenly if
Speaker 4: you have I don't know, one of the half megabytes
Speaker 4: of javascripts, hopefully lazy loaded in chunks and so on,
Speaker 4: then it suddenly makes sense you can afford bringing React
Speaker 4: and React on, especially react on. I mean, React is
Speaker 4: still white weights to the end user. But then we
Speaker 4: have now these other frameworks like solid and they're really
Speaker 4: aim for let's pick this small use case apart. We
Speaker 4: can still help you make you productive, and then we
Speaker 4: just shift the minimal amount. So what is my recommendation?
Speaker 4: If all you want to do is write with something
Speaker 4: really simple, one screen, just look around. You will find
Speaker 4: something that will suit you from how you approach the
Speaker 4: thing as a developer, with a community, also enough documentation,
Speaker 4: and maybe also being efficient and white weight. If you
Speaker 4: say you're building a full single page application, a tool
Speaker 4: like experience I always call it, we'll say you're building
Speaker 4: the next Photoshop in the browser something I mean, React
Speaker 4: is certainly a good choice. You can certainly afford shifting
Speaker 4: this one hundred one hundred twenty kilobytes. Additionally, which Jesus, Jesus,
Speaker 4: maybe I don't know fifty forty KO pipes. I don't
Speaker 4: know something in that range, so that certainly doesn't make
Speaker 4: a great difference, but that would be my recommendation. There
Speaker 4: are a lot of great frameworks, and I mean the
Speaker 4: principles and the parading that reacts to the table you
Speaker 4: can find now in a multitude of frameworks, and there
Speaker 4: are really some great ones. Just because they don't have
Speaker 4: so many stars or not take by by Facebook doesn't
Speaker 4: mean they're worse. Just look around, make sure that they
Speaker 4: are properly maintained, and not just stop tomorrow.
Speaker 2: Yeah.
Speaker 6: Well, and I think it's just decent software development advice
Speaker 6: in general. Right, Like, abstractions in themselves are not bad.
Speaker 6: Black boxes are not bad, but you have to accept
Speaker 6: a certain amount of trade offs. You have to make
Speaker 6: sure if you need the abstraction, if you need that complexity,
Speaker 6: if you're dealing with that level of problem, then great,
Speaker 6: Like that's a trade off, it's probably good for you.
Speaker 6: But if you're solving a much simpler problem, you could
Speaker 6: probably reach for a much simpler tool at least to
Speaker 6: start with.
Speaker 4: Right, right, And I mean, discussion with obstruction is also
Speaker 4: not newer, but I'm surprised that these days, it seems
Speaker 4: like obstructions, well, at least there is a little bit
Speaker 4: of let's say, a trend in articles to say obstructions
Speaker 4: are bad becauseous here, and I mean, of course they're right.
Speaker 4: There's no simple solution to say, oh, I mean always
Speaker 4: obstruct a way we've seen any angular example story. Again,
Speaker 4: it will be a theme that I guess that too
Speaker 4: much obstruction will just hurt you because you need to
Speaker 4: learn all these things too, right. So it firstly starts simple, oh, well,
Speaker 4: just one obstruction, I can save these three linns. But suddenly, oh, oh,
Speaker 4: which obstruction did I use to abstract these three lines?
Speaker 4: I need to find it? And suddenly you're more concerned
Speaker 4: about finding the right function that you extracted formally than
Speaker 4: just to do the coding right. And so there's always
Speaker 4: this straight off and there's certainly no one site fits
Speaker 4: some all solutions here, like with everything right. So this
Speaker 4: is one of the things that are always criticize many
Speaker 4: art because only say oh this is good or everything
Speaker 4: else is bad. Yeah, I mean there's always a reason why.
Speaker 4: For instance, why exists, even though why is now bad
Speaker 4: and excess the new thing to do, right, there was
Speaker 4: a reason for that and we shouldn't forget that reason. Maybe,
Speaker 4: of course technology advanced and maybe why is really not
Speaker 4: the thing to do anymore, but maybe there was a reason,
Speaker 4: and that reason just well, in this context is not
Speaker 4: valid anymore, or something else should be, let's say, considered too.
Speaker 4: And it's always good to know the tradeoffs and what
Speaker 4: other things exist and in what context that makes sense,
Speaker 4: because yeah, I mean there is in my opinion, there
Speaker 4: is no real black and white always it's just great
Speaker 4: and you need to find which shade of prey you
Speaker 4: fits to your particular problem. And I guess, yeah, we
Speaker 4: can discuss it in the REACT context, but I just
Speaker 4: said it's all in soft I mean, I guess also
Speaker 4: generations of what we knew that and we also learn
Speaker 4: it again, at least I do. And it's always a
Speaker 4: little bit of this cycle that that goes around, and
Speaker 4: we just need to see right where we end up,
Speaker 4: is where we are currently, and what we can do
Speaker 4: to just yeah, not make the same mistakes again. I mean,
Speaker 4: I think this is the only thing to really go forward,
Speaker 4: to reflect a bit and to find let's say, a
Speaker 4: better way forward, and to not forget why we picked
Speaker 4: that one. The why is quite often really crucial.
Speaker 6: Yeah, I feel like that the EBB and flow is
Speaker 6: an interesting way of putting it, because I feel like
Speaker 6: that's we've had cycles like that before, even in the
Speaker 6: front end world, Like I remember there was a time
Speaker 6: where pretty large JavaScript frameworks were quite popular. There are
Speaker 6: things like Dojo and Sencha, things that were fairly fairly
Speaker 6: heavy that got popular for a while, and then there
Speaker 6: was the push towards jQuery and like smaller things, and
Speaker 6: then now we started to creep back up again with
Speaker 6: some of these JavaScript frameworks. And I almost feel like
Speaker 6: this is true in the bill tools world as well,
Speaker 6: Like there's I mean, there was a while where Webpack
Speaker 6: had like a monopoly and everybody was totally cool with it,
Speaker 6: and now it's like cool to be like counter webpack
Speaker 6: and to be using all these hip, new, strangely named
Speaker 6: tools that are like different and smaller and faster, and
Speaker 6: it's like we can just as an industry, we can't
Speaker 6: make up our mind, Like as soon as we go
Speaker 6: too far in one direction, we come.
Speaker 5: Back in the other.
Speaker 2: Yeah, it's very much a pendulum of popular opinion. But
Speaker 2: one thing that I remember from a senior developer telling
Speaker 2: me once, which I liked a lot was that if
Speaker 2: I could explain to him why I had chosen a
Speaker 2: particular way to solve a problem or style or whatever,
Speaker 2: he was fine with it. He just wanted a reason
Speaker 2: for why I was choosing to solve a problem other
Speaker 2: than well it was like this and the rest of
Speaker 2: the code, or I saw somebody online do it, or
Speaker 2: somebody told me if I had a valid viewpoint. He
Speaker 2: was totally good with it. It was just have a
Speaker 2: reason for why do you think to do it this way?
Speaker 4: I think there's a good attitude. But I mean cod
Speaker 4: re views or let's say, yeah, just knowing why things
Speaker 4: went in a certain directions are always good to let's say,
Speaker 4: be based on well, this kind of knowledge because at
Speaker 4: the end of the day, I mean, there will be
Speaker 4: always also new people joining team class of course, people
Speaker 4: that are not as on your level or as senior
Speaker 4: as you, and so for them knowing the reason is
Speaker 4: also really good at a learning experience, either to the company,
Speaker 4: to the project, or to software development in general. Right,
Speaker 4: And so I always think that quite often we are
Speaker 4: not asking the why or answering the why good enough,
Speaker 4: at least I know that for myself. So I think
Speaker 4: this is always something where we can be also, yeah,
Speaker 4: full of critics of ourselves and always try to improve.
Speaker 4: And yeah, I think the why question is one that
Speaker 4: is also of course if we go back to the
Speaker 4: black box topic, one that you don't really see them
Speaker 4: right again, you're interacting with something where the system is
Speaker 4: completely hidden from you, so you don't see why things
Speaker 4: might end up in that state. Yeah, and microphonance, if
Speaker 4: we also good why questions? Why are you doing microphoneance?
Speaker 4: This is something I can ask a lot these days
Speaker 4: because believe it or not, I don't know how you
Speaker 4: feel about microphonance if you heard a lot about it,
Speaker 4: or on what side of the pandulum you are. But
Speaker 4: this is again like the guys are saying, we just
Speaker 4: that Microsoft didn't work or was used for everything and
Speaker 4: shouldn't be used for everything, totally agreed. Then the other
Speaker 4: guys will say, oh, Microsoft was so great, now we
Speaker 4: need to do microfondance. We don't know why because of
Speaker 4: front and is working great, but we want to do it.
Speaker 4: And so I mean also here I have the full spectrum,
Speaker 4: would really be eager to know what your opinions are
Speaker 4: on this one.
Speaker 2: Well, that's a great segue actually, as we were talking
Speaker 2: about things that are gaining popularity. So I have not
Speaker 2: really worked with micro front ends. I've worked in a
Speaker 2: very heavy micro service environment where we had different back
Speaker 2: ends mostly serving one one single front end. But I'd
Speaker 2: love to hear more about what is the use case
Speaker 2: because I've had pretty big mono repos that are massive
Speaker 2: REACT projects, so I could see if you could break
Speaker 2: that up that would possibly be useful. But I'd love
Speaker 2: to hear more about how this came about and your
Speaker 2: experiences with it. And TJ, I don't know if you've
Speaker 2: ever worked with microfrinends.
Speaker 6: Either similar experience. I've got it back in with micros
Speaker 6: or a background with micro services, but never really had
Speaker 6: a use case for a micro fun end. So maybe
Speaker 6: maybe a good place to start it. Maybe you could
Speaker 6: just give us like the very simple like one oh one,
Speaker 6: what is the micro fun end?
Speaker 5: Why would you use it? That sort of thing?
Speaker 4: Yeah, Or I tell microphone is all about distributing the
Speaker 4: work on a front end application, and there are various
Speaker 4: ways to do it, which is where the complexity already
Speaker 4: comes into play here. So you could, for instance, do
Speaker 4: what to just describe as a mono report. You could
Speaker 4: do that. You could say, okay, we just now make
Speaker 4: certain libraries, let's say component libraries for instance, and in
Speaker 4: order to let they have it's still all together. We
Speaker 4: have them in a MONORAPO, and we have one large
Speaker 4: build that could certainly justify let's say, or it could
Speaker 4: be counted as a micro front them. But then we
Speaker 4: still have maybe large or longer bill times. Let's say,
Speaker 4: we still have maybe conflicting full requests, and we still
Speaker 4: need to give everyone access to this. Plus of course,
Speaker 4: yeah cd I already mentioned along build times. Now everyone
Speaker 4: of course shares the same build pipeline, which means this
Speaker 4: is always let's say the one bottle neck potentially, and
Speaker 4: so there are of course other ways. So one way
Speaker 4: is to say, okay, instead of having real micro services,
Speaker 4: we now have micro web servers so to speak, so
Speaker 4: servers that still are there, but instead of serving for instance, Jason,
Speaker 4: they may still do, they now serve also HTML. And
Speaker 4: then we combine these things, for instance on a reverse proxy,
Speaker 4: so we have one like an API gateway in front
Speaker 4: of it that now takes these different HTML fragments, puts
Speaker 4: them together, spits it out. Challenge here is of course,
Speaker 4: how do you now debuct this? You're responsible of one
Speaker 4: of these fragments, how do you get that? And who's
Speaker 4: responsible for let's say, maintaining that reverse proxy or this?
Speaker 4: That's good, call it microfront and gateway. The area where
Speaker 4: I'm mostly working is in the third one, where you say, oh,
Speaker 4: what you can do is you still may have something
Speaker 4: like these component lips, but instead of needing a build
Speaker 4: process with tooling like webpag or another bundler, you deploy
Speaker 4: them independently in form of still javascripts for instance, and
Speaker 4: now you combine them in the front and are There
Speaker 4: are a couple of popular approaches. Usually what you do
Speaker 4: here is, of course you have in a single page
Speaker 4: eptic and sometimes people call it in a single page
Speaker 4: application of single page applications, because each of these javascripts
Speaker 4: can be independent single page application. I'm not really into
Speaker 4: that one, but nevertheless you can can, of course refer
Speaker 4: to it. The gist of it is that you need
Speaker 4: some orchestration engine now in the front ends that runs
Speaker 4: in your browser, on your web app, and that can
Speaker 4: handle now getting these different javascripts and bringing them together,
Speaker 4: isolating them as well as possible. Even though I mean
Speaker 4: there are limits. Of course, in document object models, if
Speaker 4: you want the true isolation, only way to do it
Speaker 4: is an eye frame, which is problematic for a couple
Speaker 4: of reasons. Then of course we have the web components
Speaker 4: here in this space. They allow us at least to
Speaker 4: have proper style isolation, which is great and can be
Speaker 4: also not se great. My opinion is for a partier,
Speaker 4: but we still have from the scripting perspective a lot
Speaker 4: of potential conflicts. And then we can also do something
Speaker 4: like yeah, standard script injection with ESMs or UMD modules
Speaker 4: and hear things like single spar or the framework where
Speaker 4: eye contribute to which is called viral. They help you
Speaker 4: to use that as an orchestration engine. So in the end,
Speaker 4: it's really about that you allow different teams to work
Speaker 4: on the same application even though they have their own repository,
Speaker 4: own CD pipeline right, which allows to ship new updates
Speaker 4: off their code or a new feature in really seconds
Speaker 4: to minutes depending how it is all set up, instead
Speaker 4: of waiting longer and maybe having more loaded processes sharing things.
Speaker 4: So this is what it is about, a little bit
Speaker 4: like in the micro service department. Also here you often
Speaker 4: here hear one argument you can now use independent technology.
Speaker 4: So one team uses React, another users Anglar. Well, let's
Speaker 4: not go there, right. Personally, I would say you should
Speaker 4: try to have a set of core technologies because it's
Speaker 4: the front and if you combine it in the front
Speaker 4: and in the browser, right, you ship all that to
Speaker 4: users browser. And if you suddenly run ten frameworks in
Speaker 4: this yeah, maybe on a mobile device, it will not
Speaker 4: be a great experience, right, So you should maybe try
Speaker 4: to limit it to one. Or maybe there's this other
Speaker 4: cool framework that's used in a particular page or particular
Speaker 4: part of your page, maybe you should try to limit it.
Speaker 4: But I guess it's the same again as with micro
Speaker 4: services that the goal was also never to have a
Speaker 4: patchwork of technology. It was always to just you know,
Speaker 4: allow using different technologies. That then the best thing, the
Speaker 4: best tool for the job. If you have their service
Speaker 4: that deals a lot with it, I don't know, data manipulation,
Speaker 4: you can use a language or framework that's dedicated to that.
Speaker 4: If you have another service that I don't know, should
Speaker 4: do something else, and you have a team that only
Speaker 4: knows I don't know, c sharp dot net, they can
Speaker 4: use this this one And I guess it's similar here right,
Speaker 4: so you shouldn't. Just because you can doesn't mean you should.
Speaker 4: But yeah, it gives you a little bit more freedom.
Speaker 4: And this is what microphone is about, giving you this
Speaker 4: freeedom to actually, yeah, I have distributed developments possible and
Speaker 4: be a little both or flexible and agent as we are.
Speaker 4: But there are, of course, maybe that's a good transition.
Speaker 4: There of course counter arguments too, right, So complexity rises
Speaker 4: just that two and you need somehow to Yeah, I
Speaker 4: have this orchestration there under control. You also need new
Speaker 4: processes because yeah, now teams can maybe deploy independently. Maybe
Speaker 4: you don't want that, maybe you want that. It always depends,
Speaker 4: and so you always of course also hear shift complexity, right,
Speaker 4: So you gain something, but then something else is maybe
Speaker 4: a little bit worse or challenging for no silver bubllets.
Speaker 2: Kah.
Speaker 6: Well, no, it's interesting because I'm thinking like so it
Speaker 6: helps my brain to think in terms of like concrete examples.
Speaker 6: So I imagine I'm building my standard react app, but
Speaker 6: I have a shop, and the shop is quite a
Speaker 6: bit different, and so today, because my brain doesn't think
Speaker 6: in terms of micro friend ends, I would think like, oh, okay,
Speaker 6: my shop is quite a bit different, So I'm going
Speaker 6: to want to do my best to make sure I'm
Speaker 6: like lazy loading that or like deferring loading of that.
Speaker 6: But I would still my gut would still be like, oh, well,
Speaker 6: of course i'd keep that apart of my same React application, right,
Speaker 6: I just make sure to try to do my best
Speaker 6: to lazily load this stuff in. It sounds like the
Speaker 6: micro front end approach would essentially say that shop would
Speaker 6: be almost like its own separate project in a sense. Right,
Speaker 6: that it would that there's some like like you said,
Speaker 6: orchestration layer that figures out how to bring that app
Speaker 6: in and reconcile it. So first of all, I'm curious
Speaker 6: if my understanding of this is correct, and then I'm
Speaker 6: also trying to get like sounds like the benefits of
Speaker 6: this is it's because it's like it's isolated thing, then
Speaker 6: the team that's working on it can kind of work
Speaker 6: on it potentially even like deploy it without worrying about
Speaker 6: the rest of the app. Like, if you're we assume
Speaker 6: the rest of our React app is quite large, it
Speaker 6: probably would take forever to build and test and deploy,
Speaker 6: and having like little logical sections of these isolated I
Speaker 6: could see some benefits of that, but like you said,
Speaker 6: I could also see trade off. So I guess, first
Speaker 6: of all, is my understanding of this correct, Is that
Speaker 6: use case sort of makes sense?
Speaker 4: Yeah, it makes We've got in the shop most I mean,
Speaker 4: there are a lot of e commerce companies that use
Speaker 4: micro fundance. Most of them, however, don't do client side
Speaker 4: what we call client SiGe compositions. So where we already
Speaker 4: ship a JavaScript that acts as the orchestration layer and
Speaker 4: then brings together the other script, most of these companies
Speaker 4: actually do the server side composition here. The reason is that,
Speaker 4: first of all, their parts are not really so much
Speaker 4: about interactivity. Second, they care a lot about performance, so
Speaker 4: that they really want to have something that can be
Speaker 4: pre cash and so on, and they just send it
Speaker 4: out to the end user that it's as fast as possible, right,
Speaker 4: so they followed this, one hundred million seconds of additional
Speaker 4: loading time means that less revenue, and so they always
Speaker 4: try to optimize here. But nevertheless, there are of course
Speaker 4: also e commerce shops that are built using microfundant, using
Speaker 4: a microphonat approach, and for that, yeah, so what you
Speaker 4: would do usually, but there'll of course a lot of
Speaker 4: different approaches, but what I personally like as an approach
Speaker 4: is that you follow here a more domain chrythm approach.
Speaker 4: So what you would want to do is you identify
Speaker 4: first of all the grand theme of your applications. Well
Speaker 4: it's in the e commerce space, right, But then you
Speaker 4: start identifying subdomains here, right. So one subdomain could be
Speaker 4: I don't know a recommendation model. So you're on a
Speaker 4: product detailt page. You want to see a list of
Speaker 4: recommendations related products I don't know, products that may only
Speaker 4: make sense for this particular user, and so there could
Speaker 4: be one team just working on let's say you I
Speaker 4: fragment for that. This team may also want to bring
Speaker 4: in I don't know something now menu bar or in
Speaker 4: some menus here that that we offer, and we may
Speaker 4: have another team that only works on maybe the product
Speaker 4: details page. There may be a third team working just
Speaker 4: on the product search. And product search is also interesting
Speaker 4: because while it may have a dedicated page right search
Speaker 4: resultants on, it also has of course maybe a search
Speaker 4: that's always visible and they own this spar right, so
Speaker 4: every input and so on that's owned by this one team,
Speaker 4: and so you would actually not just one screen and
Speaker 4: say this one screen belongs to this one team, but
Speaker 4: you would actually do it. Well, I actually decompose every
Speaker 4: screen that I have, and maybe I have the main
Speaker 4: content of this screen that goes into particular team, but
Speaker 4: then I see other components that may be on a
Speaker 4: lot of pages, maybe all pages, may only be in
Speaker 4: a few pages, but I identify in what's the main
Speaker 4: does this fragment of your eye lie? And this is
Speaker 4: what microphons are about, that you cannot find the correct
Speaker 4: team that only let's say, ear is now the search
Speaker 4: the search bar and the search page, the search without page,
Speaker 4: and they will do everything with it, and then if
Speaker 4: there have an improvement for the page, they can ship
Speaker 4: it completely independently and they are just responsible for that.
Speaker 4: There are also approaches out there, I mean one that
Speaker 4: is certainly easier to implement, but in my opinion, will
Speaker 4: lead to well, let's say more frustration team where you
Speaker 4: divide the UI by what you see on the screen.
Speaker 4: So you just say, oh, there's a head up, that
Speaker 4: should be a microphonet, there's a food, should be another
Speaker 4: microphone in, there's a navigation bars should be a third microphoneant, Yeah,
Speaker 4: you see that. It are quite a lot of beginner tutorials.
Speaker 4: In my opinion, it's there because it of course makes
Speaker 4: sense visually and it's easy to implement, I mean easier maybe.
Speaker 4: But on the other hand, of course it will have
Speaker 4: a lot of frustration points because suddenly this team that's
Speaker 4: doing in navigation bar is always let's say, dragged and
Speaker 4: pulled by every other team. We need something in here
Speaker 4: under this condition, we need it. Can you just update
Speaker 4: that we have a new icon and it will never
Speaker 4: work out smoothly? I mean you just created now Yeah.
Speaker 4: I don't know if there's a word for it, maybe
Speaker 4: spaghetti modulet I don't know. Yes, we can, we can,
Speaker 4: we can invent something now here, but but it's really
Speaker 4: it will not be maintainable in my experience, and so
Speaker 4: I always advocate going for the identifying domains and putting
Speaker 4: those into let's say teams or microphondance, which are then
Speaker 4: responsible or in charge. Yeah, certain teams are in charge
Speaker 4: of them.
Speaker 2: That's what I was going to ask is how do
Speaker 2: you do you have any advice for how to know
Speaker 2: when a project has gotten so big or something a
Speaker 2: piece of a project is so complex that it should
Speaker 2: be broken out because it seems like that's a very
Speaker 2: that might be a very difficult thing to identify. When
Speaker 2: when is the right time to break this into its
Speaker 2: own separate front.
Speaker 4: End the good question.
Speaker 3: It depends.
Speaker 4: I always say, if you're happy with your monoliths, don't
Speaker 4: change it. I mean there's a reason for it. Also,
Speaker 4: I mean we started with the monorepple, right, and I
Speaker 4: said mono repo. It can also be something like a
Speaker 4: microphone introdutionally, just now combined to different pieces of build time,
Speaker 4: which is also fine. Right, So if you start with
Speaker 4: a monorepple, for instance, if you say, I don't know
Speaker 4: if they ever need this micro front and stuff, but
Speaker 4: it would be nice to architecturally maybe group it, my
Speaker 4: advice would always be, well, start with a monolith, but
Speaker 4: do it as a mono report, because if you did that,
Speaker 4: it will be easy later on to just extract out
Speaker 4: certain modules and just put a little bit of with
Speaker 4: the right framework debugging and seedra capabilities on it, and
Speaker 4: you then have your distributed microphone and solution. But you
Speaker 4: don't need to start with it immediately because that adds
Speaker 4: just complexity at a stage where all you should care
Speaker 4: about is really bring out your stuff and see that
Speaker 4: it works. But nevertheless, so when it's the right time
Speaker 4: to let's say, make the transition, well, I would say
Speaker 4: if the majority of the team members are unhappy, that's
Speaker 4: always a good time because if frustration grows, I mean,
Speaker 4: you suddenly have a pain point and you need to
Speaker 4: solve that pain point. People wouldn't be let's say, in pain.
Speaker 4: If they would say, oh, we ship features too fast, well,
Speaker 4: it's too much fun. We can experiment around this new stuff. Well,
Speaker 4: that death doesn't sound like pain to me. But if
Speaker 4: they say, oh, my poor regress is hanging there for
Speaker 4: two weeks and we were supposed to shift that feature
Speaker 4: a month ago, but suddenly all the bills take so long,
Speaker 4: and then there was this conflict here. In conflict there, well,
Speaker 4: it sounds like some things he needs to change somewhere.
Speaker 4: I'm not sure if microphone is is a solution here, right,
Speaker 4: but I'm sure that something needs to change, and maybe
Speaker 4: microphone isn't a good solution if you hear as pain points,
Speaker 4: especially things like it needs to go faster particular features.
Speaker 4: So this is really where microphones may hit the nailia.
Speaker 4: But make no mistake, migration of existing applications I mean,
Speaker 4: if we have this case that it just describes monoapo
Speaker 4: all nicely grouped this, this is the beauty. This will work.
Speaker 4: But usually it's not as nice like this because the
Speaker 4: application is five years old. It started nice, but then
Speaker 4: duct taper duc Tapier there was a feature that never
Speaker 4: someone thought us, so we needed to work around for it.
Speaker 4: How can we now do that in this distecret world.
Speaker 4: It will not be a pretty journey. I mean, certainly
Speaker 4: the architecture will be more sound afterwards, and most time
Speaker 4: will not be spent in this microphone in space, but
Speaker 4: rather in how can we distributed? Because we've made it
Speaker 4: a smucketti before it. But certainly I think this is
Speaker 4: when you hear enough people complaining, it's a good point
Speaker 4: to think about it.
Speaker 6: Yeah, Honestly, the productivity and the sort of flexibility around
Speaker 6: this seems like the biggest advantage to me because I've
Speaker 6: certainly been on teams and been in projects where it's
Speaker 6: like you put it in terms of happiness, but it's
Speaker 6: almost in terms of just like how how evil you
Speaker 6: are to get stuff done? Because countless times where like
Speaker 6: you go to deploy something and it's like, oh no,
Speaker 6: we can't put the push this out because this is
Speaker 6: in the way, or no, this is tied to this
Speaker 6: really so that's not ready.
Speaker 5: We have to back this out.
Speaker 6: We have to bring in the person who's really good
Speaker 6: at get to figure out how to reconcile all of
Speaker 6: these problems, right, and you keep stepping on each other's toes,
Speaker 6: and nobody wants that to be their day at work,
Speaker 6: like you want to be shipping things, doing things, and
Speaker 6: software just being a complicated topic. I think as projects grow,
Speaker 6: as we work on bigger and bigger things, there's something
Speaker 6: in here about that sort of stuff getting in your way.
Speaker 6: So it's an interesting way of bringing it out because
Speaker 6: as you described it, you're talking far more granular components
Speaker 6: than I had like pictured in my head because again,
Speaker 6: like I went, I immediately went to like, oh, my
Speaker 6: entire shopping experience, but you're talking like just even like
Speaker 6: individual widgets like the search or the products thing, and
Speaker 6: it's it just goes to show how like my mind
Speaker 6: does not work this way just because I haven't been
Speaker 6: a I haven't really considered this. So now like I
Speaker 6: used to like retrain my brain to like when I
Speaker 6: see things like that, to think, oh, like that's that's
Speaker 6: an option or that's a potential way that I can
Speaker 6: attack this.
Speaker 4: Yeah, I mean it takes. I mean I'm not working
Speaker 4: in this now for already more than five years in
Speaker 4: the microphoneance space. So when I thought it was just
Speaker 4: the well the term microphone and wasn't well existing yet,
Speaker 4: they later on I think it first came up in
Speaker 4: the salt Works radar. I don't even know. Someone taught
Speaker 4: me while ago that it was first point. But anyway,
Speaker 4: that was then coined afterwards, just retrospectively, I was like, ah,
Speaker 4: that's what That's what I was doing. Right either way,
Speaker 4: I mean that you don't start with that right away.
Speaker 4: And still, of course getting the rights decomposition right on
Speaker 4: this domain that I described is also not easy, right,
Speaker 4: so you need, of course do main experts. You need
Speaker 4: to know people of course that really understands the requirements
Speaker 4: of your solution that you either want to build or
Speaker 4: that you have built and I want to let's say
Speaker 4: roll out as microphone then and yeah, you need of
Speaker 4: course to then train the people. Ideally, of course, this
Speaker 4: is the experience I had in most projects. I mean,
Speaker 4: if the micro frontum setup was done well, developers of
Speaker 4: individual modules don't even let's say, know that they are
Speaker 4: doing micro fundams. I mean they're just developing. I mean
Speaker 4: you tell them you now do the shopping basket, okay,
Speaker 4: and then they develop ideally at least now this client
Speaker 4: site perdigon like for a single page application. They even
Speaker 4: have the debugging experience the same as you know, as
Speaker 4: if you would debug the grand application right on. The
Speaker 4: difference is in their view, they only see let's say,
Speaker 4: naked application. Maybe I don't know how to food are
Speaker 4: in there, some design elements and they're they're saying that
Speaker 4: they are focusing on and all the other microphones may
Speaker 4: not even be there. Maybe they are there. I don't
Speaker 4: know they've used in but you can decide it in
Speaker 4: the setup for instance. And so they don't even know.
Speaker 4: They're just developed there and they don't need to know
Speaker 4: the particularities of this kind of style. And I think
Speaker 4: this is a good way, because we're back at the
Speaker 4: black box. I guess here, if you would now know
Speaker 4: a lot of stuff, or need to know all this
Speaker 4: stuff what's happening below, I mean certainly would be great
Speaker 4: and in certain edge case conditions it would help you.
Speaker 4: No questions are But in the ninety ninety five percent case, right,
Speaker 4: I mean if the platform with the run time or
Speaker 4: it takes away all that for you, and all you
Speaker 4: need to do is focus on your problem and how
Speaker 4: you solve that. No technological questions asked, No, oh oh ah,
Speaker 4: I need to wire up this with that. No, you
Speaker 4: just focus on your domain specific problem. This is where
Speaker 4: I want to be because at the end, I mean,
Speaker 4: this is also where for instance, our case, we are
Speaker 4: getting the money from our customer doesn't say we're paying
Speaker 4: you to debuct react. No, we're paying you to bring
Speaker 4: the shopping cards to life, for instance. And I think
Speaker 4: this is working in your problem. I think this is
Speaker 4: what makes some frameworks productive and great, and others well
Speaker 4: technological interesting, but otherwise maybe not the productive.
Speaker 2: So are these the kinds of things? And I'm sure
Speaker 2: much more that you talk about in your book that
Speaker 2: you just wrote.
Speaker 4: Yeah, the book is, I would say, well, let's be
Speaker 4: just end in the camera. It's called The Art of Microfondance.
Speaker 4: You can find an Amazon. It's released from the Pucked
Speaker 4: Publishing company, and half of the book is very practical.
Speaker 4: So there I mentioned, let's say the three grant schemes
Speaker 4: that we have in a microphonance space right, built time,
Speaker 4: in service side, client side. These are all covered in here.
Speaker 4: Class of course, a lot more patterns, so there's a
Speaker 4: lot of also here a lot of shades of prey, right,
Speaker 4: so I think it has seven patterns and all of
Speaker 4: these very practically introduced. But most of the or let's say,
Speaker 4: the other half of the book really deals that with
Speaker 4: how do I choose the right to maintain composition? How
Speaker 4: do I now work with designers for instance, because they
Speaker 4: will still design a monolith and you need to teach
Speaker 4: them what are you doing technically that they will well
Speaker 4: give you the best experience because at the end of
Speaker 4: the day you will design, you will create something that
Speaker 4: is in its mature flexible. So for instance, the navigation bar,
Speaker 4: it's not cut in stone. Someone can just write a
Speaker 4: new feature and they have a new item. How does
Speaker 4: it behave in under these conditions? Right, So suddenly designers
Speaker 4: need to go beyond the static screen design and really
Speaker 4: think about these things, but also about organizational changes, because yeah,
Speaker 4: if you really distribute the code, suddenly responsibility should be
Speaker 4: also distributed and things like that. So it's really half
Speaker 4: and half, so one half very very practical. The other
Speaker 4: half I would still say practical, but maybe not for
Speaker 4: the let's say standard developer more let's say for architects
Speaker 4: or decision makers than and people to say, oh, I
Speaker 4: now want to know what what is beyond the horizon
Speaker 4: if we go that way. Yeah, and certainly is one
Speaker 4: of the things I covered.
Speaker 5: He and it's got a five star average on Amazon,
Speaker 5: so I mean.
Speaker 4: It's a lot of small numbers. So I wouldn't say
Speaker 4: it's dead.
Speaker 5: You've got to market it, sell the bush.
Speaker 4: Sorry, Yeah, I didn't want to just spoil you, and
Speaker 4: I always try to be honest. So at the moment, mean,
Speaker 4: the book is fresh one month out there, so I
Speaker 4: don't know how many reaviions it now has on Amazon.
Speaker 4: Common on the German side has I think two reviews
Speaker 4: for three I don't know anyway all five starts at
Speaker 4: the moment. It will not stay that way, so I'm
Speaker 4: I'm a realist in that case. But still it would
Speaker 4: be happy if any guy, any any girl once say
Speaker 4: well look at that. Just also you can give me,
Speaker 4: let's say, a message on Twitter for instance, because I
Speaker 4: still have I think fifteen or twenty five percent of
Speaker 4: the ebook, and there may be a chance. I still
Speaker 4: have I think some physical copies, so hard copies of
Speaker 4: this that's like the one I old man that I
Speaker 4: could get you for free actually if you message me.
Speaker 4: But these are limited. Actually I think I have five
Speaker 4: or six left there. But anyway, if you're interested, always
Speaker 4: just taking me. I'm very open, of course, and sorry,
Speaker 4: I want to sell the book more. It's the best together.
Speaker 4: It even discusses west development in general in the introduction.
Speaker 4: You should read it. If you don't know what cgi
Speaker 4: SSI and so on, it's in there. If we talked
Speaker 4: about tooling web peg parcel, it's all disgusting here. Why
Speaker 4: that's to new? That's not in this book at I think.
Speaker 4: But I even have ees building here, so you can't say,
Speaker 4: I'm yeah, there's still pretty new stuff in here. Could
Speaker 4: be on the computing stuff. But anyway, any kind of
Speaker 4: criticism also to me, right, So if there is something
Speaker 4: you like to improved, I don't know if there will
Speaker 4: ever be a second edition, but just tell me. I
Speaker 4: always also love to learn. And yeah, I'm not saying
Speaker 4: the book is perfect, but I try to put everything
Speaker 4: I know about my performance in there, even though as
Speaker 4: always right, you finish the book when you're like, hmm,
Speaker 4: this is one cool thing. I didn't mention it, but
Speaker 4: then I just make a blog post about it and then.
Speaker 3: Well that's fantastic.
Speaker 2: So Florian, as we were talking about, if people want
Speaker 2: to get in touch with you about your book or
Speaker 2: about anything else, what are the best ways to reach you, I.
Speaker 4: Guess the best way is Twitter. They might handle the
Speaker 4: flow and rubble just one word. Maybe we'll have the
Speaker 4: address also in there. Otherwise, I'm of course on guit
Speaker 4: ub some of the projects I'm contributing there to Guita,
Speaker 4: So this is a chetroom. For instance. I'm very active
Speaker 4: in the Piral chatroom, so if you're interested in a
Speaker 4: microphone and framework PIRL, I will also paste the address
Speaker 4: in there. Would we want to check out? And we
Speaker 4: have their public guitar chatroom. I'm very active there. You
Speaker 4: will see me chatting around giving answers to Pyrol in
Speaker 4: particular or microphones in general. And I think we have
Speaker 4: a great community in our channel. We have I don't know,
Speaker 4: one hundred and sixty one hundred and seventy people, not
Speaker 4: all of course active all day, but there's always one
Speaker 4: good answer for every question. And I will paste it
Speaker 4: in the chatroom. But that's either I guess that's the
Speaker 4: best way to reach me. Otherwise, of course email can
Speaker 4: give you this and otherwise on my personal website. They're
Speaker 4: also all the I mean, I'm also in Skype and
Speaker 4: so on. All the messengers rights in a Richmond which one. Yeah,
Speaker 4: it's like it this comic about all the stand ups, right,
Speaker 4: So there are certain stand ups we need to imprace
Speaker 4: them all. We need a new one. It's the same thing,
Speaker 4: so we need a messenger to have all the messengers.
Speaker 3: Very good, excellent.
Speaker 2: Well, now is a portion of the show where we
Speaker 2: move into picks. So TJ, would you like to start
Speaker 2: us off this week?
Speaker 6: Yeah, I'm going to pick some Marvel stuff. So I
Speaker 6: went to the theater for the first time and since COVID,
Speaker 6: which honestly was probably the best part of the experience.
Speaker 6: It was just really I didn't realize I'm not a
Speaker 6: big movie person. I didn't realize how much I sort
Speaker 6: of missed the atmosphere of this actually going seeing a
Speaker 6: movie in person. And we saw Black Widow. It was
Speaker 6: pretty good. We definitely enjoyed it. But it's set off.
Speaker 5: Now we have to watch all the Marvel things.
Speaker 6: So now we've been on Disney Plus and started WandaVision,
Speaker 6: which was it' quite the trip, like, very very engaging
Speaker 6: and very interesting show. So highly recommend, I guess go
Speaker 6: to if you can safely go to a movie theater. Now,
Speaker 6: i'd recommend getting back to that. And WandaVision has been
Speaker 6: a pretty good show that sounds like a good re
Speaker 6: entrance to the movies. Marvel movies very rarely disappoint me.
Speaker 5: Yeah.
Speaker 4: Nice.
Speaker 2: Well, my pick this week is going to be totally unrelated.
Speaker 2: It is a GitHub course that I found, or I
Speaker 2: guess GitHub documentation and it's called IoT for Beginners, and
Speaker 2: it's actually made by Microsoft. But if you've listened to
Speaker 2: the show with any regularity, you'll know that I started
Speaker 2: a new job about a month ago now, and the job,
Speaker 2: while it is web development, it is working for a
Speaker 2: company that specializes in Internet of Technology enablement called blues Wireless,
Speaker 2: and so we make things called note cards that connect
Speaker 2: to Raspberry pies or are we knows, or to just
Speaker 2: the cloud by themselves. And so I need to actually
Speaker 2: understand how the Internet of Things works because I've never
Speaker 2: really interacted with it before. So I'm starting with some
Speaker 2: of the really basic online things that are available to
Speaker 2: kind of learn how to use raspberry pies and get
Speaker 2: into that sort of space. And this IoT for beginners
Speaker 2: is very comprehensive. It's free, there's videos, there's build kits
Speaker 2: that they recommend, there's all kinds of really useful getting
Speaker 2: started from the very basics, and I'm really enjoying it,
Speaker 2: So I would recommend that for anybody who's kind of
Speaker 2: looking for a foray into it. So, Florian, do you
Speaker 2: have anything that you'd like to pick?
Speaker 4: Well, I mean, first of all, well those are all
Speaker 4: good picks. Black Widow. I still want to see I've seen.
Speaker 4: I can also stream it. It's the twenty euros quite
Speaker 4: expensive actually for the extreaming access there. But anyway, one division,
Speaker 4: I yeah, I've seen the first two episodes. It was
Speaker 4: crazy for me. I don't know.
Speaker 6: I actually you have to stick with it because it
Speaker 6: starts absolutely insane and then they start to somewhat explain it.
Speaker 4: But then I heard it got better, but I mean
Speaker 4: they lost me. Anyway. The Microsoft things, they're always greater.
Speaker 4: I remember when Microsoft release, for instance, the clouds patterns
Speaker 4: that was really great. So they always do a great
Speaker 4: job at documentation and being really comprehensive, really accessible and approachable,
Speaker 4: so that that it certainly kick out. I need to
Speaker 4: check that out. So my pig would be a book
Speaker 4: and all good. But I mean that's for me, is
Speaker 4: like a hidden classic which is called I don't know
Speaker 4: your code as a crime scene. It's, yeah, an interesting
Speaker 4: book in that fact that sometimes I mean already things
Speaker 4: like for instance we heard about GIT here leave trails
Speaker 4: where you can see where the problems are in your
Speaker 4: code base. So for instance, if you see that let's
Speaker 4: say a certain amount of commit is always in a
Speaker 4: part of your application with a certain file, let's say that
Speaker 4: usually doesn't carry any feature, but you know it's just
Speaker 4: for instance, some orchestration lays. Then you know architecturally something
Speaker 4: isn't dry because after a while, I mean, it should
Speaker 4: stabilize pretty much, and you should just see for instance
Speaker 4: changes in well, new files being added, new features coming along.
Speaker 4: And if you see a pattern like that, well you
Speaker 4: have a very healthy application. Congratulations. Usually, especially in our
Speaker 4: own applications, I see a lot of commits happening to
Speaker 4: files where well they should be already stable somehow. But
Speaker 4: either I'm just in refectory mood or really something is
Speaker 4: not really done right. And I mean, this book goes
Speaker 4: into a lot of patterns of detecting such fishy things.
Speaker 4: What you can do then and well, yeah, following then
Speaker 4: your crimes to detect what to improve, because after all,
Speaker 4: we shouldn't just reflector for the refectory sake, but we
Speaker 4: should reflect them and make things more productive. But for
Speaker 4: that's the first to recognize what's all making us not
Speaker 4: so abductive. This book is I think, at least for
Speaker 4: me it was and still is when I haven't opened
Speaker 4: it a great guide. Today I will post an Amazon
Speaker 4: link for it.
Speaker 3: Excellent.
Speaker 2: That sounds like a really good read and something that
Speaker 2: I will definitely be looking into. I'm always looking for
Speaker 2: new ways to improve my own coding practices. Well, Florian,
Speaker 2: it has been an absolute pleasure to have you on.
Speaker 2: Thank you so much for joining us today on React
Speaker 2: Around Up.
Speaker 4: Thanks for having me was a pleasure, all right.
Speaker 2: We will see everybody on the next episode.