Long time friend of the show Gil Tayar joins us again this time to discussing using JSDoc for JavaScript type annotations instead of TypeScript. Turns out that you can now get all of the benefits of TypeScript types without having to adopt the entire TypeScript workflow. Gil describes the benefits of this approach, and how it could impact the future of Web development.

Sponsors

Contact Aimee:

Contact Charles:

Contact Dan:

Contact Steve:

Special Guest: Gil Tayar.

Sponsored By:

Gifting is hard. This isn't news, but what might be news is that you can now send beer, wine, and spirits right to your friends and family with Drizzly, the go-to app for alcohol delivery. Save time shopping, save money comparing prices across stores, and spend more time sipping with your gifties. Now that's good news. Download the Drizzly app or go to drizzly.com. That's D-R-I-Z-L-Y.com, and get your favorite drinks delivered today. Must be 21 plus, not available in all locations.

 

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: Steve Edwards. 

STEVE_EDWARDS: That's Steve Edwards, the fun guy, not the smart guy. Don't forget. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hi from Mormon Sunny, Tel Aviv. 

CHARLES MAX_WOOD: I'm Charles Max Wood from devchat.tv. Quick shout out for devinfluencers.com. We have a special guest this week and that's Gil Tayar. Did I, I'm always worried I say people's names wrong. 

GIL_TAYAR: Uh, you got it right. Which is people usually don't. So, hey, yeah, sounds like. 

 

This episode is sponsored by Sentry. Sentry is the thing that I put into all of my apps. First, I figure out how to deploy them. I get them up on the web. Then I run Sentry on them. And the reason why is because I need to know what's going on in my app all the time. Yeah, I'm kind of a control freak. What can I say? The other reason is, is that sometimes I miss stuff or I run things in you know, works on my machine. I've been there, right? And then it gets up in the cloud or up on a server and stuff happens and stuff breaks, right? I didn't configure it right. I'm an idiot and I didn't put the AWS credential in. I didn't do that last week, right? That wasn't me. Anyway, I need that error reported back. Hey Chuck, I can't connect to AWS. The other thing is, is that this is something that my users often won't give me information on and that's, hey, it's too slow. It's not performing right it's slowing down because I don't want them going off to Twitter when they're supposed to be using my app. And so they need to tell me it's not fast enough and Sentry does that, right? I put Sentry in, it gives me all the performance data and I can go, hey, that takes three seconds to load, that's way too long. And I can go in and I can fix those issues and then I'm not losing users to Twitter. So if you have an app that's running slow, if you have an app that's having errors, or if you just have an app that you're getting started with and you want to make sure that it's running properly all the time. They support all major languages and frameworks. They recently added support for Next.js, which is cool. You can go sign up at sentry.io slash sign up. That's easy to remember, right? If you use the promo code JSJABBER, you can get three free months on their base team plan. 

 

CHARLES MAX_WOOD: All right, well, Gil, we're happy to have you back. You want to tell us what you're up to these days? And then I think Dan wanted to brag on you a bit as far as what impressed him about what you're doing.

GIL_TAYAR: I'm currently a senior software architect, whatever that means. 

CHARLES MAX_WOOD: It's impressive. Super impressive. 

GIL_TAYAR: Yeah. You know, you imagine like an army of architects and I'm the senior one, except I'm the only one, but I'm too old to just be an architect. I basically I'm the architect at a company called Round Forest, which does e-commerce, comparison, shopping, recommendation engine for products on the internet. And we're building the whole new engine, the recommendation engine from the ground up using Node.js, React, TypeScript, well not TypeScript, we'll talk about that in a second. That's basically what I do. Previously I was in Wix, which is where I met Dan Shappir and we've been friends ever since. 

DAN_SHAPPIR: Yes, indeed. So as we discussed before we started recording, I was the one that actually invited Gil on the show this time. And I'm going to say this time because I think you've been on the show like, what, this is your third time, fourth time? You're, you're, you're a friend of the show. I think we can trim you. 

GIL_TAYAR: Thank you. Yeah. It's always a pleasure. Uh, definitely. I think last one was about ES modules and I think there's a thread connecting both of those and maybe we'll talk about that. 

DAN_SHAPPIR: That'll be definitely interesting. So it's a funny story. I got to start a new project within Wix some months back, I think something like a year back which was literally creating something new from the ground up. And I was thinking about whether I should implement it using TypeScript or plain old JavaScript. And there were benefits, upsides and downsides to both these approaches. By the way, Wix is really big on TypeScript, but there's still a lot of stuff at Wix that's being implemented in JavaScript. And I was kind of on the fence. And the reason that I was on the fence was because this particular project was essentially a library that was a relatively thin layer over browser APIs. So I didn't feel like I had to construct really significant logic constructs and stuff like that. And also it happened to be dealing a lot with property bags, objects that are essentially just collections of data, or you can think about them as JSON objects. And it can be kind of a bit annoying to deal with these sort of things in TypeScript because you need to specify all of them, like create the type, the interfaces for all of them. And if they change a lot and a lot of the fields are optional, then you kind of feel like, what's the point? I'm maintaining something that isn't providing a whole lot of value because this object can literally almost contain or not contain anything or everything and why am I trying to specify that? So I was kind of debating with myself what to do. And then I came across a blog post that Gil wrote, more or less I think at that time, about using JS doc for type information in JavaScript instead of using TypeScript. And I looked at it and I got really excited about it and decided that that's what I'm gonna do. And that's what I did. And I'm really happy with the results because I kind of feel like I got the best of both worlds. Interestingly, after discussing what I did with Gil, it turns out that the way that I implemented it is somewhat different from the way that he actually implements the same approach in his projects. But we can talk about that as well. But in any event, after I read it, after I used it, and after enjoying it so much, I thought that it would be an awesome idea to have Gil here on the show to discuss this exact approach to implementing JavaScript projects. 

CHARLES MAX_WOOD: Now, hold on. Because, I mean, I know Anders, I have a lot of friends who do Angular. And I thought that TypeScript was the way and the truth. So I mean, what are we talking about here? As far as because TypeScript, it isn't just typing, right? There are other features. They implement some of the ES what 20, 21 or 20 anyway, ES. Six plus ES. Next features in it as well. So there are other things that you get from it. So do you get that, that kind of thing from JS doc as well, or is this strictly speaking type annotations? 

