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.
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?
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?
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.
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?
Why Scala js?
Adam: Oh, very cool. So why would you want to do that? I guess is an obvious question.
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.
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?
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?
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.
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?
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?
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.
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?
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.
GraphQL and Static Types
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.
Speaker 1: What steps have you taken to make Slinky make sense to somebody who’s familiar with 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?
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?
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: 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
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.