Speaker 1: Hello everybody, and welcome to another exciting episode of JavaScript Jabber.
Speaker 1: Today on our panel, we've got a j O'Neil how aj.
Speaker 2: Yo yo yo, coming at you live from the Shed.
Speaker 1: The Purple Room, the Purple Room, and.
Speaker 3: Steve Edwards yo coming at you from a how's always
Speaker 3: cool and cloudy Portland this time of year?
Speaker 4: Wow?
Speaker 1: Here in tel Aviv it's well, it's effectively summer really,
Speaker 1: So we've got two great guests with us this week.
Speaker 1: We've got Ariel Schulmann and we've got Liran Tal Say
Speaker 1: hi to our listeners please.
Speaker 5: Hey, how's everybody going live from Tel Aviv? Which is
Speaker 5: again summer here now?
Speaker 4: So jealous?
Speaker 3: Yeah, we got like really want we got to tease
Speaker 3: really two really warm days last week during the kids
Speaker 3: spring break, and then went back to the cool and rainy,
Speaker 3: which it's great for skiing, didn't snow up on the mountain,
Speaker 3: but not so much for everybody else.
Speaker 5: We had two rainy days.
Speaker 1: Yeah, this year we hardly had any any winter really,
Speaker 1: it was mostly summer all year long.
Speaker 4: This year. I'm kind of springish.
Speaker 5: Just the best part of global warming. When the winter
Speaker 5: is warm, it's enjoy.
Speaker 1: Yeah, so putting the weather aside, Uh, we are here
Speaker 1: to talk about typescript.
Speaker 4: I guess in the context of oh no.
Speaker 5: Already we're already going to start fighting.
Speaker 4: Yeah, typescript.
Speaker 1: But I guess in the in general or in the
Speaker 1: context of security, maybe both, maybe both. So I think
Speaker 1: like everybody knows what typescript is, and from what I've
Speaker 1: been experiencing and seeing, everybody is more or less using typescript.
Speaker 1: I'm hard pressed to think about projects that don't use
Speaker 1: typescript unless they're really legacy projects. Any new projects seems
Speaker 1: to be written in typescript. Does anybody disagree with this statement?
Speaker 5: Absolutely secure standard.
Speaker 4: Please in the enterprise space, even not in.
Speaker 5: The enterprise base, I would say that even small projects
Speaker 5: tend to start with typescript now for the sake of
Speaker 5: the developer experience.
Speaker 1: Well, for the sake of AI, because you use an
Speaker 1: AI tool to generate your code and it generates it
Speaker 1: in typescript.
Speaker 6: I think before that, though, like you had, like even
Speaker 6: starter projects, like the default for like astro, if you
Speaker 6: wanted a blog would be like defaulting to typescript, and
Speaker 6: you know things like that. So you'd think a framework
Speaker 6: or some library and like it would default you to typescript,
Speaker 6: and I think it would be if you weren't doing
Speaker 6: typscript before, you'd like have to mess around with it
Speaker 6: to figure out how to like don add to typescript here,
Speaker 6: which maybe I know because I'm not naturally a typescript
Speaker 6: but yeah, I also do agree like the typescript that's
Speaker 6: kind of like taken over the system, and I think
Speaker 6: that's okay.
Speaker 4: Oh yeah, by the way, it just said that you
Speaker 4: switched audio devices for some reason, do you hear me?
Speaker 1: Yeah, yeah, yeah, it seems it's not coming through your
Speaker 1: microphone anyway. Uh. Probably the only scenario where I'm probably
Speaker 1: unlikely to use typescript would be if I'm doing something
Speaker 1: like a lead code interview. Uh, and then I you know,
Speaker 1: in that type of a situation, I probably just.
Speaker 6: Use photo, which is JavaScript essentially.
Speaker 1: Yeah, like you you're going for speed rather than for
Speaker 1: type safety.
Speaker 6: I mean, I can I can tell you why some
Speaker 6: of us maintainers hate the divescript part, which is for debugging,
Speaker 6: which was a long time pain for debugging like currently
Speaker 6: installed libraries like they're already like you know, went through
Speaker 6: like the build phase and they're electron spiled and it's
Speaker 6: it's a mess debugging it. So that was something that
Speaker 6: was like, I mean, it's still kind of painful, but
Speaker 6: as a maintainer or as a as a dev have
Speaker 6: to maintain within the note modules package for older you,
Speaker 6: you'd kind of get lost and really want to reap
Speaker 6: all your herd out just because of it.
Speaker 5: Even though now everything changes.
Speaker 4: Yeah, yeah, I.
Speaker 1: Think we're on a better trajectory now a real We're
Speaker 1: still not on your microphone though, I think I.
Speaker 5: Need to lock out and knock back, and.
Speaker 6: It's the JavaScript microphone.
Speaker 5: See see typescript bug. And I'm gonna log out and
Speaker 5: log back in.
Speaker 1: No problem, We'll be waiting for you. So yeah, I guess.
Speaker 1: I guess that's true in in the sense that whenever
Speaker 1: you like, I think we had guilta yao on the
Speaker 1: show like a long time ago, speaking about that very
Speaker 1: fact about why he actually used to prefer jas doc
Speaker 1: over over you know, using typescript because he wanted to
Speaker 1: avoid the transpilation on the note side. His argument was
Speaker 1: that on the browser side, you're going to have transpilation
Speaker 1: anyway because of the bundling, because of JSX, so you
Speaker 1: might as well do typescript as well. But on the
Speaker 1: note side, where you could have just run the code
Speaker 1: as you wrote it, Transpiling never adds value in that sense,
Speaker 1: and I totally agree with that.
Speaker 3: Well, I don't know if you remember the whole big
Speaker 3: stink that's Vell basically did that exact same thing, where
Speaker 3: they've had a whole big announcement about we're getting rid
Speaker 3: of typescript and what they started doing with jastocks, and
Speaker 3: we talked to Rich Harris about them.
Speaker 5: I think we can maybe draw the line because jstocks
Speaker 5: is still typescript. Okay, there's typescript as a language as
Speaker 5: a developer tool, and there's Typescript as the transpiler, and
Speaker 5: you can enjoy typescript on your ID even without transpiling,
Speaker 5: which is what j stocks does, you're still writing Typescript.
Speaker 2: They are fundamentally different languages. JavaScript has a type system.
Speaker 2: It has a finite set of types, and there's things
Speaker 2: that you can and cannot do with those types. Typescript
Speaker 2: as a version five has become much better at dealing
Speaker 2: with JavaScript types. But Typescript was designed to deal with
Speaker 2: C sharp types and to apply them to a browser,
Speaker 2: and so the pattern of code that you get with
Speaker 2: Typescript versus JavaScript is radically and wildly different. You cannot
Speaker 2: easily write simple programs and typescripts, certainly not with AI,
Speaker 2: but you can write simple programs in JavaScript because JavaScript
Speaker 2: does not require complex type hierarchies and JavaScript type system
Speaker 2: is not turing complete.
Speaker 5: But wouldn't you say that large systems have large type
Speaker 5: hierarchies and require applications contexts.
Speaker 2: Why would they? Why would you need to have large
Speaker 2: type hierarchies. That's the design flaw, that's not something inherent
Speaker 2: of the system.
Speaker 4: I mean, look at GO.
Speaker 1: I think the large type hierarchies were an attribute of
Speaker 1: Typescript in the early days, where indeed the language was
Speaker 1: kind of directing you toward building class hierarchies. All the
Speaker 1: examples at least were written that way. But I think
Speaker 1: people are not have not been writing Typescript in this
Speaker 1: way for a while now. Most of the typescript code
Speaker 1: that I'm seeing can be thought of as JavaScript with
Speaker 1: static types. People are not building these huge collections of classes,
Speaker 1: and then with implementing interfaces and building Typescript that way.
Speaker 1: I'm just not seeing it now. It might be because
Speaker 1: of React, because React went with hooks rather than with classes,
Speaker 1: or it might be that people just discover that they
Speaker 1: could use typescript in a more JavaScript sort of way.
Speaker 4: I don't know.
Speaker 1: Maybe it's a combination of both, but that's the reality
Speaker 1: that I'm seeing.
Speaker 5: I think there are also two like there are many
Speaker 5: ways to use typescript. Yeah, you can take it in
Speaker 5: the very c sharp like old schoolp way, but you
Speaker 5: can also use typescript as just a tract maker, just
Speaker 5: to define a contract that a function expects some contract
Speaker 5: as an input and expects to return some other type
Speaker 5: as an output, which is like defining contracts. And you
Speaker 5: can also use typescripting like in a higher level, which
Speaker 5: is to create an applications context. So if I have
Speaker 5: a function that accepts a name and an ID and
Speaker 5: another function that accepts an object with a name and
Speaker 5: an ID, I can say that both functions accept the
Speaker 5: type of person. And by doing this, I created a
Speaker 5: context between these two functions. And I think that is
Speaker 5: kind of what's big about typescript. And do you know,
Speaker 5: do you guys know how typescript like, how did it start?
Speaker 5: How did that start?
Speaker 4: It? I will let you talk about that.
Speaker 1: And by the way, there's a documentary about that but
Speaker 1: before that, I do have to mention that these days
Speaker 1: in Node we do have a building support for type stripping,
Speaker 1: which effectively just erases the type out. So that means
Speaker 1: that we can now use typescript files without transpilation with Node.
Speaker 1: We don't have to use js doc for that purpose anymore.
Speaker 5: It's transpiled internally like it is still transpiled. It uses
Speaker 5: an SWC plug in like it just transpis it internally
Speaker 5: inside notes. The code has.
Speaker 1: Transponed obviously because at the end of the day, Node
Speaker 1: is using v eight, which is a JavaScript engine.
Speaker 4: It's not a typescript engine.
Speaker 1: So it needs But it still means first of all,
Speaker 1: the transpilation is basically just erasing the types. It replaces
Speaker 1: the type declarations with white spaces, and the as I said,
Speaker 1: the interesting or the useful aspect of it is that
Speaker 1: you can use the same source files. You don't need
Speaker 1: to go through a transpilation step before loading the files
Speaker 1: into Node. What you used to need something like tis
Speaker 1: snowed for in the past. You can just do it
Speaker 1: with Node itself now. And obviously you can do the
Speaker 1: same things with bun and Dino, So it means that
Speaker 1: you don't need that the source maps to be able
Speaker 1: to single step to the files anymore. You can just
Speaker 1: use those files as is the same way that you
Speaker 1: would with let's say, Jase doc. I'm just putting that
Speaker 1: up out there. But now going back to your point
Speaker 1: about that history of typescript that you were alluding.
Speaker 5: To just then, because for the haters, So the reason
Speaker 5: why typescript was even a thing, Anders was supposed to
Speaker 5: be joining the vis Co team that they were developing
Speaker 5: viskode in JavaScript, and the moment he joined the team
Speaker 5: and joined the effort, the first thing he suffered from
Speaker 5: was it's impossible to really refractor without the context. And
Speaker 5: he was like, guys, we haven't much bigger problem here,
Speaker 5: and that's kind of how we started off building typescript
Speaker 5: in order to help developers develop and out of his
Speaker 5: own pain as as a developer. So like these days,
Speaker 5: it is a human tendency when when we have something
Speaker 5: to be when we have a pain, so to be
Speaker 5: focusing on the pain. But there are a lot of
Speaker 5: things that we do get a lot of value from typescript,
Speaker 5: and there are trends, it's true, but I do think
Speaker 5: that there is a reason why this is an industry standard.
Speaker 1: I think the bottom line I think is that to
Speaker 1: the great to a great extent from again, from what
Speaker 1: I'm seeing, but I'm the simple size is relatively large,
Speaker 1: is the typescript one. I'm seriously not seeing any significant
Speaker 1: new projects being started in JavaScript.
Speaker 4: None.
Speaker 1: It's not like one or two or here or there,
Speaker 1: truly none. Every new project that I'm seeing is starting
Speaker 1: being started in typescript.
Speaker 6: That's great, even more of a case to talk about
Speaker 6: the security aspects of it.
Speaker 1: Okay, then do we want to talk to switch talk
Speaker 1: about that. By the way, I didn't introduce you to
Speaker 1: but because I forgot, but I think you both of
Speaker 1: you are coming kind of from the security space, right.
Speaker 5: No, no, no, not from the security space.
Speaker 1: Okay, then correct then please correct me? What space are
Speaker 1: you coming from.
Speaker 5: I'm a full sex developer. Typescript is my bread and butter,
Speaker 5: so I've been talking about typescript quite a lot and
Speaker 5: in the past two years. And it's also very exciting
Speaker 5: to see the massive shift that is happening now in
Speaker 5: typescript because the performance of Typescript has been a pain
Speaker 5: point in many projects for the past two years, and
Speaker 5: so it's just a topic that I really like, and
Speaker 5: I teach and I give workshops about so that's kind
Speaker 5: of why Duran invited me as the TS expert here.
Speaker 4: Okay, cool, and now about ju Leian.
Speaker 6: I'm a develop product at for Snake, so basically doing
Speaker 6: a lot of education and security research in the node
Speaker 6: and the travelscript space, I guess now effectively maybe officially
Speaker 6: in the typescript space as well. But the Areela helped
Speaker 6: me kind of like I think, sharpened some of these
Speaker 6: ideas and really try to frame them for tiptream developerss.
Speaker 6: I'm not, naturally, like I said, a type ship dev
Speaker 6: obviously going to adopt this more and more with the
Speaker 6: tooling and everything else. But it's it's been fun looking
Speaker 6: at it coming from I think fresh eyes to look
Speaker 6: at these problems. And I've had some which we'll talk
Speaker 6: about here, I think, but I've had like my journey
Speaker 6: into this really started with sharing something on social well,
Speaker 6: and then like it got blown up as like a
Speaker 6: really long tread with like what's they dodge from express
Speaker 6: and stuff like that, and people lurking and asking questions afterwards,
Speaker 6: and it became clear, like very evidently clear. Also by
Speaker 6: doing a bunch of like social media polls that devs
Speaker 6: view typescript in a very specific way, yet use it
Speaker 6: in different ways. And the whole security part is it's
Speaker 6: kind of meshed in between, but not in a really
Speaker 6: good way. And that's kind of like I think the
Speaker 6: premise for a lot of this discussion here.
Speaker 4: So can you elaborate please.
Speaker 6: Yeah, So it's basically started. I obviously share like a
Speaker 6: lot of security related stuff and most of them is
Speaker 6: like snippets and kind of like say, hey, this is
Speaker 6: like there's a security issue here, can you spot it?
Speaker 6: And stuff like that. And while we're on a medium
Speaker 6: that's like not really easy to share a code snippet,
Speaker 6: I can very clearly explain it. You don't have to guess,
Speaker 6: so we can fucture it together. But it basically a
Speaker 6: function for a template engine on a node not not
Speaker 6: in Typescript at that time. This is like ten years
Speaker 6: old or so. But it's basically something that escape htmls
Speaker 6: HTML characters. And the function has this type guard where
Speaker 6: it starts with like if type of you know some
Speaker 6: string that I'm getting equals a string, then do something
Speaker 6: and replace the characters, like basically turning them into HTML entities.
Speaker 6: So it's effectively doing a sort of output encoding like
Speaker 6: your favorite you know, react a framework would do. And
Speaker 6: then there's like there's no else but but outside of
Speaker 6: the conditional. So if if it's not a string, it
Speaker 6: just exits it, and it's like, you know, returns the
Speaker 6: string itself without sanitizing it or escaping it properly. And
Speaker 6: so that's the that's the that's the that's the quiz. Basically,
Speaker 6: that's the challenge. So I was posting that picture and
Speaker 6: someone replied like typescript would have got this, and I
Speaker 6: was like immediately like I don't think so, like why
Speaker 6: would it have got this? And you know our social
Speaker 6: media and internet goes or like yes it would, and
Speaker 6: I was like, no, it wouldn't. And it became like
Speaker 6: a long tread on blue sky, and you know, Wesley
Speaker 6: thought was started. We discussed that, and I think that's
Speaker 6: kind of like the promise, Like that's how it got me,
Speaker 6: like why would it? And I was like actually testing,
Speaker 6: like let's let's say, let's let's get a nice vulnerable
Speaker 6: project up and running, run divecrip on it and see
Speaker 6: if it works.
Speaker 4: And the real.
Speaker 6: Premise for like what's going on under is, which I
Speaker 6: think it's it's an interesting think talking through the security
Speaker 6: kind of like landscape or surface of developers using divescripts
Speaker 6: and the actual real world vulnerabilities that come from it.
Speaker 6: Also ZOD related to it as as a building block
Speaker 6: is interesting. But my I think, I think what kind
Speaker 6: of like hits it on the nail. And that's something
Speaker 6: that's been very i think, very resonating with both me
Speaker 6: and Wesley, was that if it seems that developers kind
Speaker 6: of like you know, feel about typescript and put misplaced
Speaker 6: trust on typescript in the same way that they put
Speaker 6: misplaced trust on code coverage, meaning they think of it
Speaker 6: more than it should they should, and they think of
Speaker 6: it as a security tool. And I think that by
Speaker 6: itself is while touchscript is, you know, like any strongly
Speaker 6: type language is helpful, it's not a security tool by itself,
Speaker 6: and that creates a fallicy and that is something that
Speaker 6: I would like to to change and maybe should do
Speaker 6: this conversation on this, you know, on this session, I
Speaker 6: can give you several examples of why that happens and
Speaker 6: how that fails developers.
Speaker 1: The fact that you said that people put trust in
Speaker 1: code coverage in the context of security reminds me of
Speaker 1: that old joke about QA and engineer working for a
Speaker 1: bar and ordering one beer, ordering zero beers, ordering million beers,
Speaker 1: ordering a hammer, ordering a ray, ordering yeah. And then
Speaker 1: and then the first customer walking in asking where the
Speaker 1: toilet is, the bar blows up and kills everybody inside.
Speaker 4: And the one yeah.
Speaker 1: So so that that grows to show like.
Speaker 4: The value of unit testing.
Speaker 1: Let's say, in the context of app of application security.
Speaker 1: I mean, I guess it's it's better than nothing, but
Speaker 1: but not by much.
Speaker 5: There are a lot of controversial posts about I wouldn't
Speaker 5: mention the name, but how teams replaced a lot of
Speaker 5: unit tests because they have typescript.
Speaker 4: Now, m.
Speaker 5: On that.
Speaker 4: If the unit test is there, why replace it?
Speaker 6: I mean time, I'll give you no better. Let me
Speaker 6: like you build another one on our else. Take. Now
Speaker 6: we said like if you have a typescript, then you
Speaker 6: maybe don't need tests. Well how about this. I have
Speaker 6: a take where someone said we don't need zoo if
Speaker 6: we have typescript and stuff like that. That's that's you
Speaker 6: know that, that is where this is happening. And this
Speaker 6: isn't like a random person, you know, getting pulled out
Speaker 6: of like ten thousand. There's a lot of confusion. Let me,
Speaker 6: let me pull up something. Wait, let me So I've
Speaker 6: pulled and I was was asking, when do you work
Speaker 6: on typescript code base? What is your level of ecosystem depth?
Speaker 6: And I gave three options. One is just typescript and TSC.
Speaker 6: The way that, for example, maybe I would use it
Speaker 6: as like a beginner you mean for type checking the man, yes,
Speaker 6: just type checking. You just you know me as a
Speaker 6: bit like I said, I'm beginner developer with typescript easy
Speaker 6: you know, you know, adapter for it. And the way
Speaker 6: that I would just like, you know, type my of course,
Speaker 6: have like a typing system type my data parameters and
Speaker 6: run a typescript checker compiler for it. So this is
Speaker 6: option one, and like fifty four percent of developers chose
Speaker 6: that one. The other two options was typescript and type
Speaker 6: narrowing also known as type cards, And the third option
Speaker 6: was typescript and narrowing and ZOD. And obviously, I think,
Speaker 6: like among the other experts here on typescripts like maybe
Speaker 6: more that you could pull into the ecosystem. But I've
Speaker 6: read this pollic quite a few times and it's always
Speaker 6: the same answer, like at least half of the people,
Speaker 6: if not more, really just us typescript as the compiler
Speaker 6: and the checker, nothing beyond it.
Speaker 1: Look putting ZOD for a site for a minute, and
Speaker 1: I think that would actually be the crux of our discussion.
Speaker 1: But before we dive there, type narrowing to me is
Speaker 1: part and parcel of typescript. I don't see the exact
Speaker 1: difference between number one and option number one and option
Speaker 1: number two, like you said, just typescript versus types of
Speaker 1: the type narrowing. How is type narrowing not just part
Speaker 1: of typescript?
Speaker 5: It means if you do runtime checks about the times, Yeah.
Speaker 1: I understand, I understand what oh you mean, like specifically
Speaker 1: doing lots of tests using type of exactly constructor equals
Speaker 1: and stuff like that exactly and which.
Speaker 6: Is not dipescript, you will even if you just do
Speaker 6: pure JavaScript. But I think that's you see, But that's
Speaker 6: that's the exact fallacy. Like developers don't they think they
Speaker 6: don't need to do this runtime security of type of
Speaker 6: even before we go to that, like you said, because
Speaker 6: they use a type system, because the compiler is fine.
Speaker 6: And someone gave me a screenshot where they show me that, uh,
Speaker 6: the request imagine like let's talk let's talk back end
Speaker 6: and servers and express and typescript, okay, because that's like
Speaker 6: the easiest uh you know attack surface here. So if
Speaker 6: you use that, you have a type request, right, and
Speaker 6: the request may get like requests or filter strings and
Speaker 6: stuff like that, like maybe a filter and maybe that
Speaker 6: is typed as a string or something like that, and
Speaker 6: then all the types that kind of like you know
Speaker 6: that string is is flowing through the code flow to
Speaker 6: the code path in different functions. And they show me
Speaker 6: and they say, hey, you know what, I can't even
Speaker 6: write a vulnerable function because it only accepts types and
Speaker 6: typescript safety because of the compiler, and I would find
Speaker 6: it on CI and I was like, no, it's won't
Speaker 6: because like runtime is not dev time. You can't make
Speaker 6: that assumption.
Speaker 4: Even dev time is not dev time.
Speaker 1: And I'll touch on that in a second, but yeah,
Speaker 1: I think that's the key point that we need to
Speaker 1: explicitly make. In case it's unclear to anybody who's actually
Speaker 1: listening to the podcast, pypescript type checking is done only
Speaker 1: at build time. It is it has zero impact on
Speaker 1: runtime Pipescript does not do any type checking at runtime.
Speaker 1: And that's an intentional feature of Typescript. It's not a bug,
Speaker 1: it's a feature. That's how Typescript is built intentionally. So
Speaker 1: anybody disagrees with this statement.
Speaker 5: I like it. When I give talks about Typescript, I
Speaker 5: like to talk about the development space, and I call
Speaker 5: it the development matrix because in run time, which is
Speaker 5: the real world, like, the types don't exist. And it's
Speaker 5: kind of because a lot of us are really as
Speaker 5: we said, it's standard, and projects start off with Typescript,
Speaker 5: and people that are beginner developers they see that you
Speaker 5: can define what shape of an argument it's going to be.
Speaker 5: It is quite confusing at the beginning to make the
Speaker 5: difference that the code that you see as the developer
Speaker 5: is not the code that would run. And that confusion,
Speaker 5: that matrix is really the root of all of it.
Speaker 5: And we can even take it to many other spaces
Speaker 5: in development these days, when things are layers over layers
Speaker 5: over layers, develop beginner developers see the upper layers and
Speaker 5: not everything that composes underneath. So I think this podcast
Speaker 5: is finally important for any beginner developer listening that might
Speaker 5: be confused about it.
Speaker 6: I think experience developers who are like fifty typescript poll, well.
Speaker 1: You know, whenever we whenever anybody speaks about experience or
Speaker 1: senior developers versus junior developers, I'm reminded of the fact
Speaker 1: that every like poll about JavaScript shows that the Java
Speaker 1: the median experience the JavaScript developer has is something.
Speaker 4: Like three years.
Speaker 1: So half the developers have less than three years experience.
Speaker 1: So half the developers would be considered junior, I guess,
Speaker 1: but at least half. But going back to the key
Speaker 1: point is we were talking about how Node now supports typescript.
Speaker 1: It supports Typescript by type stripping, So I think that's
Speaker 1: the best way to think about it. The run time
Speaker 1: of typescript is just all the types gone. That's the
Speaker 1: run time of typescript. It's that's the JavaScript that comes out,
Speaker 1: and that's key to understanding this aspect. But going back
Speaker 1: to what you said about the developed the safety at
Speaker 1: the time of development, if that's a bit of a fallacy,
Speaker 1: or let's put it differently, it's a fallacy if you
Speaker 1: have any any in the code, because once you've got
Speaker 1: even a single any in the code, anything that goes
Speaker 1: through that comes out of the other side without that
Speaker 1: type context, and then it might have been a string
Speaker 1: coming in, but it can be a number coming out
Speaker 1: and that kind of propagates throughout the code like a
Speaker 1: single any can have a wide ranging impact across your
Speaker 1: code based depending on where it is in the code.
Speaker 6: Taught because I was doing the exact same thing in
Speaker 6: my in my slides for I have like an upcoming
Speaker 6: talk on this. So I was doing the same thing
Speaker 6: and I was like, oh, rel, I need your help
Speaker 6: reviewing this our dipecript expert, and she was like, Okay,
Speaker 6: you're using any here. You know, like a lot of
Speaker 6: beginners and sorry, a lot of experienced users of typescript developers.
Speaker 6: We'll see it and we'll tell you it's it's it's
Speaker 6: like a basic problem.
Speaker 5: It's a bad practice.
Speaker 6: Yeah, like don't do it. And I was like, okay, fine,
Speaker 6: let's not do it. Let's I'll put I'll put string
Speaker 6: and I'll use the I've used requests, you know, request
Speaker 6: body or request quarry. That's that filter as string too,
Speaker 6: But that fails too, Like that will not save you either.
Speaker 6: Whatever you type it.
Speaker 1: That's when you say, as you're basically telling typescript. Trust me,
Speaker 1: you don't, you can't figure out what the type is.
Speaker 1: Then consequently I have to tell you, and I'm telling
Speaker 1: you that it's this, and you've got to trust me
Speaker 1: on that, and maybe you're right and maybe you're wrong.
Speaker 1: But but it's kind of like sort of a it's
Speaker 1: it's time. It's typecasting, and typecasting is unsafe in every
Speaker 1: language that supports it, but not just not just typescript.
Speaker 5: And it's also inevitable, like because the alternative would mean
Speaker 5: that you don't have a way to when it is
Speaker 5: necessary to detail typescript. What is it?
Speaker 4: Yeah, for sure.
Speaker 1: I recently I'm working on we were talking about existing
Speaker 1: code bases that are in JavaScript. I'm one of the
Speaker 1: projects that we have at work is a fairly large
Speaker 1: legacy JavaScript code base, but it's still under development. So
Speaker 1: there's value in migrating it to typescript, but it's going
Speaker 1: to take a long time. I was looking at a
Speaker 1: piece of code and I was kind of forced to
Speaker 1: do as are known as X.
Speaker 4: So I have a.
Speaker 6: Question, is that is that a bad thing? Like should
Speaker 6: I not use as string for example?
Speaker 4: Well, so here's the story.
Speaker 1: So I was I was want to do something, and
Speaker 1: the only way I could get the code to compile
Speaker 1: was doing something like as a known asterisk, which annoyed
Speaker 1: the heck out of me because why do I have
Speaker 1: Because when I do something as unknown.
Speaker 4: It feels like I feel like dirty.
Speaker 1: So I reached out to the number one typescript expert
Speaker 1: that I know, which is Matt Pocock.
Speaker 4: I assume you've heard.
Speaker 1: Of him, and I told him I'm doing this disgusting
Speaker 1: thing in this code snippet over here. Do you have
Speaker 1: a suggestion for you know, something nicer than I could do?
Speaker 1: And he said, if that, what, if that, what's work?
Speaker 1: Just go with it? Because because he said, don't don't
Speaker 1: overthink it. If it's localized, if it's small, if it
Speaker 1: gets you, if it gets a job done, just go
Speaker 1: with it. So so, yeah, sometimes you know it exists
Speaker 1: for a reason. The language supports this idiom because it's needed.
Speaker 5: There are no way bad practices, there's only a context.
Speaker 6: For sure, well kidding.
Speaker 2: The typescript checker does get better, Like version four was
Speaker 2: very very bad at understanding JavaScript types. Version five is
Speaker 2: incredibly improved and understanding those And I think that as
Speaker 2: it goes forward, I would hope that there will be
Speaker 2: a point when the idea of typescript would just be
Speaker 2: redundant because if the Typescript checker gets better and better
Speaker 2: and better at doing JavaScript, then you wouldn't need something
Speaker 2: like any because it would just be able to introspect
Speaker 2: and look at the code. See what she returned.
Speaker 4: See.
Speaker 2: You know, there are some idioms you have to follow,
Speaker 2: Like you can't just willy nilly add a property on something.
Speaker 2: You need to use object out a sign if you
Speaker 2: want to add a new property that didn't exist before.
Speaker 2: But if you use object out a sign, for example,
Speaker 2: whatever comes out on the other end of that. If
Speaker 2: you add something with name, age, and birthday on one
Speaker 2: side and you do object out of sign social security number,
Speaker 2: the object you get out on the other side now
Speaker 2: is correct and it will have all four properties on it.
Speaker 2: So there's a lot of stuff that that as as
Speaker 2: time goes on. I think that the reason ay exists
Speaker 2: is I believe just because Typescript started out not to
Speaker 2: be a JavaScript type checker, but to be a new language.
Speaker 2: And and as that gets closer and closer to how
Speaker 2: JavaScript works, yes, you'll still need to do annotations, and
Speaker 2: you know to some degree, but I think it it
Speaker 2: could get. It could get as good as zig Let's
Speaker 2: say that.
Speaker 1: Yeah, but here here, here's the thing, though, I agree
Speaker 1: in the sense that the basically what I understand that
Speaker 1: you mean by Typescript understanding JavaScript types is that the
Speaker 1: static analysis mechanism has become much better. It can track
Speaker 1: the type. You know, JavaScript has very dynamic and malleable types.
Speaker 1: It can track these things and figure out what's going
Speaker 1: on and basically assign the accurate type at build time
Speaker 1: based on what it figures out that the run time
Speaker 1: will be. But there's a limit to how much you
Speaker 1: can figure out with static analysis. It's not my area
Speaker 1: of expertise. I'm not a compiler or type system expert.
Speaker 1: I think what the people at working on typescript have
Speaker 1: achieved is pretty remarkable, a lot more so than people
Speaker 1: give them credit for. It's much more sophisticated than the
Speaker 1: type analysis that's built into a lot of typed programming
Speaker 1: languages statically type programming languages. But there's still a limit,
Speaker 1: especially given that JavaScript itself is like the poster child
Speaker 1: for dynamic types. It's like everything in JavaScript is as
Speaker 1: dynamic as it can be. So what Typescript does I
Speaker 1: like to The analogy that I like to use is
Speaker 1: that it's like hurting cats, and there's a limit to
Speaker 1: how much the cats will respond to your your instructions.
Speaker 4: Exactly.
Speaker 2: But it's kind of like JavaScript the good parts, right,
Speaker 2: Maybe we need a JavaScript the type parts, because certainly
Speaker 2: you can't use every feature of the language and have
Speaker 2: a coherent type system.
Speaker 1: It's kind of happening. It's kind of happening naturally, because
Speaker 1: what I've seen, what I'm saying is that certain JavaScript
Speaker 1: idioms that were really, you know, fairly commonplace when people
Speaker 1: were writing in straight on JavaScript, were less typescript friendly.
Speaker 1: And now these days, where everybody is essentially writing typescript,
Speaker 1: these idioms are not being used anymore, or alternative idioms
Speaker 1: that are more typescript friendly are coming along and replacing them.
Speaker 1: I'll give an example. In the past, we will you
Speaker 1: would create an object and then you would do if
Speaker 1: if something, then add property X to it. If some
Speaker 1: other things add property why to it, And typescript doesn't
Speaker 1: really like that. It doesn't like the fact that you're
Speaker 1: adding a new property to something that is considered as
Speaker 1: a mpotent close kind of closed type. So people are
Speaker 1: starting to do things like they're spreading objects into the
Speaker 1: initialization just so that Typescript can better figure out the
Speaker 1: actual properties and type the actual properties that are associated
Speaker 1: with that particular type. It's kind of difficult to explain,
Speaker 1: you know, without actually showing code. Hopefully I've kind of
Speaker 1: made it clear. But when types are modified in run
Speaker 1: time using imperative code, it can be fairly difficult and
Speaker 1: sometimes impossible for typescript to properly track the type.
Speaker 5: The way the typeescript handles these things, by the way,
Speaker 5: the terminology for the static analysis is inferring when we
Speaker 5: talk about type the types of how typescript analyzed like
Speaker 5: does the setic analysis. So the terminology is inferring. But
Speaker 5: the thing about the way typescript handles types, it kind
Speaker 5: of takes the safe way. Okay, So let's say I
Speaker 5: have an If something happens, then add property A, and
Speaker 5: if something help else happens, then add property B. So
Speaker 5: the way type stript would infer this thing is that
Speaker 5: this object has both A and B like. I like
Speaker 5: to call it the shreddingers union. So it's both A
Speaker 5: and B like with only with the and the only
Speaker 5: way for you to narrow this down is within a
Speaker 5: certain scope to make an assumption. And that's also the
Speaker 5: reason for the pattern discriminated union. It maybe you guys know,
Speaker 5: so for the listeners that don't know what discriminated union is.
Speaker 5: So because of what I just explained, that types will
Speaker 5: take the widest type possible because in development time, it
Speaker 5: can't really know what would happen. There's a pattern called
Speaker 5: discriminated union. So if I have a union of types,
Speaker 5: so let's say I have a property or the property,
Speaker 5: the way for me to help type script and help
Speaker 5: it narrow it down is by adding an extra key
Speaker 5: that the key would not overlap any other keys in
Speaker 5: the union. So let's say, for example, I have property
Speaker 5: A is something, and then I would have key is
Speaker 5: true and then the other type I'm merging into I'm saying,
Speaker 5: or other types of property B, and I would say
Speaker 5: that the key is false. True and false don't overlap.
Speaker 5: So I can when whenever I check this object, and
Speaker 5: I would say if key is true within that scope,
Speaker 5: typescript knows the type narrow down. Typestrip knows which which
Speaker 5: type it isn't. That is kind of maybe like a
Speaker 5: new idiom for handling.
Speaker 1: Yeah, so That's one example. There are several such examples.
Speaker 1: The bottom line is that I'm saying that, especially again
Speaker 1: when I'm looking at older JavaScript code bases and I'm
Speaker 1: moving them to typescript. Ideally it should be just about
Speaker 1: adding types. In reality, what I am saying in that
Speaker 1: is that in a lot of cases, I, in order
Speaker 1: to add types in a way that is actually useful
Speaker 1: or sufficient, I end up massaging the code. It doesn't
Speaker 1: stay exactly the same.
Speaker 5: You can say the same thing about tests. How do
Speaker 5: you mean that sometimes you might find yourself changing the
Speaker 5: code to make it testable.
Speaker 1: Yes, although a lot of times when it happens, I'm
Speaker 1: really annoyed with it because it usually means that people
Speaker 1: are testing internal things that and then are exposing them
Speaker 1: to the outside just so that they can test them.
Speaker 5: Or just bad dependencies.
Speaker 2: Yeah, but the correct to the point earlier of the
Speaker 2: I already forgot how you called it that guards or
Speaker 2: the union, the discriminate discriminated union. So obviously this is
Speaker 2: something that people want to do. It's not something you're
Speaker 2: going to beat out of people. But metaprogramming is a
Speaker 2: code smell. There's a certain I don't know, I guess
Speaker 2: I'm not really a fan of dynamic programming. The way
Speaker 2: that I program JavaScript is the way that I program
Speaker 2: go And if you need something to return a different type,
Speaker 2: then you should just have a different function, you know, if,
Speaker 2: rather than have one function that handles many different cases
Speaker 2: and then have metaprogramming inside of the function, just split
Speaker 2: it out into separate functions.
Speaker 4: I'll give you an example, though.
Speaker 1: The common example, where the canonical example almost of where
Speaker 1: you see this sort of thing is where you have
Speaker 1: a function that has a success It returns either a
Speaker 1: success value or an error value with an explanation, and
Speaker 1: you've decided not to use exceptions, so you're actually returning
Speaker 1: an object that either has the result or has the error.
Speaker 4: So you would have a.
Speaker 1: Discriminating field saying that success or failure, and then based
Speaker 1: on whether it's success or failure, you would have the
Speaker 1: fields that are associated with the success in the object,
Speaker 1: or you would have the fields that are associated with
Speaker 1: the error, like the error code or the error text
Speaker 1: in that object, and you would use that discriminating field
Speaker 1: of success or failure to know what the other fields
Speaker 1: in there are.
Speaker 2: This is already been solved, though, Like we already have
Speaker 2: a tupule pattern for this, where the first element in
Speaker 2: the tupole is your success object and the second element
Speaker 2: in the tupol is your air object. So and you
Speaker 2: can return toopoles in JavaScript.
Speaker 1: Yeah, but again the reality is that in many cases
Speaker 1: you first of all, you're first of all you're correct,
Speaker 1: and also, like I said, you could just use exceptions instead.
Speaker 2: Yeah, and I think that that that's why I'd say
Speaker 2: that to me, sounds like an anti pattern. I know
Speaker 2: why people use the tuple, especially if they're coming from
Speaker 2: go or or Rust or another language where it's common
Speaker 2: to use tupuls to to emulate option types or result types.
Speaker 2: But yeah, I my my biggest question to be why
Speaker 2: aren't you using air handling to your best advantage.
Speaker 4: I'll give another example though.
Speaker 1: Suppose you have a reducer and you have the action
Speaker 1: and the data and data that you pass in varies
Speaker 1: based on the action. So again you would use the
Speaker 1: action field as a discriminator and then the other field
Speaker 1: and the object depends on the action that you're doing.
Speaker 1: There are a lot of situations in which this kind
Speaker 1: of in JavaScript, you would just pass an object in
Speaker 1: and then you would effectively do runtime introspection. To figure
Speaker 1: out what it contains. Typescript tries to add static type
Speaker 1: checking on top of that, and in JavaScript you could
Speaker 1: often make do without that discriminating field because you would
Speaker 1: just check whether particular property exists or not, like you
Speaker 1: know has on property, et cetera. Typescript encourages you to
Speaker 1: have this kind of discriminating field that is more explicit
Speaker 1: about it.
Speaker 5: Also, a question like the tuple has a lot of
Speaker 5: advantages to it. But wouldn't you say that if success true,
Speaker 5: like is a bit more readable than in place zero
Speaker 5: or in index one?
Speaker 2: No, Because you mean, if you're going to do that,
Speaker 2: you're going to do the deconstruction, right, So you're going
Speaker 2: to do let bracket result common error bracket equals. So
Speaker 2: from a readability perspective, I I don't know how it
Speaker 2: makes a difference, because I mean I have not seen
Speaker 2: anybody do it without deconstructing, right. So, first of all,
Speaker 2: it's not a pattern. It's not a pattern that's widely used.
Speaker 2: It's interesting, I there's a now they've got there's something
Speaker 2: in the pipeline for this pattern. I don't remember what
Speaker 2: it's called. But in the JavaScript standards right now, there's
Speaker 2: something in the pipeline for this, but it so that
Speaker 2: you don't have to do the square brackets and it's
Speaker 2: like it's like a special I don't remember what the
Speaker 2: syntax is, but it's like a special type of a
Speaker 2: weight where you where you get the ghost style slash,
Speaker 2: rust style old slash.
Speaker 6: You can just distract the error without the whole try
Speaker 6: catch block.
Speaker 2: Well, you can do that. You can still do that anyway,
Speaker 2: because you could just put a dot catch on there
Speaker 2: and then you can do if type of error.
Speaker 6: Yeah, that that proposal isn't Yeah.
Speaker 4: I know what you mean.
Speaker 6: I know that proposal is.
Speaker 2: It is it?
Speaker 6: And I think it's it's coloring that practice with the
Speaker 6: dot catch as as not a fancy one either, which
Speaker 6: is why it's proposing that you could like do the
Speaker 6: ghostyle for a bit.
Speaker 2: Well, I definitely hope that it fails because I don't
Speaker 2: think that's an idiom that we need to bring in
Speaker 2: the JavaScript amazing. I think we have the problem with
Speaker 2: JavaScript is it's everything to everyone and nothing for no
Speaker 2: one to.
Speaker 4: Be fair, and it's hard to get right.
Speaker 1: It's it's kind of it's kind of we're digressing, we're
Speaker 1: going down a rabbit hole. But I sent you brought
Speaker 1: us there. So I'm in contact on on X with
Speaker 1: one of.
Speaker 4: The with Rob Palmer.
Speaker 1: He's one he's like the co chair of the TC
Speaker 1: thirty nine. And he was talking about and he regularly
Speaker 1: posts about new things being added into into JavaScript, and
Speaker 1: he like titles it JavaScript excitement.
Speaker 4: Uh.
Speaker 1: And the last so I was kind of being intense
Speaker 1: intentionally facetious when the last time that he did it
Speaker 1: about like the entire year, and I said, and he said,
Speaker 1: like typescript excitement. And I said, I'm looking at your
Speaker 1: proposals and there's nothing much exciting here. And he was
Speaker 1: going like, like, how do you mean, And I said,
Speaker 1: because these are all like these are all like library functions,
Speaker 1: like you now have this extra method on type of
Speaker 1: string or this extra method on type of array. There's
Speaker 1: nothing like sorry left bad, left bad exactly. Uh.
Speaker 4: There's there's nothing like.
Speaker 1: Similar to when you added a sinka weight, or when
Speaker 1: you added constant let or when you added erow functions.
Speaker 1: And he basically responded seriously by saying, yes, we are
Speaker 1: intentionally winding down the amount of syntactical changes to the
Speaker 1: language that we are making. We are at this point
Speaker 1: in time of the maturity of the language where we
Speaker 1: really hesitant about adding new stuff into the actual syntax
Speaker 1: of the.
Speaker 5: Language, and they have Typescript now.
Speaker 1: Yeah, but look, there are certain proposals that a lot
Speaker 1: of people are pushing for and are still stuck maybe
Speaker 1: because of that stuff like the pipeline operator, which has
Speaker 1: been kind of waiting in purgatory for something like three,
Speaker 1: four or five years because it requires a significant change
Speaker 1: the syntax of the language. People have been talking about
Speaker 1: all sorts of pattern matching capabilities that aren't happening, again
Speaker 1: related to actually changing the syntax of the language. But
Speaker 1: again we really digressed, going back to your pointly run
Speaker 1: about the fact that the majority of the people assumed
Speaker 1: that not necessarily made it conscious assumption, but based on
Speaker 1: the way in which they write their code, assume that
Speaker 1: Typescript provides them with type security run type type security
Speaker 1: that it does not. And we talked about one fact,
Speaker 1: which is if you're using any in your code, and
Speaker 1: it's not such a weird pattern because again, if you're
Speaker 1: taking an existing code base and you're moving it from
Speaker 1: JavaScript to typescript, it's really hard to get rid of
Speaker 1: all the nis.
Speaker 5: It's also what it's for I must say that's what
Speaker 5: the type trip team. I say any is for.
Speaker 6: I will, yeah, but I will. I actually don't want
Speaker 6: to give people like a discount and say Okay, if
Speaker 6: you use any, then you get it. It's not that
Speaker 6: if you use as string, the same problem. If you
Speaker 6: use interfaces and you infer data or the aque you
Speaker 6: point to data from an interface, exactly the same problem.
Speaker 6: So I want to I'm here to like raise the
Speaker 6: awareness of typescript and its follicy and security. And if
Speaker 6: we just say that it's because you use any or unknown,
Speaker 6: then we fail that because whatever you use to type
Speaker 6: it on the typescript side of things. If you use interfaces,
Speaker 6: I don't know all your Union stuff, branded types whatever.
Speaker 6: Actually wait, Brando types has a in which this actually
Speaker 6: does work if you can like assert it on run time.
Speaker 6: But if you don't do that, and you'd still use
Speaker 6: interfaces and everything else, and you use as string and whatever,
Speaker 6: all of that fancy typing does not save you from
Speaker 6: having runtime security issues and type juggling vulnerabilities.
Speaker 1: Does that have to do only with when you're sending
Speaker 1: information over a medium like you know the network, or
Speaker 1: does it also just happen in your in the code itself,
Speaker 1: Like what's this sort of problem associated with?
Speaker 6: So obviously like the easy use case here, you can
Speaker 6: of like simulate this is where you want. And this
Speaker 6: is like a general concept in application and security, right
Speaker 6: like you whatever you put as as like your own
Speaker 6: data or you know you're trusted data, that that's fine.
Speaker 6: Like I can like as an attacker, as an external
Speaker 6: entity to the system, maybe I can truly manipulate it
Speaker 6: and do anything with it. Which is why I'm kind
Speaker 6: of like taking the example to what is the most
Speaker 6: common scenario with application development, which is you're having servers
Speaker 6: and servers get data from somewhere and that's usually data
Speaker 6: that flows over HTP requests, okay, and so that is
Speaker 6: where data comes in. And that data can come in there,
Speaker 6: but it doesn't have to come in there. For example,
Speaker 6: maybe you save user names sorry, file names and I
Speaker 6: don't know, in the cloud somewhere, okay, a very strict
Speaker 6: way without pat reversal, without anything else. But that data,
Speaker 6: you don't manage it in any other way like you've
Speaker 6: you've saved it in some way it doesn't impact the application.
Speaker 6: But then in some other place in your application you
Speaker 6: actually use it and trust it, but that file name
Speaker 6: was saved by you don't know it at that point,
Speaker 6: right that imagine the developer working on that other system
Speaker 6: or other component of the system. They treat the data
Speaker 6: from the database or from like a bucket name as
Speaker 6: potentially safe, but it's not. I can give the exact
Speaker 6: example with Git branches. Do you know that you can
Speaker 6: actually have a semicolon in a Git branch name, which
Speaker 6: imagine now that I'm telling you go ahead and get
Speaker 6: clone or get checkout to my leran semicolon rm you know,
Speaker 6: percent twenty whatever to your ref your entire directory. You
Speaker 6: will actually if you run this on a shell, you
Speaker 6: actually have shell meta character interpolated, and you will not
Speaker 6: just do a Git clone or get checkout actually, because
Speaker 6: that wuch name is valid by GitHub, will actually run
Speaker 6: a command. So this is where the typing system kind
Speaker 6: of like you know, it stays on the development side,
Speaker 6: and it's easiest to give you those by juggling.
Speaker 4: Yeah, little Bobby tables.
Speaker 6: Yes in different ways and unexpected ways, which is why
Speaker 6: I'm kind of like wanting to hit that with a
Speaker 6: hammer and say, like type scrift is not a security
Speaker 6: at all. Like, I appreciate it, but I don't want
Speaker 6: you even though it gives you strongly typed security benefits,
Speaker 6: if you want to take it there, I am happy
Speaker 6: to give you that concept, but I don't want you
Speaker 6: to think of it as a security tool because the
Speaker 6: moment you did, you'll have those mistakes done, like not
Speaker 6: understanding that it's not on run time and all of
Speaker 6: these other issues.
Speaker 5: So if it makes fun of type scriptures not being
Speaker 5: strongly typed, quality, weekly typed, or strongly typed, that's my favorite.
Speaker 4: Awesome extremely typed. Had to hear that.
Speaker 5: Strangly type because US trends are equal, because it's it's
Speaker 5: an because it's a duct type, it's not a phenomenal
Speaker 5: type system. Well.
Speaker 1: I think the bigger issue though, is the fact that
Speaker 1: we're we're kind of used from JavaScript of working with
Speaker 1: data in kind of blobs like you've got to json,
Speaker 1: and the JSON is effectively a JavaScript object and it
Speaker 1: can have any structure in any fields, and anything can
Speaker 1: be hung on it, and the strings can be any
Speaker 1: and can be anything, and so on and so forth.
Speaker 1: But to be fair, this is not just a typescript thing.
Speaker 1: I mean the amount of times that have written type
Speaker 1: safe C plus plus code and have run into situations
Speaker 1: where the bits and bites didn't exactly match what I
Speaker 1: expected them to be.
Speaker 4: You know that that happens.
Speaker 6: Yes, But there's a there's a big difference between like
Speaker 6: if you'll malock for whatever, like any bytes versus forty bytes,
Speaker 6: or you forget or not do it correctly versus you
Speaker 6: actually interpret a string as an array or an object
Speaker 6: because that flows through the systems and can wreck havoc.
Speaker 6: And we have like this, this is this literally has
Speaker 6: like its own vulnerability class called type juggling, which PAHP
Speaker 6: developers know it because you know PAHP, but also JavaScript
Speaker 6: developers should know it because also JavaScript.
Speaker 1: So can you again elaborate a little bit about type juggling.
Speaker 6: Yes, So let's take let's go back to like our
Speaker 6: simple case. We have an Express server running with typescript okay,
Speaker 6: and we only use type twitter. I'm not even going yet.
Speaker 6: We haven't crossed that phase of using type know ring,
Speaker 6: which we should probably get through and then zod, but
Speaker 6: we haven't crossed to that part. And imagine we're building
Speaker 6: something as simple as like a React like a poor
Speaker 6: man's React server component sort of things So imagine you're
Speaker 6: having a request coming in. You want to take the request,
Speaker 6: you want to check that, maybe call a function as well.
Speaker 6: If it's sanitized, everything is a string, you know, the
Speaker 6: username is a string whatever, and then that that server
Speaker 6: response is basically an HTML object back to you that says,
Speaker 6: you know, hello world or hell low arel or whatever,
Speaker 6: and you type it all the way and you do
Speaker 6: the sanitization. But if I'm sending you, if I'm sending
Speaker 6: you now like the in the Corey string, I'm doing
Speaker 6: name square, brackets equals and then start an image tag
Speaker 6: like an actual HTML image tag. Because of the way
Speaker 6: that express is set up, what you'll actually get is
Speaker 6: an array interpreted there and then all of your typing
Speaker 6: systems within your express and touch tip doesn't help because
Speaker 6: now the system, the application itself, interprets this name as
Speaker 6: an array and not as a string, and that is
Speaker 6: type job. That's like the pure example of from an
Speaker 6: attacker perspective, that's called HTP parameter pollution. Because we're able
Speaker 6: to kind of like you know, fuzzy test, create kind
Speaker 6: of like a mutation testing sort of on the request itself,
Speaker 6: but to the application itself, it is actually being being
Speaker 6: juggled from one type to a different one. And that's
Speaker 6: a very classic one that happens a lot of time,
Speaker 6: a lot of time.
Speaker 1: So basically, just to clarify, you were using typescript typecasting,
Speaker 1: which is the as key word to tell typescript, trust me,
Speaker 1: this is a string, because you assumed that it's a string,
Speaker 1: but in reality and run time, it was actually an
Speaker 1: array rather than a string. So you were telling typescript
Speaker 1: this is a string, but it actually turned out to
Speaker 1: be an array. And then from that point on, flowing
Speaker 1: throughout your entire code base, it's trying it, it's treating
Speaker 1: it's it's the assumption is that it's a string, but
Speaker 1: it is it correct?
Speaker 6: And now and now imagine that your sanitized function to
Speaker 6: this controller or whatever you want.
Speaker 4: And again, oh, one more thing.
Speaker 1: And of course typescript does automatic jobscript does automatic conversions,
Speaker 1: so that when you actually try to use it as
Speaker 1: a string, it will be transformed into a string. But
Speaker 1: if you do certain sanitation functions that will only sanitize
Speaker 1: the first part rather than the entire thing, maybe.
Speaker 6: Yeah, yeah, you don't have to cast it. That's where
Speaker 6: I'm at. So you imagine that that sanitized function again,
Speaker 6: have the function signature says as string and everything, so
Speaker 6: that shit goes fine. But now that array flows through
Speaker 6: the system function as an array. But when it hits
Speaker 6: something like you know your your disallow list or the
Speaker 6: name the data itself that includes, and then you give
Speaker 6: it that input, that actually will get coerced from from
Speaker 6: with a two string function from an array to a string,
Speaker 6: and you will get the first element because that's just
Speaker 6: how it works, and you don't know this ahead of time.
Speaker 6: And worse than that, if you type check the system,
Speaker 6: everything will be will match just fine, and your units
Speaker 6: will work just fine because it's typed throughout the system
Speaker 6: as a string. And I want to also correct on
Speaker 6: because it doesn't matter that you lie to job to
Speaker 6: typescript and tell it as a string. Because if you
Speaker 6: define an interface or you rely on the the query
Speaker 6: parameters of the interfaces as exported by by Express or
Speaker 6: any other framework, that will also not save you because
Speaker 6: you will get to the exact same problem we're talking
Speaker 6: about front time.
Speaker 5: Let me maybe help sharpen this up a bit. An
Speaker 5: Express for example, so the data that you accept from
Speaker 5: a request, you don't have to like cast it that
Speaker 5: cast is known as like a bad practice where you
Speaker 5: tell it as a string, like if you just type
Speaker 5: the argument of the function like requests expresses request, the
Speaker 5: type is a generic type, so you can be like
Speaker 5: request should accept a user of some interface. Like you
Speaker 5: don't even see the bad practice here, it's just like
Speaker 5: you're actually doing a good practice. You know, you have
Speaker 5: you type the argument of your function. But on this
Speaker 5: entry point of the application where you just accept the
Speaker 5: request for type stript it's any and that's where type
Speaker 5: shrip expects you to type it. But this is where
Speaker 5: like it gets confusing because you think you're going on
Speaker 5: press practice because you type your argument. But on the
Speaker 5: other hand, typing a request without actually doing some run
Speaker 5: time validation is a bad practice and it's not very common.
Speaker 6: I don't actually want to cross that chasm. Like let's
Speaker 6: let's cross and say let's go to like that phase
Speaker 6: and say if we did if if the run time
Speaker 6: type checking is the type narring okay, or that what's
Speaker 6: so so known as like the type cards that if
Speaker 6: type of Like what do you think of that? Because
Speaker 6: I have my own opinions, but what do you think
Speaker 6: of that?
Speaker 1: Well, first of all, there are a couple of issues
Speaker 1: with that. First of all, it's unfortunate. First of all,
Speaker 1: it's kind of bad practice in JavaScript, again, putting typescript aside.
Speaker 1: In JavaScript, I always considered it kind of bad practice
Speaker 1: to have to do to write this type of code,
Speaker 1: because the whole concept of JavaScript was about duck typing
Speaker 1: about how something behaves rather than exactly what it is.
Speaker 1: So creating these kind of switch statements or if if
Speaker 1: l if l if ls based on the type of
Speaker 1: a thing basically kind of indicated that it was. I
Speaker 1: kind of thought of it as a cod small. But
Speaker 1: that being said, stuff coming in over the wire cannot
Speaker 1: be trusted. So there are certain points on the edges
Speaker 1: of the system where I feel that type these type
Speaker 1: of type guards are a must within the application itself.
Speaker 1: I would strive to avoid the need for them as
Speaker 1: much as I possibly can in terms of just the
Speaker 1: way that I write the code.
Speaker 6: I resonate with that, and I'll just add another clarification here,
Speaker 6: because I see how like, how like some security some
Speaker 6: security aspects are kind of like creeping in here and there,
Speaker 6: Like you're very concerned about something that's on the wire,
Speaker 6: and I want to give you an example of a system.
Speaker 6: Imagine you're building the WebAPI for things and you're typing
Speaker 6: everything and it goes through the schema and everything is perfect,
Speaker 6: not cynically, it is perfect, and you're saving something and
Speaker 6: you're putting that data into a message bus. Okay, it's
Speaker 6: going into a queue, and some other system gets it,
Speaker 6: and that system could say something that got into the
Speaker 6: queue is our internal system. That user name or that
Speaker 6: email or something, that file name is a trusted data
Speaker 6: because it's not over the wire. I'm actually getting it
Speaker 6: from like my own rabbit and qure whatever. And that
Speaker 6: is exactly where things fall apart because if you're not
Speaker 6: using any actual security controls and measures on that end
Speaker 6: as well, and you're having that concept of it's not
Speaker 6: over HTP, it's not over API. No one is sending this.
Speaker 6: This is not user input. I'm literally taking off of
Speaker 6: the file system, off of the message queue, off of
Speaker 6: you know, something that I presume as trusted because it's
Speaker 6: our I don't know, internal thing, it's an internal service.
Speaker 6: That is where things also, you know, break apart. Why
Speaker 6: the same thing because that data flowed in my file
Speaker 6: name flowed into the system, and you could have typed
Speaker 6: it and said okay, it's supposed to be a string,
Speaker 6: and you saved it as like an image that you
Speaker 6: will manipulate later and find like it. There's no sco injection.
Speaker 6: When you save the file name, whatever you put it,
Speaker 6: you put it in the database. You also created a
Speaker 6: queue on You started the que with the event over there,
Speaker 6: and that system gets it and does something with it.
Speaker 6: Imagine that's like a worker and asking worker offline. Worker
Speaker 6: that takes that data and now it's it needs to
Speaker 6: do something with your image, like manipulate it, like recize
Speaker 6: it or whatever. So maybe it goes off and does
Speaker 6: and does something like you know, an OS command to
Speaker 6: run something like image magic or something to convert it.
Speaker 6: Then it takes that file name and puts it on
Speaker 6: this and the moment it did that, it trusted the system.
Speaker 6: What if my file name is literally called they run
Speaker 6: that jpeg semicolon rmnus r F exact same problem.
Speaker 4: So it's still it's still a.
Speaker 6: String, but it's now in a different context abusing you.
Speaker 1: So I want to verify that I understand what you're saying.
Speaker 1: What you're saying is anytime code, anytime I put data
Speaker 1: outside the direct control of my own code to an extent,
Speaker 1: my ability to trust that data goes away. It's because
Speaker 1: if some other part of the system gets compromised, now
Speaker 1: I'm vulnerable to that compromise.
Speaker 6: There's just like a lot of a lot in play here,
Speaker 6: Like this isn't type juggling. This is I was just
Speaker 6: like specifically like going with a needle on what you
Speaker 6: said were like you were like very concerned and conscience
Speaker 6: on the transport like the htplay. But from saying it's
Speaker 6: more than that. So I mean the way you probably
Speaker 6: have done it better is you have like proper security
Speaker 6: controls and secure coding. So the way that you would
Speaker 6: do an OS command, like an operating system command, we
Speaker 6: just need to be in a more secure way and
Speaker 6: then whatever the data is, it wouldn't impact you. So
Speaker 6: there's like a bunch of things in play here. What
Speaker 6: you said is not incorrect. It's just like there's a
Speaker 6: complete answer. There's more than just one thing that needs
Speaker 6: to go and that is that's like that's related also
Speaker 6: to a lot of concept in security, like defense in depth,
Speaker 6: you have to like have several layers of defense and
Speaker 6: security controls and security measures, and for example, a lot
Speaker 6: of people think, hey, let's just sanitize all the data. Well,
Speaker 6: that doesn't that's not how you know, real world works.
Speaker 6: You don't really have to sanitize all the data. For example,
Speaker 6: when you put user input as like an image, you know,
Speaker 6: and a very bad like xtmil image tag, and you
Speaker 6: give it to react, it doesn't sanitize the data for you.
Speaker 6: It does something else that's called output encoding. It converts
Speaker 6: the data into xtamil entities. That's a whole different and
Speaker 6: concept from sanitizing the data. The data remains the same,
Speaker 6: but the way that it gets interpreted on the dome,
Speaker 6: the way it's sweetened to it changes. It's not sanitization
Speaker 6: because the source of the data remains the same.
Speaker 1: Do want to move on because we're starting to run
Speaker 1: out of time. I do want to touch on the
Speaker 1: type cards and on those.
Speaker 6: Dog let's talk about zod okay. I have nothing else
Speaker 6: on type pards like this is I was curious about
Speaker 6: your opinion. I, by the way, resonate the same. I
Speaker 6: love the duct taping, but I just feel that it's
Speaker 6: like it's really hard to maintain a lot of type
Speaker 6: if type of and I can't like agree with that.
Speaker 1: And and By the way, type off is not enough
Speaker 1: because type off is like a very rough knowledge.
Speaker 4: It's a snedgehammer. You need. Probably you need instance off.
Speaker 1: As well, and from what I know, like half the
Speaker 1: JavaScript developers at least don't really understand how instance off
Speaker 1: actually works. But putting that aside, that's a different discussion.
Speaker 1: Let's talk about zode.
Speaker 6: Amazing, Let's talk about zode.
Speaker 5: It's one of my faves, and I talk about this
Speaker 5: quite often, so for the listeners that don't know ZOD.
Speaker 5: ZOD is a very cool way to kind of bridge
Speaker 5: between the development time and the run time. So it's
Speaker 5: kind of a bridge between typescript and jobscript. So it's
Speaker 5: basically a schema validation library that is what's called typescript first.
Speaker 5: So the idea is that you define a run time schema,
Speaker 5: so you're defining a schema that would check the object
Speaker 5: in run time, and ZOD exposes a method called infer
Speaker 5: which allows you to create a type out of your
Speaker 5: run time validation. So basically you kind of have a
Speaker 5: single source of truth primarily define your run time validation,
Speaker 5: and you also get the type inferred out of it.
Speaker 5: The reason why SOD is called typescript. First, it's kind
Speaker 5: of because it's kind of leading in the industry in
Speaker 5: terms of how handling more complex types, so beyond the
Speaker 5: basic adjacent ZOD is very good at inferring union types
Speaker 5: and et cetera.
Speaker 1: But also not familiar with ZOD, but maybe familiar with React.
Speaker 1: ZOD in a certain to extent is kind of reminiscent
Speaker 1: of the prop types that we used to have in
Speaker 1: in in React that that also did run time type
Speaker 1: validation when you were running in developed in development mode.
Speaker 1: So it's not exactly the same, but there were a
Speaker 1: lot of similarities in the way in which it's kind
Speaker 1: of written.
Speaker 5: You mean that did infer that the typescript from the
Speaker 5: right time.
Speaker 1: No, No, not that, I'm talking about how you literally
Speaker 1: write the ZOD run schemaema. You used to do the same.
Speaker 1: You have this kind of schema definition language that gets
Speaker 1: executed at run time, and you kind of had a
Speaker 1: similar thing with the now precated React prop types that
Speaker 1: you used to put on on React class components in
Speaker 1: order to specify before we had typescript, we used to
Speaker 1: use that to specify the types and it would actually
Speaker 1: get checked at run time rather than a bill time,
Speaker 1: because there was necessarily an actual bill time to test
Speaker 1: it in, but it would only be tested in developer mode,
Speaker 1: in development mode.
Speaker 6: Not in So what's the issue with D you're wondering?
Speaker 1: No, First of all, I hope everybody is clear. Ah,
Speaker 1: Steve was Ariel's explanation. It seemed to me it was
Speaker 1: an excellent explanation. But I was wondering if you have
Speaker 1: any questions about that?
Speaker 4: Okay, it was excellent.
Speaker 1: So basically what it means, though, is that by adding
Speaker 1: in ZOD we can do run time type checking. We
Speaker 1: can say that what I'm getting over the wire supposed
Speaker 1: to have this exact structure. It gets checked at run time.
Speaker 1: If it passes, then great. If it fails, we get
Speaker 1: an exception.
Speaker 5: Excellent, you can handle it. You can choose whether you
Speaker 5: raise an exception or I love.
Speaker 6: That you use the structure because it's a good segue.
Speaker 4: Yeah. So given that problem solved, no.
Speaker 6: Yeah, almost, yes or no, kind of It depends which
Speaker 6: problems are solved. So here's the thing. Now, let's forget
Speaker 6: that the site you do use. Imagine you're using something
Speaker 6: like your use case, being like there's a notification system
Speaker 6: and you have to update a bunch of stuff related
Speaker 6: to like a notification systems or it's like notification type
Speaker 6: and mode and you know the value of it and whatever,
Speaker 6: like an email daily and is it disabled or enable?
Speaker 6: Just like a bunch of stuff. That's an object that
Speaker 6: flows into the system. Your API on you know, on
Speaker 6: this server side uses ODD it says, okay, my notification
Speaker 6: schema is is an object that is made up of
Speaker 6: notification type, which is supposed to be, like you said,
Speaker 6: done a structure of a string. So that's fine, that's
Speaker 6: a string, and the mode is a string, and everything
Speaker 6: else is maybe a string or a poollyon it depends.
Speaker 6: So far, so good. And if I try to send
Speaker 6: you something like to try to like do type juggling
Speaker 6: and send you an array in the notification type so
Speaker 6: it's not just email as a string, but you know,
Speaker 6: I don't know email and something else as an array,
Speaker 6: it will get rejected and you think you've kind of
Speaker 6: like solved the problem, except there are more sort of
Speaker 6: vulnerabilities that can flow in indeed not directly related to ZOD,
Speaker 6: but just that using ZOD is potentially a policy that
Speaker 6: wouldn't save you from it. So my use case for
Speaker 6: that is imagine that now I'm sending in a string,
Speaker 6: but that string for notification type is underscore underscore proto
Speaker 6: underscore underscore. I won't do the whole underscore again, but
Speaker 6: just know that when I say proto, that's what I mean.
Speaker 6: And my notification mode is going to be a string
Speaker 6: also now as adamin identification mode value is going to
Speaker 6: be true. Okay, so I'm giving you all of those strings.
Speaker 6: ZODD has no issues and it works towards your defined schema.
Speaker 6: Of all of them have to be strings, so it
Speaker 6: flows in. But if all of them you have a
Speaker 6: question there no, okay. So if all of them flow
Speaker 6: into the app itself and the application does something one
Speaker 6: of two things with the data incorrectly in an insecure manner,
Speaker 6: then you now have a prototype pollution vulnerability.
Speaker 1: Basically, if you're using that field as a key on
Speaker 1: an object and you're now accessing that object's prototype instead
Speaker 1: of one of the fields on the object.
Speaker 6: Correct, that is one, so you could insecurely use it
Speaker 6: directly with what is not a literal string. But actually, and.
Speaker 1: You know what the lesson is, don't use JavaScript object
Speaker 1: as dictionaries.
Speaker 4: Use the map instead.
Speaker 6: There we go. But there's another way where it can
Speaker 6: it can bite you, which is if you don't do that,
Speaker 6: but instead you do something like let's say you work
Speaker 6: with a nasted data structure. Imagine like address, and then
Speaker 6: there's like a business address and office address, and maybe
Speaker 6: there's like nested data structures there. And sometimes what people
Speaker 6: do is recursive Jason parts the data and set it
Speaker 6: like that if you do so. Actually, that is the
Speaker 6: canonical example of prototype pollution vulnerabilities. So many, many, many,
Speaker 6: many libraries, like Lowdash, like object path, like so many
Speaker 6: others that's been used like prototype pollution has been found
Speaker 6: to be impacting many kinds of vulnerability of libraries in
Speaker 6: different ways, but they all basically do the exact same
Speaker 6: insecure issue, which is an insecure way of doing a
Speaker 6: recursive Jason merge. And if you do that and you're
Speaker 6: not aware of prototype pollution, then that can crawl in.
Speaker 6: And then again, using ZA doesn't help you unless you
Speaker 6: do something else, which is using ring literals in ZOD,
Speaker 6: but that's not always possible, not always. That data is
Speaker 6: hardly typed in advance, like type email or type digest.
Speaker 6: Maybe your user data is user name or an address
Speaker 6: or something like that and you can't confine it to
Speaker 6: a literal schema.
Speaker 4: Fat.
Speaker 6: Oh my god, we did not open that door. That's
Speaker 6: a different topic.
Speaker 1: The fact the fact that typeescript can you in certain situations,
Speaker 1: like everybody goes to evail, but evail is like the
Speaker 1: extreme situation. But the fact that even without evil, typescript
Speaker 1: can sometimes consider strings as code can introduce certain vulnerabilities
Speaker 1: because just looking at the type of the thing is
Speaker 1: not sufficient, is what you're saying.
Speaker 4: Do I understand? Correct?
Speaker 6: Correct, It's it's not I mean, yeah, it's not sufficient
Speaker 6: because this vulnerability can impact you. And there's another actually
Speaker 6: issue with ZOD, so I don't know if you know
Speaker 6: you knew this. Another one that's related to a mass
Speaker 6: assignment vulnerability that would happen with God is if you
Speaker 6: define a schema and let's say my schema is like
Speaker 6: my name and my email, and that's what you define
Speaker 6: and that's what I send in and you do, like
Speaker 6: you know, ZOD, you know schema safe parts and all
Speaker 6: of this thing, and it doesn't throw it's all success
Speaker 6: blah blah blah. You push it down the wire to
Speaker 6: your services and repository pattern and you normally do like
Speaker 6: you know, user dot save and that user data comes
Speaker 6: from the request because you already invalidated it with the schema,
Speaker 6: and so that gets persistent on the database. That's a
Speaker 6: very common pattern also with ORMs. But if I send
Speaker 6: another string with the data in the schema, like is
Speaker 6: admin or role equals admin, that will also satisfy ZOD
Speaker 6: because by default it doesn't have any issue with data
Speaker 6: that is not on the schema. So if I add
Speaker 6: fifty fields and your schema has two fields, your schema
Speaker 6: parsing will still say that it's valid. Schema okay, And
Speaker 6: that's that the ending.
Speaker 1: Of JavaScript objects are open by.
Speaker 6: Default because well because you haven't used I mean, the
Speaker 6: correct pattern would be to create a new object or
Speaker 6: like you said, like map it to a new object
Speaker 6: that takes fields one by one that you trust. But
Speaker 6: if you just take you know, user equals request by
Speaker 6: the user you say I validated it, it's fine. But
Speaker 6: then you pass that user from the from their request
Speaker 6: which comes from the user input, and pass it all around,
Speaker 6: you have again that fallacy as if that schema was
Speaker 6: checking it and it's valid.
Speaker 5: Well you can you can strict par it.
Speaker 1: Yeah, it doesn't has the ability to say only these
Speaker 1: fields and no more.
Speaker 5: I think it does. It's called strict mode. It's strict
Speaker 5: parsing and by default. But when ZOE just started it
Speaker 5: was actually the other way around. So the default was
Speaker 5: too strict parts and obviously it's not that comfortable for
Speaker 5: many use cases, so they change the default behavior. But
Speaker 5: I think that ran like what we really want to
Speaker 5: bring out here for the listeners is that even if
Speaker 5: you're using ZOD, try to consider understand that if you're
Speaker 5: not strict parsing, it could be larger, and that there
Speaker 5: is the ability to strict pars it, and we need
Speaker 5: to wisely choose it when it's needed.
Speaker 6: Exactly, it's just not the default. And when you don't
Speaker 6: have defaults, you're going to have adopters who use the
Speaker 6: system by the reading or whatever in an insecure way
Speaker 6: by default. That's not what you want to do.
Speaker 1: And then somebody does Jason stringify or two string or whatever,
Speaker 1: and they get something that's different than what they expected.
Speaker 1: Correct understood. We're starting to run really short on time.
Speaker 1: Is there anything else especially that we want to touch
Speaker 1: on that we haven't talked about so far.
Speaker 6: We're going to do rejects next time, right, Reel.
Speaker 1: I would love to have you on again to talk
Speaker 1: about redis everybody's favorite topics.
Speaker 5: Recently I've been writing, I've been developing only parsers, so
Speaker 5: I've a vote. Like I started off my EXPERI as
Speaker 5: a Cobal developer and the Army, and then i moved
Speaker 5: to web development, so react and now I'm doing backhand,
Speaker 5: so it's pipe and now that's it. I'm a Regicks developer.
Speaker 5: Like the next level is pure energy.
Speaker 6: Your pyramid right now looking.
Speaker 1: Down with all of you lots, you're actually one of
Speaker 1: my picks will have to do with parsing, but we'll
Speaker 1: get there. So so before we finish and we go
Speaker 1: to picks, if anybody wants to get in touch with you,
Speaker 1: what would be the best way, especially you are, Reel
Speaker 1: as you are have like no presence on the interwebs.
Speaker 5: I have LinkedIn.
Speaker 1: Oh yeah, everybody's favorite social network, the social net to die.
Speaker 5: I'm protecting my soul for now, so no X. Yes,
Speaker 5: but you can reach me on LinkedIn and I'm very
Speaker 5: polite and I will answer you all.
Speaker 1: So it's Aariel Schulman on LinkedIn?
Speaker 4: Yes, are you the only? Ariel Shulman on LinkedIn, and I'm.
Speaker 5: The how many girls are there with the profile picture
Speaker 5: of them on a stage called Aeriel Shulman on LinkedIn.
Speaker 5: Let's let's research this thing.
Speaker 1: Okay, cool?
Speaker 4: Cool.
Speaker 1: That's another thing about both of you that your conference speakers,
Speaker 1: and that also goes to one of the picks that
Speaker 1: I'll have today. But anyway, and how about Julian. If
Speaker 1: anybody wants to contact you, what's the best way For.
Speaker 6: People outside of Israel? You can just google le Rantel
Speaker 6: and you'll find me on x or whatever. Inside Israel,
Speaker 6: there is a famous famous Israeli singer called me Randal.
Speaker 6: That's not me, it's a very it's it's a very
Speaker 6: crude music style here. So I don't know. I won't
Speaker 6: ope any more than that.
Speaker 1: Cool cool, Okay, let's uh, let's move on to pics then, ah,
Speaker 1: do you want to start us off with picks?
Speaker 2: So I went through the Proxmocks Advanced training with Wihui,
Speaker 2: which is the Canadian company that does the training. And
Speaker 2: not that I regularly do trainings, but it was the
Speaker 2: best training experience that I've ever had. Everything if you've
Speaker 2: ever done a workshop, you know the first part of
Speaker 2: the workshop, because this training had both educational material and
Speaker 2: labs and whatnot that like everything just worked. There was
Speaker 2: there was no there was nothing that didn't work except
Speaker 2: for things that were common user error that were part
Speaker 2: of what was going to be covered in the material anyway,
Speaker 2: and I just thought that that was really really great.
Speaker 2: So I am myself working on some proxmox material, which
Speaker 2: is why I part of the well. I took the
Speaker 2: training primarily to become proxmox certified, but also because I
Speaker 2: you know, I wanted to learn, and I wanted the
Speaker 2: material that I create to match the same quality that
Speaker 2: you get from the official training, and hopefully even I'd
Speaker 2: like to be on the path to become an official
Speaker 2: trainer with Proxmox. But anyway, uh, if you if you
Speaker 2: want to have the official Proxmox training, the wee Hui
Speaker 2: is probably a better bet from from some of the
Speaker 2: things I came to understand then even getting it from
Speaker 2: Proxmox themselves, just in terms of the way that that
Speaker 2: we Hui's business works and how that drove them to
Speaker 2: create the course content because there's a lot of leeway
Speaker 2: and how to present it. So anyway, and for people
Speaker 2: that don't know proxmox is.
Speaker 4: It's for co.
Speaker 2: Location or for on prem So if you want to
Speaker 2: save a ton of money, then you can. You can
Speaker 2: use proxmox and have you know, as many nines as
Speaker 2: you want up time without without having a cloud bill
Speaker 2: that costs you the same amount per month that it
Speaker 2: would cost to by the servers out right. And that's
Speaker 2: that's all. That's all I got. That's that's my that's
Speaker 2: that's my thing.
Speaker 1: See if I wonder what you want to tell us
Speaker 1: talk to us about today in your picks.
Speaker 3: Uh, let's see, Well, I suppose we could try something
Speaker 3: new like dad jokes.
Speaker 1: I love the one about the half brother by the way,
Speaker 1: the one that you.
Speaker 3: Yeah, that was good for those who aren't familiar with
Speaker 3: the one. It's a very short conversation tweening myself and
Speaker 3: our friend, and I said, I have a couple, I
Speaker 3: have a half brother, and he says different. Mother said,
Speaker 3: no shark attacks. But now I'll do some new ones
Speaker 3: this week.
Speaker 6: The question why.
Speaker 3: Shouldn't they dentist marry a manicurist because they'll fight nail
Speaker 3: well desert drums? What do you call what do you
Speaker 3: call cheese that isn't yours not.
Speaker 5: I knew that one.
Speaker 3: Yes, well, you should have jumped in and answered it.
Speaker 3: I would have taken an answer.
Speaker 2: I was on you.
Speaker 4: Oh okay.
Speaker 3: And then finally, this is just more of an observation
Speaker 3: that Bigfoot is sometimes confused with sasquatch, yet he never complains,
Speaker 3: you know, yedi y e t I yi. Anyway, those
Speaker 3: are the jokes.
Speaker 5: You can tell the jokes work because I was like
Speaker 5: grasping my hand.
Speaker 3: You know, it's more like it's usually the moan and
Speaker 3: oh my god, I can't believe he said, Dad, yes, yes,
Speaker 3: and when I said it. Sometimes I'll try to work
Speaker 3: those in as as you know, real stories, and my
Speaker 3: family has gotten wise to it after so many years.
Speaker 3: Their first thing out of the mouth, Dad, is this
Speaker 3: a joke?
Speaker 6: Are you serious?
Speaker 3: I just listen, okay, anyway.
Speaker 1: Okay, So now it's my turn, and I've not been
Speaker 1: on the show for a while. I've I've had various things,
Speaker 1: actually a lot of them fun things, but they've kept
Speaker 1: me away from the podcast recording. So I've got a
Speaker 1: bunch of picks that have accumulated. I'm hoping I'm making
Speaker 1: the right choice of using them all now and not
Speaker 1: saving some for next week, but we'll see. So anyway,
Speaker 1: one thing is I was doing this thing. It was
Speaker 1: really fun. You reminded me when you were talking about parsing.
Speaker 1: We had a certain idiom in again going back to
Speaker 1: existing legacy code. We had a certain idiom in the
Speaker 1: code which was bad performance wise, and I wanted to
Speaker 1: fix it. And it was really just, you know, a
Speaker 1: very localized rewriting of the code. Now, initially I thought
Speaker 1: about using some sort of regular expression and doing a
Speaker 1: global search and replaced across the entire project, but that
Speaker 1: that kind of turned out to be a bit messy
Speaker 1: and kind of what I But I'll get to that.
Speaker 1: The other thing was that I was worried that, you know,
Speaker 1: it fixes the situation as it currently is, but there's
Speaker 1: nothing preventing anybody from using that the same poor edium
Speaker 1: in the future. So I wanted to safeguard against that
Speaker 1: as well. So what I came up with in the
Speaker 1: end was a custom EA slint rule with a fixer,
Speaker 1: And so I actually had built an E slint rule
Speaker 1: that analyzed the ASD, identified that kind of localized bad idiom,
Speaker 1: and then had the fixer which actually fixed it to
Speaker 1: the correct code. And then I basically told the slint
Speaker 1: to fix that thing across the entire project, which fixed
Speaker 1: all existing occurrences. But now I also had it as
Speaker 1: a custom rule going forward, so if anybody ever uses
Speaker 1: that bad edium in the future, they will get it
Speaker 1: reads quickly and they can even you know, right click
Speaker 1: and request a fix and it will automatically fix that
Speaker 1: code for them. So it's a safeguard. It both fixed
Speaker 1: the existing problem and is a safeguard for the future.
Speaker 1: And it was a lot of fun to write and
Speaker 1: I really enjoyed it. So that was point number one.
Speaker 1: Point number two, there's a Last year, I actually did
Speaker 1: not participate in any conference, which was really depressing in
Speaker 1: a way because I'm kind of an extrovert and i
Speaker 1: like speaking at conferences. But this year I'm already speaking
Speaker 1: at three so I'm really happy about that.
Speaker 5: Yay.
Speaker 6: Nice.
Speaker 1: So so I'll be speaking at the JS Heroes conference
Speaker 1: in uh Coclues in Romania. Yeah, it's I think they've
Speaker 1: still got tickets. So if you're in Europe and you
Speaker 1: want to attend a really top notch JavaScript conference, and
Speaker 1: it's top notched despite the fact that I'm speaking there,
Speaker 1: it's because it's got some amazing speakers on the list.
Speaker 1: I highly recommend attending inclusions of Lovely City, although I've
Speaker 1: not been, but I've been told I've been to other
Speaker 1: parts of Romania they're also lovely. But I've been told
Speaker 1: that Clusures Lovely as well. I'm looking forward to it.
Speaker 1: So that's conference number one, and then in Tel Aviv,
Speaker 1: I'll be speaking both that react next and at No TLV,
Speaker 1: back to back, day after.
Speaker 5: Day, sharing the stage with us two.
Speaker 1: Yeah, both of you are speaking at both conferences.
Speaker 5: Just one of you this year. Last year I did
Speaker 5: never again good luck.
Speaker 1: Just so, just so you know that, like a couple
Speaker 1: of years back, I gave two talks at the same
Speaker 1: conference back to back.
Speaker 4: I wasn't.
Speaker 5: Isn't it?
Speaker 6: That's true?
Speaker 4: I yeah, kind of.
Speaker 1: But I spoke in one room, finished, wrapped up, went
Speaker 1: to another room.
Speaker 4: I gave another talk there, changed out. Yeah.
Speaker 1: No, anyway, and uh, the other pick that I wanted,
Speaker 1: My final pick is a really funny story.
Speaker 4: Did you hear that one about in the.
Speaker 1: New interview Interview Coder story?
Speaker 4: That's so funny?
Speaker 1: So yeah, yeah, So basically, these two well ex Columbia students,
Speaker 1: they were looking they were.
Speaker 4: They were like in the what's it called? They were?
Speaker 1: They were like in the They had the mind the
Speaker 1: entrepreneur mindset, and they were looking for an application to develop.
Speaker 1: So what they created is an application that allows you
Speaker 1: to cheat on lead code interviews. It basically, per my understanding,
Speaker 1: I've not ever tested it. I'm not interviewing. But anyway,
Speaker 1: what it does I understand that it does is that
Speaker 1: creates an invisible It's a local desktop application that you install.
Speaker 1: It creates this kind of invisible window, but but it's
Speaker 1: not reflected through Zoom or whatever you're using.
Speaker 4: And it shows you answers using AI.
Speaker 1: And and it shows you though in a sort of
Speaker 1: progressive way, so you kind of it seems like you're
Speaker 1: thinking about the answer and coming up with the answer
Speaker 1: as it goes along. And it also moves the windows
Speaker 1: around so that your eyes aren't always focused on the
Speaker 1: same point in the screen, and it does all sorts
Speaker 1: of magic. And then they use that program to interview
Speaker 1: for basically all the fang companies and got offers from
Speaker 1: all them. And then they after they got the offers,
Speaker 1: they advertised the story and showed the images of all
Speaker 1: the offers that they got and apparently somebody from Amazon
Speaker 1: got really really upset about it, contact Columbia and had
Speaker 1: them expelled.
Speaker 4: But I think they're amazing.
Speaker 5: Let's hire them now. I think they're jumps.
Speaker 4: Yeah, I think they're good for jobs.
Speaker 5: Now sounds like overqualified. I would even say.
Speaker 2: Yeah, that's that's There was something else like this that
Speaker 2: came out a couple of years ago. There was a
Speaker 2: United States state government website that put something I mean,
Speaker 2: it was ridiculous, like social Security numbers were rendered into
Speaker 2: the HTML for It's like they were rendering out their
Speaker 2: entire database into the HTML. So when you just search
Speaker 2: I was doing that way. It was something just absolutely
Speaker 2: ridiculously stupid. And then when the person points it out,
Speaker 2: then they they you know, trump up these charges of
Speaker 2: cybercrime and hacking. It's come on, you know, he right
Speaker 2: clicked inspect. So I think that that sounds so overblown
Speaker 2: from the perspective that they're just pointing out a flaw
Speaker 2: in the system. You know, I don't know whether or
Speaker 2: not they actually helped people to get the.
Speaker 6: Call on browser.
Speaker 1: Yeah that's uh. Who likes to use that term a lot,
Speaker 1: like Yeah, that incredible tool, the view source and the
Speaker 1: browser that incredible hacking tool. By the way, there's the
Speaker 1: old story about the person who who uh decoded the
Speaker 1: code for DVD coding I think it was, and then
Speaker 1: some young guy from Norway or or Icelander somewhere, and
Speaker 1: they tried to hit him with the DMCA violation or something.
Speaker 1: So he basically the way that he got around it
Speaker 1: was that he printed the code on the T shirts.
Speaker 4: Yeah.
Speaker 1: Anyway, by the way, talking about T shirts, somebody might
Speaker 1: you might have noticed if you when I got up
Speaker 1: that I'm actually wearing the T shirt for a different podcast.
Speaker 1: It's the shirt that I got when I was a
Speaker 1: guest on JS party. And the reason that I'm wearing
Speaker 1: it is because that, unfortunately JAS parties ended. Now you
Speaker 1: might think that podcasts compete with each other. No, I
Speaker 1: think it's certainly a case of rising tie lifts all ship.
Speaker 1: I'm really saddened whenever something like whenever a podcast just stops.
Speaker 1: I know that change log now has like general podcasts,
Speaker 1: but the fact that they had a dedicated JavaScript podcast
Speaker 1: was great. I enjoyed listening to it. As I said,
Speaker 1: I was a guest on it. I'm sadden that it ended,
Speaker 1: and I'm happy that we're continuing, so you know, if
Speaker 1: you're looking for your JavaScript fix, then stay with us.
Speaker 1: And those would be my picks. Reel Iran who wants
Speaker 1: to go Firstran goes first.
Speaker 4: You don't have to.
Speaker 1: You don't have to give picks. It's it's it's a nice.
Speaker 5: I'm not ruining my reputation.
Speaker 6: Then I'll go quick on them.
Speaker 4: Though.
Speaker 6: TV shows, I'll go for Arcane and Blue Eye Samurai,
Speaker 6: which are masterpieces. You have to watch them if you're
Speaker 6: into and if even if you're not into like anime
Speaker 6: and stuff like that, they're like amazing.
Speaker 4: They're not exactly animated though.
Speaker 6: Not exactly animate though, but it's also not like live
Speaker 6: action and stuff, so I highly recommend watching them. Arcane
Speaker 6: specifically has an incredible soundtrack which is very emotional. It's
Speaker 6: it's yeah yeah. Video game book wise, I'll go with
Speaker 6: sand Worm by Andy Green. If you like the kind
Speaker 6: of like how cyber security kind of like started, you know,
Speaker 6: all the things like you know, Russian hacking groups and
Speaker 6: stuff like that, everything that started in Ukraine like over
Speaker 6: a decade ago. It's super cool. It goes and analysis
Speaker 6: like why in the politics and how security researchers go
Speaker 6: at it incidents and stuff like that podcast go with Starduk.
Speaker 6: I love like space and astronomy and stuff like that,
Speaker 6: and it has niled the grass dison and it's like
Speaker 6: a super fun space and time and everything around this
Speaker 6: physics stuff is super fun to watch events. Sorry to
Speaker 6: listen if you go to events and you like that.
Speaker 6: I'm actually going to recommend everyone here who are developers
Speaker 6: to go to def Con, which is super weird hacker
Speaker 6: kind of like underground punk style hacking conference in Vegas
Speaker 6: in the summer in August. You'll get a definitely a
Speaker 6: good taste of what the culture is like.
Speaker 4: Would you also get hacked while you're there?
Speaker 6: So for a long time actually that was a thing
Speaker 6: where you would be recommended to go without any mobile
Speaker 6: devices or mobile devices turned off, never connect to any
Speaker 6: Wi Fi whatever you think that is, mobile devices off,
Speaker 6: louted off everything else. Wow, But yeah, it had that
Speaker 6: reputation for a long time, definitely since like the early days,
Speaker 6: like like nineties and stuff like that. But it's far
Speaker 6: more mature now like that it's people like, don't do
Speaker 6: those things anymore. And I mean, if you do care
Speaker 6: about your privacy and devices anyway, don't culture with your
Speaker 6: phone and laptop and just work off those are my.
Speaker 5: Picks greatly, like all of the above.
Speaker 4: No problem.
Speaker 1: Just having you here is good enough. Okay then, everybody,
Speaker 1: thank you for participating on our show. Steve had to
Speaker 1: drop off, but you know we are still here and
Speaker 1: hopefully so are you. So thank you all, Thank you Ariel,
Speaker 1: thank you Leroan, and see you all next time.
Speaker 5: Thank you for having us