The Scrimba Podcast

Dev Agarwal (00:00):
I was at a conference two or three weeks ago and by far the popular opinion seemed to be View is better than React or most people are using View. I think View seems to be the dominant choice because it doesn't have really any of the bad history that either Angular or React does. But in terms of future outlook, I'm really excited to see where React is going. I don't think React is going to be dethroned anytime soon.

Alex Booker (00:27):
That was Dev Agarwal, an independent software developer and content creator. I wanted to speak with Dev about the states of React and what the future of React might look like. I noticed, and maybe you noticed as well in the community, there's some contention around React at the moment. A basic React app is a lot more complex than it used to be. There hasn't been a major update lately and the updates we have seen, like React Server components depend on a Meta-frameworks like Next.js for example, to implement them, creating something of a divide depending on if you want a Meta-frameworks at all, and if so, which one? Even though I'm optimistic about React and I love React, it's not going anywhere. I recognize this kind of converse is never encouraging when you're learning a new framework, which I know you might be or maybe React already and you're just curious about what's going on. That's why I invited Dev who's a React expert deeply embedded in the community to tell us more.

(01:25):
Was it always obvious to you that you had become a professional developer of some kind?

Dev Agarwal (01:28):
Yeah. You mean considering given my name is Dev, did I always know I was going to be a dev?

Alex Booker (01:34):
When I met you, I thought Dev was a nickname. I wasn't sure if it was your real name or a perfect nickname.

Dev Agarwal (01:38):
Yeah, I get that a lot. It does have a different meaning in our language to be honest, up until maybe five or six years ago, I didn't even realize that my name actually was Dev, which was perfect for developer because I wanted to be a developer, so I got into programming very early. My brother who's like seven years older than me, he was learning a little bit of C++ in high school and just as a learning exercise, he used to teach me a lot of things. He used to explain them to me. He was using me as a rubber duck and I was like 12 years old and I somehow grasped some very basics of programming. I wrote a little bit of C++ and then I never touched programming for another six years.

Alex Booker (02:21):
So you weren't doing any programming in school basically, but when you turned 18 or so, something was telling you to pick it back up?

Dev Agarwal (02:28):
Maybe I was much younger than 12 actually. I think I was like nine or 10, but yeah, I picked up HTML and CSS in high school. I saw some of my classmates making some cool websites and being popular in class because of it, giving presentations to the class, being our computer teacher's favorite students.

Alex Booker (02:47):
Whoa, I wish I was in your school. Nobody thought programming was cool when I was in secondary school.

Dev Agarwal (02:52):
Yeah. It only looked cool because they could do cool animations using CSS. CSS three was the hype and everyone was doing transitions and CSS animations and going to web design contests. It wasn't considered cool by the majority. It was just considered cool by a few select nerds and I was just a part of those group of nerds.

Alex Booker (03:15):
It was considered cool by the really cool people, I think is what you're trying to say.

Dev Agarwal (03:19):
Yeah, let's phrase it like that. After that I started taking some classes in high school and after high school, those were PHP, ASP and a little bit of JavaScript. I started with HTML and CSS, but I immediately jumped into full stack with PHP and JavaScript, so since very early on I've always been just making full stack apps. I've never had a project or a period of my life where I'm only working on the front end or I'm only working on the back end. Pretty much most projects that I've been on has been full stack projects. Initially it was PHP and JavaScript, then it became Full Stack JavaScript and sometimes Java or .NET when I was in college just because of classes.

Alex Booker (04:02):
That seems to be the way it goes in school. They often use things like Java, but then when you code in your own time or at a company you might veer towards like a JavaScript or a Ruby or something considered a bit more trendy for some reason, but nothing against those languages either. Was this a hobby or was it something that you were trying to make a profession out of?

Dev Agarwal (04:22):
It certainly started out as a hobby, but as high school was coming to a close and we all had to decide what to do with our lives or follow some sort of whatever, convention, societal template we are provided-

Alex Booker (04:35):
Yeah, I know bills to pay.

Dev Agarwal (04:35):
But I got really excited about web dev and I decided that that's what I'm going to go to college for. I was already sinking a lot of time into it and at some point I also decided that I don't want to study in India. If I want to be in tech, then the good old US of A is probably a great place to be in.

Alex Booker (04:54):
Yeah, I'd say so. How many years have you been in the States for now, by the way?

