Transcript

The Reason for Types in JavaScript

Adam talks to Jared Forsyth about his journey from untyped JavaScript, to using flow, and eventually ReasonML.

Today’s podcast is sponsored by Springboard

“I mean, I was, I’ll admit it, I was definitely in the: ‘I was scarred by Java and C plus plus in an intro to programming class and I never want to look at types again’ Camp”

“My first language was Python and followed closely by Javascript. And so I was, I was loving the loosey-goosey scripting language.”

“My first experience of using types in JavaScript, I was like is this going to be terrible? Because there’s so much overhead in Java and C plus, plus you have to write types for literally everything.”

Transcript

This is a machine translated transcript. Podcast page for this episode is here

Adam:  I have been confused about something. I really like having static type information when I code. When I think about building something, I think about defining types, writing things to map from my one type to my other. That’s kind of how I design in my head when I’m thinking about how to solve problem.

However, smart people, talented people that I know view things very differently. There are skilled people who would leave their job before using language with static types. So I emailed this guy.

Jared: I’m Jared Forsyth. I am a software developer at Khan Academy.

Adam: Jared started in one camp and moved to the other. Well sort of, because now he’s all about the inferred types.

And maybe that’s the best of both worlds, but I’ll let him explain.

Jared: I’ll admit I was definitely scarred by Java and C plus plus and, um, intro to programming class. And I never want to look at types again camp. My first language was Python and followed closely by Java script, and so I was loving the loosey-goosey scripting language.

So my first experience of using types in JavaScript, I was like, Oh, is this going to be terrible? Because there’s so much overhead and so much because in Java and C plus, plus, you have to write types for literally everything, right? You declared a variable. It has to have an explicit time, any function, explicit type.

just all over the place and. It was actually really refreshing in flow and TypeScript and also reason, which we’ll talk about, we are, so much of the typing can be inferred for you. So you declare a function, you use it one place, and kind of from the contents of the function, the type system can discover, Oh, they’re adding this variable to another.

Those are going to be numbers or strengths depending on, it can be really clever about that so that you don’t have to be writing types everywhere, but you do still get the checking and you can hover over a variable to discover what’s the type that was infered for this, which is super nice.

Adam: Like there must have been some moment where you were like, “Oh, this thing got caught”, or “Hey, I can go to definition” or something where you were like, Oh, the light bulb turns on?

Jared: Thing that really has made it so that I never want to go back. Is the way that having an explicit type system changes the way you think about code. And where are you define explicitly this is the shape of the data that I’m going to be dealing with.

Here are the data structures. I’m going to lay those out, and then I can write functions that will manipulate those . It results in  much better organized code. And is it just such a help in me being able to process new code that I’m reading or code that I wrote two weeks ago and I’ve forgotten entirely about?

And that was kind of the. Wow. This is essential. Right? Cause like, Oh, it caught a bug for me. That was nice. But like, you know, I’ll just not write that bug next time. Yeah. But here are new tools for thought. Here are new tools for writing high quality code. We’re now, anytime I’m starting something in JavaScript, I add flow to it.

Adam: So I had a previous interview with a DHH, who created Ruby on rails. And he was, I think he said he doesn’t get it right. He’s like, I get, some people really want types. I don’t want them. It’s like a personal taste thing. So you know, you’ve made this transition. So I’m trying to figure out, there’s a thought process or a perspective that needs to change, or am I just missing something?

Jared: No, it’s true. And I’ve heard also Rich Hickey, the creator of closure is famously skeptical about types and in fact has come up with a different thing that he uses in place of types, schema. And it’s, it’s runtime schema checking. But it’s not really a type system. So I’ve also kind of listen to him discoursing on why types are just a matter of taste.

And so I’m familiar with that perspective. I think it’s maybe a cop out to say that we’re not talking about the same things, but I think it might be a matter of misperception. . Like I said before, I was sold on static typing. I viewed it as this is going to be a lot of manual labor and yes, maybe it will find some bugs for me, but I can write you in a test and that’s fine.