GIL_TAYAR: Okay. Well, TypeScript started out as a combination type checker and transpiler. So it both type checked your code to see whether the types are correct so that if you pass a string to a function that needs a number, you will get an error. But it also transpiled the code. So if you had like ES2018 code back in the days, it could transpile it to ES5 or ES6 or whatever needed. It still does that today. But if you're not using, if you're not going to IE11, there's actually no real need today to transpile most of your code. And the little things that you'd like to do, like decorators, which anyway are problematic or whatever, then Babel can do that just as easily. So these days TypeScript is seen mostly as a type checking engine. I'm not saying that it's not there also for the transpiling, but if you look at the feature set in the last three years, there have been no features that go beyond whatever stage three features there are in JavaScript. So yes, they implement things a little bit further. They go to stage three and not stage four, but that's about it. Basically the same feature set that you get with Node and V8 and Firefox and Safari, even Safari. So yeah, you're right. It used to be a transpiling engine. Today it's mostly type system. And Microsoft itself views TypeScript as JavaScript with types. Definitely. So in the end, you can use JavaScript two ways. You can say, I love the dynamic nature of JavaScript. When I have this function add, and I give it a, b, and I return a plus b, then I'm fine with somebody calling it with two strings because the user will figure out the bug or or our tests will figure out the bug, or I'm really, really smart and I can figure it all out in my head and whatever. And you know, my ancestors used JavaScript that way. If it's good enough for my ancestors, it's good enough for me. So you could use JavaScript that way. But a lot of people are migrating to TypeScript because they want the safety and comfort and usefulness of types. And obviously this comes with, you know, attacks. Yeah, you have to specify that A and B in that function add are numbers, whereas in JavaScript you don't. So there's like, I would say a 5% tax, 10% tax, maybe on your code, on the time you take to, but you get it back, like with interest, because types enable you to understand what you need to pass to a function and enable you to catch the errors even before you run your really, really good tests. So that's why like it's not a migration. I see it today as a stampede towards TypeScript and not away from JavaScript because any valid JavaScript program is also a TypeScript program, but a migration towards adding types to JavaScript. Until now, the only way you could do that was through like two type systems, Flow and TypeScript. There was, you know, Facebook's Flow which also had the ability to add types to JavaScript, we added syntax for specifying types. TypeScript won like knockout. So today you can write dynamic JavaScript, which is great, or you can migrate to TypeScript and use that and have the safety of types. 

DAN_SHAPPIR: Before you delve deeper about that, I do want to mention a point and also maybe like, a voice a bit of an objection on something you said. So my first point is that one of the biggest benefits from my perspective in adding a type system to JavaScript and TypeScript obviously is the leader in that regard, maybe the only, almost the only game in town these days is during the development process itself and that means while you're working within your text editor. The fact that these days when you're writing code in the editor and you're implementing, let's say, some object, and you press dot, it used to be that in the old days, more or less, if you got the completion that suggested two string, that was almost all you could expect to get. Because all the editor knew about your object, more or less, was that it probably derived from object. And that's about it. These days, if you have type annotations on your variables, then when you click and let's say that variable is called X, which is obviously a really bad name for variable, but let's say it is and you do X dot, then it knows the type of X, it knows all the properties that could exist on X and it implements the completion automaton and it proposes the relevant completion options for you. And we kind of discuss this whole topic at length when we talk with Kyle Simpson, another friend of the show about code nine and using even AI for completion. So the support that you get in the editor is much better when you're using TypeScript. I find it, by the way, especially useful when working with complex APIs like the DOM itself, because there are so many functions there and you can never remember exactly which argument is what. Also, the text editor will do this squiggly red line if you to use an incorrect method or parameter type or whatever, and catch errors even before you run the TypeScript compiler and get the type checking that's built into it. So that's one of the biggest, from my perspective, that's maybe the biggest benefit that I get. Because to be honest, in terms of catching errors, I mostly rely on tests for that. I mean, yeah, static type checking does catch certain classes of errors more easily. But at the end of the day, I'm still writing tests anyway. So there's that. Where I do want to slightly contradict you is you said you pay something like a 5% tax when adding TypeScript. I agree that that's the case when the types are simple. I mean, if it's a string or a number, the examples that you gave before, well, yeah, obviously things can get really tricky when you try to implement some of the patterns that work really well in a really dynamic language like JavaScript and don't work in languages like Java. And there's a reason we are like TypeScript version. What are we now? Three, four, something like that. It's because they have to keep adding ever more sophisticated rules and capabilities into the TypeScript type system in order to be able to handle all of these weird JavaScript things. And I've seen developers implement a certain bit of JavaScript in like five minutes and then literally struggle for hours coming up with the appropriate type annotation for that piece of JavaScript code. And so it's not always this 5% tax. That's what I'm trying to say. 

GIL_TAYAR: Yeah. It's always before we get into JSDocs and typings and everything, let's talk a little bit about TypeScript, which I'm not a big fan of by the way. Well, let's talk about that. TypeScript enables the whole spectrum. That's why TypeScript can enable people like Dan Shappir who just want to specify that this is a number and this is an object with these properties and, but doesn't want to specify it for everything. And people like me in the middle are people like me who want to specify it for everything, but still want to use simple types up to people. Crazy people like, uh, Galsh, Lezinger and people I know in Israel, they do those complex, weird stuff with type, with TypeScript types, you can actually parse statically JSON using a TypeScript typing, using this recursive types and then do all sorts of weird and wonderful things, which I don't want to hear about. That is right in that regard. But, and if you write totally idiomatic JavaScript, then you certainly have to contort using TypeScript. But what I find myself doing is making my interfaces simpler, not using some like a little bit of those JavaScript idioms which are like totally dynamic and you can figure out. Try to keep my parameters like simple, like a number, a Boolean, an object with these properties, which are also numbers and Boolean, et cetera, et cetera. These are still JavaScript-ish idioms and this still finishes with JavaScript-looking code. It doesn't finish with, you know, Java, horrible Java interfaces and inheritance and everything. So I think the middle ground here is, yeah, some functions which you are very difficult to specify in TypeScript, I don't allow myself, but all the rest I do. And I find this is a middle ground that makes me very, very productive using TypeScript and yet still JavaScript in my code. So, but again, that's the spectrum and that's the, I'm guessing I'm, I'm new to the TypeScript family. I I'm guessing that this is a, you know, conversation TypeScript people have been having for, for years. And I, I'm not certain that we could be talking about that, but in the end, Dan and I agree, types are a benefit. A lot of them, less than, but they are a benefit when you're writing code. And I totally agree with Dan on one thing. They do not replace tests. That is crazy important. They, I don't care about types. I test everything and I never rely on, oh yeah, I know this gets past the correct way, so I won't test it. I test everything always and types are not a replacement, but they do help when coding. So getting back to JSDoc, where's JSDoc in all this? Well, again, there's JavaScript, which I've written for like 20 years. Oh yeah, probably. And there's TypeScript, which I tried. And I love JavaScript in the dynamic nature. I love the dynamic nature of JavaScript. And when, when people started writing TypeScript, I hated it because I thought it would bring me back to Java style code, which, which I do not want to go back to all those interfaces and inheritances and everything. And then I talked to somebody, Benjamin Grunbaum, which was a Node.js contributor and does lots of open source. And he said, don't worry, TypeScript doesn't, well, it could, you could use it to write Java isms, but most of the idioms people use in TypeScript are very much JavaScript-ish. So you're basically specifying this function receives this kind of object with these properties. So you're more specifying what the data schema is rather than what the behavior of various kinds of things are interfaces, as in a set of methods isn't very JavaScript and it's JavaScript and it's not very TypeScript. So, and I started thinking, okay, maybe I should try this TypeScriptish thing and I tried it and I have this open source project called Build, which is a build system for monorepos. And I took it and I converted like, it uses lots of packages, it's like about 10 packages, and I converted like three or four packages to use TypeScript. And I hate, I mean, I loved it suddenly. You know, you see all the types, just like Dan said, the productivity goes up. Your confidence goes up when you're writing your code and you understand more what's going on. But I hated it because built is, is a no JS program. It's a CLI program and no JS and transpilation doesn't work in the TypeScript, you can't run your TypeScript code. You have to go through a transpilation phase. 