Dev Agarwal (04:58):
A little over five years now. It was a five-year degree, so the college that I went to, they have a co-op program where for any STEM majors along with taking your classes, you're also doing a full-time job, so you alternate between a semester of full-time study and a semester of full-time job. So this is very useful, especially for someone who was in a tech field, in an IT field where industry experience is a lot more valuable than traditional education. I think those are two things that have significantly helped my career. The first one was being full stack from very early on so I can build a lot of cool stuff and the second was being able to work full time while I'm studying.

Alex Booker (05:42):
Yeah. That's very valuable because I think when you're teaching yourself how to code, of course we all start in a similar place with the basics and although there's some cool things you can build with variables and if statements and loops, it's often the case that you start to build real applications and then if you don't know a full stack aspect to it, I think it's okay to specialize in front-end as a junior and maybe you can use platforms as a service like Firebase to bridge the gap and stuff and add some cool features, but in any case, if you're a one-person band and you want to bring something to life, that full stack component is going to help you I think build something you can show to somebody and share a link to and they can get value out of. But the other thing you said, which I think is really interesting is getting to combine this, I suppose theoretical experience you get at school.

(06:29):
Maybe it's more textbook based, that kind of thing with an actual real-world experience because I noticed for a lot of people learning to code and myself as well, you reach this point where you're doing all this learning via courses, but you're not actually putting it into use in the real world, and then it's like are you learning the right thing and then you start to realize that a whole part of writing software is writing software together, coding the right things and going about things in the correct way, and these aren't things you typically learn from a classroom or a module and an online course. I think you only get them from the in-person experience when you're collaborating with a team.

Dev Agarwal (07:06):
Honestly, that's one of the areas where my experience has been lacking the most because from very early on, again, I was a part of the small group of nerds who was excited about programming and web dev back in school, but that group, it's hard to do projects together at any point. You can always find people who are enthusiastic about something, but being able to work with people is a whole different kind of skill set that I don't really know if I fully unlocked it yet. I've been doing a lot of solo development, so when I was in high school I started with PHP and stuff, but the first freelance project that I got, contract-based project, it was before college, but I was the only person working on it. We were supposed to be two people, but the other person didn't really contribute much as group projects go, and then because of the experience that I had racked up leading up to college, once we got into projects, either school projects or side projects or even work projects, I just prefer to be left alone and just do my thing.

(08:10):
I didn't really for a long time unlock the scale of how do I work with different people, let alone how do I lead a team. That's something that's being hammered into me while working at these full-time jobs, both at my last job where I was put in charge of a team, a pretty small team, but I was put in charge of it and then obviously now that I'm in a Dev Rel team at Clerk. I guess my answer to your question is I don't really have that skill a lot.

Alex Booker (08:36):
To be fair, I do think it's the hard thing to measure. You can look at old code and be like, "Oh, this code's bad", and that's how you know you've improved sometimes. Or you can look at your scores on a test or whatever and get a measurable sense of where you've come from, but I think when it comes to these soft skills, it's a bit hard to measure and it does creep up on you a little bit. All that to say, I think it's very likely you are forever along then you might suggest, and maybe that's a testament of doing these kind of things because I think for a lot of people it turns out to be a bit of a blind spot and then it catches up with them one day, but by putting yourself in those positions sounds like it's hard to fall too far astray.

(09:10):
You're getting better at coding and better working in a team. I really like that. A lot of people wonder, do they have to go to university to get a job as a programmer and we know that isn't true anymore. Lots of people get jobs without a degree, but at the same time, it's easy to wonder, because a self-taught dev, by the way, I never did comp sci or anything like that at school, so sometimes we wonder what are the things that we're missing out on if we didn't do a five-year degree like yourself.

Dev Agarwal (09:36):
I'm honestly wondering the same thing, I have been for a while. I have been trying to justify why did I even bother to get a college degree. Obviously if we divine back time and if I didn't actually end up going to a college here in the States, I don't know what kind of a position I would be in. For me, it was very important to break into tech by breaking into, not breaking into, but getting into this country, legally getting a visa to get into this country to be able to study and work. That was one of the big changes in my life that has obviously had a lot of positive impact and if I did not go to college, that wouldn't have happened. So I guess that's one of the things that someone who doesn't go to college might be missing out on is just going to a different location with a different perspective, with different opportunities and basically diversifying their own perspective of the world and then obviously once I got to college, once I was in this environment, there's a lot of resources here.