Right? Certainly the Ruby community is all in on unit tests and w we’re going to do exhaustive tense thing and that will be great, but it’s possible that you’d be able to find some programmers out there that would say commenting your code as a matter of taste. But I th I think in professional development it’s pretty standard that, yeah, you want some doc comments to describe at a higher level, kind of at a human level, here’s what this class is going to be doing.

Here’s what this general group of functions is responsible for. And some people take those comments and they’re like, Oh, well let’s add Java doc to these comments. And in JavaScript, if you add Java doc style comments, then. Yes. Lint can do some things or Google’s closure compiler can do some things, but the issue is those comments can go stale if you’re like, Oh, this argument is, has this thing, or you know, there are these arguments and type annotations to functions are like comments that can’t go sale, and they add so much to the trackability of a code base.

It’s possible that I’m too far removed from when I, he didn’t like type systems to be entirely useful to you. But I mean, these days I see code bases that were written without regard to types, kind of like  digging into  dynamism that’s possible with JavaScript and are just like, we’re going to, I had a bunch of random attributes to this object and there’s no way to know at any given time which attributes at a tad out to it yet.

And maybe I should read some of DHH’s code, but I would guess that the code that he’s writing is easy to type. It’s not like, Oh yeah, I love to have functions that take a ton of different types of arguments depending on how you call it. No, that’s actually  bad practice. Generally. So having a type checker just helps you read other people’s code, and especially as the size of a team gets larger, keeping everyone on board, it’s so much easier if there’s something that’s enforcing kind of those coding practices.

Adam: It’s kind of like the TypeScript slogan about scaling, right? They’re talking about like scaling a team actually, not really in terms of the

Jared: exactly

Adam: Whatever amount of data you’re going to throw at it.

Jared: I can’t tell you how many times I, I guess I said this already, but looking at a function and untied JavaScript.

You’re like, where does this value even come from?  what guarantees do I have? Okay.  zero I have zero guarantees. So then another direction to take it is I’m going to do a million dynamic checks at the top of this function. Mm. And this is what we had in like 2013 2014 Java script.

Adam: Like check the number of arguments

Jared: and the, yeah, we’re, we’re going to check the number of  arguments,  we’re going to do a bunch of type of checks to be like, okay, make sure this is a string and this is a number on this. There’s an object that has these attributes. That’s so much code that is, you know, it’s defensive programming. We’ve got a better way now and it’s fantastic.

Adam: Yeah, that makes sense. If you think of that, the type checker is something just doing all that defensive stuff for you, right?

Yeah. What about prop types and react?

Jared: Prop types were a gateway drug, I guess the creator of react. Jordan Walker is also the creator of reason, again to Ocaml all begin to types. And one of reacts big selling points early on is this is a framework that can scale because it does really dials in  hard on encapsulation.

So these components can be reused. In comparison to angular at the time with kind of the dynamic scoping stuff that was going on there, made it moderately dangerous to reuse code, react, really dialing in on, let’s make these things were usable and in order to really deliver on that promise, especially with a team that’s large.

You need to be doing this defensive programming. So react proptypes built in all of those texts for you. And then a couple of years later, along came flow, which was like, we can do this comprehensively for all your JavaScript, not just for your react components.

Adam: Today’s episode is sponsored by springboard.

If you want to learn how to write machine learning algorithms or if you want hands on experience deploying a machine learning model into production, or if you want to learn how to build and deploy a deep learning prototype, check out their machine learning engineering career track. When you join this program, you’ll be paired with a machine learning expert who provides one-on-one mentorship throughout the course.

This program is designed for software engineers, so you must have at least one year of experience in a modern programming language like Java or C plus plus or Python. Now, here’s the cool part. Cool. Recursive is exclusively offering 20 scholarships of $500 to eligible applicants. Make sure you use code AI springboard.

When you enroll. I’ll put a link in the show notes as well. The 20 scholarships are awarded on a first come first serve basis. Check it out. See if you are eligible. Applying is free and it only takes 10 minutes. Thank you. Springboard.

Adam: And then where does reason come into this?