DAN_SHAPPIR: And I use Daniel. Dino, sorry. 

GIL_TAYAR: Unless you use Dino or you use TSNode or you use this or you use that, but it's still a hassle. I mean, Dino is nice, maybe in the future, but it's still in the node world and even in the frontend world, but less so, it's a hassle and source maps never really work and there's always problems. And when you compose packages and you call packages together, you need to remember that you're not pointing to the TS files, you're pointing to the JS file, which are a compilation. And then when you change the JS file in one package, which you're linked, and then you need to remember to rerun the build and, oh, the type transpilation kills composition. And maybe hopefully I'll get to talk about that a little bit more. It kills the fact, now you need to compose this ESLint and TypeScript and Babel and this and that, and it doesn't compose very well. You need to always cludge your configuration all the time. So I hated it. And then I came across JS Docs, or actually Microsoft's implementation of JS Docs. What Microsoft does, what TypeScript does, is when it's going through a JS file or a TS file, it can grab the type information either from the signature if it's TypeScript. So foo colon string, and so it knows foo is a string, or it can grab the type information from a jstoc. So if the signature, if the function has a jstoc comment above it which says at param foo string, at param bar number, then it knows that foo and bar are string and number. And that is equivalent from type perspective to specifying it in Linus TypeScript. 

DAN_SHAPPIR: I'm going to interrupt you again for our listeners. I'm sure some of them don't actually even know what JS doc is. So it might be worthwhile to say a couple of words about JS doc. So I did a quick check on Wikipedia because that's where you go to find history of things. And I found that JS doc is actually 22 years old. It dates all the way back to 1999 originally. So it predates TypeScript itself by a long time. So people kind of think that maybe JSDoc is this new thing that's out to replace TypeScript. That's totally not the case. 

GIL_TAYAR: Absolutely. And, you know, my guess is that what predated JSDoc is JavaDoc, which was in Java world from the beginning and because JavaScript was like a distant cousin to Java, then JSDoc looks very, very similar to JavaDoc. So the idea about JSDoc, which it got from, like you said, from JavaDoc was that we want to be able to generate documentation for APIs as easily and painlessly as possible, because usually generating documentation is a real hassle and it quickly gets out of date if you're not careful and nobody likes to do it and definitely nobody likes to keep it up to date. So the idea with JS doc was that you put comments in your code just above, let's say, just above a function definition in a particular style. So instead of just having a comment start with a slash star, it starts with a slash star star. And this way it knows that this is a JS doc comment. And this comment contains a description of the function that comes afterwards. So you have a line literally saying what, you know, what this function is about. And then you can tell it provided with information about the parameters. And the information that you can provide about the parameters is essentially type information. So that people, when they look in the documentation for that function would know that, hey, the first argument, that should be a string or that should be a number and so forth. 

STEVE_EDWARDS: And- I've seen this used in PHP, Drupal used it to document all their APIs. And it's interesting because if you looked in the core code, a lot of times you'll see comment blocks that are just huge paragraphs and stuff you know, describing what's going on in a thing. But the upside of that is if you go to the API site and look at a particular function, you get that whole description because they're just using PHP doc to, to, to generate all the API documentation. So yeah, it's, it's very efficient. 

DAN_SHAPPIR: You're absolutely correct. Steve, there's the PHP documenter, which I think was also itself influenced by Java doc and itself influenced JS doc. So you basically would take some tool. You would run it on your JavaScript project or your PHP project or your Java project. It would parse through the source code files, find all these comments, and extract them and use them to generate, let's say, markup or markdown documentation or PDF or whatever for your project that would constitute the documentation for it. But at the end of the day, what you did was specify type information, among other things, but a lot of type information four variables in your code as code comments. And now back to you, Gil. 

GIL_TAYAR: Yep, by the way, I am a huge not fan of the documentation generated by tools like JS doc and Java doc. I think they did a huge disservice to Java in that you can generate documentation very easily, but it's basically unreadable because nothing. It's not human. It's like an index of functions and interfaces and classes. And you don't understand. And I think the JavaScript way of readmeets, which are human written is much, much, much, much better than JS doc, but that's an aside. So yeah, what TypeScript did, and by the way, they weren't the first Google closure, which was also something of a type predated TypeScript, a type system for JavaScript did the same thing. So not only can you state what foo means in the JS doc in English, you can specify its type. And what TypeScript did was, well, if you're specifying the type in the JS doc, why not have it be the type for that parameter, for that function? And they said, yeah, why not? Instead of writing TypeScript, you can write JS doc. And when you're specifying foo as number, you're specifying not you can specify number, but you can use any kind of TypeScript annotation you want for that type. So if you need like a map of a string column, whatever object or whatever TypeScript isms you need, you can specify that Foo has that type. The whole power of TypeScript, you can get it as basically what they've created was an alternate way of writing TypeScript. And back then when I wrote that open source and tried it, it didn't really work. It wasn't like a hundred percent there. The documentation was not very good. It was bad. And I gave up and wrote TypeScript and then, okay. And then, you know, I had to choose between a bad and worse, not bad and worse because JavaScript is great, but between a dynamic type system and a type system that is static, but that I hate with a vengeance because transpilation and because it's not jobs. And as I said, I work at round forest and I got to round forest about four months ago. I started working there and as I said, we built from the ground up. So I had again, the chance just like I had at Abloh Dull to write stuff from scratch. And I said, let's give it another try. Let's give Jay's talk another try. And what I found out that Microsoft did a wonderful job both in documentation and in the TypeScript compiler. That for all sense and purpose, you can do anything you want using JS Doc, just like you can do in TypeScript. Whatever you write in TypeScript, you can write in JS Doc comments and get the same type checking and the same code completion and all that. I said, oh, perfect I get all the benefits of TypeScript without transpilation. And this was amazing. I can even write a package, everything being in JavaScript and in JS Docs, and ask the TypeScript compiler to type check it, which is great, and it'll do it. But I can also make it create what are called type definitions so that other packages that import that package can use it just like any other TypeScript package. They get, I get for free type checking for libraries that other libraries use. So I get the full gamut of TypeScript capabilities and my code is still total JavaScript, zero transpilation. And I loved it. I really, really loved it. I still love it. We're using it at Roundforest a lot. I mean, basically in all our code. There's a caveat here, but basically that's it. And I wrote a blog post because, you know, I was in love with it with the method and it got a lot of traction. And we're seeing more and more people warming up to the idea of, Hey, we love TypeScript with JavaScript. We don't want transpilation. We don't want another tool in our toolchain, but we can still get all the benefits of TypeScript without, without abandoning JavaScript. And that is great. Really. I love it. 

CHARLES MAX_WOOD: So I guess we've kind of come kind of back around to this conversation then, right? Because types and yeah, we're not transpiling, but what does my workflow look like then? Right? So if I come back to putting JS docs in, am I getting sort of the language service that I get out of like VS code or something that's kind of doing the checking? Is it what do I get if I turn this on? Right. And how do I? How do I turn it on? I guess is the other question. 