(10:38):
There's obviously a lot of people who are specifically rooting for students to succeed, so there's a lot of opportunities that open up for all sorts of students. You get to talk to these professors, you get to talk to professionals and a lot of things about college I feel like you have to know that they exist. You have to know how to be able to use them properly, how to use those resources to accelerate your own growth over college. That's something that I feel like a lot of college students miss on or I guess college is a lot of a build your own adventure. You pick and choose what you want to do. It has a lot of tools like obviously colleges come with fraternities and parties that you can go to or they come with resources that you can use to accelerate in your career or you can do both. I decided to just do one of them.

Alex Booker (11:25):
I never thought about a school like that in terms of a choose your own adventure because teaching yourself to code, that feels also like a choose your own adventure. It didn't really occur to me they both could be that way.

Dev Agarwal (11:35):
And I primarily think that way because the curriculums, the guided courses, those have not really been very helpful to me. I think any structure that the colleges will give you, especially if you're in tech, if you're in software, if you're in programming, it's going to be very disconnected from where the world is right now. That's primarily why I call it build your own adventure because the adventure that's handed to you, I don't think that's very relevant or helpful.

Alex Booker (12:01):
That's how you end up coding Java applets with Java 5 or something outdated like that or God forbid, a Delphi or Pascal or something super dated like that.

Dev Agarwal (12:10):
Or you spend all your time on leet code and you never really learn how to build an actual app.

Alex Booker (12:16):
Yeah, that's so funny. I've come across people who have great lead code scores and then you're like, "Okay, do a join on this database", and they're like, "What?" They're just so focused on the algorithms in that case, you can get to narrow focused on something.

Dev Agarwal (12:29):
Yeah, or center a div.

Alex Booker (12:30):
I don't know how to center a div to be fair, but nevertheless.

Dev Agarwal (12:33):
See if colleges made courses on how to center a div and how to exit Vim, it would be so much better.

Alex Booker (12:38):
I've still got Vim open on my computer. I mean, I just can't close it.

Jan Arsenovic (12:42):
Coming up on the Scrimba Podcast, what's going on with React?

Dev Agarwal (12:46):
It's the exact same thing that happened over a decade ago.

Jan Arsenovic (12:50):
But first, let's take a look at social media. Hello, I'm Jan, the producer and in every episode I look for your LinkedIn and Twitter posts about our show and the coolest ones get shout-outs. On LinkedIn, Ingrid shared our interview with Leo de Leon that we published in April of 2023 and wrote, "This Scrimba Podcast was so awesome and Leo's story resonated with my own coding journey. I admire his growth mindset and tenacity. A few excellent takeaways from this podcast. Number one, consistency is key. Number two, keep going, motivation fluctuates. Number three, start today if you haven't. Number four, ReadMe Driven Development mentioned by Alex, the host, is something I'll look into for my next project. I highly encourage you to listen to this story and get inspired."

(13:43):
Thank you, Ingrid. That was a really cool episode and I will be linking it in the show notes in case you missed it and if you would like to join the conversation, just post about us on Twitter and LinkedIn. As long as your post contains the words Scrimba and podcast, we will find it. Word of mouth is the best way to support a podcast that you like, but if you are feeling super supportive, you can also leave us a rating or a review in your podcast app of choice, so like Apple Podcast or Spotify or Overcast or Pocket Casts, Podchaser, Podcast Addict. We also read your reviews on the show, but for now we're going back to our interview with Dev, the dev.

Alex Booker (14:28):
How did you end up transitioning into your first role in tech? Did university help you there by helping you tee something up or did you have to kind of hustle on your own?

Dev Agarwal (14:36):
I think that depends on what counts as first role in tech. If you're going to count the freelance project that I got before college, then that was mostly through networking and knowing a person who knows a person who knows a person. I think actually every job that I've held or anything that was paying me to do anything, it's always been because of networking or because of showing enthusiasm or because of finding someone who has a problem and convincing them that I have a solution or I can help in some way. That has been the story for four out of four of my jobs and projects that I've been able to work on.

Alex Booker (15:15):
This is an example of where we could do two full podcast episodes because what you're saying is reigning true for me and I have to say I'm not surprised, hey, you say that. That's the way I've seen it play out as well and yet understandably, when you're new to the industry, you think it's all about applying to jobs and building a portfolio and stuff and there is definitely room for this. It definitely can make an impact, but it's often about proving your value I would say, and proving it to the right person. That's how you open up some really interesting conversations.

