Introduction
Shadaj: 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.
Adam: Hello, this is Adam Gordon Bell. Join me as I learned about building software. This is CoRecursive.
I have a checklist here for myself, because technology always goes wrong.
Shadaj: Yeah. When I used to publish videos for my YouTube channel, that was just always, I had like that 28 item long checklist of what to do before publishing.
Adam: Awesome. Let’s call this the beginning, then.
Shadaj: Okay.
Adam: That is Shadaj Laddad. I’ve been curious about Scala.js 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. Shadaj knows his React and he knows his Scala.js. And he built this framework, called Slinky, for using React from Scala.js. He is also still in university, but he’s been given 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 bailed on it. So the thing I’m hoping that, over the course of talking to you, that we learn is, what does modern front end web app development look like? And then, because I’m a Scala developer also, I was curious to hear about Scala.js and some of the projects you’ve worked on in that area.
Why JS Frameworks at All?
Shadaj: Yeah.
Adam: So I thought we’d start with, why do we have JavaScript frameworks at all?
Shadaj: Maybe 10 years back, most web applications might have a little bit of JavaScript, but it was mostly jQuery code to do a couple animations. When you submit a form, show the results of submitted forms. Simple things like that. I think the really big shift that we’ve had recently is webpages have gone to being server-side generated to being client-site generated. So before, you had your server or 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 API will send that data over, and then it’s the client’s job to present that to the user in the best way possible. And this is a really great shift. Because before, when you submitted a form, you were just waiting there seeing your browser spinner run while it was loading in the data, the server was doing its processing. Now the webpage 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 clients have this much more complicated, because your clients, it 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.
Adam: So is it all about interactivity?
Shadaj: Yeah, a big chunk of it is interactivity. There’s also just a lot more features you can deliver to the user, if you’re doing stuff on the client side. For example, your app could work offline. That’s not something they can do if you’re dependent on your server.
Adam: Yeah, I feel like I stopped paying attention to this area and, it just moved very quickly. I recall a web app, it emits HTML, and that’s how things were used. And then at some point, I remember learning Ember, Ember.js. And then there was like Angular and Angular 2. I just, at 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?
Shadaj: 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, and Vue and Angular, just provides the very core of like, here is my component, I want to collect some data, here is my state management system, here is my rendering system, and 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.
What Is React?
Adam: So, what is React?
Shadaj: 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 what you want your page to look like, to an HTML tree. So 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 kind of abstract away from that, and says, hey, this is the result, this is the data that you currently have in your webpage. Just tell me what you would like the webpage to look like, and I’ll do the internal work, to actually make that happen. And so it’s kind of like… I watched this keynote by Joe Beda about Kubernetes recently. And it’s a very similar principle that you had 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 care about the final result.
Adam: The Kubernetes metaphor you’re talking about is like, that in Kubernetes, you don’t say, add one new node. You say, I would like three nodes, right?
Shadaj: Exactly.
Adam: So you kind of describe the end state. React works the same way, it sounds like you’re saying there’s a certain functional approach to it as well?
Shadaj: Yeah, that’s where props comes in. Every component that you define is a function, quite literally now, with React hooks, that takes props and returns you an HTML tree. And that’s how you define a component. So a component is kind of the equivalent of an HTML node, except it’s all customized, you emit whatever you want. But here, now your props basically are defined attributes of your components. For example, you have a button you’ll say, okay, what color should the button be? What text should the button contain? And 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.
Adam: So is that the render function?
Shadaj: Yeah. Render function is kind of what does that. There is another big piece of React components, which is state. Because you’re going to have 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 props and state to an 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 like, what should the click counter button text to 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. So you have these two things. One which is passed down from parents, and one which is tracked locally. And the combination of those two, defines everything that’s happening in your application right now. So when you have a React class component, which is kind of 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 a tree.
Adam: When you said state, this is local state to that client component. Like, 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?
Shadaj: When you’re doing with a React component, just like you have with regular HTML, you can put event handlers on all of your HTML elements. 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, but then also fire off a regular API request to the server. And that’s one of the beautiful parts about React is, it doesn’t care how you’re doing 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 to, then maybe you could have something like the local state which is saying, hey, what’s the local counter have and what’s the count of the server. So then maybe you could show some indicator to the user that, hey, I’m uploading the newest count. API requests 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 whether 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.
Adam: That makes sense. React is interesting because it mixes markup and JavaScript together in the same file, right?
Shadaj: Yeah. That’s part of a language called JSX. 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 a macro. It just compiles down to regular function calls.
What Is Scala JS?
Adam: You mentioned Scala.js. What’s Scala.js?
Shadaj: 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, through a 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 in 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.
Why Scala JS?
Adam: Oh, very cool. So why would you want to do that? I guess is an obvious question.
Shadaj: Yeah. So 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 staticly-typed language. Strong types are a very core part about how you develop Scala code. So by using Scala.js, 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 Scala.js, Regular Scala JVM code can also be compiled to Scala.js. 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 good parsing library. And it just works perfectly with JavaScript.
So 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 on 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. [crosstalk 00:11:27] Scala has this really powerful standard library, so you get access to that all in your client end. And especially, if you’re developing larger web apps that are doing like, document editing, things like that, then those collections come in really helpful.
Why Not Typescript?
Adam: And then I guess the other big question I would have, thinking about this is, why not TypeScript? Because it’s nice, actually.
Shadaj: Yeah, so actually, I used 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 set type support. But I think the really big advantage of Scala is, it’s staticly-typed from the beginning. TypeScript, it’s a staticly-typed language, but it has this strong requirement of needing people to really easily interact with existing dynamically-typed code. So like, 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 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, because if you’re using a JavaScript library, that means you do have to put it a little more effort into defining that typing off 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, 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. Scala is a very popular language for writing your backend with a 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’s side, to make sure that you’re talking the same language. You can do stuff, for example, 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 back 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.
Adam: Well, that’s very cool, yeah. That 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 backend and you don’t realize like, oh, you’re actually changing the front end. You don’t want to send the user that has, is admin = false, to the client.
Shadaj: Yeah. I think, if you are doing the cross-Scala path, basically, all your developers now are full stack developers. That’s 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 a larger company, that might not be as practical.
Building React From Scala
Adam: We’ve talked about React and we’ve talked about Scala.js. So then, how do we use Scala.js with React?
Shadaj: 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 are writing Slinky applications, your code will actually look quite similar to what it would look like if you were running in pure JavaScript. The APIs are very similar.
And the idea here is, the Slinky doc 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, 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 the need to be onboard 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, growing an 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.
Adam: And can you mix and match? Like if I work with this large React code base that has all these components, can I also just write a component in Slinky? Or does it have to be a all or nothing type of endeavor?
Shadaj: Yeah. That’s one of the cool things you can do with Slinky. So one of the features it provides is, you can take Scala components and expose them as regular JavaScript components. And Slinky will have to take care of all the type conversions. So if you have a component defined in Scala, which takes string, a sequence of strings, and maybe a function. If you expose it as a 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.
Adam: Oh, very cool. And can I do the reverse, like you bring in the ecosystem that exists for React into my Scala.js?
Shadaj: Yeah. That’s an even older feature. I guess, the exporting components is the newer feature of Slinky, but that was one of the principles from the beginning. That there is 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 Scala case class, that here are the props it takes, and define a static type definition for all of 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 setup 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-
Prop Types
Adam: Is that props types?
Shadaj: Yeah, these are prototypes. 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 in whatever form you find them, docs or code, and convert them, and just call a case class. And based on that case class, Slinky does the 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.
Adam: Very cool. If I do the React, hello world, I just open it up and, I have this app.jsx. And it says, class app extends React component as a render method, and the render method returns. And then it has markup, like <div> hello world </div>, and then that’s it, right?
Shadaj: Yeah.
Adam: That’s the JSX. That is JavaScript with some markdown explicitly in it. And that’s going to return that, hello world, statement. Is that a component?
Shadaj: Yeah.
Adam: 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. What does that end up looking like?
Shadaj: Yeah. So with, hello world, it’s actually really simple. So what you do is, instead of for just saying class, you do, @react, 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. And so you do, @react class MyApp extends Component. So, so far, almost identical to JavaScript. One thing you do have to do is, because Scala is staticly-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 = Unit, to just say, I’m not taking any props. And then all you have to do is def renderer, open your curly braces, and then just do the regular div. Instead of JSX, Slinky uses just method calls. So instead of doing <div>, you would just do div ( ), and then put children inside there.
XML Literals and JSX
Adam: Okay. Very cool. So I really wanted to ask this question, because 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?
Shadaj: Yeah. 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 Scalas.js That do use the XML literal syntax. I think the main reason for me not using it is, the Scala developer team, like the 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 were using more standard library features. There’s some discussion for a Scala 3.e to re-introduce XML literals, but instead as a string interpolator, which would be interesting to see. So use Scala string interpolator syntax, but then you can write regular XMLs.
Adam: 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. Very concise. But yeah, I know what you’re saying. Instead of, <div>, it would just be, div, in Slinky, right? And that is a function, I assume?
Shadaj: Slinky, I guess, doesn’t have closing tags. It just has the closed parentheses. So when you’re creating a tag, it’s basically just curt application, where the first set of parameters are your attributes, and then the second set are your children, and that’s your tag.
Adam: Because you don’t need div, open, and close. It’s just div, and you pass in the content.
Shadaj: Yeah.
Adam: Oh, that was easy. I thought that was going to be some sort of complicated builder syntax where you had to match something. [crosstalk 00:21:19] Yeah. That’s very cool. With Play, with a traditional Play app in Scala, that returns HTML, it has a templating system, Twirl, that you can do markup and mix Scala in. Is there a reason you didn’t try some sort of template-based approach?
Javascript First
Shadaj: 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 the principle of React. So a lot of other frameworks, like I know Angular and Vue, have a different system than Svelte, which is this new framework where it’s HTML with some JavaScript mixed in. React is very JavaScript first. At the end of the day, all your code is supposed to be JavaScript. So Slinky mirrors that approach, where it’s Scala code with HTML mixed in.
And that also matches the general trend of how web applications look. 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 a 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, and then import it. But that, A, for IDEs, makes it harder because you can’t do like, jump to definition, and 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.
Adam: 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 the Scala people on the back end are looking towards, right?
Shadaj: Yeah, absolutely. So React is definitely a very good fit for Scala code. I think that’s why, if you see most applications in Scala.js, they’re almost all 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, or 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 staticly-typed languages. So Facebook has their extension of JavaScript called Flow, which lets you do static typing on JavaScript. So all the Facebook web app is written with that. TypeScript is extremely popular these days. I was at a GraphQL summit last year. So one of the questions after the keynote is, out of all the developers, how many of you use TypeScript? And more than half of the hands 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 quite intrusive in your coding. Where, every single time you declare a variable, you have to define the type. And that, it’s a lot more 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 static typing, and it’s not that hard to actually write code with that language.
GraphQL and Static Types
Adam: 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 like a single typo, the only way you can find it is when that line actually gets hit. And I think that, at scale, these checks and balances are really valuable.
Shadaj: Yeah, absolutely. I think, 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. That’s why Python is such a popular language for writing together simple scripts. 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, you really need that static typing. Because you’re going to have multiple developers work on the same code base. Who knows that they’re in sync. And that’s where it really starts to help out.
Adam: Definitely. So you built Slinky, which is pretty cool. So who’s using it? Has it found adoption? [crosstalk 00:25:31]
Shadaj: Yeah. So the first user of Slinky was actually my parents. So my parents had 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 attribute a lot of the success of Slinky to having that product early on. I know a couple of different people are using it. I know Oracle Cloud has been using Slinky for some of their internal tooling, and also was looking at using it for some customers 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’s a great choice.
Building Slinky
Speaker 1: What steps have you taken to make Slinky make sense to somebody who’s familiar with React?
Shadaj: Yeah. The most important thing for me, when developing Slinky, I mean, the official tagline of Slinky is, “Write React application in Scala just like you would in ES6.” So I think first of all, was the direction to go with React class components as the first class API in Slinky. So there were 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 a ES6, where you would actually define a class. So Scala.js has a recent feature, which allows you to define Scala classes, which will be exposed as JavaScript classes. So 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’d be reinventing the wheel. So if you’re using something like React Router or style-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 get that identical user experience.
Another thing is, Slinky does not introduced 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, sometimes users ask for some helper functions, where you might have some common pattern that shows up frequently. But the idea is, we don’t want to introduce new concepts that don’t exist in React.
Adam: 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 was, 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 find that vision that you wanted to keep it close to React? Or how did you find that?
Shadaj: I’ve been programming Scala for quite a while, but at Kahn Academy, the entire front end is written in JavaScript. And I was a front end software engineering [inaudible 00:28:42] . 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, 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 project. That was originally written with a different library. So they were already using Scala.js, but they were using a different API for React applications, and the different libraries.
So they actually had an 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 aren’t used to programming in JavaScript. And with Scala.js, I’d been programming in Scala.js for a while. It was 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 their 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 helps out, at the time I was actually a high school senior. So I started with 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 kind of a design document for Slinky. 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 solidify in my mind, what I wanted this project to look like.
React Dev Ergonomics
Adam: There’s a couple of 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 the ecosystem of React and the developer experience is really nice. So what is nice? And what can we learn from that?
Shadaj: Yeah. So I think the biggest for me, in terms of the developer experience, is the kind of edit-load-refresh workflow. So in JavaScript, with most application bundlers and compile tool chains, 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 like, 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 we worked on with Slinky, 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. And so when you’re using Slinky, you do get hot reloading. So you save it in Scala, it’ll compile it, it’ll update the browser with the new version of the 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 React. You 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 style 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.
Adam: Very cool.
Shadaj: Kind of having all 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.
Adam: You when you say templates, you don’t mean like HTML templating.
Shadaj: No. Yeah, I mean like project starter templates.
Adam: Yeah.
Shadaj: Because if you’re just getting started with Scala or JavaScript, there’s a lot of overhead. And after 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 Scala 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 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 I can just type in a single command, sbt new create-react-scala-app, and you’ll get, right there, are ready to go template. And in two minutes, you can have a live running Slinky app, that’s running locally on your computer.
Adam: Oh, that’s very cool. You mentioned earlier that you made Slinky when you were in high school, is that right?
Shadaj: 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.
Programming at 6
Adam: Wow. So it sounds like you must’ve gotten into programming quite early, then. Like, when did you start programming?
Shadaj: Yeah, I started programming when I was six. So both of my parents are software engineers. So they got me into that groove very early on. I started with programming simple Lego robots. Then 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 for introductory developers, to start learning how to program in Ruby. 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. Scala can be used to write your back end. It can also use to write your front end. It can also be used for right robot code, if you’re using a Scala native. So you can do all sorts of stuff, and so I’ve just found that Scala is a great language to know, and you can apply to almost any application
Adam: 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? Like, what’s ahead of you?
Shadaj: 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 the burden on developers. It’s kind of like, I tell people it’s not a popular area to work in, but I think it’s powerful as 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 a 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 these theoretical foundations of how we develop languages, and seeing how we can apply that to how these frameworks develop, too.
Programming Language Innovation
Adam: Very cool. So what programming language doesn’t exist, or where would you like to see innovation?
Shadaj: 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 run-time characteristics in 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?
Kotlin vs Scala
Adam: 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 niche-targeted language, like a GraphQL or something that is very targeted at a specific use case. But you’re saying, no, types all the way. Just focused on pushing type systems forward?
Shadaj: Yeah. I think there are the two approaches to designing programming language that we’re seeing right now. One is, let’s create a core set of axioms that are embedded into language, and then make them powerful enough that you can combine them in different ways to create additional features. That’s kind of the Scala approach. You have implicits, which is this really powerful building block, and you get [inaudible 00:37:24] concepts on top of each other. And there’s the other approach, which is, 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. 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, for me, Scala is really a great language because, as I was learning to code, I could also be exposed to all of these 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 a mix of those two, where one is focused on 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? Something more interesting, there, considering designing.
Adam: That was the interview. If you have any guest suggestions, go to corecursive.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: @corecursive or @adamgordonbell. Or you can also find me on our Slack channel. To join that, just go to corecursive.com, click Slack in the top level menu, and you should be all set.
Until next time, thank you so much for listening.
Sticher
Overcast
Dec 02, 2024
42
min