Jared: So reason is reason is built on OCAML. Ocaml is one of those languages that routinely makes it onto . Gotta learn these five languages to change the way you think about code. You know, there’s going to be probably closure on, there are some other lists and there’s going to be Haskell and there’s going to be ocaml, it’s something like 25 years old, been around for a really long time, and a lot of the modern, cool languages are.

Very much inspired by ML and Ocaml. So Rust, Swift, Scala, these things are, are drawing on the type system that, ocaml, and also to some extent the Haskell have. So reason is and attempt to make Ocaml more palatable to JavaScript developers is really kind of one way to pitch it, right? Because there’s so much tied up in syntax that.

For many people, myself included at the beginning, I was looking at Haskell, I was looking at Elm. Elm is a very cool language, but the syntax is so foreign. It takes me so long to read a snippet of code cause I just don’t know how to parse it. Gotta be like, okay, what’s the precedents here? How do we deal with, is this getting called with arguments or is it just getting past?

If you just slap some parentheses and curly braces, it just. Feel so much more familiar. And that’s essentially what reason is. It’s building a community, bringing in JavaScript developers, and fairly early on reason also got very tied to bucklescript, which is a compiler that will take you’re ocaml code and turn it into performance and readable JavaScript.

So these days, the reason ecosystem is a way to write something that compiles to JavaScript, but that has a, a rock solid type system. And has also taken a kind of a middle ground approach on a number of, maybe you’d say purity questions. It supports mutation if you want it. You can do an imperative style in cases, and sometimes there are algorithms where it’s like doing this, the FP way is just going to be, well, orders of magnitude slower, so I’m going to, you know, I’m going to do mutation here.

It’s fine. So there are a lot of, me starting out in reason. I felt very comforted by the fact that I could reach too and do something that the messy way, the JavaScript way. And just kind of get the function written so I can move on with my life and then I could go back and write it better with more safety guarantees, that kind of thing.

So that’s, I don’t know how well I described reason for him, but that’s what it is.

Adam: Well, there’s a lot to unpack there. So it sounds like OCAML had could compile to JavaScript, is that right?

Jared: Yeah, it’s got a bunch of backends, so it will compile to native desktop also to Android, iOS, JavaScript.

Adam: But then reason is not okay.

Most strictly speaking, it’s a different language, right?

Jared: It depends on what you call it. Language is elixir, a different language from Erlang. If you’re familiar with those two, Elixir is literally just a new syntax for Erlang. Maybe. I think it has any standard library, but is Scala a different language from Java?

They both were on. The JVM scholar is probably arguably more of a different language than reason is because  uses the exact same compiler as Ocaml does, but it is a new syntax and tool chain is often what I call it. We’re Campbell.

Adam: So you have, okay, we’ll compiler. You take off the front, right, and you put some new syntax on the back.

Yeah. And then you take off the back and you put JavaScript there.

Jared: That’s right.

Adam: And then, but then haven’t you removed everything,

Jared: Well the type system is the same.

Adam: Oh, okay.

Jared: Yeah. And that’s really the bones of, if you look at the, okay, a compiler, the compiler itself has a number of, there’s the Lexer, there’s the parser, there’s the type checker, and then there’s the, the thing that generates the assembly, and it’s really the only last bit.

Generally no assembly change it. Well, there’s a couple other internal steps, but there’s a lot that is shared. And that is. I think the things that make

Ocaml. Great. The language semantics, if you will. The module system, the function system, all of that is the same.

Adam: Ah, I see. I think I get what you’re saying.

It’s not just the syntax has changed. It’s like the syntax has changed at a very surface level to make it more Javascripty. Like it’s still like,

Jared: yeah. Yeah. So literally you could go through, and I mean initially the changes to the parser, like it was based on the OCAML parser and it was like, let’s just switch out, let out some, tell me Colin’s here and add some parentheses here.

In, in the intervening years, it’s gotten further from that, but it is still based on the  parser and has a, most of it is shared.

Adam: Yeah. And so we started off talking about types. So it is the exciting bit of reason.

Jared: Yeah. Especially coming from JavaScript and also coming from flow and TypeScript.