(15:42):
So what we'll do is table that and if people want to hear a second episode where we go more into Dev's career advice, I think that'd be an excellent episode indeed. But something else that I want to talk about today and segues into a little bit is, well, you just strike me as being really embedded within the React community and you strike me at least as someone who's always toying with and learning about the latest React technologies and that to me is a great opportunity because the React ecosystem and community, it seems a bit fragmented you could say at the moment.

(16:14):
I'm not sure if you see what I mean by that and if you agree. We have seen posts cropping up lately, people questioning the state of React, something that used to be so simple and straightforward, there's not quite a lot of proving parts. What's your take on the current situation with React?

Dev Agarwal (16:30):
Man, I wish I could summarize what's happening with React in a concise manner, but there's a few things that are going on. The "disappointment" that we have seen from some of the React community is geared around a few core issues. I use the word issue very loosely. I'm not saying that these are solid issues with some institution, I'm just saying that this is what I've noticed. The first one is that the priorities of the React project, the React team seem to be at a misalignment with the priorities of the community, so that's how I want to put it. You might've seen that some of the React team has left Meta, which is where React originated and they have left to join Vercel, which is a web hosting company and these are prominent members, prominent influencers within the React team member.

(17:21):
They're not just a random individual contributor, it's the tech lead of React, Sebastian and a couple of very core people and even the person who managed the React team, Tom Akino, he's now at Vercel, so this pops up some red flags with the community. Why is this happening? There's some change going on, there's a difference in priorities seems like, and server components are like another manifestation of the priorities seem to be misaligned, so I'm sure we'll get more into server components at some point. And the other thing that's powering this disappointment with the community is that React seems to hasn't done much in the last few years. It seems like the ecosystem, the community, it's getting big. A lot of people are using it, but there's problems with React, obviously no tool is perfect. There's a lot of problems with it and when some tool gets that popular, all the problems with it really come to the surface. They become really visible and it seems like React is doing nothing to fix those.

Alex Booker (18:23):
Well it's interesting you mentioned that Vercel is a web hosting company, that's true. I suppose another key point to highlight is that they are the company behind Next.js, which is a Meta-framework. It might be fair to say that it's gaining some traction lately and I also see things like ReMake, that did not exist two years ago as far as I know. That's been gaining a fair bit of traction, at least on social media. And then you have other categories of massive frameworks like Astro and so on. And I just wondered if this has anything to do with the stuff you're talking about with regards to this split in the community.

Dev Agarwal (18:55):
Definitely. I'm also going to first disclaimer everything I say is that obviously I'm not a part of React core team. I don't work at Vercel, so everything that I'm saying is an outside perspective, it's what I have observed and it's my own interpretation or educated guess of what might be happening underneath, so a lot of things that I'm going to say could turn out to be wrong. If that's the case, just let me know. So Meta-frameworks, I think when a lot of people started adopting React, they started adopting it for things that maybe React wasn't always supposed to do. We've always had the apps versus sites argument, where do you use React for apps? Yeah, but do you use React for sites where the distinction between app and sites has always been hand wavy, so I'm not going to get into that, but there's certainly a class of applications that needs a lot of page load performance that needs to be, like you can quickly navigate through it and basically it shouldn't suffer from the heavy bundles that we end up with a lot of times when we create React applications.

(19:58):
So Meta-frameworks came in to help solve that problem so that you can build SEO sites, you can render on the server, you can build your blog sites or content sites, static sites, but still use these frameworks like React. And I think what's happened over time is that because of Meta-frameworks, a lot of the community has lost the perspective on how big this problem used to be. Like we have Next.js and things like Remix and Gatsby, I guess Gatsby, we still have it, let's go with that. We have a lot of these tools that help us build better apps and better sites. With React, so when we see React solving the exact same problem, we look at it and we are like, "Wait, why is this needed? I already have a Meta-frameworks, why are you working on this to stick to the client side and solve the problems that I have on the client instead of doing the server stuff that every other framework is doing."

Alex Booker (20:55):
Yeah. I guess that React originally, without any question of a doubt, it was all about the front-end and it was a way to structure your front-end app in components and manage how the data flows between those components very simply. In fact, people didn't want to call React a framework. They really deliberately, very specifically, wanted to call it a library because it was a bit more focused than say Angular, which brought in a lot of nuts and bolts with it. The idea was React was purely about rendering components. That's what React was all about. But these days I think calling it a library might be really wrong actually because when we talk about things like React Server components, but also Next and Remix and all these Meta-frameworks of a server component, it feels like React has gone from being only about the front-end to being more of a full-stack type of solution.

