Hello everybody, and welcome to another episode of JavaScript Jabber. Today I'm flying solo both as host and panelist. Maybe some of our other hosts will join us later on we will see. Our guest today is Josh Goldberg. Hi, Josh, Hi, thanks for having me. You do know that when you wave, people who listening to our podcast don't actually hear anything.
I was hoping the good vibes. Would you know m Nix from the podcast. That's a good one.
Yeah. It reminds me that when my kids were really young and we would drive and they would be sitting in the back and I would ask them something while I'm driving and they would nod their heads.
Yeah.
So yeah. Anyway, so welcome back to a show. It's been a while, had you here before. We're actually going to be talking about similar topics to what we've spoken about in the past, but a lot of I guess has happened since then, so hopefully we can catch up. The topics are going to be tess Lint, which is a project you've been working on for a while now, and also your new conference what's it called squiggle.
Coff squiggle comf Yes, named after the things that give you squigglies in your editor.
Cool. Cool, cool. So what do we want to start with?
Well, I'm a sucker for going in order ts s lint.
Yeah okay, but you know what before then, since it has been a while, can you also, you know, provide a quick introduction about who you are, what you do, why it's exciting to have you.
On with pleasure. Hi everyone, I'm Josh. I'm a full time independent open source maintainer. That means that instead of working for one specific company, I'm independent. I work on my own and I work on open source projects that benefit the ecosystem for me. Specifically, the main ones I work on are typescriptyestlint, which is the tool that lets your run standard JavaScript tools like Eslin's are prettier on types shop Code, as well as eslint itself, on the
committed team, and Moca. So I'm just kind of generally happy to float around GitHub and try to make things better for everyone.
It is not recall we've spoken about in the past, but I think it is worth bringing it up again. Is it really possible to make a living off of open source? You know, especially given that it's free?
Yeah? Free as in it's a hard question. It is theoretically possible. Some projects are better suited for it than others. The ones I tend to work on tend to be not very well suited. But I do. I do make what is defined as a livable wage in my area, which is better than the even last year, which was minimum wage. But it's not anywhere near it was as it was in a full time salary position for me, So there's a good chance that'll eventually go back once I've made the impact I wanted to an open source.
So you're what living off some of your savings? Is that what you're saying.
I don't think I'm that negative right now, in large part because my fantastic wife, my spouse has a real job and health insurance, which is very important in the United States, as some may know.
But I do.
I do get income. I have community sponsorships on a lot of the projects that I'm on that I get a share for many of them. I've got book revenue from my learning types of good book go buy it today, And generally there are some people who sponsor me individually on get up sponsors, So I'm not hemorrhaging money. I'm just not making a.
Lot of money, and if people who are listening to us do want to contribute to your efforts, what's the best way to go about it.
Well, first of all, they should feel very good about themselves because that's very kind and noble of them. Thank you. If they want to support me specifically and the stuff that I'm specifically doing kithub dot com, slash sponsors, Slash Joshua K. Goldberg, or if you just google me or look me up my names on my site for any of the projects I work on, if that's particularly exciting
to you, especially t sees link. They all have open collectives that you can sponsor, so there's definitely a way for you to give me money if you want to.
And you mentioned your book on typescript. When did that come out.
It's been a couple of years now, I belie twenty twenty two, mid late summer. It's through a Riley learning Typeescript and it has this beautiful yellow and colored bird on the cover.
And given the name learning Typeescript, I gather that it's primarily for people who are not familiar with it and want to get into it, like newbies, effectively exactly.
Yeah, the general flow of the book is that if you can start with roughly intermediate JOBASCRIPT knowledge, you should know how variables and closures and stuff like that work. You don't need to be super fancy advanced javascripts expert. You don't need to know you know, I don't know symbols and stuff like that. But you don't need any prior knowledge or experience with types through whatever, C Sharp,
C plus plus Java Rust. None of that is necessary if you already know what great TYPESKIPT works a little differently, so you'd still learn stuff, but you can come in with just JavaScript and emerge a relatively competent typescript developer.
You know. That brings up an interesting point. So a few weeks back, we recorded in an episode with the people talking about the lead code lead code tests that so many companies are using these days when filtering out applicants, and I wasn't actually able to participate on it, so I'm just listening to the recording like everybody else, And they brought up one of the things that they discussed was about which programming languages are supported by that platform.
Turns out that many are. You can practically choose any which you want, and both JavaScript and typescript are supported as languages apparently that you can use for you know, solving the lead code challenge, and I, you know, I was thinking about it, and if I were to do it today, I would, you know, there's a good chance that I would choose to use JavaScript. But I'm like wondering why anybody would use typeescript as opposed to JavaScript
when solving elite code challenge. What do you think about that?
That's a good question. I don't know what i'd use, honestly, I haven't done lee code in a while. I think it's a fun little hobby that one can do, like a niche little area programming, and I detest how associated it's become with job interviews. That's just not a core competency that we use day to day as much as you know, debugging or pairing. But I digress. I don't know. It's the rule that I normally go through is the
rule of three. If I'm using more than three files or working with three or more people in a project, I'll switch from JavaScript to type scripts. Leak code doesn't really satisfy that rule. So the overhead of typescripts needing to or trying to get you to define types for things, or being aggressive when you haven't defined it enough. Types oftentimes isn't worth it. It can be useful though, if you do, and if you have experience, and if you feel comfortable writing out types or just using any in
a lot of places. So yeah, I can see the motivation for it. I wouldn't go for it myself.
Yeah, me too. I'm thinking that probably the sweet spot for dynamic languages is rapid prototyping. And with lead code, you are that's essentially what you're doing. You're trying to hammer out a working solution as quickly as possible. You know, usually you're constrained in time. Writing anything that at the end of the day doesn't actually get translated into executable code seems like a waste of time in that context. So yeah, but you know, in any event, it's nice
of them to support it. Is an option, you know. Interesting. I once, by the way, commented that my ideal development environment would be me writing JavaScript and everybody else writing typescript. That way, I don't have to mess around with types, but everything that I do is supported by types, and I get all the completion. And the only problem with that is that everybody else, includes me from about a
week ago. So you know, I might be smiling now, but I'll be sad in a week if I write my stuff in JavaScript.
I think the really baller move for interviews is to to use the types type system instead of the run. That's really where we shine.
Yeah, using uh the type system itself as ah as a programming language. Uh yeah, I know some people who do that, who dabble in that sort of thing. I used to do that sort of crazy stuff when I back in the day with C plus plus because as sexually, any language which which supports a sufficiently sophisticated generics can be used as its own, you know, quote unquote type programming language. Because you get conditional you effectively can implement
conditionals and loops uh via recursion. So so yeah, it's it's an interesting, interesting approach, but mm hmm yeah, mostly mostly a game and not something you want to do anywhere near production code. Yeah. By the way, one more interesting point about this whole thing about typescript and when it's appropriate. I have to confess that when Typescript initially came out, my initial attitude was kind of negative because all the original demos were around classes and enams, and
stuff like that. And it might not be surprising given that it was created by the same Microsoft people that gave us c sharp, and you know, back at the time they kind of, I guess, didn't really know any better. But my feeling initially with looking at the original sample typescript code that they were you know, showcasing, was that this is kind of a poor man's Java. And since I much preferred JavaScript to Java, that feeling that Typescript was kind of pulling me back into the Java realm
was something that you know, really rubbed me the wrong way. Uh, And I kind of like totally flipped on that. I did like a one eighty on that when I realized that you can do you know, function JavaScript functional style programming and get all the benefits of types with typescript. And now the typescript has come such a long way and you got so much inference going on and the cool things with generics and stuff like that, you can achieve very cool type safety and without having to use
classes and interfaces at all in your code. So yeah, so that's my confession about typescript. Does it kind of match your own feelings about the topic?
It does? Yeah, I think you really hit the nail on the head on the two big advancements in marketing the typescripts had. One is that at the beginning they were really appealing to people on the in large part on the premise of you can use these features you've been missing, which included both classes and the type system.
Nowadays the marketing doesn't really mention classes, both because that's a core part of the language now over a decade later, and because we accidentally ended up with the misconception in the community that typescript is more for class oriented rather than say, functional approaches, which is now that you've hit the nail on the second point that typecript actually supports functional programming and really really non class but still type safe approach as well, that I would even say that
that's a better way of using Typescript in many cases. So I think it's just really cool to see how marketing evolves over time as people learn better how to use and how to market a tool like typescript, for example.
But is it just marketing or is it also how typescript itself has technically evolved.
It's a good question. I would love to hear you interview every two to four years at the very rarest or at least common core folks from the Typescript team. To see how their answers to this evolve over time,
I'm sure would be fascinating. I think that if you look back at how typescripts discussions, which are many which are public, like their meeting notes and their issue responses have been on GitHub, it's been pretty consistent that they don't try to specifically go for say, classes and OOP, It's just that that was one of the big things they had to implement early on for standardization, for marketing for by I don't say marketing and drug protum might
just mean these are the things that people needed from typescript, but they've they've in virtually every discussion tried to pull the focus back from specific things like you know, supporting I don't know, injectable classes or supporting functional style insert paradigm here, and try to think, what are the common
community needs for type safety. What are the ways of bending or describing or manipulating types that folks are commonly using across many different teams, organizations, paradigms, and how can we build that in an dignostic way in the type system such that anyone benefits, not just specifically say classes.
I'm totally with you on that. I think that first of all, I have to say that in a lot of ways, the Typescript people like have a super hard job. I compare it to herding cats. Basically, you take the poster child for dynamic languages, a language that is dynamic but also has dynamic objects, like everything in job script is dynamic. Is it's dynamic as you can get, and then try to enforce the static type system on top
of that. And my feeling is that, especially in recent years, and to be fair and honest, I'm not sufficiently knowledgeable about the history and evolution of typescript to tell you know which features came first and which features came in later, and you know what happened sooner or later. I'm more
knowledgeable of JavaScript and Typescript in this regard. But what I see now is that in the past I had this kind of feeling that typescript is trying to force me to do things certain ways that sometimes I wanted to do. I had certain paradigms that I implemented in JavaScript in ways that I really liked, and I couldn't get them to work properly with typescript, and now I
can now. It's difficult for me to say whether it's because typescript has evolved and improved or because my knowledge of typescript has evolved in proved might be probably it's both, But the feeling is that you can now be much more expressive in what you can achieve with typescript, and you don't necessarily have to forego, you know, mainstream JavaScript paradigms just to get the benefits of typescript.
Yeah, I agreed. I think included in that second point of you're more happy with typescript or more typescript d yourself, part of that includes understanding intuitively what are the types of flows or types that typescript is easily able to represent.
There are a lot of complex things you can represent with typescript with a lot of glue and comfoolery, but the stuff that's really clean and beautiful and sistinct people tend to gravitate towards the more they write typescripts, which I think is a really good thing because typescript types are how we generally represent JavaScript concepts and the way our data flows and code. So if something is difficult
to represent in typescript. There's a very good chance that it's based on something that's not easy to explain to others or easy to represent in code. I think there's this kind of beautiful synergy there.
By the way, Jay Larky comments that quote, I think JS got better, so they had to do less stuff on top of JS nowadays. I agree, but doesn't necessarily mean that the typescript people have less work, because you need to support in the type system all this new JS stuff as well, especially since a lot of the typescript sophistication comes from the ever growing ability to statically analyze the code and figure out stuff like type narrowing based on logic that you actually see in the code.
So if you're doing like an if in the code and bail out a short circuit some condition, then it probably also narrows the types moving forward, because you've kind of ejected out that those aspects of the types that are no longer relevant. But by the way, speaking of all that and taking us finally to take it to ts s flint, it, you know, brings up an interesting point. You know, given all this sophistication and power in typescript itself, why do we actually need a linter for typescript? Isn't
typescript itself enough? In that regard?
I love it. There's so many good reasons why one would want a linter, and a few bad reasons, just for my emotional sake, If you don't mind, I'd like to start with the bad. A lot of folks to go for it, Yes, a lot of folks used to use eslint for a few things that, among others that we no longer recommend in the linting world. Formatting or
silly stylistic rules would be the big one. Es slint is a linter, which means you it allows you to provide a bunch of individual rules, which are little pieces of code that yell at you if your code is not working the way it should or it doesn't look the way it should. And then that's separate from a formatter which reformats your code or a type checker which looks at all the types.
In your code.
Formatter winter type checker. A linter is structurally not very good at formatting. So if you're using es and for formatting, there are a lot of gaps, like there are a lot of little edge cases that aren't really covered by any one rule, or it's hard to write that type of logic in a linch role. It's much easier to do a big formatter sweep, like with prettier. So there are.
Formatting is about just to make it clear to our audience about stuff like indentation, line lengths, line breaks, stuff like that.
Yeah, yeah, semichel and you know white space type Yeah, so uh there are. There is a project, really good one called the Lent Stylistic for in four in formatting with d slint, but it's not part of Core anymore, and a lot of people associated, oh it's yelling about me doing at me about semi Collin's with linter. Then then just stop using linters altogether. It's not the right conclusion, but there are a lot of really good things you can do with them. Generally speaking, winters can apply logic
in cases where it might be type safe. For example, you might be creating a promise which is type safe, but then you do something dangerous with it that's still type safe, such as not handling the rejection case of that promise, like if you forget to await it and then you console log it. That's all type safe, but that's probably not what you wanted to do, which means you still want a tool separate from your type checker to'll let you know about these probable mishaps.
So can you give a couple of examples of some of the rules that DSCS lint enforces. I know we discussed those in the previous time that we had you on the show, but I think it's still worth reviewing. Also if you've got some new one since then, you know.
Oh yeah. The classic example that we always jump to is promises like the you know you forgot to await type stuff, because that's that's a huge source of bugs, and we get a lot of reports from from people that that's the key thing they need from us, you know, having a having a function that returns a promise, particularly that in your code, and then passing it to something that doesn't know the function that's calling that you're passing
returns a promise. So then the async logic just floats off in the distance somewhere that that type of weird edge case that is still type safe but not right. Another one would be for in array is the rule or no foreign array, where there are two common ways of looping over an object in jobs this four in and four of four in loops over the keys for of loops over the values of inodurable. So if you use four in on an array, you'll get the stringified
array keys, which is technically type safe. That's technically something some people might want to do, but in practice, why the heck would you ever want to do that. That's that's a link rule yelling at you. Area of concern.
Yeah, four in is one of those things that in the language it's legal, probably doesn't It doesn't do what you probably expect, and therefore you should probably not use it. Or put another way, if you're Kive Simpson, then you probably have a very good reason to use it, but otherwise you probably don't. Then don't and don't.
Yeah, there's I think you touch on such an interesting point that there are a lot of people who are very very deeply experienced, knowledgeable, influential javascrip developers who do not see the value of linting, or at least do not themselves experience it because they instinctively, you know, they
always handle their promises, they know what they're doing. They don't write four in on an array, they write for of but a lot of the value the winters for people who don't have, you know, twenty years of writing javascripts and then typescript people who are still new and learning.
To be fair, there's a certain point in it, I'd say not seeing the value in linting is a bit harsh. I would say rather that they would disable certain rules that you probably want to keep enabled for most people. And but the reality is that usually like you don't work alone, and you want to conform to the race
the rest of the codebase. So the example that I like to give, and I don't know if there's a linting or formatting rule for that, is that whole debate about whether when you're creating functions named functions, whether you should use the function keyword, or whether you should do something like const name equals in err. I see a lot of people using uh. Now. Now, obviously they're not identical.
There are certain differences, and we can you know, touch on those, you know, but but to a great extent, it's an just an issue of personal preference. My personal preference is the function keyword, and I can explain why that is. But at the end of the day, is what I do is I conform with the project code base, Like if the project use it, does it prefers errow
named errow functions. I will use named errow functions because if you start, you know, deviating in your own code, you're creating an unwanted and unnecessary cognitive overhead because people will look at that piece of code later and say, hey, this code looks different than the rest. Why is that? Is it doing something different? You know, and they have to start thinking about it, you know, start they don't trust their instincts around it anymore, and that's a bad thing.
So consistency above everything else, and that that's another big benefit of linting, both stylistic linting and semantic linting. I agree that it generates consistency.
Yeah, that's something a formatter can't do because, as you said, sometimes there is a subtle logical difference between different keywords or different types, and that's something a type checker won't do because well it's all type safe. That's exactly what one of the big use cases for winter is keeping on.
So you said that some of the main benefit of linting is to highlight things that are correct, like using four in or not doing not putting a weight on your promises or maybe not putting a catch somewhere. So those are all things that are totally valid in terms of the code. Are probably something that things that you know are not right. That's put it is way you probably don't want to do. So it's it's it's a
warning rather than an error. Would be the way that I would phrase it, and then you want and that's where the linter kind of steps in. Is that the way that you would phrase it as well?
Yeah, it's a warning that in most cases you generally still want to fail the build down. Yes, yeah, for sure, there's a one more really good use case that it gets forgotten a lot. You can write custom Lynch rules. That's one of the big things that ESLNT became successful
from being able to support early on. If you're on a team that, let's say, moving from one way of calling an API to another, you can write a Lynch role enforcing you know that people use the new way not the old way, and you can even write a fixer like an auto fixer in your Olynch role. So migrant code from the old way to the new way as a form of a code mob and having been on a web platform team. I can tell you that's incredibly helpful and useful.
That is nice. So what is new in TSC slint. I gather that a new version is coming out, came out about to come out.
Came out type ship yes, and V eight thank you for bringing it up.
V eight is a special name.
I know we've had a few people get confused about how it's not the Tomato juice and it's not the engine underlying you know, Chromium and JavaScript. But it's our newest major version. It has a lot of good things in it. Just the high level overview is every major version we improve and iterate on the list of recommended rule sets are little sharebok in things. This one has ESL and V nine support, which was unfortunately kind of
delayed on our end. And it has this new thing called the Product Service, which makes typed rules the most powerful rules we offer a lot more we hope, easy, straightforward, understandable to configure. So we're really excited about it.
So what's the thing that you're most excited about in the context of the new version?
The Project Service. A lot of the lint rules that we just talked about and that are elsewhere mentioned about being awesome and powerful need type information. For example, we said no for in array, Well, how do you know what is an array? Or you know, properly calling a function that's a sync and make some promise, how do you know the function is a sync or re turns
of promise. In general, you have to use a type checker for that because what if you import it from a file or some other MPM package or something, and in order to do that we have to then call into the Typescript APIs And there are not that many products that do at. So this is still kind of a new and exploratory area in the realm of JavaScript
typescript doing so. The project service is this term for this new set of APIs that we're using from Typescript at align type checking to behave more like what you're using your editor, which means it's a little easier to set up. We can infer more stuff and it shouldn't have these weird differences where eslint understands something differently than what you see in vis code.
Cool. So it's like effectively leveraging the language server to a greater extent.
Yeah, yeah, a lot more code path sharing under the hood. We use what the typescript calls it, the project service, which is the set of functions provided by Typescript that you can pass a path to a file and we'll give you back here's how to describe type information for the file. Some APIs like that, which is really exciting because previously we were manually creating those things on our end,
effectively doing what the project service does for us. And because we are not Typescripts, neither technically nor organizationally the people behind it, we weren't doing as good of a job as what the project service is able to do now.
By the way, one more point that Jay Larky brought up in another comment is that some things are framework specific, like rules of hooks or solid lind for restructuring props. Yeah, that's absolutely true. I mean, you know, these days, most typescripts JavaScript developers work in the context of a framework and a meta framework, and there are let's call it, additional rules that are that are or paradigms that are
more specific for whatever framework you choose. So things that again are totally legal in the context of you know, general purpose typescript or JavaScript might be things that you want to avoid in the context of framework, and indeed the structuring is probably in issues with the structuring in solid is probably a good example where you might unintentionally lose reactivity because of the structuring that's perfectly legal in JavaScript and typescript.
Yeah, shout out j Larkie a great point.
Yeah, by the way, it's an interesting In another context, we had the people from the Meta team a few what's it weeks months back talking about the new React compiler, and interestingly that compiler also has a linking aspect to it. They have like the rules of React, and they're looking at ways to enforce best practices of React using that compiler. So it'll be interesting to see how they flag things,
whether it's the errors of warnings or whatnot. Like you said, even if it's warnings, there's a good chance you still want to break the build. But interesting. Yeah, it's interesting to see blinting making its way into so much stuff.
Yeah, I'm really excited about it. I think it's a really really cool area and it's really useful. And now that folks respect it, you know, it's it's getting more and more stuff.
Mm hmm. And I now that that's out, I imagine that your work you've started working on the next version, right.
Yeah, we tend to reserve a few months even in a year or two at most, probably just up to a few months after each major version of just cleanups. You know, we released this big new thing, this project service, which is a different way of configuring type flinting. Well, now we have all the myriad different ways people were previously setting up type plinting coming in and telling us way as it does or doesn't work for them. So
there's a lot of clean up there. Also, I think there's a lot of value in a project just spending time working on things that don't have a huge determined purpose like you know, paper cuts, cleanups, documentation improvements, which is I think the phase we're in right now.
Hmm. Cool. So you're not yet thinking so much about V nine at this point in.
Time, Yeah, not so much. I think long term, there is a new snazzy thing we want to start using more, which is there's an API that typescript used to not expose called the assignability API. Is type assignable too previously in type checking. APIs to the stuff that Lynch rules can use. You can you can get the type for something, you can say, get the type of this function, call the returns type and see if it's let's say, a
promise or something with a dot. Then but you couldn't check two things and see if one is assignable to the other, like if this number is assignable to that string or something else. But now that that API is available to us, they marked it as stable and you can use it. We think there are a lot of
really interesting Lynch rules you can do with it. For example, you could, instead of just saying no inferable types, don't at of type annotation that's triple legal to the same as whatever type something is, you could write a linter role that bans type annotations that are wider than the thing. Like if you say constant value colon string equals quotes, we can say, aha, that string is actually losing type information.
Typescript by default would be able to infer that this is some string literal or union of literals rather than just the general string. So very exciting stuff.
I know, Yeah, no, this is this is cool. Look, there is a challenge here, and it's it's an issue that's been brought up by people like THEO I think
and others. Also Ryan Carniato about how like that typescript really has two target audiences in a way, there's the distinction that they may it was between application developers and library developers or library makers that application developers usually are able to use it at you know, without diving too deeply into sophisticated types, and library developers or people that
create APIs are kind of forced to. I think the line is often drawn around generics, but you know, I'm it seems to me that generics is becoming more like, you know, public domain like it's it's no longer such black magic that as it used to be, I think. But you know, it's an interesting point and I'd love to hear from our audience about that what they think. So it used to be that, you know, if you were an application developer, you could use typescript without having
to understand how generics work. But if you were a library developer, if you created APIs, you had to understand generics. It's interesting to think whether or not a tool like E like ts S SLINT can in a sense make it easier for people to up their typescript game, like to be more like library developers and not and being able to do it without getting too much in the weeds. Like The alternative, of course, is to use some sort of chat GPT like tool to write your typeescript for you.
But I'm wondering whether something like eslint ts slint can also help in that context. What do you think?
Oh, I have so many thoughts here, yes, strong degree. Another big benefit of interrules can be best practices, not just the you know, don't use four in on an array, but things like preferring you know, stylistic consistency and how you write your types. Types versus interfaces is one of the big debates in type scripts, where much like the functions you mentioned earlier, the answer is it doesn't matter,
just be consistent. We do have quite a few rules though that that flag common bad practices that results from people not having that full deep understanding and then let you know, hey, this is why it's wrong. Here are the option or options to fix it. I think the two really exciting big ones that I can dive into if you want are empty types and the golden rule generics or unnecessary type parameters. Those are two big ones that a lot of people trip up on that we now have line rules to help people.
Learn no, please do, please do awesome.
So the empty object or the just curly boys object type in typeescript that describes any object any value other than null and undefined. So you can say let value colon curly brackets. Just empty object equals quote something. The string is a value in JavaScript and typescript. Therefore it's assignable to the empty object type. Same with number. The literal zero is allowed, which is horrifying and confusing to
many people. So we have a win role that says, hey, don't use the empty object type except in certain situations where it's reasonable to. Instead, what you probably want is an insert list of common alternatives, such as unknown or non.
So basically, just to clarify though, in typescript, when you use empty object as a type, not as a value, but as a type, it means anything which isn't null or undefined.
Yes, I might be missing some nuance there, but that's roughly what it comes out to in production in practice.
Okay. To be honest, I'm you know, I'm struggling to remember if I've ever used this. Probably not. I prefer my type to be a bit narrower, fantastic. It's not much better than in any. Let's put it this way.
Yeah, it's it's like it's this weird kind of halfway between any and unknown, where a lot of things are assignable to it, but you can't really do anything with it. And honestly, some people just happen across the type and then use it instead of unknown. That's like a really common slip up there where they should have just used unknown or any.
Yeah, that's what Jay Larki is saying as well.
Hi j Larki.
Yeah, so you you've got an S T S C slint. It's a problem. I start saying is lint, and then I remember to say ts. So you've got a T SC slint rule? That basic? What forbids it?
We used to have. We used to have a rule called band types, which banned a list of problematic built in types such as that and uppercase en number as opposed to lowercase end numbers same as string and boolean. We split it up into several rules. So the specific rule we're talking about now I have to go to our website to look up the name because I can never remember is no empty object type that's specifically.
For that one.
And then we have a few other rules for other problematic built in types, like the uppercase built ins.
So it's basically it's kind of like JavaScript in a sense. And it's not surprising that once type script adds stuff in, it's very difficult for them to take it out without you know, breaking an extinct code basis. But it's easier for you guys to add rules that forbid it.
Yeah, and arguably in this case they made the right choice by having it as is. On my right, Let's say generic function that takes in a t a generic type that extends any object with length number as a property. So you could pass in strings arrays some object that happens to have length on it. That's all fine, intentionally, that type that squiggly brackets length number type allows a raise because the rays are objects that happen to have
a length property. It would be weird and confusing if removing that length property from the object now meant a raise. Warrant allowed in this case. So there's no real right answer here. Either you have a weirdness in the type system, or you have a weirdness in the type system that also tips people up, sometimes in a different way than before.
Interesting. Okay, So that was one interesting example. What will you had? The second one was it? What was it?
I respect and appreciate that you remember that I'd forgotten about it. It's a new rule called no unnecessary type parameters. It's based on what's called the Golden Rule generics, which is actually comes from another types good book published by I Rightiley I'm authored by Dan Vandercamp, who then was a co author on the PR adding this lunch role. Shout out Dan Vandercamp. But the idea is people oftentimes write generic type parameters for functions that don't actually do
anything or actively hide type errors inside. The most common one is they'll write wrappers around Jason dot stringify or some kind of parsing thing where they'll add in a generic type, saying, okay, the result of this function is whatever generic you pass me. Let's say Jason dot stringify my type turned Jason dot pars thingy as my type.
The problem is there's nothing in the type system that actually verifies the value you return from that function is the type you said it was, and there's nothing at run time either, So this is unsafe. Someone could pass a totally invalid string and your type parameter usage made it look like the return of that function adheres to that type, even though the totally invalid string gave you some other garbage. So this is what's called the golden
rule of generics. Only use type parameters if they are actively useful, if they're actually used to relate two types later on, or if they're somehow used repeatedly throughout your type signature. This rule is new, and I'm still not sure. I'm quite good at explaining it. Did that kind of make sense?
Yeah, but I'm still thinking about it because but obviously, if there's a type that you pass in that you don't actually use, like an unused parameter, that's really easy to flag, but you are talking about something else.
Yeah. Unused would be that it's declared once and never used again. Unnecessary in this context would be that it's declared once and used once, such as in the return.
Of a function.
The point of a type parameter is to relate two things to say, based on the input. The output is defend if you're.
Yeah, if if you're just let's put it this way. If the type can never be inferred, then it's kind of and it's kind of pointless in a sense. I need to think about that though, like you might explicitly pass in a particular type. Let's put it this way. Whenever I'm whenever I'm using generics, and I find myself being required to explicitly specify the type rather than having it being inferred, then it kind of feels like a cold smell. Yeah.
That's a great point, both on this context and just the general usability if you should stry sure you're you know, generic, such that people don't have to do weird explicit things. The I think a better example that I should have given to start would be let's say you're writing a generic log function. Log takes a typecharameter T and a single value of type T and returns void. So you could like log parentheses some strength, or log parentheses in a array or an object or whatnot. There's no point
to that T, to that type parameter. You're not returning it. You could have said unknown for your values type and there would be no functional difference in your code or its types. So that T function log t parentheses value T. It's not unused because the value is still type T, but it's unnecessary. It doesn't change the return type. It doesn't relate anything. Does that make sense.
Yes. Here's the thing though, because in in other programming languages statically typed programming languages where where the type system is part of the actual compile languages like C plus plus or Java or C sharp, then these case it is useful because that's for two reasons. First of all, that's how they make themselves more like JavaScript. And the second thing is that it allows them to have different
implementations thanks to functional overloading. So they can have like a generic parameter like you said, t, and the type goes in, but then they have a different implementation if t is a string or t is a number, or t is an error or whatever. In JavaScript, those things are meaningless. First of all, you don't need to create dynamic on type of JavaScript because it is. And with Typescript, like you said, it's just any and you've got it.
You've got the same dynamic capabilities that you had before, and you don't really have implementation overloading. So both of those benefits that you have in other programming languages are kind of meaningless in the context of Typescript. But like you said, it's too legal. So yeah, it's a place where the linter can kind of step in. But yeah, I think that's a really good example.
Thanks what we've seen when people adopt the rule in larger code bases is still have the occasional little thing like the parts of the log function. It'll catch, you know, save them a few characters or some clarity here and there. But then deep in their utilities library, there will be this long trail of deleted code where there's this chain of whatever five things deeper. At the very bottom of
the chain, there's an unnecessary type parameter. And because of that unnecessary type parameter existing, they previously had all sorts of places passing type parameters through piping it down to get there. And once we remove the unnecessary typearameter, we could delete a dozen different type parameters in their code, making it all simpler automatically or semi automatically with the rule, and it doesn't actually harm or remove anything that was useful.
So this rule, I think is going to be more and more exciting to people as time goes on and we advertise it and learn about it more.
Yeah, I've been thinking about another way to phrase it. At the end of the day, we have to remember that in typescript, ultimately all the types get stripped away. Types that you put in have zero impact on the code that gets generated. They're they're totally they're deleted in this context by the way. You know, it could have
been a pick. But it's interesting, what then, what Node is now introducing with that ability to like with their support for typescript, which which literally just strips out all the types. And therefore, if if the types have zero impact on run time, they're value is that they assist you during the development time. But if they don't do that, then they're pointless.
Yes, yeah, well, I mean I would say there is one point to them, which is some people feel very good when they put types in that are very complicated, and that honestly is a reason for a lot of the really complex types out there. And you know, sometimes
it's worth it, sometimes it's not. I think a lot of developers go through a lot of growing pains adding types, getting excited about it, and then realizing, oh no, not all this was useful before they find that beautiful zen of only adding them where it's it's actually functional.
Let's put it this way. You can have sophisticated types in your typescript if the end result is that the actual user of the API can avoid specifying any types. That's the true beauty of sophisticated types in typescript. Yeah, if you're the user of your API needs to specify types like in generic types, then then my argument is that it's a code smart you kind of failed.
Yeah, it'd be cool to see if someone could enforce that with a Linch rule. You know, I don't know how that would work, but there whatever is the best practice. My instinct is to try to and codify it, even if it's not possible. You know, there are some best practices that are not really code capable.
So, unless you've got more things that you want to say about typescript and types and linting, I think we want to talk a little bit about squiggle COMF, don't we.
Yeah, let's do it. Squiggle COMF Conference for Excellent Web Dev twoing, Sparkle Emoji.
It's it's one of those times where you actually want those automatic reactions that you get on the Mac where you do like something like that or balloons pop up. I can never get it to work when I wanted to work.
Yeah, I think I disabled them at the OS level and then completely forgot about it. And I always get this point.
So squiggle like I think you might have said that it's because of the squiggle lines that we get from developer tools that you know, want to highlight certain things or draw attention to certain things, so they put a squiggly line under it. I actually think that it came it was we had it first in things like word or office before it actually made its way to developer tooling.
I think, yes, Like I also think that, but I'm not sure myself.
Yeah, like spelling errors and then grammar errors and stuff like that and anyway, so that's the Moulti's that's where the name comes from. Right, It's because the topic of the conference is developer tooling, right.
Yes, we're talking about I mean the catphrase is excellent web debt tooling. But in general, yeah, it's anything that you, as a person writing web such as without limited to JavaScript, typescript rust might want to learn about. So everything from typescript at scale at say how Bloomberg does things to the person who may know my Zisha's talking about the journey of that open source tooling and the lessons learned.
So first of all, when and where.
October third for talks and then morning workshops October fourth, that's a Thursday, twenty twenty four, so at time of recording in the month and a half.
And it's like, is it online, is it physical? It is?
It's physical. Will put the talks up for free videos after the conference. But the location, the venue is the attached theater at the Boston New England Aquarium, so we have got a bit of a fish theme. I will say, there's an excellent penguin exhibit next door at the aquarium itself, and we're on the pier, you know, like on the water, so I think it's going to be a lot of fun. Lunch is going to be at Feneral Hall that like really nice too of her Steam marketplace right next to
the venue. And because it's a Thursday during the week, you have to be not so crowded.
And it's so it's one day for the talks and the second day for workshops. That's the format.
Yeah, morning workshops. We're trying to keep it a little smaller. I think our deal would have been two days of talks with some workshops, but it's our first time and we wanted to make sure we could get it right before really going thick.
Can people still get tickets?
They can, and I would encourage them to do so. Fun fact that a lot of conference organizers have told us we've seen also that most people wait until the last minute to buy tickets, which is horrible for two things. One it's well, you never know, maybe they'll sell out. Two it's very scary for US conference organizers.
Yeah to see.
Yeah, so please buy tickets. Discoidal the com We got both discount options on the website. We're happy to work with you if you need help getting it. We also have volunteering options if you can't afford a ticket.
So let us know. So how many talks are you planning to have me?
Get that schedule up right now? Currently our plan is nine full length talks and five lightning talks.
Oh cool, that's really nice. Any any ones that you especially want to draw attention to, you.
Know, I fear I fear responding to that to assertively, as I don't want to upset any speakers. But I'll say our launch speakers, as an arbitrary delineation are Dan Vandercamp whoever. Earlier he's talking about ASTs and source code
and text like how source files actually work. Roselle Scarlett over at TVD talking about documentation as part of your tooling and processes, and Tishy and Cinacova dragon me are over at Bloomberg talking about Typescript at scale and the things they do to manage a gigantic amount of Typescript code. Also fun fact, they contributed some great features.
Up to Typescript. Yeah, they're doing some really interesting stuff over at Bloomberg, that's for sure, So that is really cool. Also, Boston is obviously a beautiful city. Yeah, and October that means like fall, so it's like the trees will be all red and stuff.
I hope, So, to be honest, I'd originally really wanted a Halloween conference, as that is my favorite holiday. By far, I was told rather bluntly that parents do not want a conference instead of trig or treating. It's not something that they can support. So yeah, I think we'll have a good fall thing going on. You're right. It's a
beautiful city, beautiful area. And one of the things we intentionally did was have it on a Thursday with workshops next morning so that speakers can go with us on a ductor after and then we're going to try to get some kind of partnership with the aquarium to tell people explore that.
Are you also still looking for sponsors and stuff like that.
If someone wants to sponsor us, they certainly can reach out. It's on the website. But we've got a good set of sponsors so far. I can't now them all, but we're pretty happy with it. Yeah. No, if if you want to send us money, we're happy to work with you.
That's really cool. It's it's really nice to see a new conference appearing. It's ever it seems like ever since COVID, you know, conferencing has been in a bit of a rut. Like we all hope that it would make a total comeback after COVID, but it seems to be fairly challenging, and I'm even seeing certain conferences like suspend operation and so seeing a new one come along, especially about such an important and exciting and interesting topic, seems like a
great thing. And hopefully I can get my own employer to sponsor let's say next year or something, because we are also into developer stuff. You know, some of our stuff is and ready yet, so we're not ready to showcase it yet. Hopefully next year we will be. So we will say we will see. I'd love to talk at the confidence like that. Anything else before I put us in two picks.
No, I appreciate actually, yeah, one thing. I appreciate you giving me the opportunity to like scriggle comp The reason why we chose to have it this year, you know, post COVID, neither neither of us two organizers actually live in Boston. I'm moving into August this year. Is we agree it there's a lot of benefit from conferences. You don't have to go to a conference, you know, to be whatever a great dev infortunate, et cetera. But there's a lot of benefit from the Hallway track, from just
chatting with people. Oh yeah, for giving cocks. So we're really excited to be able to provide that, you know, to people, both generally in Boston and generally in web dep tooling, which doesn't have a lot of dedicated conferences for it specifically.
Yeah, it seems like it should mean like developers are so into tooling. It feels like we are, like we definitely should have a conference about tooling. So it's it's great that finally we do.
Yeah.
But by the way, so this is I think, is it your first time as a conference organizer.
Yeah, I've helped out with conferences before, like websites are helping with promotions, but nothing quite so in the weeds as being an actual organizer. And I gotta say it's a lot of work. They were right, all the people who told us it was a lot of work.
Yeah, for sure, h happily I've I've yet to to to do it. I've I've spoken at conferences as have you, but organizing I don't know. I'd rather let somebody else do it. Okay, Then before we go going to picks, if people want to, you know, connect with you, be it about TSC S, flint, about linting in general, about open source, about squiggle conf what's the best way to reach out to you?
Love the question for me. Joshua K. Goldberg on virtually every platform dot Com, GitHub, Twitch, YouTube, Twitter, Blue sky Mastered on Joshua K. Goldberg for my projects. Each of them have their own website. So tych it b a slint, be a slint moca. Yeslint time, but on the committer team. So please don't come at me yelling about flat configure or whatever pain you're going through. That's the team at holl but for all of the projects, we're always happy to hear your feedback and work with you.
Cool. Okay, then I'll pull us now into picks. To be honest, if I don't have so much in the context of picks, I actually, you know what, I actually have two things. So my first pick is I might have mentioned this before. I recently started tweeting out my
favorite stand alone fantasy novels. So one thing about fantasy books is that fantasy authors really love to write a series of books, usually trilogies, but not necessarily, and I sometimes want to just go for a single standalone books, something that you know, you can read on its own, finish it, and then kind of move on with your life. And that's especially the special benefit is that you don't have to worry about when the next book is ever
going to come out, you know cough cough. You know uh George R. R. Martin and uh you know Game of Thrones and Tales of Ice and Fire, which seems to be to be honest, if he ever does come out with with the next book, which is I'm highly doubtful of, I probably won't read it now. It's it's the time. The time is coming gone anyway, So I I tweeted out the list. I actually have a couple of more books that I have to tweet out in this context, so you know, let me see if I
can remember some of the examples that I gave. One of them would be Neil Gaiman's Never Where Have You Read It? No?
But I know the author name.
Yes, and uh. Another one is uh Zilasni's Lord of Light. Roger Zilasni was a very famous UH science fiction and fantasy author, very prolific, now deceased, so he wrote some very famous series of books. But I have a very special spot for the Lord of lightbook, which is a standalone book. And and you know, I'll basically i'll i'll post the link to that Twitter thread that I keep adding to in the show notes, so that would be
my first pick. And by the way, if people have their own favorite books that they want to suggest, you know, feel free to send them to me. I love a good I love suggestions of good books. Another one, by the way, you know what, I'll give you another one or two. There's a Weave World by Clive Barker. Have you heard of Clive Barker?
Vaguely familiar name.
Yeah, he actually is more famous for writing horror related stuff, like the Pinhead character if You is from one of his books. And so he wrote this crazy book called weave World, which is a crazy combination of It's like part fantasy, part horror. It's very weird and it's very wonderful in my opinion. So that's another great standalone book. And another one would be Kigana by Guy Granville k. He's the guy that worked with Christopher Tolkien on releasing
the Silmarillion. They basically went through Tolkien's notes and writings and and basically managed to make a book out of it. So he wrote some book on his own and his stand alone book is called tigan and it's also a great book. I think I actually picked that one. You our in the last episode that I participated on, sort mentioning it again the second. My second pick is I've been kind of down. This is this is not a good time for me. I mean, on a personal level,
things are fine. I've got a new job that I'm happy with, Everybody in my family is healthy and whatnot. But my my mother in law passed away, and in Israel in general, it's a it's a bad time, and uh yeah, so I've been kind of down and I'm, you know, looking for things that can pick me up. And my wife and I happened on the Despicable Me Sash Minion movies and we kind of rewatched several of them and they're so great. They're so lighthearted, funny, pleasant
to watch. The Minion characters are obviously wonderful, but not just the group character is great as well. So yeah, if you're looking for pick me up, I would definitely recommend these movies. And those would be my picks for today. Do you have any picks for us?
Josh, I do plus one ted having some nice, lighthearted, high quality lightheartedness in today's world. I've been wanting to become more of a reader. I used to when as a teenager, read constantly, I know, exhoomed everything from the depths of the sci fi fantasy section of my local library, and I haven't done that as much recently, so I'm still kind of catching up. So recently I've led kind of the classics that a lot of people may know. Neuromancer is a great sci fi book. I think it's
rather influence on the genre. I'm not cutting new ground here. I recently read through the Foundation series also, which was very good, really really changed over the course of the series. Yeah, yeah, a lot of respect for that.
People should be aware that the book series is very different from the TV show. Both are actually pretty are good, but they're very different, both in terms of tone and the actual story. Yeah.
Similar. On that note, Witcher loved the game, you know, Butcher three was the one I played. I've been meaning to play the others, and then I'm in a book club with some friends reading the series. Not a huge fan of the show, to be honest.
Yeah, to me, to be honest as well, I wanted to say it. I tried to watch the show and I couldn't get into it.
Yeah, there are a lot of great parts of it, especially Henry Cavill. Oh my gosh, but that one bathroom scene, but his acting is phenomenal, and just I couldn't get into the rest of.
The show, you know. Yeah, yeah, this is what it is.
It is what it is. Now. Otherwise, my wife and I we've been watching Monk, the old TV show. It's kind of hard.
It's on Netflix, I believe.
Yeah, yeah, midway through it. It's quite good. Highly recommend it's it's very nice. It's kind of the I think the epitome of that genre, that era of early two thousands episodic shows where people they had an appetite for actual good shows, but it wasn't you know, there's really deep intense stuff you get these days with these HBO mini series.
Is so yeah, you could was just a single episode. Then it's totally self contained. It's not quite believable, like you know, it's it's funny to compare to a lot of the British TV shows of the same time or the same era, where in the American shows you had like that every episode was self contained. So I feel like it was a crime drama. The crime happened at the beginning, they solved it, there was a trial, the
criminal got convicted done. It's like, you know, Law and Order I think was the epitome of that type of shows also and also CSI, whereas the British shows they kind of, you know, the entire season was just the one crime, and then the mini dramas of that you get on streaming today kind of emulate those those British shows where it's the entire season for that the one crime.
Yeah, different that actually, by the way, reminds me I fell in love with the show Good Omens, the British one. I had never heard of it until it randomly popped up and read it or something. But it's fantastic. Highly recommend. It's this whimsical, I don't know, you know, biblical characters in the modern day. It's it has Michael Sheen and David Tennant. John Ham shows up in the later season. Really really good stuff. Highly recommend.
Funnily, I read the book, but if not seen, not watch the TV show. The book, by the way, is by Neil Gaiman and Terry Pratchett.
Yeah, it's hilarious. It's it's all sorts of lever. I'd say, it's I don't know how to describe these it's like very British humor, Like you know, it's it's these characters who driven by these odd quirks, just getting these ridiculous situations. But it's also this really compelling story about you know, good versus evil and the nuances and the inability to define those two concepts in a dynamic, people driven world.
If that's your jam, then I would highly recommend that you read, not watch, read the Hitchhiker's Guide to the Galaxy series of books. The movies pretty bad. The books, on the other hand, are awesome. Okay, So so if that kind of sense of humor carry, Pratchett was very much inspired by Douglas Adams, let's put it this way. Yeah,
So with that, I think i'll end our show. Thank you again for coming again onto our show and speaking both about tsslint and about squiggleconf and putting yourself out there and all the best with both endeavors and with the move to Boston.
Thanks Dan. Yeah, I really appreciate you having me on here, letting me plug things, and also, you know, best of luck with the new job and getting them to sponsor school Comp twenty twenty five.
Yeah, that's hope. That's hope. So okay, bye everybody, thank you for listening in. Bye bye.