GIL_TAYAR: Okay. So what do you get if you turn it on is easy, whatever you get from TypeScript, VS code and IntelliJ, by the way, we checked, we have a new, a new developer that doesn't want to leave WebStorm. Both understand these, the types and anything you get from TypeScript, which is type checking and the squiggly lines and the documentation and auto import. Wow, you know what, I didn't know all the things VS code can give you once you move to the TypeScript world. And once I moved it, I found all so many things. It can even generate JS docs from you. So if you take a JS doc code or a TypeScript code and you select a certain lines and you create a function from that, you can do that. I think it may be an extension, but it could be built in. And then it says, oh, I don't know what these parameters are. And it shows me a squiggly line because I'm using strict mode in the TypeScript compiler. So it says, oh, I don't know what this and you right click and you say, infer types from usage. Okay. And boom, I get JS doc comments, not TypeScript. I get JS doc comments written by VS code describing exactly the types I need. I basically don't, I get the it's as streamlined and I was very much surprised as writing TypeScript code. And until you move to this JS doc world or TypeScript world, you would not believe the productivity gains you get. So yeah, you're writing types, but VS code really, really helps you there. You still pay a tax writing those types, but it's not that big because you're using VS code with the language server that helps you just like it helps in TypeScript.

DAN_SHAPPIR: So I think it's worthwhile to again touch and perhaps a little bit expand on one of the points that you kind of mentioned in passing, which is type inference, just to clarify what that is. So if we go back to the example that you gave initially, let's say I create an add function that accepts two parameters A and B and then does a return A plus B. Well, theoretically in JavaScript, A plus B could be a number or a string because the plus operator works on numbers and it converts other things to string and then it does string concatenation. So theoretically the result of this function could be a number or a string. But if I specify explicitly that A is a number and B is a number, then the TypeScript compiler is smart enough to infer that the result of A plus B has to be a number as well. And if I'm using something like a strict mode, I probably need to specify the type explicitly. 

GIL_TAYAR: But oh, no, you don't. 

DAN_SHAPPIR: Yeah, but that takes me back to one of my kind of complaints about TypeScript as a type system. You have certain programming languages like OCaml and these types of languages. ReasonML is another is a great example in the front-end world where they were designed with types in mind from the bottom up. And type inference is extremely powerful in these languages because it was designed this way. It can infer almost anything. You specify some initial basic points and from that you get a lot, a lot of the stuff automatically. You don't need to specify complicated type because it does it for you automatically. In the case of TypeScript, they couldn't do that because it was built on a language that was created not only with no static typing in mind, like with the inverse of static typing in mind. And consequently, a lot of, you know, it does an amazing job with the inference it can do, but there's a hard limit. And that's why you kind of need to be, theoretically, it can inference a lot of the types for you, but practically, you need to specify most of the types practically, you need to specify the complicated types. And that's a certain limitation there. But undoubtedly, it is powerful. I mean, yeah, you can do, let's say a const x equals add of three and four, and x will automatically get the type number. You don't need to specify the type for that variable. So yeah, it's very useful in that regard undoubtedly. And a lot of the power that you get inside the development environment stems from this automatic inferencing. 

 

This episode of JavaScript Jabber is brought to you by DigitalOcean. DigitalOcean recently announced their new App Platform service, which is a solution to build modern cloud native apps. With App Platform, you can build, deploy, and scale apps and static websites quickly and easily. Simply point your GitHub or GitLab repository and let the App Platform do all the heavy lifting. As it has support for Node.js, Python, Go, PHP, Ruby, static sites, Docker, and container images, DigitalOcean runs their app platform on their own infrastructure, so your costs are significantly lower than the other products. Plus, they build this new app platform on top of DigitalOcean Kubernetes, providing a smoother migration path so you can take more control of your infrastructure setup. As a listener of JavaScript Jabber, you can get started for free. Better than free because DigitalOcean is giving you $100 credit when you go to do.co.jabber. Again, go to do.co slash Jabber to get your hundred dollars free credit on digital oceans, new app platform. We want to thank digital ocean for sponsoring this episode of JavaScript. Jabber. 

 

GIL_TAYAR: And that's true. And I think I tried reason and it really is powerful, but, uh, I think types will get, gets you 80 or 90% of the way. And yes, you have to specify the types for the 10% that if in reason, you just don't I think it's still useful. And you know, it's funny because I was like, talk to me. I I'm known in Israel as the TypeScript hater. No, yeah, Gil talked to Gil. He doesn't like TypeScript. He has all these reasons. And today it's not that I agree with them. If you go complex types, you're screwed, but if you keep it simple, you get a lot of benefits and my development environment is better for having static types and not worse. And you know, there are places where I say, oh Annie, I don't care about the types, I'll figure it out. It's dynamic code anyway, and TypeScript allows you to do that very, very easily. So I'm definitely good with adding types. What I, half of my hate, it's not really hate, but half of what I disliked about TypeScript was transpilation. I have, I can rant about transpilation from here to wherever, and I try to avoid it as much as possible and in Node.js I avoided it using JS doc and for that this is great. By the way, an anecdote, I, we have backend people, obviously backend developers and frontend developers and the frontend developers are, we, we did a whole React stuff and you know, JSX and everything with JS docs. And I can't say they hated it. They worked on it, but they disliked it. And they put constant pressure on me as the architect to say, come on, please, let's go back to TypeScript. It's nice just doc typings, but we're transpiling anyway. I mean, it's not like you can avoid transpilation in the front-end world. You can't. So that argument goes away. And I was telling them, no, it doesn't go away because most of the tests you're writing are using JS DOM and running under node. And currently all your tests are running without transpilation. They're just running Node.js code, no transpiling, no bundling and all the tests run with native code under Node.js. And by the way, the way I do it is I use ES modules in Node.js. So that, you know, front-end code and back-end code, look, it looks exactly the same and can run both under Node.js and front-end code. And like they're saying, yeah, but anyway, you need to transpile blah, blah, blah, blah, blah, blah, blah, please, please, please. And in the end, I had to relent. I mean, constant pressure and I had to relent. So now we have this weird situation where the front-end people are using TypeScript. And they're using all kinds of magic so that the transpilation is essential in under node is essentially transparent. And the backing people are using JS doc. And the beauty of JS doc is that it coexists with TypeScript because it is TypeScript, but without the transpilation. 

STEVE_EDWARDS: So speaking of the backend, I'm just familiar, curious to see if you've played with Dino at all, which is the new and improved version of node. Because as I understand it with Dino they're building type checking into the language instead of requiring something external. So I'm just curious to see if you've had any experience with that or looked at that. 

DAN_SHAPPIR: I would just comment that Dino would probably define themselves as no done right rather than as the new and improved version of Node. 

STEVE_EDWARDS: Yeah, yeah, right. Yeah, understood. 

GIL_TAYAR: No, I haven't tried it. It looks good. And my point is that any competition with Node is good. Node already had competition, if you remember, uh, IO.js, the fork, not the, the second fork, the first fork, which then caused a war of, you know, competition. And then IO.js and Node merged into Node 4. And Node is the better for it. And Node development was much faster and much better since then. I love the competition and you can feel it in the Node contributions today. People are saying, yeah, but node has this, yes, but Dino has this, yes, but Dino has this, et cetera, et cetera. And you're seeing the pressure on the node contributors to add that. And it's a good thing. I love it. Is Dino ready for production? I don't know. I never tried it, but I'm pretty happy with the ecosystem and Node.js, so I don't really have any reason to move. And what they're doing is Dino, in terms of TypeScript, is they're transpiling on the... They're actually not even transpiling they're removing the type annotations from JavaScript and then running the JavaScript itself, source maps and all that. So they're making the transpilation, they're not even type checking. So they're making the transpilation transparent to the user, but transpilation is still going on there. 