(21:40):
I don't actually know if that's a good or a bad thing because one thing that's nice about REST APIs or whether you're using GraphQL or something like that, is that you do have this separation between front-end and back-end. People like that for a few different reasons, mainly that it's flexible and it also meant it was versatile in the one team could work on the back-end, one team could work on the front-end. It just made sense I think to a lot of people. But inevitably I would say the majority of React applications, they are basically full-stack applications just with a separate back-end technology. So I can see why the team might be thinking a little bit about, okay, how do we solve this problem in the same place and get some advantages along the way.

Dev Agarwal (22:19):
How much do you know about GraphQL?

Alex Booker (22:21):
Let's assume for everybody listening that we don't know.

Dev Agarwal (22:23):
GraphQL is another one of those tools that attempts to unify the back-end and the front-end in a shared language. So GraphQL is the extreme of what you get when your front-end could be absolutely anything, your back-end could be absolutely anything, you have no idea, but you want them to talk to each other and you want them to be closer together. React Server components, the conception of React Server components started with this idea of what comes after GraphQL. So it's attempting to solve a very similar problem where the server and client are unified together, they can work collaboratively to ensure the best possible UI experience. And yeah, I definitely see how that seems like React is becoming more of a framework, like it's overstepping its boundaries a bit.

Alex Booker (23:08):
What do you think?

Dev Agarwal (23:09):
I was watching this amazing talk by Pete Hunt, called Rethinking Best Practices. It's like one of those iconic talks about React where when originally React came out, it received a lot of backlash for the things it was doing compared to other frameworks.

Alex Booker (23:24):
JSX.

Dev Agarwal (23:24):
Exactly. Yeah. JSX, that's what everyone focused on and how it completely destroyed separation of concerns. But this talk by Pete Hunt, Rethinking Best Practices, it really gave us a punch in the face about how we think separation of concerns work and why that's wrong and what React actually is meaning to do. The whole point of React always was that our UI library should not enforce a pattern or a separation of concerns on us. This should be something in our control. So React gives us these components that only render once. These components are basically how you would structure your app like in a template and logic, but separately, because most frameworks want you to do it separately. React made them the same thing, you just have a one component. What that means is that the separation of concerns becomes our problem. If we want to separate logic from UI, we can do that. We have done that. There has been pure components, like smart and dumb components or-

Alex Booker (24:23):
Presentation.

Dev Agarwal (24:24):
Yeah. So all those practices have been around. What happened here is that React gave us the complete control of how we want to draw our boundaries, how we want to compose the components together. And I think we are basically seeing history repeat itself. I am 95% convinced that we are seeing history repeat itself. Server components do a very similar thing where instead of breaking the boundary between a template and the logic, it's now breaking the boundary between the client and the server, which means once again, we are in complete control of how do we want to structure our backend and frontend code. We are no longer bound to this limitation of what server code is and what client code is because now they can seamlessly interrupt with each other. So it's up to us how we want to come up with those separation of concerns boundaries and how do we want to enforce them.

Alex Booker (25:14):
I think where this conversation starts to get hairy, and it might be one of the reasons why Next comes into the crossfire sometimes, is as you're talking about this, it makes sense, but my experience with React's other components is of Next and in Next it does feel quite like it's not up to me. It's a little bit opinionated maybe about the way to go about doing it. Is that fair to say?

Dev Agarwal (25:34):
Yeah, for sure. Server components are kind of, it's an architecture, it's like a paradigm. It can be used in many different ways. The problem that a lot of people run into is, and I completely get this, I've had this issue myself many times, is that what is server components and what is Next.js and how are they different from each other? It's really hard to see where that boundary is, and that's been a pretty big barrier in people understanding several components and people adopting several components or just thinking about the possibilities with several components just because of how closely those two are intertwined.

(26:10):
And you already talked about a whole different podcast episode that we can do. I can probably also do another 40 minute session on how Next.js app router and server components are different from each other, where the boundaries are. Because I've also been looking at a lot of other frameworks, especially like Solid.js and SolidStart, I'll obviously follow Remix creators, Ryan Florence, and I've been watching all of these framework authors battle with where do the boundaries lie and how do we combine the React model and what the framework wants to implement.