Reason has an OCAML has an almost entirely inferred type system. So whereas with TypeScript and flow, in order to really. Get the advantages from it. You need to right function signatures or at least for the export functions, and you did write your interfaces and stuff, but with reason I only right data types, right?

I create the data type and this is like I was saying before, when I’m thinking about a problem, I will write out the shape of the data and then I just use it and that I just used the variables and everything is inferred, but unlike flow and TypeScript. There is no any that would just be pervasive throughout everything, right?

It’s like I can have confidence that it really has my back and the tool chain, uh, the JavaScript compiler for OCAML is lightning fast. That’s one of the other things about the O’Connell system in general is generally been written for speed. So if you’re used to Scala compile times or rest, compile times or anything like that, you’ll just be blown away.

Like it is milliseconds to do a full rebuild of a reasonably large project. And you used a Webpack or babble or you’ll be blown away as well.

Adam: Oh, so it might actually be faster than my existing JS.

Jared: Oh so much faster. Oh wow. Cause the js build system is running JavaScript and JavaScript has a 200 millisecond startup time  buy to run node.

You’re giving away 200 milliseconds for every process. And your reason build chain can  completed 10 times in that. I’m going to do that.

Adam: Oh wow. I wouldn’t have expected that. That’s impressive. So you mentioned laying out a data type and then using that, do you have an example that might help us understand?

Jared: Well, let’s see. We could talk to new MVC. What’s your, to do item shape? It’s going to have a title that’s going to have an author. Maybe it’s going to have a Boolean for whether it’s been completed.

Adam: Yeah. So I define a to do item. It has some properties. And then if it were TypeScript, then my functions that dealt with that, I would just put like type annotations on them.

Right, and you’re saying I don’t have to do that.

Jared: No. Yeah, I mean, you create the object somewhere and again, reason tries to be as familiar to JavaScript developers as possible, so it’ll look like the same object syntax. And the reason they’re called records instead of objects because of complicated past, but you just create the object literal and then pass it around.

You can access attributes and all that, and you don’t have to be. Dropping annotations anytime you want to use it.

Adam: But so can I if I want to.

Jared: Certainly. Yeah. For the purposes of reading code, especially if you’re reading it on good habits. Nice to have the annotations there, cause you don’t have the hover for type kind of stuff.

Nice.

Adam: What else does reason to have? What else makes it

Jared: unique? I’ve got a different pitch depending on where you’re coming from, right? If you’ve tried Elm, I could talk about kind of similarities and differences. Mmm. For example, Elm has a. A focus on immutability and sandboxing from JavaScript where the creators of Elm somewhat justified in this say JavaScript is very dangerous, right?

It like does not give you guaranteed. And so in order to interact with you always, if you need to go through a serialization bridge and we’re going to make that asynchronous. And that will make sure that there’s no way that JavaScript’s unsafety can infect the safety of your own program. I’ve talked to some people that we’re using Elm and we’re running up against that a lot and tried reason and we’re very happy about how reason.

Doesn’t enforce that we are nearly to the next step. You write your type adaptations for what you expect Java script to give you, and that’s that. You can call the function synchronously. There’s not, that’s the realization bridge. There’s not nearly as much work two bind to a node module, for example. Now that comes with unsafety, right?

If you expect JavaScript to give you a number and it gives you a string, then you’ve got a run time exception. Oh, I see.

Adam: Yeah, so Elm is they want it to be completely sound, so then they lock it down, but. It prohibits adoption to a certain extent,

Jared: right? I mean, and it can make some performance things more difficult and some other things.

Now, one thing that I love about Elm that it has kind of narrowed the scope of what it wants to do, right? It is, this is a language for building UIs  and it’s phenomenal at that. Because of that, it can make some tradeoffs. Generally, UIs are not performance bound despite what the demos might suggest.

Your unlikely to be rendering 10,000 elements on a page. Okay.  most of us don’t do that in general, and so the trade off that it’s made, I think are are perfectly reasonable reason. And OCAML are much more of a, this is a language that we can use for UIs. We can also use a per servers and for embedded devices we can use it.