DAN_SHAPPIR: Yeah. There's no type checking in Dino because what are you going to do? Like fail the entire run because some arguments, some they're mismatches in code that might not even execute it. Once you decide to run statically typed code out of the box, you're almost by definition saying, well, I'm not really going to statically type check it. 

GIL_TAYAR: Yeah. I don't know what they're going to do once TypeScript gets a version that is very different. And on what tsconfig.json are they working on? I mean, Matteo Colina has this word, there is no one TypeScript language. There are an infinite number of TypeScript languages, depending on your tsconfig.json and all the parameters you put there. And he's right. So what happens when things start moving significantly in the TypeScript world and things that used to transpile well, don't transpile well now? I don't know. I don't think it's going to be a major problem because if it will be a major problem, then probably the TypeScript people today won't do that because they care about Dino, but it's a problem. And today using ESM loaders or require hooks you can get the same functionality, not as fast, but almost as fast in JavaScript, transparent transpilation in Node.js. 

DAN_SHAPPIR: So one of the things that kind of differentiates between the way that you use this mechanism and the way that I use it is that you're a strict person and I'm a chill person, a relaxed person. Just to clarify that point, in strict mode, TypeScript verifies the types of everything. And if something is not explicitly typed, well, that's an error then. And that's the way that I understand that you're using it. You're typing everything. And I've adopted a much more relaxed approach intentionally where I type exported functions in modules and also exported data structures when they're used by exported functions, and I type commonly used functions. And finally, I type functions that have complex arguments, but for me, that's really a code smell. So if a function gets a really complicated argument, I tried to simplify the argument and, and I intentionally don't type everything else. So if I have a function inside my code, inside a module, which is not exported and it's, let's say used from one or two places that more or less it, I'm not, I'm just not going to type it. I don't, the value that I get out of it is insufficient to justify the effort of maintaining the type information. 

GIL_TAYAR: That's a big question. I do get value. So if the exported function gets an object with like these four or five properties in it, and I pass it to an inner function, I really want to specify that that inner function parameter gets those four properties and returns an object with four other properties, because that'll help me type check and check my code. Not because I want to avoid tests. You know, I test everything I write, but because it makes it easier both to understand the code and to write the code itself. So, you know, I just infer types from usage, mangle a little bit, you know, some enters and some stuff because prettier doesn't work with the JS docs very well or at all. And that's about it. It's not for me, the, the, the time it takes to write the types is very small and value I get from it is still large. 

DAN_SHAPPIR: By the way, I hate prettier. 

GIL_TAYAR: Well, it's just you, Dan, I think. 

CHARLES MAX_WOOD: So we're using ESLint or you're just not linting it at all. 

DAB: You're asking me or you're asking Gil? 

CHARLES MAX_WOOD: Yes. 

DAN_SHAPPIR: Well, I'll say about me. I, I, so first of all, going back to the JSTOCK and the relaxed approach that I use, I find that inside the editor, the relaxed approach thanks to inferencing is good enough for my needs in the majority of cases. I do lint and the linting does catch those cases where I do specify the types if I use an incorrect type. It also catches other things. So ESLint is not just about TypeScript. It's about other things, other things as well. And Prettier, well, I hate it when I get errors because of Prettier. I mean, you know, why do I need to put a comma there? I don't want to. It's still valid JavaScript without it. And anyway, so yeah, so that's the answer. I do use ESLint, but I used, but I don't use strict TypeScript type checking. 

STEVE_EDWARDS: Yeah, I've used, I've tried ESLint Prettier before, and they've always been sort of a nightmare to get to work together from what I've seen, but to me, Prettier is a little too opinionated. It's pretty limited in what you can configure and change. And there are some things that I would like to change that it just doesn't allow. So I saved myself a lot of headaches with not using Prettier. 

DAN_SHAPPIR: I'll say one more thing about Prettier. I look, I like consistency in projects. People sometimes ask me which type of indentation I like. And I say the one that already exists in the project. So I do like the fact that Prettier does enforce consistency. But what I see in a lot of cases is that somebody managed to configure Prettier in a certain way in a certain project and then left the project. And everybody that's still working on the project hates the current configuration, but nobody's exactly sure how to change it. And nobody wants to go through all the code to fix it. And then we're kind of, you're stuck with certain style that you dislike and you can't even gradually fix it because prettier is kind of an all or nothing type of approach unless you start disabling it for entire files and then you know what does that get you? 

GIL_TAYAR: Just run ASL, just run prettier fix and one commit and you're done. 

DAN_SHAPPIR: Yeah but like I said doing a gradual change on a large project is difficult. Why do a gradual you do everything at once. 

CHARLES MAX_WOOD: Rip the bandaid off. 

GIL_TAYAR: Yeah. 

DAN_SHAPPIR: Yeah, maybe. 

GIL_TAYAR: I have people who are- That's what I love about, well, that's one of the things I love about. I dislike the defaults, like double quotes, come on, or I dislike semicolons, and 80 is too little for me. I prefer 100 with column widths. So I change that. But for me, prettier is not about enforcing. I see it differently. It is a formatter first and foremost. So now when I write stuff, I don't care about the formatting. I write it like, uh, let's say I want to separate, let's say I want to add braces. And then let's say I don't have the VS code extension for that. I add braces around a single line. Uh, if, so I just add them anywhere and keyboard shortcut prettier and boom, it gets formatted. The fact that I'm not formatting, but just saving in auto formats or whatever, that saves me a ton of time. It makes me, in terms of writing the code itself, much, much more productive than back in the days when I had to do arrow up, arrow up, arrow down, space, delete, delete, delete, enter, enter, enter, and all those. I just save auto format done.

DAN_SHAPPIR: I accept that. I'll think about it. I will say though that in some of our projects, that especially one that have a lot of people working on them, if I do a sudden commit of all the 1,000 files, people will kill me. 

GIL_TAYAR: Yeah. It's a decision that is not taken lightly. It's like a team decision. Okay, everybody stop. We're going to do it now and then continue on. Definitely. It's everybody push. Let's do it. But that let's do it is like 10 minutes. So from my point of view, it's still a better choice. 

DAN_SHAPPIR: Anyway, going back to- 

CHARLES MAX_WOOD: BC stands for before commit and AD stands for after dump. And you're in your code base. 

GIL_TAYAR: Yeah. 

DAN_SHAPPIR: I once said that if I had to rank from the easiest to the most difficult, whenever implementing a new feature, then the easiest thing is actually implementing the feature. The next much more difficult is passing the tests and the most difficult- 

STEVE_EDWARDS: And then-

DAN_SHAPPIR: And the most difficult thing is merging the PR. 

GIL_TAYAR: Yeah. Which is why we do trunk based. No PRs for us. 

DAN_SHAPPIR: Yeah. Doesn't work for some of our projects anyway, but that's a whole different discussion. 

CHARLES MAX_WOOD: Yep. 

