Matt Pocock, Minko Gechev, and next-gen React[Mini ep 7]
===

[00:00:00] 

Emily: happy Friday developers. Today is August 11th, 2023. And welcome back to our roundup episode where you can catch up on episodes you missed or get a quick rundown of the past two weeks from PodRocket. So let's get started. 

First up, we welcome back our favorite TypeScript guy, Matt Pocock, to answer your questions about TypeScript.

In this clip, one of our listeners asked him about design patterns and how to use them within TypeScript.

Noel: So there's a couple more kind of in the dev sphere I want to cover here before we do that. There was one, let me see if I can find this question. Yeah, they're asking about design patterns and like kind of TypeScript's relationship.

They're asking what are the specific use cases for different design patterns to use with TypeScript? What are some steps that can make working with those design patterns easier? Have you found there's any kind of anything unique to TypeScript in particular that makes certain patterns easier to deploy and utilize versus just vanilla

Matt Pocock: Yeah, for sure. So TypeScript does a lot of it's all about the shapes of [00:01:00] things. So every time you declare like an interface or a type, then you're declaring a shape that something has to correspond to. And what TypeScript is really good at is making sure that every line by line, the shape of something is as you think it should be.

This means. Quite naturally, it's better with immutable data structures instead of mutable ones. Because if you're mutating something line by line, then you're changing it as it goes and you're not really able to tell TypeScript what that new thing is. That means it's, let's say you're mutating an object, for example, and you're saying, okay, I want to take this array of things, stick these all in an object.

It's going to be quite hard for you to dynamically type that really, so you're going to need some type signatures on that. And, but that's fine. TypeScript also, it's really like the more complex your JavaScript is, the more complex your TypeScript is going to be. Because TypeScript just describes JavaScript.

That's all it does. It doesn't add any, anything extra, [00:02:00] really. It just does some stuff on top to make sure that your JavaScript is doing what it's supposed to be doing. Really, it can do everything that JavaScript does. There are no patterns that you can do in JavaScript that TypeScript can't do. It's all about what's more idiomatic to TypeScript.

What's easier to do. What requires fewer annotations. And in general, what that means is... Programming in a more I don't know about functional style, but TypeScript really just loves functions. That's what it loves. And if you're designing like an API or something, and you're finding that you're, you need people to like, mutate stuff or do lots of sort of class inheritance.

It's good with class inheritance as well. Good with OOP, but functions is really where it shines. And that's where you can really use the more powerful TypeScript features to your advantage. So I don't know about specific patterns and stuff, but use more immutability instead of mutation.

And TypeScript is really as flexible and wide as you want it to be.

Noel: Yeah, I think I guess I agree. That's what I found as well. I found I'm not like a [00:03:00] functional diehard, like a lot of devs are, but I do think that I go out of my way heavily to write code that is like very functional. I'm even hesitant to use a case statement or something. A lot of the time we're like, I'll break something out into a function, even if I'm adding additional lines, just because I know I don't have any extemporaneous state at all.

There's zero mutations here. If I can just go into a function and I think that TypeScript. Tends to point me that way. It wasn't like a conscious thing when I started using it, but it it just feels the inference is smarter. Like it makes me even more hesitant to like mutate at all. It's no, everything needs to be static.

Like I just know what's going on.

Matt Pocock: Definitely. And every function you feel really good about, because, you've got you understand what all the arguments are strongly typed. And so you can capture stuff in that function and it just makes you feel warm and fuzzy. Really? There's not that much kind of global stuff that you can interact with if you don't need it.

And and also I'd say that. It's also pretty hard to type this, for instance, in TypeScript, [00:04:00] and it's certainly possible, but it's just not very idiomatic, and so you end up not using that much in terms of classes, in terms of this on objects and this in functions and stuff, just because it's a, it's just easier just to type a function and have a function and just do it in the normal sort of way.

Quasi functional way.

Noel: Yeah. And there's probably something there. Again, I've never been like a huge, a person that like is super reliant on the object oriented paradigm. So I'm probably not very well equipped to speak to that either. But I guess if you encounter people that have, that were like, have operated in that way for a very long time, they're very familiar with it.

It's how they expect code bases to look when they're in them and they rub up against this, Suggestion the TypeScript is making, or it's preference towards having code that works this way, just in ease of the dev experience. And that kind of be a point of I don't know, just friction for them at all.

Matt Pocock: I think it's easy to look at TypeScript from the surface and say, Oh, I see TypeScript has it has native support for enums. So it has native support [00:05:00] for interfaces and classes. Oh, that's interesting. Oh, the guy who made TypeScript, he's, he made C sharp, didn't he? So I see. So it's like a C sharp in JavaScript, but it's.

And that might, it's often the opposite. Actually. Often people say, like this is way too object oriented for me. This was an early criticism of TypeScript. It was like, no way, man. It's just C sharp and JavaScript. And I've had to field that opinion as well, but it's not, it's just not like it's, if anything, like TypeScript, I think probably interfaces might not be added, no interfaces probably will be added for various reasons, but enums wouldn't be added, I think classes, if they didn't exist already in JavaScript.

Wouldn't have been added in TypeScript. So yeah, I dunno, that criticism sort of rings a bit hollow to me, but it's gotten a lot more flexible and I think TypeScript's job really these days is just to describe JavaScript and just to what JavaScript does, and it's doing a great job of that at the moment.

Emily: Next, we [00:06:00] had Minko Gechev, head of product for Angular at Google, who came on to talk about the evolution of Angular over the years and how he sees it changing in the future. Here, he talks about how competition has helped keep Angular growing.

Tejas: As Angular has grown in, seven times in the past five years and so on, it's grown also in the face of competition, right?