Two build games and there’s a ah, very cool text editor, native desktop, et cetera, are being written in reason. It’s just such a wide gamut and that’s one of the other things that makes me really excited about reason.  written and shipped a couple of native Android and iOS apps, Britain, and reason. And being able to learn one language and then right at cross-platform without having the tradeoffs and performance hits that come with react native with JavaScript on a mobile device, that’s always going to have worse animation performance.

Adam: How are you writing a Android app in reason?

Jared: That’s right. Yeah. And this is taking advantage of the incredible work that’s been done in the OCAML world, where there’s no ocaml backend for Android for iOS. So I’m not bringing in NPM libraries.  my Android app. Yeah. But there is a wealth of code that has just been written in pure ocaml, pure reason, and you can just bring that in.

Interesting.

Adam: It’s really exciting. I could see how it could be a limitation too. And just like you’re spreading yourself very thin. If people are using this language to do this and that and not, it’s like, I don’t know. Sometimes it’s really great to have a certain domain where people use things and libraries build up in it.

Gather steam.

Jared: Totally. And that is certainly a limitation. I think reasons community has generally coalesced around web development. Reason also has best-in-class react support, so using react and reason  better than using react to JavaScript. I mean, react was built for types. It was built with types in mind, and JavaScripts types are just not going to be as good because flow and TypeScript are partial type systems.

Using it as a reason, it is a dream, and so we’ve got a lot of people doing reaction reason and then certainly much smaller communities doing game development, doing native development, that kind of thing.

Adam: What’s the advantage of react and reason? Like what is reason by you in the react ecosystem?

Jared: It’s nice that it’s a mutable by default, right?

You don’t have to worry that somebody will accidentally have modified the props because they don’t know the conventions of react. There are a lot of things that you can do in JavaScript to completely mess up your react application just by accident  because JavaScript lets you, whereas it’s much more tuned in reason because of the type system and the general program semantics on top of that reason has JSX built in, so you can be up and running immediately.

Did

Adam: you say the react creator created reason?

Jared: That’s right. Yeah. Jordan walk was originator of react and you know, helped by a bunch of other really excellent people. And then he also started at the reason project.

Adam: Oh, very cool. I’m primarily a backend developer. I do a lot of FP stuff and people use that term very generically.

Right. And I think, at least in my little group, we mean something pretty specific that has to do with  types and immutability and kind of composing things. We’re trying to always convince other people that this is super useful. It’s been a new discovery to me that actually on the front end, people have been figuring this out.

Like while I wasn’t looking, I guess like react seems very, uh. It seems to have a lot of this spirit, I guess in it, maybe.

Jared: Yes, definitely. That’s actually another good point with reason and react because react is built very much in an FP mindset. And the reason I know OCAML are kind of the, what you might think of as the original FP is Ocaml Haskell, like those are the things that people are drawing from these days.

Unless you want untapped FP and then it’s the lisp side of things. But if you want reason has immutability, automatic currying of all functions. And just generally functions are the way to do things as opposed to classes that encapsulate both data and functionality.

Adam: You mentioned immutability. How does that work?

Jared: So the default is just that all attributes on all objects are immutable. You can annotate them as mutable and then you can mutate them. But the default is immutability and structural sharing. As JavaScript has developed, it’s actually gotten more and more reason and so it’s, it’s easy to move over cause it’s like, Oh, object spread.

I know that my thoughts, how I do things and we’ve got map and filter and reduce and all these things.

Adam: I imagine though, I’m just guessing. When I do something with immutable lists and whatever in Scala to make it performance, there’s a certain implementation, right? But are we just using the JavaScript built in types like arrays or whatever?

Jared: So, ocaml has arrays and lists, unless they’re linked. So if you’re using a raise, they are mutable and there are certain cases where you’re writing reason and a raise make sense. But most of the time I’m just using the default list implementation and the functional methods that go along with that.

Adam: And like, if I want to. Use something that outputs a reason list, but from JavaScript, like what is it ended up looking like?

Jared: It’ll be a link list. So the buckle script, internal representation is a JavaScript array with two elements. The first is the contents, and the second is the tail, and that’ll be another too elementary.