(26:43):
So I think just because of how much time I've obsessed and spent onto this, I obviously have a good idea of where the boundaries are, but I don't really expect most people right now to be able to tell that difference.

Alex Booker (26:56):
It's interesting because what we're describing, even though there's a very good reason to explore these things and it sounds productive, and by the way, I played with these things and they seem productive to me, I think the trouble with software sometimes is that it is really hard to predict how people are going to use your library or framework potentially. It takes a bit of time to see if this is the right approach, and I feel like Next maybe, no negative feelings about this at all, I think someone has to, but it's obviously advantageous for them to bring the first React Server components framework you could say to developers, and when I say framework, it's like not just RSCs, but they support server actions and the router works of all of it.

(27:37):
And if you go to the React documentation, they have a section on Bleeding Edge frameworks and they mention Next, as you mentioned before, all these React people went to Next. I don't know, it feels like it could be a little bit hasty, maybe. I don't know. Whereas what I see from just my very thin musings from Twitter when I see Ryan Florence and so on Tweets, it's a bit like we're going to wait and see or we're going to give it to you in a slightly more flexible way so that we're not putting all our eggs in this basket and if it turns out to be the wrong paradigm, we can change that.

Dev Agarwal (28:08):
Yeah, I think the first thing is that I really want to challenge the notion of, and Next is in an advantageous position. My view of the reality is completely opposite because what I have seen is that Next.js, a really, really popular RAP framework decided to tell everyone who's using their framework is that, "Hey, we are now going to do things differently." And as a popular framework developer, why would you ever want to do that? Why would you ever want to completely switch your API's and the paradigm on your users? If I was in the position of the developers of Next.js, I would feel horrible doing that. I don't think Next.js is actually in a great position and I don't think Next.js has any control over what React is doing or how React is coming up with ideas or several components. I don't really think Next.js is an advantageous position. I don't think Next.js wanted to be in this position. Obviously as the framework developers, they would've much rather preferred if they could just bring the new features into the framework without completely rewriting the underlying technology, the underlying infrastructure.

Alex Booker (29:14):
If you go on the Next documentation, now there's a drop-down at the top. pages router, which is considered old, and the app router, which is fundamentally incompatible, but new and embraces RSCs and things like that. So it sounds like you think they've taken a bit of a risk maybe and it's not an advantage.

Dev Agarwal (29:30):
They've taken a big risk, yeah. I think the Next.js's developers were probably one of the first few people to be fully sold on server components. And you can imagine that for a framework that big, if someone like that decides to completely switch over paradigm, obviously it's a big risk, but maybe there's something actually really valuable there that they decided to completely gut its internals completely, basically build a completely new framework to support this new kind of paradigm. And because of that, I don't think they're in an advantageous position because they're one of the very first few frameworks to really test what server components and production looks like. There's a Shopify framework that was involved in it a while ago, but now they completely got rid of that and then instead they decided to invest in Remix instead of Server components. I think anyone who's going to come after Next.js, once Remix implements server components, I definitely think it would have a nicer implementation of server components compared to Next.js. But most of that is because they're not the first ones to the party.

Alex Booker (30:35):
It gets to learn from the mistakes.

Dev Agarwal (30:37):
Exactly. Yeah. I know there's a phrase for this, second mover.

Alex Booker (30:40):
Second movers advantage. Yeah, exactly. Or maybe it's like late mover advantage or something, but I recognize the sentiment.

Dev Agarwal (30:45):
The later you come into a field, the more perspective you have on how to do things right.

Alex Booker (30:50):
That's right. But the downside is, in a startup world, you might be too late, but I think when it comes to developers, there's a lot more of a nuanced decision to make there about what is the right technology to take a project forward with, and do you agree with it? Because one thing that Next seems to get a bit of flack for honestly, is they don't seem to totally respect web standards it feels like. And they do tend to give certain attributes, for example, a different meaning on the server side than the client side.

(31:18):
And I personally don't really mind, to be honest, but I think that some people praise Remix because it does seem to, instead of replacing an existing attribute, which we know to mean something, it might create a new one with a new meaning, which I guess the whole thing is you said that history is repeating itself, and I'm curious what you meant by that because it does feel like all these frameworks or libraries. Remember people were using things like Knockout.js and Backbone at one point and they got really popular, Ember.js as well, and they gained adoption because they did one thing really, really well you could say, and they continue to evolve and add features, but then at some point it got a bit bloated or they were just going down the wrong path, like a new paradigm had emerged and we needed a new library or a new framework to take advantage of this paradigm.