And I don't mean competition negatively, I just mean there's a lot of options nowadays, especially around things like solid selt kit selt. Quick and react, of course. I'm curious, how has this competition influenced Angular? I know for example, that you're moving from zone js to signals, and I'm assuming this is because of the competition with solid, but I'm curious how else the competition has affected Angular and its development.

Minko: Yeah. I love that you're bringing it up. And also I love that you're positioning like competition and just having different alternatives is something good. Not necessarily bad because I see how the community often thinks that framework alters there spending their [00:07:00] time in the. Like a dark basement trying to compete with everyone else in heating water frameworks, which is definitely not the case.

We've had Ryan ero from solids given, give us a talk about their activity model. We had Rich Harris talk about sve. us like, so we are in touch. Like we discussed hydration recently with him. We had Evan New and obviously Mishko who built Quick, was very heavily involved in the initial design of Hangar.

Yeah, we're talking to all these people and. We're learning different things from each framework. For example, when we were evaluating the different, like we wanted to change the dangerous activity model because we saw that zone just might not be the most optimal thing because of the way it operates.

It just assumes that we're going to be performing global change detection. We started researching different alternatives and we have also always we already have a compiler, so we're thinking should we just make our compiler a little like. More [00:08:00] sophisticated so it can track dependencies at build time or, and this way we can have a runtime reactivity that is supported by this compiler, or should we just keep it the way it is?

Compiling templates to very efficient instructions and using alternative reactivity primitive, such as signals because, Why not? Or should we use signals in the way that they're being used in solid? Or should we explore something more with proxies instead? So we just explored this activity space.

We learned a lot from different frameworks, from solid, from felt. We learned a lot from view, like all these frameworks which have already really well established patterns for reactivity. And we try to put these reactivity concepts. Into the context of Angu and see how they fit the Angus mental model and Angus change detection and what is going to be the most efficient, the most like performance and developer like ergonomic thing for us to do.

So we decided to go with signals. [00:09:00] That's one example where we drew a lot of inspiration from solid jazz, for instance. And this has been an ongoing process. We're looking to how it can improve the anger altering experience because we got feedback from one of our developer surveys that this is a good opportunity for us to modernize the.

Altering experience for components. We have been looking at the entire framework space and evaluating the tradeoffs for each individual altering format and figuring out how it fits the anchors principles. So one of the minor changes that we did recently, I'll say it's minor just because just changing the control flow statements like our NGF and NG four are now going to look a little bit more People are saying that they look a little bit more like selt, but I'll say that they look a little bit more like the temping formats that inspired SELT in the past. So it has been just like a cycle over time where different concept just proved to be successful over time [00:10:00] by being adopted by next generation technologies.

Emily: And finally, we welcomed on Michael CTO of Variant, who came on to talk about how React architectures have changed and will continue to change in the future.

Mikael Brevik: But I think it's at some point, architecture wasn't a big part of frontend because it was just fragments of code running on the frontend in addition. So there weren't getting need of architecture in a broader sense, but also after a while, when moving over to the client in more sense, we get more code and more needs to structure it and do more with it.

And at that same point, I think just by happenstance or something, but also the functional paradigm was at a rise. So thinking more about it at bot at the functional pot patterns in a way. So it's just happened to coincide, but I also think that it's. One of the reasons is that the web and how the statelessness [00:11:00] of the web functions is also something that's good to model , in the functional aspect.

So I did some talks about this for instance, at JSConf Budapest, I think in 2015, I tried to see that if we're structuring our code as composable bits of components, essentially we can. Build complex applications on top of smaller iterations or smaller fragments of code, which is like the functional manifesto in a way, but yeah, so I think it's. A merging of two thoughts that's fits together in a way. I

Noel: Yeah, do you feel it's kind of, uh, the languages the languages or frameworks, sorry like react or, it's very similar. Do you feel that they're inherently functional at least today and that they, mingle with state where they need to, like inputs and stuff like that.

But do you think that the frameworks are encouraging devs to write functional code inherently? Or is it still something that needs to be[00:12:00] consciously thought about?

Mikael Brevik: think it's getting a bit more pragmatic at least. So I think when the flirtatious period with functional program was at its strongest, when we were doing functional lenses and cursors and then immutable data structures, that's simulating how like applicative functures means and whatever, like all the.

The terminology and all the academic things from the functional programming world was at its strongest, I think is where. More likely to be guided toward that thought and that architectural patterns. But I think that's regressed in the later years. So for instance, now we're having, yes, you can say it's like a functional aspect pro in, in, in a way, but it's more pragmatic.

You have more escape hatches. in different ways. Fundamentally, it's functional. But it's not as important [00:13:00] to know that it's functional in a way.

Noel: got it. Yeah, I think, that's probably a very concise way to put it, like a highly pragmatized functional kind of framework is interesting , how does this play into what you cover in your talk? , is this shift what you're talking about? Or is there more to it?

Mikael Brevik: Not really. So the main parts of functional that we're still striving towards is determinism in a way. So how to produce applications that are inherently. Like foreseeable or something that you can say that this is guaranteed to be this value, or this is something that's I can stand for in a sense.

But I think that's just like the kind of , the web taking its direction or taking its paradigm in 2013 ish react world. I think that this is how we're supposed to think about it. , I think maybe my key takeaway to start with that is that we're doing a lot of things in the front end world that [00:14:00] also seems like there's a lot to do and a lot to think about, but it's variation of the different concepts that's explored user land, as I call it.

Emily: And that's it for today, Friday, August 11th.

You can check out the full episodes linked in our show notes or on our feed. And if you like what you hear, follow PodRocket for more great web development content. See you at the next roundup. This episode was brought to you by LogRocket. Try it for free at logrocket. com.