DAN_SHAPPIR: Okay. Going back to J's doc, is there anything else you wanted to cover there? 

GIL_TAYAR: Yeah. It's my rant on translation. I think I like to think of JavaScript is passed through three, from my point of view, three waves. The first wave is, you know, the, the, the beginnings 95 to, I don't know, 2000, 2000 and something where we just did a big script source and, uh, and there was basically no DOM. So there wasn't a lot we could do anyway. So that's fine. One, one big JavaScript file and we're good. Jake 

DAN_SHAPPIR: wasn't so big. Wasn't so big given back then. 

GIL_TAYAR: Yeah. JQuery reigned supreme. The second wave was where projects like AngularJS and others started feeling constricted because they had to build these huge projects like Gmail or whatever, and they built what Shema called it RequiredJS and AMD and AngularJS had also used some kind of a module system and enabled modular JavaScript. That forced people to introduce transpiling and bundling. And the two hates that I have. Trans bundling because bundling because browsers can't do modules and transpiling because browsers were really bad back then and they could only understand ES5 and everybody wanted ES6. So Babel and AngularJS and AMD reign supreme. Then came the third wave where we're still using Babel for some reason. We found new uses for it, not just to translate to ease five, which we don't need as much as we used to, but we're still using it for various things like JSX, by the way, and react. I use that. And we're still in the world of bundling. We're still bundling all our code into one big, you know, two meg file, JS file, and we're doing code splitting and figuring out all these various machinations to make it work in an efficient way. So we're still doing bundling, we're still doing transpiling, even though we don't need to transpile as much, but, and browsers understand ESM today. So why are we doing this? And I believe, I may be the only one that we need to go back to our roots. The wave number four is a back to roots thing where we write code, it's JavaScript code. No regular JavaScript code and it's all in ES modules and the browser just runs it without any transpilation or without any bundling. And a lot of technologies are starting to come in, which I believe will enable this dream I have of going back to the basics. 

DAN_SHAPPIR: Again, I constantly interrupt you because you bring up so many interesting topics. I just wanted to mention that a while back we had Joao Weiss from Google, from the Chrome team, and he spoke exactly about the future ways in which browsers may have built-in support for bundles. 

GIL_TAYAR: Yes. 

DAN_SHAPPIR: Yeah, exactly. So if people are interested, we'll have a link to that episode, which was excellent, by the way, in the show notes. 

GIL_TAYAR: Definitely. I think web bundles are the future web bundles in a way are a way where you can write your code using ESM and bundle in the most naive way, as in not requiring tooling, but just zipping all your files together. So in development where you don't care about performance and you don't need bundling, you don't need to transpile and you don't need to bundle. Everything is like perfect. And for production, you just need to create one or more bundles and the browser will need know how to load not all the JavaScript file, not all the four megabyte JavaScript file, but just the modules it need from that zip file. It's not really a zip file, it's much more performant, but that's the point. So we're getting all the benefits of bundling without the problems of bundling, which is caching and all that. So yes, I think web bundles are part of that puzzle. I think JS dock is part of that puzzle. I haven't figured out JSX yet, but hopefully it will become a standard maybe one day, like TC39 standard. 

DAN_SHAPPIR: It's unfortunately not syntactically complete or something. It's not quite a programming language. 

GIL_TAYAR: We can, I think, figure it out. But even then, you can do things like use ESM loaders. So just like Node.js has the MSM loaders, which allow you to transform the source. So you could have in the browser ESM loaders, which allow you to transform the source. 

DAN_SHAPPIR: Or we can use tag template, which is an interesting suggestion that I heard in this context. 

GIL_TAYAR: Which one? 

DAN_SHAPPIR: Tagged template string. 

GIL_TAYAR: Oh yeah, as I said, I'm not a fan of transpiling. So how do you do React, JSX? And I used tag templates, template literals, HTML, Jason Miller of Preact fame did that. And you can, instead of you doing JSX, you can use, uh, tech templates and it works quite well. There are other problems with it, which is why we went back to JSX, but it works. So that's my, you know, my dream and just doc is just one part of that dream. Yes. Sam is another. And one big part, which I believe will happen is I think TypeScript has so much momentum that TC 39 will want to create a feature whereby TypeScript code will be valid JavaScript code, except that JavaScript will just ignore the type annotations. I believe firmly that this is a direction that we shouldn't go and then we won't need JS doc typings. In that JavaScript will have these, you know, another language which did exactly that is Python. Python has type checking. No, it does not have type checking. It has like these areas in the code, in Python code, which the compiler just ignores. TypeScript could be used that same way so that JavaScript runtime will look at the code, ignore all the types, and just run the JavaScript as is. I believe in that dream too, just like, you know, some version of JSX will get in. I believe some version of TypeScript, or not of TypeScript, of ignoring the type annotations will enter JavaScript, and we will have that capability as well. That's another dream of mine. And the end goal for me is let's go back to standard tooling. Let's go back to no tooling. Not because I hate tooling. I love tooling. I love ESLint. I love Babel, et cetera, et cetera, but they're not composable. If you're using Webpack, you can't use this. If you're using this, you can't use this. If you're using that, you can't use this. Anytime you get into any new JavaScript project, you get so confused from that. And the reason, the main reason for that is because you're doing transpilation and you're doing bundling and composing all those tools together is just one big mess. End of rant. 

CHARLES MAX_WOOD: I'm going to push us toward end of podcast because I need to start wrapping up. 

STEVE_EDWARDS: Hey Chuck, before so I just wanted to say, hey, Gil, I really appreciate how unopinionated you are and right down the middle and really making sure nobody else is offended. So I really appreciate that about you. 

CHARLES MAX_WOOD: Oh, I know. Right. I'm sure you didn't hurt anyone's feelings? None at all. Yeah. 

GIL_TAYAR: I'm actually not sure whether that was sarcastic. 

STEVE_EDWARDS: Yes, that was being very facetious kill. Oh, I also wanted to ask you are your arms tired? 

GIL_TAYAR: Oh, no, I'm used to that. 

STEVE_EDWARDS: Okay, yeah, I've been watching over the last hour and I was like, dude, you got to be getting a good shoulder arm workout in there with all the hand waving and stuff. You know, podcast listeners can't see it. So I thought I wouldn't share that valuable 

DAN_SHAPPIR: and to wave our arms around a lot when we speak, there's this old joke about, uh, like really old about somebody introducing the phone to some person way back in like the fifties or whatever, and, or the forties. And he explains to him that you hold the phone with one hand and you dial with the other, and then you speak. And this really goes, well, if I hold with one hand and dial with the other, how can I speak? 

STEVE_EDWARDS: Right. Well, I've heard another variation about other nationalities where how do you mute so-and-so nationality, you cut off their hands, you know, so. 

CHARLES MAX_WOOD: Yeah. I lived in Italy for two years and they just articulate a lot too. 

STEVE_EDWARDS: So I wasn't going to list nationality, but thank you for, yeah, that's a long joke anyway, back to finishing the podcast. Sorry. 