So that’ll get boring pretty quickly. So generally when you are writing interface code between reason and JavaScript. You’re converting your list to a race, but like I said earlier, if you’re interfacing with JavaScript for the most part, you’re not. Can I be running into performance intensive applications?

You’re not transforming a million items and somebody’s browser. Yeah, that’s true. Yeah. But there is some trade off things where you’re like, what’s the best tool for this job, right? And there are the hash array maps trie thing that. Uh, that clojure has that. It has some cool properties, their implementations of that for ocaml.

You can bring in that library if you want, but the defaults tend to be good enough, especially as the JavaScript that is output. The reason compiler or the bucklescript compiler is very performance sensitive and it’s very kind of tuned to take advantage of ways to make JavaScript pass.

Adam: Well, why would I want something to be immutable.

Jared: Immutability saves you from spooky action at a distance as generally my pitch, I mean, there’s so much uncertainty around I’m doing this thing and I call this function, and what if this function completely messes up the object that I passed to it? Right? So I’ve got a clone object before I hand it in or whatever.

Like again, defensive programming  and in a large code base where mutation is the norm, you just have to be looking over your shoulder all the time. Now in, uh, the code bases that I work on at work, immutability is the norm. And so I generally just trust that I don’t have to be worried about somebody changes something out from under me.

It would be nicer to have that statically guaranteed by the language system. But, uh, we do what we gotta do.

Adam: Yeah. So it’s like you’re working in a world where you just assume immutability, but, and that generally probably works, right? Because everybody has the same assumption.

Jared: Right? And if you’re using react and you’re using redux, especially.

Redox will fail in comical ways if you start mutating objects. And so I think these libraries have done a lot to bring immutability as a norm into professional jobs. Group development.

Adam: Yeah. What about some types and algebraic data types?

Jared: Yeah. It’s hard to pitch something that you don’t know you don’t have right.

For. So a JavaScript developer is not going to be like, Oh, I always wanted that because they just use other ways to get around it. But if you have done any Swift or you have done Scala or  Kotlin or Rust and you’re like, Oh, I wish JavaScript had sum types I wish it had product types, then reason’s got your back.

So some type is an enumeration. It’s like a enum except it can hold data and different kinds of data. And it’s so helpful, like there are just so many problems that if you’re trying to do it the JavaScript way, you’ve gotta be doing a lot of checks if you’re used to flow or TypeScript. They both have some types called  tagged unions where you have an object and one of the keys is the tag that says, Oh, this is going to be the loading state, or this is going to be the loaded state.

So you already have that, but it’s nicer and reason to have that built in to have dedicated syntax for it to make sure that you’re handling all the cases that you need to. It gets really cool when you’re writing a switch statement and you can enumerate over all the different cases, whereas in JavaScripts, switch statements are anemic, like they don’t even have separate scope between the different branches of the switch.

And so like you’re just dying inside as you have to come up with different variable names. So they don’t.

Adam: I didn’t know that.

Jared: Oh, for right now it’s the worst because there’s automatic fall for, right. And so like, Oh,

Adam: I feel like we need to put an example on it.

Jared: Yeah.

Adam: What’s a thing that I would do in JavaScript that will get easier with this kind of some type, like I have two different things that are related but have different data on them.

I’m trying to.

Jared: Right? No, I mean the biggest or the most important, some type that we have in our code base that’s using flow is our loadable data type. This is for anything we fetched from the network that we’re putting in Redux, and kind of the, the naive implementation would be on your reacts component.

On state, you would have a, a Boolean that is whether I am loading like, so there’s loading, which is a Boolean, and you would have error, which is an optional error. And then you’d have data, which is optional data. Right? And so on component dead Mount, you set loading to true and you kickoff the fetch and then when the fetch comes back, either you set the error to something or the data to something, and then in your render method  I have a couple of his statements.

If we’re loading, then render this. Otherwise if there’s an error under this, otherwise hope you have the data and nobody messed up your state and render them with the data. But having a some type that and forces, there are three disjoint States. One of them is loading, one of them is. Loaded with error and one of them is loaded with data.

