← CoRecursive: Coding Stories
CoRecursive: Coding Stories
React and Scala JS with Shadaj Laddad
00:38:52
Today Adam talks to Shadaj Laddad. What is React? Why do we need front end frameworks at all. Shadaj explains modern front end web development. He also explains why he likes to use react from scala.js and built a framework to make that easy for all. "R...
Loading summary
Transcript82 lines
- [00:00]
shadajdad
So I was writing JavaScript all day, every day and the thing that stunned me was, wow, the experience here is really nice. I want this in Scala. So it started from that.
- [00:10]
Adam Gordon Bell
Hello, this is Adam Gordon Bell. Join me as I learn about building software. This is code recursive. I have a checklist here for myself because technology always goes wrong.
- [00:26]
shadajdad
Yeah, when I used to publish videos regularly to my YouTube channel, that was just always I had like that 20 item long checklist of what to do before publishing.
- [00:35]
Adam Gordon Bell
Awesome. Let's call this the beginning then. Okay, that is shadajdad. I've been curious about scalajs for a while and also about just what modern web development looks like on the front end. I've been doing a lot of backend development and kind of lost track of what's going on in the JavaScript world right now. Shidaj knows his REACT and he knows his scalajs and he built this framework called Slinky for using REACT from scalajs. He is also still in university but he's been giving keynote speeches since he was 14. So I hope you enjoy the interview. I used to be kind of like a full stack web developer and at some point the world of front end just got very complex and I kind of bailed on it. So the thing I'm hoping that like over the course of talking to you that we kind of learn is what does modern front end web app development look like? And then like, because I'm a Scala developer also like I was curious to hear about Scala JS and some of the projects you've worked on in that area.
- [01:34]
shadajdad
Yeah.
- [01:34]
Adam Gordon Bell
So I thought we'd start with why do we have like JavaScript frameworks at all?
- [01:39]
shadajdad
So maybe 10 years back most web applications might have a little bit of JavaScript but it was mostly like jquery code to do a couple animations when you submit a form, show the results of submitting forms, simple things like that. I think the really big shift that we've had recently is web pages have gone to being server side generated to being client side generated. So before you had your server something like Play Framework, which is optimized for, hey, we can write these templates with HTML and Scala and stuff mixed in. We'll generate the page, send it to the user and that's how we present data. Now we've shifted it towards, we'll have JSON APIs, we'll send that data over and then it's a client's job to present that to the user in the best way possible. And this is a really great shift, right? Because before, when you submitted a form, you were just waiting there, seeing your browser spinner run. While it was loading the data, the server was doing its processing. Now, the web page is still interactive while it's sending that data processing, so you can keep on using it, and you get much more fluid interactions. But this comes at a cost where now your client side is much more complicated because your client side has to do all the work that originally your backend would have to do with whatever web framework you were doing. So that's where things like React and Angular and web frameworks like that come in to help ease that load and basically bring over the tooling and templating support that you had on the server side and bring that to the client side and then also make it easier to create richer interactions with the user.
- [03:03]
Adam Gordon Bell
So is it all about, like, interactivity?
- [03:05]
shadajdad
Yeah, so a big chunk of it is interactivity. There's also just a lot more features you can deliver the user. If you're doing stuff on the client side. For example, your app could work offline. That's not something you can do if you're dependent on your server.
- [03:20]
Adam Gordon Bell
Yeah, I feel like I stopped paying attention to this area and it just like it moved very quickly. I recall, like, emitting like, you know, a web app, it emits HTML and that's kind of how things were used. And then at some point, I remember learning ember. Yeah, Ember JS. And then there was like, angular, angular two. I just, @ some point I was like, this is too much. But now it seems like, at least React seems pretty standard. I guess VUE is popular too, but it seems like at least there's fewer number of frameworks coming in and out of popularity. I mean, that's my outside perception. Would you agree?
- [03:53]
shadajdad
Yeah, yeah, definitely. Because I think the reason any framework will be successful is what ecosystem grows around it. And that is what happened for React and VUE and Angular is there's a really rich ecosystem of libraries to help you out, because React and the equivalents in VUE and Angular just provides the very core of, like, here is my component, I want to collect some data. Here's my state management system, here's my rendering system. It provides those functionalities. But if you want something like, hey, I want to Talk to my GraphQL server. Now, react isn't going to handle that, but if you have really great libraries that are designed to work well with React, that can do GraphQL, that makes React a really great choice for you. So I think that's helped propel these frameworks even further, that they have this wide ecosystem where most things that you'll need when you're getting started with developing a new web app are already ready to go if you're using one of those frameworks.
- [04:48]
Adam Gordon Bell
So what is React?
- [04:49]
shadajdad
React is a lot of things, but I guess the core principle is it lets you model your entire application as a function from properties of kind of what you want your page to look like to HTML tree. Everything is defined as this function. I guess in the traditional web, everything was built upon mutations. You'd collect some data and then you'd do some DOM manipulations to say, hey, modify the contents of this HTML node. React abstracts away from that and says, hey, this is the result. This is the data that you currently have in your web page. Just tell me what you would like the web page to look like and I'll do the internal work to actually make that happen. So it's kind of like watched this keynote by Joe Beta about Kubernetes recently and it's a very similar principle that you have there, where instead of doing the hand tuning of saying, oh, I want this pod to be deployed here, this container to be here, you just say, this is kind of the overall layout. I want, I want these things to happen. Now you might have to do a bunch of different internal moving around to make that possible, but I don't care how that happens. I, I only care about the final result.
- [05:58]
Adam Gordon Bell
The Kubernetes metaphor you're talking about is like that. In Kubernetes you don't say add one new node, you say like I would like three nodes. Right. So you kind of describe the end state. React works the same way, but it's also, it sounds like you're saying there's a certain functional approach to it as well.
- [06:15]
shadajdad
Yeah, that's I guess where props kind of comes in. So every component that you define is a function, quite literally. Now with React hooks, that takes props and returns you an HTML tree. That's how you define a component. A component is the equivalent of an HTML node, except it's all customized. You emit whatever you want. But here, now your props basically are defining the attributes of your components. For example, you have a button, you say, okay, what color should the button be? What text should the button contain? Then you just have a function saying, given that specification of what I want the button to look like, how should I render that button? And that's what defines a component, which is the core building block of React.
- [06:53]
Adam Gordon Bell
So is that the render function.
- [06:55]
shadajdad
Yeah, render function is kind of what does that. There's another big piece of React components, which is state, right? Because you're going to have like a counter, something like that, you want to track internal state. React handles that by saying that each component can track its own state. So once you add in state, now the function is prompts and state to HTML tree, and then you can have callbacks to modify the local state of the component. So for example, you say, oh, I have a click counter. The counter has properties saying what should the click counter button text be? But internal to that, the world doesn't need to know what the actual count value is. It can keep track of that locally. You have these two things. One is which is passed down from parents, and one which is tracked locally. The combination of those two defines everything that's happening in your application right now. When you have a REACT class component, which is the traditional way of writing React components, then that's your render function, which is what's actually implementing the logic of generating that HTML tree. With the new style of components in React, which is functional components is literally a function which takes props and returns.
- [08:01]
Adam Gordon Bell
A tree when you say state. This is local state to that client component. I wanted to learn React a little bit before we had this talk, but that didn't happen. So I have a lot of naive questions. So if I have the state in my React component, how do I communicate that back to the server?
- [08:17]
shadajdad
When you're dealing with a React component, just like you have with regular HTML, you can put event handlers on all of your HTML events. So for example, if you're doing something like a click counter, you'd say, okay, if I click the button first update my local state, then also fire off a regular API request to the server. And that's kind of one of the kind of beautiful parts about React is it doesn't care how you're dealing with the server. That's regular API, so it doesn't intrude into that layer. So you make that request and when it comes back, then maybe you can have something like a local state, which is saying, hey, what's the local count I have? And what's the count of the server? So then maybe you can show some indicator to the user that, hey, I'm uploading. The newest count API request comes back. You can just update your local state as well to say, hey, the count on the server is. Now this because I fired off that API request. But because you have the state, React doesn't care where that state is coming from locally defined logic or from some asynchronous call that you went to the server and came back. As long as it's updated, React is fine.
- [09:14]
Adam Gordon Bell
That makes sense. React is interesting because it mixes markup and JavaScript together in the same file, right?
- [09:21]
shadajdad
Yeah. So that's part of the language called jsx. So that's not actually required for React. It's very, very frequently used with React. But actually you can kind of think of it as like a macro. It just compiles down to regular function calls.
- [09:36]
Adam Gordon Bell
So you mentioned Scala JS. What's Scala JS?
- [09:39]
shadajdad
Yeah, so Scala JS is a Scala to JavaScript compiler. Basically you write regular Scala code using the regular Scala standard library, even the Java standard library, and through a sort of compiler plugin and then a linker, it actually compiles down to JavaScript code. So you write regular code. I mean, lots of libraries that are designed originally for Scala JVM work perfectly in JavaScript. So you can just take this existing code and just compile it to a different platform and now everything can run in the browser.
- [10:05]
Adam Gordon Bell
Oh, very cool. So why would you want to do that? I guess is an obvious question.
- [10:10]
shadajdad
Yeah, so that's JavaScript is actually a pretty great language, especially with recent changes to ES6. You have a lot of nicer functional programming support. I think the biggest reason to use Scala is a. It's a very nice statically typed language. Strong types are a very core part about how you develop Scala code. So by using scalajs you can write web applications with that type of safety that, hey, if I'm doing a refactor, I'm not going to break someone else's code. The other big thing is now that scalajs regular Scala JVM code can also be compiled to scalajs. You get access to this really wide ecosystem of libraries. So if you want to do some parsing on the client side, you can use FastParse, which is a really great parsing libby and it just works perfectly with JavaScript. So kind of the combination of this is you get the big ecosystem of Scala and you also get the safety. And then Scala just has a lot of really advanced language features. So if you want to cut down and run a lot of code, you can code generate it with macros. Slinky does fair bit of that to help reduce the burden on the developer. And there are lots of new features being added all the time. And there's also a really awesome standard library. So one thing when you're dealing with JavaScript is you basically only have one type of collection, and that's the array, and that has to fit in for all the different things that you would do. Scala has this really powerful standard library, so you get access to that all in your client. And especially if you're developing larger web apps that are kind of doing like document editing, things like that, then those collections come in really helpful.
- [11:41]
Adam Gordon Bell
And then I guess the other big question I would have thinking about this is like, why not Typescript? Because it's nice, actually.
- [11:48]
shadajdad
Yeah. So I actually, I use TypeScript two summers in a row. So when I was Interning at Apollo, GraphQL, the Apollo client, which is a GraphQL client, is written completely in TypeScript. So I was working in TypeScript. TypeScript is a really great language, especially the types of things it has with structural types make it really nice to use. Scala is a little bit behind in terms of structural type support, but I think the really big advantage of Scala is it's statically typed from the beginning. TypeScript is kind of. It's a statically typed language, but it has this strong requirement of needing to be able to really easily interop with existing dynamically typed code. So one of the jokes you'll see on Twitter about TypeScript is the moment you do type any in TypeScript, you can do absolutely whatever you want. Scala doesn't let you do that. So it's kind of more, I guess, rigorous static typing in Scala, where you have fewer of those escape hatches that could cause problems for you. It's of course limiting as well. Right? Because if you're using a JavaScript library, that means you do have to put in a little more effort into defining that typing of that JavaScript library that you want to use. But I think especially for really large code bases, it ends up becoming worth it, because at the end of the day, if you do a major refactoring, you can be fairly confident that at the end of that refactoring, all of your code should work as expected, assuming it compiles. And then also things like macros and stuff like that really doesn't exist in TypeScript yet. So having those in Scala makes it possible to do a lot more fancier stuff. And the other big advantage is oftentimes your backend will be written in. Scala is a very popular language for writing your backend with the jvm. So if you already have that backend, if you're using Scala on the client side, you get this really awesome feature that you can actually just share all of your backend code with the client. So for example, if you have a bunch of model definitions, you can directly share the source of those model definitions with your client side to make sure that you're talking the same language. You can do stuff like, for example, if one of the products that I worked on is this website for learning music online. So there's a bunch of pitch detection algorithms. So in addition to running it as a batch job on the server, you can also run it on the client to reduce load on your server and give more instant feedback to the user. So you're just able to directly share this code without any effort.
- [13:56]
Adam Gordon Bell
Well, that's very cool. Yeah, you can offload things onto the client and I guess reuse is always valuable, like less code to write. I suppose there could be some downsides where you change a model on the back end and you don't realize like, oh, you're actually changing the front end. You don't want to send the like user that has isadmin equals false to the client.
- [14:16]
shadajdad
Yeah, I think if you are doing the cross Scala path, basically all your developers now, full stack developers, that's kind of the mindset that you have to take that everyone is working on both sides and that works really great if it's a small company. For larger companies that might not be as practical.
- [14:33]
Adam Gordon Bell
So we've talked about React and we've talked about scalajs. So then how do we use scalajs with React?
- [14:41]
shadajdad
So that's Slinky, that's my framework. So Slinky is a framework for writing React applications in Scala. The core principle is that JavaScript has a really fantastic developer experience if you're writing React, if you talk to React developers, it's really polished. You get hot reloading, you get all these awesome dev tools in your browser. The idea is, can we create a way to write React applications in Scala while preserving all of these developer experiences that you have? So when you were writing Slinky applications, your code will actually look quite similar to what it would look like if you were running it in pure JavaScript. The APIs are very similar. And the idea here is like the Slinky docs should not be very large. You should be able to look at the React docs, understand how individual pieces translate into Scala, but other than that, every, everything should translate over directly so you don't have to relearn how to do React. If you have developers that are used to JavaScript and they need to be onboarded into Scala, it should just be learning the language, not relearning. The framework, that's the important part. So Slinky provides the wrapper around React, a set of APIs to interact and write components, do things like that. And then also kind of growing ecosystem of facades which allow you to interact with React ecosystem libraries. So if you want to use something like Redux or React Router or any of those libraries, you can access those from Slinky.
- [15:58]
Adam Gordon Bell
And can you like, mix and match? Like, if I work with this large React code base that has all these components, can I also just like write a component in Slinky or does it have to be like an all or nothing type of endeavor? No.
- [16:10]
shadajdad
Yeah, that's one of the cool things you can do at Slinky. So one of the features it provides is you can take Scala components and expose them as regular JavaScript components components, and Slinky will take care of all of the type conversions. If you have a component defined as Scala which takes like string, a sequence of strings and maybe a function, if you expose it as JavaScript component, that JavaScript component will take a string, a JavaScript array of strings, and JavaScript functions. So it'll do all the translations for you. So you can write a little bit of code in Scala, Export that to JavaScript code, and then use it in your regular JavaScript React code as if it was a regular component.
- [16:43]
Adam Gordon Bell
Oh, very cool. And can I do the reverse? Like you bring in the ecosystem that exists for React into my Scala js?
- [16:50]
shadajdad
Yeah, so that's an even older feature. I guess the exporting components is the newer feature of Slinky. But that was one of the kind of principles from the beginning that there's a lot and a lot of software already written for the React ecosystem. It's not efficient if we have to rewrite that all from scratch for Scala. So Slinky provides this API called an external component, where all you have to do is say, here's which component I want to be talking to. And then you also define, using a Scholar case class, that here are the props it takes and define a static type definition for all those props. So one of the things you'll actually notice if you go through existing React libraries is even though they're written in JavaScript, they actually do have some typing built in. So if you look at the docs, they'll have a set of saying, this prop is an integer, this prop is a string. So they actually already have that typing built in. So with Slinky, all you have to do is.
- [17:41]
Adam Gordon Bell
Is that prop types.
- [17:42]
shadajdad
Yeah, these are prop types. So in Addition to having prop types defined in code, people even just put it as part of their documentation. So one way or another, you'll actually find that most React component libraries already have some semblance of typing. So what you do in Slinky is just convert those typing definitions into whatever form you find them, docs or code, and convert them into a Scala case class. And based on that case class, Slinky does the, I guess, magic to take a value of that case class, convert it into the props that that React component expects, and then you can just use that component as if it was a regular library component.
- [18:16]
Adam Gordon Bell
Very cool. If I do like the react hello World, I just open it up and I have this app jsx, and it says class app extends react component. It has a render method and the render method returns and then it has like markup, like div, hello world closing div and then kind of. That's it, right? Yeah, that's the JSX that is JavaScript with some markdown, like explicitly in it, and that's going to return that hello world statement. Is that a component? Yeah, I guess it is, because it says Extends React component. So I'm going to take this, but I want to do it in Scala JS using Slinky. Like, what does that end up looking like?
- [18:54]
shadajdad
Yeah, so with hello World, it's actually really simple. So what you do is instead of just same class, you doct, which is the Slinky macro annotation. So that does a bit of the magic to create a nice API for you to use that component. So you do eactclass myapp extends component. So so far almost identical to JavaScript. One thing you do have to do is because they're aesthetically typed, you have to define what's the type of props. In this case you have a component that doesn't take any props. So you would do something like type props equals unit to just say, I'm not taking any props. And then all you have to do is def render, open your curly braces and then just do the regular diff. Instead of jsx, Slinky uses just method calls. So instead of doing like angle bracket, div, angle bracket, you just do div parentheses and then put children inside there.
- [19:41]
Adam Gordon Bell
Okay, very cool. So I really wanted to ask this question because, like, Scala has XML literals that nobody uses, and it seems like JSX might be the one feature where that actually makes a lot of sense. Why didn't you take that approach?
- [19:56]
shadajdad
Yeah, so that's something I thought about a lot when I was initially designing Slinky because I knew these XML literals existed. So there are actually libraries for scalajs that do use XML literal syntax. I think the main reason for me not using it is the Scala developer team. People developing the compiler have indicated pretty strongly that that's not something that's necessarily going to exist in a similar form in the future. So in order to stay compatible with future versions of Scala, I wanted to make sure we're using more standard library features. There's some discussion for Scala3.e to reintroduce XML literals, but instead as a string interpolator, which should be interesting to see. So use Scala string interpolator syntax, but then you can write regular XMLs.
- [20:36]
Adam Gordon Bell
Yeah, it's funny because the perception I have is that everybody kind of makes fun of that language feature, but then you go to React and it's like this has been rediscovered as this jsx and everybody likes it. Right. Very concise, but yeah, I know what you're saying. Instead of angle bracket div, it would just be div in slinky. Right. And that is a function, I assume.
- [20:55]
shadajdad
So Slinky, I guess, doesn't have closing tags, it just has the close parentheses.
- [21:00]
Adam Gordon Bell
Oh.
- [21:00]
shadajdad
So when you're creating a tag, it's basically just current application where the first set of parameters are your attributes and then the second set are your children and that's your tag because you don't.
- [21:09]
Adam Gordon Bell
Need div open, div close, it's just div and you pass in the content. That was easy. I thought that was going to be some sort of complicated builder syntax where you had to match things.
- [21:19]
shadajdad
Function, Cosmic index.
- [21:20]
Adam Gordon Bell
That's very cool. With Play, with like a traditional play app in Scala that returns HTML, it has like a templating system twirl that you kind of can do markup and mix Scala in. Is there a reason you didn't try some sort of template based approach?
- [21:36]
shadajdad
Yeah, so I guess that's generally the React approach, which is instead of having HTML with JavaScript mixed in, it's the reverse direction. That's kind of the principle of React. A lot of other frameworks like I know Angular and Vue have kind of a different system in Svelte, which is this new framework where it's HTML with some JavaScript mix and React is very JavaScript first. At the end of the day, all of your code is supposed to be JavaScript. So slinky kind of mirrors that approach where it's Scala code with HTML mixed in. And that also Kind of matches the general trend of how web applications look, right? You'll have HTML, but you'll also have a lot of client side logic. So you're going to end up with a lot of Scala code that isn't even dealing with the ui. So it's nice to have that core language being the language you're writing the most code in and then you mix in JSX into that. If you had templating, you could probably do something like write it in a separate file, then import it. But that A for IDES makes it harder because you can't do like jump to definition. You can't find references where data is being used because you have these two separate files. And it's also just generally nice to say here's my data loading logic, which has to be Scala, and then I can immediately see how that's being rendered to the client. So you have that co location.
- [22:44]
Adam Gordon Bell
Yeah, I think that the aesthetics of it are nice. It strikes me just in general that if it's the aesthetics or the approach of this modern JS world, isn't that dissimilar from a lot of the stuff that Scala people on the backend are looking towards, right?
- [23:00]
shadajdad
Yeah, absolutely. So React is definitely a very good fit for Scala code. I think that's why if you see most applications in scalajs, they're almost all with React written with React, just because React is fundamentally defined on functional programming principles, so is Scala. So your code feels very natural. You're used to writing code this way, where I'll take props, I'll update some local state, I'll pass it down. You have this kind of top down approach of how you're generating data and that fits in very nicely to Scala. Even in terms of typing. Web industry is very quickly moving towards statically typed languages. So Facebook has their kind of extension of JavaScript called Flow, which lets you do static typing on JavaScript. So all of the Facebook web app is written with that. TypeScript is extremely popular these days. I was at GraphQL Submit last year. So one of the questions asked during the keynote is out of all the developers, how many of you use TypeScript? And more than half of the hands raised were raised. And so I think people are realizing that static typing really gives you a lot of benefits. And with languages like TypeScript and Scala which make it easier to write code with static types, I think the biggest burden before was that if you were using a language like Java, static typing is kind of quite intrusive in your coding, where every single Time you declare a variable, you have to define the type, and that adds a lot of kind of more kind of mental overhead as you're writing code. But when you're dealing with TypeScript or Scala or languages like that where you have type inference, I think now it's a lot easier to convince people that you get all these benefits of study typing and it's not that hard to actually write code with that language.
- [24:36]
Adam Gordon Bell
I talked to Jim Blandy before who works at Mozilla, and he was saying they have these giant JavaScript code bases and if anyone makes a single typo, the only way you can find it is when that line actually gets hit. Right. And I think that at scale, you kind of. These checks and balances are really valuable.
- [24:55]
shadajdad
Yeah, absolutely. I think, like, once you reach a certain code base size, the benefits of static typing far outweigh the costs of having to write that in the first place. It might be harder if you're like, that's why Python is such a popular language for writing together simple scripts.
- [25:10]
Adam Gordon Bell
Right.
- [25:10]
shadajdad
Because you don't want to deal with those types, you just want to get something out. But the moment you're developing a much larger code base, things start like, you really need that static typing because you're going to have multiple developers working on the same code base who knows that they're in sync. And that's where it really starts to help out.
- [25:24]
Adam Gordon Bell
Definitely. So you built Slinky, which is pretty cool. So who's using it? Has it found adoption there?
- [25:31]
shadajdad
Yeah, so kind of the first user of Slinky was actually my parents. So my parents have their own startup called learnraga.com, so it's a website for learning Indian classical music online. So they were the first users of Slinky. And actually I think that's. I attribute a lot of the success of Slinky to having that product early on. I know a couple of different people using it. I know Oracle, Oracle Cloud has been using Slinky for some of their internal tooling and also was looking at using it for some customer spacing tooling. And a bunch of just single users all around the world have been using Slinky for some web apps. Another cool thing you can do with Slinky is Slinky supports React native, so you can actually write native applications for iOS and Android with Slinky. So if you want to do that in Scala, then Slinky is a great choice.
- [26:13]
Adam Gordon Bell
What steps have you taken to make Slinky make sense to somebody who's familiar.
- [26:17]
shadajdad
With React Yeah, so the most important thing for me when developing Slinky, I mean, the official tagline of Slinky is write React to application Scala just like you would in ES6. So I think first of all was the direction to go with React class components as kind of the first class API in Slinky. So there are a couple other libraries for writing React applications in Scala, but most of them take the approach of using some type of builder API for writing the component. So you end up using React, but you get a fairly different API for actually doing that compared to what you would do in ES6, where you would actually define a class. Scalajs has a recent feature which allows you to define Scala classes which will be exposed as JavaScript classes. This allows us in Slinky to use a very similar API where you actually define a class. You extend methods the same way you would in JavaScript, and that allows you to write components that way. I think another big component of that about writing code just like ES6 is the ability to easily import APIs and components from other JavaScript libraries. Because if you want your code to look similar, you're going to also want to use similar libraries. And it makes sense to do that because otherwise you would be reinventing the wheel. So if you're using something like React Router or styled components, there are actually libraries available that allow you to use them from Slinky with an almost identical API. So a little bit of extra work, but it allows you to kind of get that identical user experience. Another thing is not introduce additional APIs as much as possible. So all of the APIs that you should be using should have direct one to one mappings to APIs that exist in JavaScript. So for example, like sometimes users ask for some helper functions where you might have some common pattern, and that shows up frequently. But the idea is we don't want to introduce new concepts that don't exist in React.
- [28:07]
Adam Gordon Bell
I think that shows that you have a very strong sense of where this is going. I had this interview with Gabe Gonzalez and he was talking about building a successful open source project. And one thing he was saying is like, you actually need to have a perspective where you'll actually end up rejecting some pull requests because you're like, that's cool, but that's not my vision for what this is. Did your work with your parents help you kind of find that, that vision that you wanted to keep it close to React, or how did you find that?
- [28:35]
shadajdad
So I've been programming Scala for quite a while, but at Khan Academy, the entire front end is written in JavaScript and I was a front end software engineering intern, so I was writing JavaScript all day, every day. And the thing that stunned me was, wow, the experience here is really nice. I want this in Scala. So like it started from that. I want the experience that JavaScript developers have in Scala, but with the additional features that Scala gives me. So that got it started. So my parents actually at the time, they were already working on this product that was originally written with a different library. So they were already using scalajs but they were using a different API for React applications at different libraries. So they actually had intern who was working with them at the time. And one of the tricky parts that they had, and this was in general like if you're working with contractors or anything, that it's hard to onboard them because the APIs looked very different to those developers than what they were used to. Because if you're hiring a front end developer, chances are they're not used to programming in Scala and they are used to programming in JavaScript. And with SkullJS, I've been programming in SkullJS for a while. It's like it should be possible to bring this API over. And there's a lot of thought that's gone into developing the JavaScript API this way. Because Facebook has thousands of software developers working on the front end. They clearly have some kind of thought process that went into that. And it makes sense. It shows when you're actually writing that code that you can write code a lot faster. So that kind of guided the idea for Slinky. And I think actually one of the things that helped at the time I was actually a high school senior. So as part of my college apps, one of the colleges I was applying to asked for a technical portfolio. So what I decided to do for that technical portfolio was write a kind of a design document for Slinky.
- [30:12]
Adam Gordon Bell
Yeah.
- [30:12]
shadajdad
And I think that actually helped solidify my own ideas for what I wanted Slinky to look like to write. What are the principles behind Slinky? What do we aim to do? What are non goals of the project? And that really helped kind of solidify in my mind what I wanted this project to look like.
- [30:26]
Adam Gordon Bell
I think there's a couple things you went over that I think we'll have to unpack as we go a little bit further. Like that you built this in high school and that your parents are Scala developers as well. But before we get to that, you said like the ecosystem of React and the developer experience is really nice. So what is nice. And what can we learn from that?
- [30:45]
shadajdad
Yeah, so I think the biggest for me in terms of the developer experience is the edit, load, refresh workflow. So in JavaScript, with most application bundlers and compiled toolchains, you have hot reloading. So you modify a little chunk of your JavaScript, you save it, and by the time you go to your browser, your application will already be running the newer version. But it preserves all the state of your application. So you don't have to re navigate through your application, it's just there. But you can modify a color of the button and it'll just refresh right there. That's incredibly helpful if you're working on a front end application. So that was the first thing worked on with Slinky was because I was very used to doing that when I was working at my job, so I wanted that in Scala. So Slinky actually does a fair bit of work behind the scenes to enable hot reloading to happen. So when you're using Slinky, you do get hot reloading. So you save it in Scala, it'll compile, it'll update the browser with the new version of your application and everything will be running. Another really cool thing that the React ecosystem has is there's this idea of styled components which I'm a huge fan of. So this is instead of writing CSS for your application, you actually write your styles in JavaScript code as well. And this is the whole idea of like React, we want to co locate our UI with our data handling and the rest of our application logic, why not also co locate the CSS for that? So that's something that's really helpful. And so that's one of the use cases that I had for Slinky where if we're supporting these External libraries from JavaScript, this is definitely one that I want to be able to support. So Slinky does have support for styled components. There's a separate library that I've developed for that. So you get basically a string interpolator which says you can interpolate in bits of CSS and that will generate a React component that you can use throughout your application for creating elements with those styles applied.
- [32:32]
Adam Gordon Bell
Very cool.
- [32:33]
shadajdad
Kind of having all of those pieces already handled for you makes your life a lot easier as a developer. Also simple things like React has a lot of templates, and templates are a really powerful way to get started with applications.
- [32:46]
Adam Gordon Bell
When you say templates, you don't mean HTML templating? No.
- [32:50]
shadajdad
Yeah, I mean like project starter templates.
- [32:53]
Adam Gordon Bell
Ah, yeah, yeah, because like, if you're.
- [32:55]
shadajdad
Just getting started with Scala or JavaScript, there's a lot of overhead right now to getting started. You have to set up sbt, you have to get the right SBT version. You'll have to deal with like, oh, I have the wrong skull version, wrong syntax. Same thing with JavaScript. You have to set up the bundler, you have to set up the compiler. Even if you're not running Typescript, you have to use a compiler these days because you have to support all different types of browser versions. So it's a lot of headache. But one thing that React has that's really nice is Create React app, which is just like a one line command line command and you'll get a full React project with everything set up right out of that. So Slinky offers an equivalent Create React Scala app, so you can just type in a single command sbt new Create React Scala app, and you'll get right there a ready to go template. And in like two minutes you can have a live running Slinky app that's running locally on your computer.
- [33:41]
Adam Gordon Bell
Oh, that's very cool. You mentioned earlier that you made Slinky when you were in high school, is that right?
- [33:47]
shadajdad
Yeah, yeah. So I started Slinky when I was entering my junior year of high school. I worked on it on and off, and then I think towards the end of my junior year, somewhere around there, that's when I actually made it open source and started spreading the word about this new idea that I had.
- [34:01]
Adam Gordon Bell
Wow. So it sounds like you must have gotten into programming quite early then. Like, when did you start programming?
- [34:06]
shadajdad
Yeah, I started programming when I was 6. So both of my parents are software engineers, so they got me into that groove very early on. I started with programming like simple Lego robots. And I think my first programming language was Ruby, which is a very interesting language to start with, but it actually has a really nice book about, like for introductory developers to start learning how to program in Ruby. So, so started with that, did a little bit of Python and then I found Scala and I think Scala has really stuck just because it's so versatile. Right. Scala can be used to write your backend, it can also be used to write your front end. If you can also be used to write robot code if you're using Scala native. So you can do all sorts of stuff. And so I've just been found that Scala is a great language to know and you can apply it to almost any application.
- [34:51]
Adam Gordon Bell
I was envisioning some story you were going to Say where like you got this job writing JavaScript and your parents were Scala developers and they were like not on our watch. So you started programming when you were six. That's crazy. What do you want to do from here? What's ahead of you?
- [35:05]
shadajdad
Yeah, so currently I'm a second year student at UC Berkeley studying cs. But right now my main interest is programming languages and compilers because I think if we develop the right abstractions and features into these languages, it can really reduce burden on developers. It's kind of like a, I tell people, like it's not a popular area to work in, but I think it's powerful as kind of a layer of indirection that, okay, I might not be directly working on products, but I make it easier for people to create great products if you're working on something like program languages and frameworks and stuff like that. And I find that really exciting. So right now the plan is to pursue PhD in that area after I graduate. So I'm going to be graduating. Current plan is next year in the fall, so a little bit early, but that's the area I'm working on. I'm working on some research right now at Berkeley, so that's very exciting to get involved with that. And it definitely does influence also how I'm thinking about Slinky and Scalapy and some of the other libraries that I'm working on, understanding kind of these theoretical foundations of how we develop languages and seeing how we can apply that to how these frameworks develop too.
- [36:12]
Adam Gordon Bell
Very cool. So what programming language doesn't exist or where would you like to see innovation?
- [36:17]
shadajdad
Right now I'm really excited about liquid types. So it's a concept that exists in Haskell and there's also actually a paper a year or so back about liquid types in Scala. So basically it's a way of can we go beyond types, just declaring what type of data we have to runtime characteristics of the data. So for example, I'll have an int, but I'll also specify that this INT has to be greater than 10 and can we propagate that data throughout the program to type checks?
- [36:42]
Adam Gordon Bell
Oh, very cool. It's interesting because your perspective on Slinky and stuff was very user focused. So I was suspecting you were going to say some sort of like niche targeted language like a GraphQL or something that is very targeted at a specific use case. But you're saying like no types all the way. Just focus on pushing type systems forward.
- [37:03]
shadajdad
Yeah, I think they're kind of like the two approaches to Designing programming language that we're seeing right now is one is like, let's create a core set of axioms that are embedded in the language and then allow make them powerful enough that you can combine them in different ways to create additional features. That's kind of the Scala approach, right? You have implicits, which is this really powerful building block and you can develop a lot of concepts on top of each other. And then there's the other approach, which is kind of, I guess the Kotlin approach, which is, hey, we have specific use cases that the developer wants. So things like extension functions, stuff like that, let's add individual support for that. And I think both have their merits, right? Like Kotlin is generally considered a lot easier to pick up because you learn these individual features and none of them are too crazy powerful that you'll see developers doing crazy stuff with it. Scala, you'll see people doing crazier stuff with implicits, but it also means that you can explore. So I think, like for me, Scala was a really great language because as I was learning to code, I could also be exposed to all of these kind of compilers and programming languages concepts because you have these tools that you can experiment with in the language. So I think it'll be interesting to see like a mix of those two where like one is focused on like how quickly can a developer get into it, but then the other is, can the developer grow with the language? Can they expand beyond the core features? It's something interesting to consider when you're designing.
- [38:23]
Adam Gordon Bell
That was the interview. If you have any guests Suggestions, go to codecursive.com, click the link, suggest the show in the top level menu and yeah, send me those ideas. Also, just let me know what you thought of this episode either on Twitter o Recursive or dmgordenbell, or you can also find me on our Slack channel. To join that, just go to co recursive.com click slack in the top level menu and you should be all set. Until next time. Thank you so much for listening.