CHARLES MAX_WOOD: No, no, all good. I was also going to just say it's, it's interesting whether you're kind of deep into the TypeScript camp or deep into the, I'm just going to do JavaScript and nothing else camp or whether you're into kind of trying out some of these tools to think about, okay, you know, what could this give me? What trade-offs are here? What plays into decisions like this? I think it's worth exploring some of these things sometimes and going, okay, what's here? What's offered? What comes into play? Because I mean, this may be a stepping stone to something better. It may be a place we kind of land for a while. I mean, who knows, but at the end of the day, I mean, these are the conversations, I think that move the community forward. And so I really appreciate you coming on and talking to us, Gil. 

GIL_TAYAR: Thank you. It was a pleasure. Really. All right. Well, let's, let's go ahead and do some picks. 

 

When I went freelance, I was still only a few years into my development career. My first contract was paid 60 bucks an hour due to feedback from my friends. I raised it to 120 bucks an hour on the next contract. And due to the podcast I was involved in and the screencasts I had made in the past, I started getting calls from people I'd never even heard of who wanted me to do development work for them because I had done that kind of work or talked about or demonstrated that kind of work in the videos and podcasts that I was making. Within a year, I was able to more than double my freelancing rates and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, Let me show you how to do it in my DevHeroes Accelerator. DevHeroes aren't just people who devs admire, they're also people who deliver for clients who know, like, and trust them. Let me help you double your income and fill your slowdowns. You can learn more at devheroesaccelerator.com. 

 

CHARLES MAX_WOOD: You know, you've been on the show before, Gil, so you know the drill. And I'm a poet and I didn't even know it. Steve, do you want to start us off with pics? 

STEVE_EDWARDS: So I actually have a couple of blood quotes today, but I'll start out with the usual dad jokes. And you know, in the past, I've talked before about how I got fired from my bank job, because a lady came in to ask about her balance, and I pushed her over. But later on, I was a tightrope walker. And I went to the bank and asked for a loan. And they said they couldn't give to me because I had an outstanding balance. But anyway, wow, dead silence. I saw a couple of articles on Packer News. And one I was just looking at a little short article by someone named Muhammad Raza, I think judging by the domain name of the article. It's called My Favorite One-Liners. And it just has a bunch of little command line utility one-liners that combine things together to do some pretty neat things. There's one I've already copied and made as an alias that you can use to give a list of all the directories under a certain directory instead of listing all the files and directories, some get stuff and various things. It's just, I'll put a, it's not real long, but it's got some cool stuff. So I'll put a link in the show notes to that. Another article that I saw on Hacker News that I really liked is called by a guy named David Perrell, P-E-R-E-L-L, and it says, Why You're Christian. And basically what he says is, how do you advocate for human rights without a knowledge of the Bible and where the advocacy for human rights come from? Because you really, if you look back at history, you really can't have one without the other. And the guy claims he's a quote unquote, tepid believer at best. So it's not like he's in, you know, raging or a strong evangelical. He's just looking at the logic and history of it. So anyway, I'll put a link to that in the show notes as well. 

CHARLES MAX_WOOD: Yeah, I've always thought that that was an interesting place to go to just as far as whether you believe in the Bible or not, seeing how it formed the foundation of the beliefs of the folks that kind of set the framework for the United States and how that's like the world.

STEVE_EDWARDS: Yeah, exactly. 

CHARLES MAX_WOOD: That's where I was headed was, yeah. And how that's affected the world over the last 200 plus years. 

STEVE_EDWARDS: Yeah. So I've talked about this. I mean, this is the whole topic I can go off at length for. And I think I mentioned to Chuck when we did that, my JavaScript story, there's a, for instance, there's a historian named Rodney Stark that has a great book that talks about how our economics derived from Christianity and what people saw in the Bible, you know, talking about scientists like Mendel and Newton and, and so on and so forth. So but this was coming from a quote unquote non-believer. So I thought it was really, really well written article. 

CHARLES MAX_WOOD: Yeah. Cool. Dan, you have some picks for us? 

DAN_SHAPPIR: Yes. And I also have a lot of noise coming from my street. So hopefully it won't interrupt my pick. So I got the one pick this time and it's a lengthy article or post but that's actually something of a condemnation written by Alex Russell, who actually was a guest on our show a while back back in episode, what was it, 439. And it's a condemnation about how app stores, and in particular, and almost specifically, the Apple App Store is causing, is a lot, a significant detrimental impact to the success and evolution of the web. Because in order to prevent, effectively prevent competition with its app store is you might say intentionally crippling the abilities of websites and particular web applications on the iOS platform. They might have done the same thing on macOS, but there you've got real browser options. If you don't like what Safari gives you, you can install Chrome. Well, on iOS, you might think that you're installing Chrome, but what you're actually using is a thin Chrome wrapper around Safari because Apple doesn't actually allow installing any other JavaScript engine, not JavaScript, sorry, web engine, including the JavaScript part on its iOS platform. So effectively you're stuck with Safari and whatever Safari decides to implement or apparently quite often not to implement. So Alex did a really in-depth and well-research analysis of it. It's slightly depressing, but I guess it's better to know and understand the situation because otherwise, you can't try to fix it. So I highly recommend this post and Alex is an excellent writer and it's well thought out and researched and presented. So that would be my pick for today. 

CHARLES MAX_WOOD: That's really interesting. I'm going to have to go read that because it sounds thought-provoking and I've really been enjoying getting into some of the just, okay, I really got to think about that kind of things. 

STEVE_EDWARDS: Well, it's interesting. I mean, if you look at Epic Games, they're raging, raging huge. World of Warcraft, right? They're waging a huge battle against Apple, both in the public sphere and from a legal standpoint, saying, hey, you know, we can only make purchases within the app and you take 30 percent. That's a bit much. And there's other that have been raising, making noise about this for a while. But Epic, from what I've seen, has really been on the forefront, making the biggest stink about it.

DAN_SHAPPIR: Yeah. It's interesting. The guys who, what's this really popular first person shooter? Fortnite. I think those guys. 

STEVE_EDWARDS: Oh yes, Fortnite, no world of work at Fortnite. I'm sorry. I'm not a gamer, so I don't have everything all linked together. 

DAN_SHAPPIR: Yeah, exactly. So, so they're waging a big war there. There's also now, it's all starting to go up between Facebook and Apple. It's a problem. Yeah, it's, it's a problem in the, in the context of the web. It's a problem because in order to promote the success of its app store, Apple is apparently intentionally crippling the advancement of the web platform on iOS. And if you can't use a certain web feature on iOS, then you likely just not use it. So instead of the web progressing with the fastest moving platform, we are progressing at the rate of the slowest moving platform, which is, you know, now especially that I 11 is effectively dead, is becoming ever more Safari. 

STEVE_EDWARDS: I think Apple has conceded a little bit, but it's more like throwing a bone, you know, where they said basically, if you if you run an app and you have what is something like fewer than a million users, or you make fewer than a million dollars, there's a million in there somewhere, then they'll only charge you 15% instead of 30%. So they're being incredibly gracious. But that's about the only bone they've really thrown out there for people that are complaining about this. 

CHARLES MAX_WOOD: Yep. All right. I'm going to jump in with some picks. I was looking at some stuff the other day and I realized that 10 years ago tomorrow, we being myself and four other Ruby developers recorded the first episode of RubyRogues. 

STEVE_EDWARDS: Woohoo! 