You don’t have to worry that somebody’s gonna accidentally set both data and error to something like how do you render that it’s just impossible.  there’s a a couple of really good talks about making impossible States on representable where this doesn’t make sense. To have loading be true and data be true.

Yeah. Unless you’re refreshing, in which case, let’s account for that in the data type as opposed to just like some coincidence of the way you’ve set things up. How

Adam: would I pull this apart in reason or flow for that matter

Jared: in reason, you would switch on the floating state and critically, it’s impossible to get anything out of the loading state unless you switch on it.

And so you can’t make assumptions about, you have to switch and say, is this loading or is this loaded, or is this failed? And you have to handle all of those cases. Right. I can’t tell you how many bugs and web apps are caused by someone for getting one of the cases. Oh, I forgot that it could be loading here.

And it is, and so everything’s dead.

Adam: It’s not just web apps. I think it’s the world,

Jared: right? Yeah. Yeah. And so having that enforced for you. Again, this is another, I can offload this from my internal Ram. I don’t have to like try and remember what other cases this can be in. The compiler makes it so you can’t forget.

Adam: I think we talked about why this might be a smoother onboarding than Elm. How would you compare it to TypeScript or flow?

Jared: Sure. Not to quibble with your word choice. I think Elm has fantastic onboarding because they’ve locked down the problem set. And it’s an incredible community. I don’t want to turn anyone away from Al, but if you go to Elm and you’re frustrated by the lack of mutability and the difficulty of interfacing with JavaScript, then they become a reason.

Adam: Yeah. So how would you describe, and maybe I don’t have the right words here, how would you describe that distinction?

Jared: So there are a couple of continue, uh, continuums. Okay. And I would have to pull up on the spectrum from all mutability all the time versus all immutability. All immutability is where Elm is at, right?

You literally can’t mutate anything, and JavaScript is like, there’s no way to guarantee immutability and JavaScript. Well, you can do object out freeze, but then you have a performance penalty. And it’s still a runtime error, so what are you going to do? Right? And reason is in the middle, right? It’s definitely more towards immutability, both by convention and just the easier thing to write is with immutability, but if you need to reach for mutability you can, and that to my mind, it’s an easier transition from JavaScript.

Another neat thing that certainly helped my introduction to reason is you can just dump in a block of JavaScript and be like, I don’t know how to write this function in reason I give up. I’ll just read it in JavaScript. Yes, there were probably typos in it and it’s going to give me type errors and I deserve it.

But then you can call that, you know, it’s just sitting in your reason code so you can get on with your life and then later when it has bugs are, when you feel bad about it, you can go back and rewrite it the correct way. How does that work?

Adam: Because you said there’s no any type, so what happens there?

Jared: It is inferred to be, what do you think it should be.

Like you can’t call the function two different ways, which is what in any type would allow you to do. You can only call it one way, but there’s no check, right? Cause it’s just you dumped in JavaScript.

Adam: I see whatever you call it, as it becomes that right.

Jared: And there is technically you can get any type behavior and sometimes you need that for interacting with the JavaScript function that does literally, I got called with like a dozen different arguments, but it’s a massive code smell, man.

It has to be explicit.

Adam: So Elm is more. Restrictive JavaScript is the least restrictive. So where does TypeScript and flow fit on this continuum?

Jared: Yeah, so TypeScript and flow are right next to JavaScript. TypeScript or and flow are doing their darndest to fit a square peg into a round hole and doing a very good job.

So like if you can’t leave JavaScript, at least at some types, but if you can, why would you stay? Because there’s so much undefined behavior inherent  JavaScript runtime. And reason is it feels so much like working in JavaScript  but just without  the bad parts. I mean, do you remember the, I don’t know if you saw it, Douglas Crockford’s JavaScript, the good parts book that was like 20 pages long or whatever.

Jared: It’s like the good parts are enforced and you can rely on them.

Adam: Part of the allure of like TypeScript, I’m less familiar with flow, is just like how easy it is. Like you can just rename your files and start there. What’s the adoption path to get to reason?