(32:03):
And I've seen it going around Twitter a bit lately, these kind of memes where it's like showing a React app 10 years ago, it's meant to be really simple and a React app today with a complex webpack config or a Meta-frameworks behind the scenes and RSCs and all this kind of stuff. So some people say, "Oh, it's getting too complicated." But then you are also pointing out that some people say, "Oh, React isn't moving fast enough. We haven't had any new features in a while." And I just wonder what is a team like React meant to do in that situation? It feels like it's hard to win.

Dev Agarwal (32:30):
I've seen similar sentiments from Dan Abramov who was a part of React core team. He's still considered an authority in terms of React just because of his contribution on the React core team. And he has come up with similar sentiments on Twitter that there's this piece of technology that he and a lot of people are really excited about and because they think it solves a lot of problems that they've seen something like it solves a lot of problems, but now that they come to the community with this piece of technology, everyone has a lot of backlash. No one seems to care enough.

(33:04):
Again, this is why I think history is repeating itself because last night I was again watching the Rethinking Best Practices and I was watching a couple of talks by Jordan Walke who created React originally, and it's the exact same thing that happened over a decade ago that they had this piece of technology that they built internally, they use it in a lot of places, they loved it, but when they open source it, when they show it to the world, they receive a bunch of backlash until someone comes around and slams you in the face with what separation of concerns actually means. So we are just waiting for that to happen at this point. We are waiting for Rethinking Best Practices, part two.

Alex Booker (33:40):
I don't know, it all sounds a bit tumultuous in a way, but React's position is very cemented. And from what I can see, even though Next might be moving quickly, arguably. Not all the other incumbents are, even React themselves, the way they release these features, it's not via a big version, but is it called Canary, React Canary? And that's where the Meta-frameworks access, and I don't think they're doing a decision that can't be undone, but it does sound tumultuous in a way. And I wonder what you think about the future outlook of React and if what could happen is maybe Spout starts to gain traction or something. I see smirking a little bit.

Dev Agarwal (34:13):
I mean, yeah, I was at a conference two or three weeks ago, not a React conference, it was like a general software dev conference, and by far the popular opinion seemed to be Vue is better than React or most people are using Vue. Most people might be still using React, but people want to learn and use Vue in their projects. That's what they want to bring in. So for a lot of enterprise or mainstream or people outside of this little bubble that we have, I think Vue seems to be the dominant choice because it doesn't have really any of the bad history that either Angular or React does, and it has a huge momentum.

(34:47):
But obviously, when talking about frameworks that are not super mainstream, that are still niche or somewhere between niche and mainstream, I think Svelte and Solid are very, very strong competitors in this area. But in terms of future outlook, I'm really excited to see where React is going. I don't think React is going to be dethroned anytime soon as the go-to library to build web applications. I think the features that React is coming up with both with server components and with the Forget compiler that we haven't talked about yet, it's going to only cement its position as the de facto choice, and we are just in the growing pains stage right now of that.

Alex Booker (35:26):
And it's necessary, right? Change isn't always straightforward or easy, but it's through this discussion and through a lot of the experimentation that people do in relation to these things, I actually just came across a little, I think it's a minimal React framework called WAKU or WAKU.

Dev Agarwal (35:42):
Yeah, WAKU, it's amazing.

Alex Booker (35:44):
And I am reading the page and I'm like, oh, okay. You don't just have to do server components with Next. It looks like you can do this. And there's actually a cool post, which is something along the lines of you don't need a Meta-frameworks to do RSC, and it talks about how you might accomplish it, but arguably doesn't provide a full path in all this kind of stuff, but it's still very early days. So you know what that, Dev, I feel like we had an impossible task ahead of us today, which is to summarize the state of the React ecosystem, talk about your journey. But I do think that in the community right now, on dev too and newsletters and Twitter and stuff, there is a general like, yeah, this divide as you put it, I think, and you put it very eloquently that maybe someone listening is caught wind of but doesn't quite know exactly what's happening.

(36:23):
I'm not sure I did before speaking with you today. We spoke a little bit about React Server components along the way. I might have to define them a little bit in the introduction so people can follow along. But otherwise, I think this was a fantastic interview and thank you so much, Dev, for your time.