CHARLES MAX_WOOD: So that's what got this whole thing started. So yeah, I mean, crazy stuff, but yeah we started RubyRogues and then Jameson came and asked me to help him start a JavaScript show like RubyRogues. And eventually we started JavaScript Jabber. So JavaScript Jabber will be 10 in January, but yeah. So I'm going to pick RubyRogues because yeah, that's kind of where this whole thing got rolling. 

STEVE_EDWARDS: So what episode are you up to? I'm looking on here. And I'm not RubyRogues. 

CHARLES MAX_WOOD: We have an episode coming out. We're 95, 

STEVE_EDWARDS: almost 500.

CHARLES MAX_WOOD: Yeah, we're almost 500. It comes out tomorrow. Oh, that's, that's kind of ironic or kind of fun. So exactly 10 years, it'll be episode four 96. And yeah, we are going to do an episode 500 over. We're recording that here in a few, in a few weeks. So yeah, I'm going to invite pretty much all the past hosts that we've had on the show and we'll see who shows up, but yeah, it'll be fun. So yeah, I'm pretty excited about that. 

STEVE_EDWARDS: A lot of podcasts that make it that far. So that's quite an accomplishment. 

CHARLES MAX_WOOD: A lot of podcasts don't make it 10 episodes, let alone 10 years. 

STEVE_EDWARDS: Yeah, I was going to say the number I'd always heard was eight. Eight is sort of the tipping point. Are we going to keep doing this or not? 

CHARLES MAX_WOOD: Yeah, 

DAN_SHAPPIR: I've said it before, and I'll say it again. I think our community, or it's a big community, it's a JavaScript community, owes you a whole lot, Chuck, for what you've done with this podcast and the amount of content that you've done has been put forth and I think this episode itself is an excellent example of that. 

CHARLES MAX_WOOD: Well, it's not just me. I mean, a lot of people have been completely willing to come on the show and contribute. So, props to our past guests and everybody who's been involved because, I mean, we couldn't do it without the hosts and without the guests and everybody else, but it's definitely been a journey. I'm thinking very seriously about writing a book about the last 12 years that I've been podcasting. So anyway, it just kind of occurred to me this morning. I was like, wow, it's been almost 10 years exactly since we started Ruby Rhodes. So anyway, that's one pick. Another picture that I have and on a much less nostalgic, uh, pick is I've started doing the keto diet again. And I have a really good friend that he'd hear this pick and be like, that's not keto because it has a sugar substitutes in it. And he's a strict, you know, no sugar, no grain, no substitutes kind of person, but I've been enjoying these. They are built bars and they're protein bars, but they taste like candy bars. And I am not kidding. They are so good. It's actually a local company. I kind of figured that out after I was buying them and eating them. My kids school is actually right next to their factory. So anyway, just so, so good. I've got their bites. I've got two boxes of their bites on my desk and a box of their bars that I haven't opened yet, but they literally like the quest bars are kind of chewy and gritty and these they literally are like candy bars. So I'm going to pick those. And then I just ordered a new phone because my phone die is dying and it was having trouble recognizing the SIM card, which is kind of important if you want to make phone calls with your phone. And so I'm also going to just shout out about where I got my phone. I am a cheapskate when it comes to stuff like phones and cars and stuff like that. So yes, I know the latest iPhone is the iPhone 12. I just bought an iPhone 8 plus. And it's because I can get it for like a quarter of the price. And I'm just waiting for a new SIM card to show up for it. But I got it on backmarket.com kind of like black market without the L and they clean them up and refurbish them and then they sell them back to people. And they've got technicians all over the US. I wouldn't be surprised if they have technicians in other countries as well. But yeah, you can buy a used phone from them. And I was finding phones on classified sites as well for about the same price. But these ones, they guarantee them for like 90 days and they really have done a good job rehabbing them. So I've been pretty happy getting this phone from them. And so yeah I upgraded my phone kind of because I needed to at this point because it was dying. So anyway, those are my thoughts. 

DAN_SHAPPIR: Yeah, I want to say that I'll second that approach of going cheap on phones. I mean, I sit in front of a computer all day long, so I don't need a fancy phone because I read my email on my computer screen and I tweet on my computer screen. And so I don't need the phone as much for these sort of things. I obviously I use it when I'm on the road, but more often than not, I'm just in front of a screen anyway. And the other thing is I can even justify it in my case, because I'm into web performance, that's my day job. So having a mediocre phone rather than the latest and greatest exposes me to what a lot of our users experience in terms of the performance that they get when they use our websites on their phone. So that's another benefit from my perspective. 

GIL_TAYAR: But by the way, the iPhone 8, iPhone 8 Plus, in terms of power, not power, of CPU, is basically like one generation back in Android CPUs in terms of performance. So because Apple is so much more advanced and in ARM CPUs, iPhone 8 Plus is equivalent to one generation back in Android, not back from today. No, not from back. 

DAN_SHAPPIR: Oh, I totally agree. It's rather amazing. I mean, like the latest iPhone is something like five times faster than the latest Android in terms of the raw performance that you can get out of it. It's pretty nuts. 

CHARLES MAX_WOOD: Yeah. I honestly haven't had any problem getting the older phones. So I've been pretty darn happy with, with what I've been getting. So yeah, anyway, so that, that's going to be my big shout out Gil do you have some, uh, some shout outs? 

GIL_TAYAR: Can I pick a podcast? 

CHARLES MAX_WOOD: Yes.

GIL_TAYAR:  Okay. So my podcast, I don't listen a lot when I run, it's basically two podcasts, one of them is dithering. It's by two guys, you may know them, John Gruber of Apple fame. Uh, also he has this blog called Daring Fireball, which is all about Apple. He's been in the Apple world for like forever. And the other, I know that is, yeah. Okay. Oh, and the other is Ben Thompson, also called strategy, who's an advisor and, understands the high tech industry, you know, Apple, Amazon, et cetera, et cetera. Like not a lot of people, like really well. And they just, and the format is interesting and I'm not a big connoisseur of podcasts, so maybe all around, but they do 15 minutes twice every week. That's it, exactly 15 minutes. They start on the dot and once the 15 minutes end, the podcast and that podcast episode ends and they talk about what happened that week. That is it, 15 minutes, very focused, very talking between themselves about Apple, Amazon, Facebook, whatever, vaccines or whatever, really, really good. Lots of insight. 

STEVE_EDWARDS: So do they cut off mid sentence at 15 minutes? 

GIL_TAYAR: Never. I mean, they time it and they have this, this sound at the end, which is like a timer running down. So, and they, you know, they, they managed like within two, three seconds of that, so it works. 

STEVE_EDWARDS: Alrighty. So Chuck had to drop off to go on another call. So we will end today's episode for now, thank you, Gil, for coming on yet again to share with us your vast wisdom on JavaScript and types. And Amy had to drop off to work gets in the way of podcasting sometime this way it goes. Gil, if people want to reach out to you, get a hold of you, yell at you, say thank you, you're awesome. Where and how can they do that? 

GIL_TAYAR: Best places, Twitter, Gil Tyar, G-I-L-T-A-Y-A-R, easiest place. Just send me a DM, my DMs are open. 

STEVE_EDWARDS: Right on Thank you, Gil, for joining us. And we will see, we will see you all next time on JavaScript Jabber. 

DAN_SHAPPIR: Bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.