Jared: Because of the heavy emphasis on JavaScript interop being easy. You can start out by just renaming your funds and especially this is a specially compelling and the react ecosystem because a reason we are component. Is there a reason jobs or is a job react to ask him about it? So you can use a react as component from reason and vice versa. I guess there are two different syntax for introducing reason to a JavaScript project.

One of them is I’m going to bite off a component and the rest of JavaScript doesn’t have to know. And the other is I’m going to bite off some like gnarly algorithm. Because I really want some guarantees there. And then you might have to do a little bit more data conversion there, but that can often be really big bang for buck, where it’s like, this has been a systemic source of bugs and I want to really lock it down kind of thing.

But yeah, as far as you’re using Webpack and whatnot, buckelscript will produce JavaScript files that’ll be consumed by your whole tool chain if you want to keep doing that.

Adam: So have you made the transition in your day job?

Jared: Not in my day job. And there are a number of things that go into that. We recently converted to react native from native iOS and Android, and we’ve adopted flow and graphQL, and we’re rewriting our whole backend and go.

So like, there’s a lot of, a lot of technical innovation budget that’s been spent the past couple of years. And so I’ve, it just hasn’t made sense to be like also let’s ditch JavaScript for this new language. So it just depends on your situation because software development is about so much more than the programming language you choose.

It is mostly about people and it is incidentally about code. But if I were on a smaller team, five to 10 people, I choose the reason in a heartbeat.

Adam: How often is there JavaScript that can’t be converted? Because it’s type is not representable.

Jared: That depends on how strict you are because flow has any. And you can just say, ah, I’ll type it does any and I will  pay the cost and bugs and developer tiers down the line.

Flow has done some really remarkable things with the types of, some that allows it to  a lot more of JavaScript than you expect at the cost of, again, still having to deal with JavaScript runtime semantics.

Adam: Yeah. Yeah. It’s a messy world out there. I guess with TypeScript, I know that somebody was talking to is having problems just because they had a lot of stuff that took like a variable number of arguments.

It was perfectly acceptable to call it with one or five or whatever. Right. I don’t think TypeScript, I may be getting the example wrong. But it seemed like it was. Yeah. I don’t know what to do with that.

Jared: Yeah. There are libraries, especially libraries written in 2010 that were like, my favorite thing is to have a function that can be called 11 different ways with these different specific arguments.

And my response to that is, that’s a bad idea. Okay. When I’m using these functions, I have to remind myself, okay, is it three arguments or is it four? The behavior changes drastically based on that’s just not, can it be easy to maintain? Now, if you mean like a spread of arguments, like I want to be able to call this with the math.

Dot. Min function can take any number of numbers and I’ll just take a the of them. That’s fine. That’s easy to type both in TypeScript flow. But if you’re like for some interesting reason, I want my library to only export one function when it could just as well expect support 10 I’m like, why are you doing that?

Adam: Yeah. Or curried functions that people have written where you can call it with one argument and then it returns a function that takes the next one, right?

Jared: Yeah. There is the kind of Scala FP style JavaScript. It goes in some interesting directions and is harder to type. For sure.

Adam: So I’m sure somebody’s listening, you know, lives in a big JavaScript code base, and this is curious about these things.

What’s your sales pitch for types and reason?

Jared: I would say learning types will make you a better JavaScript developer regardless of whether you start using Flow or TypeScript or ReasonML. The conventions that a solid static type system enforces aren’t going to make the code just easier to read in general.

And because I have learned reason because I’ve learned Haskell, and various other languages, the JavaScript that I right is different. It is more robust, it is easier to read, and it’s just made me a better professional JavaScript, devs

Adam: dynamic type people listening. What do you think? Do you buy it? Maybe you were just thinking of telling me where to take my static type propaganda.

I don’t know, but I hope you find Jared’s perspective. Interesting. Go check out  ReasonML and Jared’s podcast called reason town. There’s a link in the show notes to both. Speaking of show notes, springboards special scholarship program is linked in the show notes. Springboard with my first sponsor.

Woo, They reach out to me and the mentorship program they have sounds super cool. So check it out.

Until next time. Thank you so much for listening. .

Your email address will not be published. Required fields are marked *

Name

E-Mail

Website

Comment

Subscribe / Listen Here