Dev Agarwal (36:37):
Yeah, thank you very much. One thing I would add about Server Components is that a lot of people seem to almost have FOMO, like fear of missing out in terms of React Server components. The biggest thing that I would tell people who might be feeling FOMO regarding Server Components is that there's really no reason to. Server Components are a purely additive thing on top of React, and they have a really high barrier to adopting and using. So at this stage, if you don't know what Server Components are, if you don't know if you want to transition to it, if you don't know if they make sense for your business case, that's completely fine. It's not something that every React developer is going to need to learn.

Alex Booker (37:17):
It's so easy, isn't it? You look at social media or GitHub, and of course we're talking about the new stuff. That's what the discourse is. That's what the future is.

Dev Agarwal (37:24):
Because we don't like talking about the boring stuff that we do at work.

Alex Booker (37:26):
People do this. They talk about how things have got too complex and we want to keep it simple, but meanwhile, we're all got this shiny object syndrome and we want to use the latest and greatest thing. It's always worth repeating on the Scrimba Podcast, we say this a lot about LinkedIn and jobs or Twitter and tech. It's a bit of an echo chamber. It's not indicative of what's going on in the industry, which is what really matters if you want to get a job. And frankly, sometimes the way I think about these things is, yeah, I think Facebook was written in PHP originally, but it could just as well have been Java.

Dev Agarwal (37:56):
Yeah. Instead of rewriting to a different programming language, they rewrote the-

Alex Booker (38:00):
Programming language?

Dev Agarwal (38:01):
Yeah.

Alex Booker (38:01):
Yeah, that's brilliant. But I guess the point I'm making is they could have implemented it with anything and still produce the world's fastest growing social network. Don't lose sight of that. It's all about delivering value to the user ultimately and creating a secure or smooth or valuable experience. Your users don't care if you're using RSC or something else, unless it has an impact on the performance, but there are more than one ways to skin a cat, as you know. You don't have to use RSCs and suspense to create a skeleton UI and stuff like that. There's other ways of doing it. So good perspective to have. I thank you.

Dev Agarwal (38:34):
If you do need to do some server performance stuff, it would be a great idea to learn Server Components and do that, but then you have to know that you're learning Server Components because you want to accomplish a specific task in an easier way, not just because it's there.

Alex Booker (38:48):
Not because you have FOMO, which unfortunately is me, by the way. For me with React, I like the fact that it hasn't changed that much in the last decade or so because I learned React maybe a few years after it came out and I learned class components and new states and component hierarchy and how to thinking components and a few advanced features here and there, and I was like off to the races, I could do it. It did everything I needed it to, and then I just didn't think much about it. And I do a lot of content creation and stuff. I'm not always coding. So I was really surprised five years later, I was like, "Wow, all this stuff I learned about React, it's pretty much up to date." And then Hooks came about. Hooks was a big change, and I had to sit down and learn about Hooks.

(39:26):
And the way I would describe it is that I don't pay attention to every small change in React or in the ecosystem, but if there's a big thing happening, I want to know about it so I don't go out of dates. And I say I had FOMO about RSC, but really it was more of a, it seemed like a big thing. It seems like a big thing potentially, and it is the kind of thing that if I slept on in 12 months, I might feel like I don't really know React anymore. And so it did create that feeling within me. I'm not sure if that's FOMO or me just paying attention to the big stuff. Maybe it's too early to tell if it really is a big thing or just a trendy thing, you know?

Dev Agarwal (39:59):
And to some extent, it's also a misinterpretation or just a problem with how people are talking about it, how people like me, how people like the React core team, how people like the Next.js, the Versal, people are talking about several components. Because everyone's talking about it, it sounds like a silver bullet, but know why you're trying to go towards the specific technology and try to cut the noise.

Alex Booker (40:23):
Brilliant advice.

Dev Agarwal (40:24):
The social media.

Alex Booker (40:25):
That's right. And it applies to everything, whether it's RSC or new developers often think, oh, should I learn TypeScript? Or frankly, you're learning React, and I'm really glad at some point during this interview, you said React is not going to be de-thrown. The way I interpreted that was like, if you're listening to this and you're learning React, you keep learning React. You summed it up perfectly. Thank you for joining me on the Scrimba Podcast. It's been a pleasure.

Dev Agarwal (40:46):
Thanks for having me on.

Jan Arsenovic (40:48):
That was the Scrimba Podcast. Thanks for listening. If you made it this far, please subscribe. You can find the show wherever you listen to podcasts. The show is hosted by Alex Booker. I've been Jan, the producer. Keep coding and we'll see you next time.