So, conclusion. I want to give a quick conclusion here to talk about these things in the abstract on abstractions, because this is something that I care about a lot. So, a lot of developers and a lot of tech shops have this focus on doing more. It's like, let's solve new problems, let's fix new things, let's accomplish like new, totally things that haven't been imagined before, like what's the newest kind of physical sensor we can put in an iPhone, or the most realistic way we can do virtual reality, or the most innovative way we can do React state management. You can tell from my facial expression how I feel about that area. And like, and some things are genuinely very new, very different paradigm shifting, some things that are like hyper optimizations of things that give new constraints. And there's a lot of benefits to all of those things.
I find that in my approach to development, I tend to focus less on do more, and more about doing more with less. So, I'm motivated to find ways to allow individual developers, side project developers, small teams, maybe teams, internal teams within a company, maybe teams that developers that do backend and frontend, and so frontend isn't their bread and butter, isn't all they do, to equip those folks to be able to accomplish more. Like that's the kind of part of the adoption curve that I get excited about, and the kind of problems that I get excited about solving. And so with those things involved, is involve removing accidental complexity. This is a term, I think it's from Fred Brooks, Fred Brooks, for Fred Brooks books, he is a classic developer on very large early software development projects. He has written really great things that have impacted a lot of theory in software development for decades. And he talks about the idea of essential complexity, and accidental complexity. Essential complexity is like, there's just some complexity to this thing. Like if you are doing cryptography, like it's going to be complex. If you're managing complicated decisions in a business where there's 20 factors that come in to deciding what to do, that's going to be complex. Accidental complexity is things that result from the tooling that we have, the software development that we have. And it's like, oh, it takes 10 steps to do this. It's like, well, in my head, it's just one thing. It's just submitting a form or validating a form. It's like, no, you got to write all these things and cook these things up. And we have layers, and we have, you know, a bunch of low level things in the programming language you have to handle. That's accidental complexity. It's things I have to do, not that relate to solving my problem directly but they just relate to the tooling. This is over simplification. It's just one way to think about things. But the idea is when I can find tools that remove accidental complexity that allow people to focus on. Let me just solve my problem and build the thing or build the user interface especially that I wanna build. That's tools that I'm really drawn to. And I really feel like that on the React Native web, React, that's what drives me to React Native and even more so than React, honestly. Like I like React. Some people love React and think there's no downside. I don't know. Like I like some other things, other frameworks. But React is really helpful for removing the accidental complexity. Declarative rendering, the fact that you don't have to manage changing the states of UIs. If you've ever worked in a older approach that is imperative like that, you know that, and I'm working in some legacy code right now in Yahoo UI, it's imperative. And so the declarative approach to react where you just say, here's what I want the UI to look like. And then the React runtime handles updating the UI. That removes accidental complexity. There was some great talks about React internals at React Advanced this year that talked about how React handles those things under the hood. And it's great that React removes it. I love with React Native that it removes some of the native development complexity and learning, you know, iOS ecosystem, Android ecosystem, different languages, different APIs. Like I love to be able to use the language that I like. I like JavaScript. I would love to learn TypeScript as well, but either one of those, that I can use those, I can use the same React programming paradigm. So even just having to switch between equally good options is accidental complexity. And if you can use the same paradigm, that is a way to stay focused on just solving your problem. And I think React Native web takes removal, accidental complexity one step further. For cases where that abstraction works, for cases where you can specify the app, like just conceptually, it's views, it's texts, it's buttons, it's loading a URL, it's saving data to a server, I feel like React Native web is a really great abstraction to remove those things. And actually the other libraries we hit are a great way to remove accidental complexity as well. React navigation is a great implementation of a navigation paradigms, React Native paper is a great implementation of UI elements that have a great look and are really appealing and intuitive to users. Lots of other UI libraries as well, but React Native is a good one of them and it works. Sorry, React Native paper is a good one of them and it works on the web. So all of these, when you put these things together, you get to the point where I can build these apps in my free time, not everybody can, there's life circumstances as well, but I've got three young kids, my time for development is limited, but I'm able to build and maintain these apps and I'm able to give them away for free, actually. It's pretty cool, I can build an app that meets my needs exactly. That gets me excited and I get excited about equipping individual developer, small team startups, somebody wants to solve a problem better than anybody else ever has before and make a billion dollars doing it, go for it. And I love making tools that will equip them so they don't need to have three development teams in order to target iOS, Android, and the web. So fixing an accidental complexity, allowing people to do more with less is what is really appealing to me about all these things. Maybe React Native Web is a good fit for your current project and use case, maybe it's not. Maybe it's a good fit for something else. Maybe you can build something for an internal team with React Native Web that you couldn't build otherwise if you had to do it in three different technologies. But that's what gets me excited about these technologies. And so, aside from any details, I would just encourage you, if that's not the way you think about software, if the only voices you hear are the voices that are saying hyper-optimize, like build the new thing, stay as close to the metal as possible, think about whether that's solving real problems for your use case, or think about whether that's accidental complexity that you can set aside by using abstractions that help you focus on the business need and solve the problem. Kilowatts talks about any thoughts on Remix. Yeah, actually, that really ties into this topic here. I haven't used Remix myself, but I am interested in several of the technologies around combining the server and the client. I see that Next.js 13 actually came out, and things are still kind of early, but React server components are more baked, they're more available in Next.js 13, and that's the technology I'm excited about as well. So when you're on the website, these are all frameworks that try to address, hey, there is accidental complexity, and we have a server, and we have a separate client, and we have to get them to talk. There's complexity around performant rendering of the client, and the SEO, and all those things. There's complexity around, I got to now write an API layer on the server, and I got to write an API client layer on the client, or I have to use one, like GraphQL, which is great, but now I got to make sure those libraries stay maintained. So that's accidental complexity, and in my understanding, if I'm, because I haven't used Remix or Next professionally, but my understanding, they've removed some of that so that you can render things on the server, which is a lot of benefits, I mean on the server, you can get access to the database directly, so that's nice. You can store secrets on the server, store login credentials on the server, and then you can send things down to the client, and you still have the rich interactivity of React on the front end. So that's new trade offs as far as being able to remove some of this other accidental complexity. One of the things for me that I haven't dug into it so much on the side is, because I have this mobile focus bent, I want to make sure that the things I build, so the simplicity of having React Native Web for my mobile and web client is a big benefit, but then it's like, the mobile client, like that's not gonna run around the server. And so the mobile client still needs a way to talk back to the server. There's another full-stack React-based framework called Blitz.js that I've been watching. And Blitz also takes the approach of let's make it simpler to have things from the server get to the client. And the version 2.0 of Blitz, they're actually looking at adding some of that same simplicity to mobile apps. And so the way they have it is they have compilation that happens such that you write, it's a function that matches a certain signature that they have, but you write a function, that function runs on the server, but then in your source code you import from that file as though you're just importing that function directly in your client code. And it transforms that into a call to the server to get that data back. And so you don't have to write the API layer there either. So that's very cool and exciting to me, not for every single system, REST based APIs, GraphQL based APIs, super great for a lot of systems that are very big or have separate teams, but I love the option for individuals, for small teams, to remove the data layer complexity. And Blitz 2.0, once they kind of get to final 2.0, they're planning on building a way to have that same kind of build transformation to work for native apps, for React native apps as well. So that's something I'm tracking with, I'm very excited about. It could be good for me to contribute to, if I can, at least testing it out, trying it out as a user. Certainly a live stream about it as they made progress in that area. But all these places that are trying to find new points in between, it's a server and a client, or basically the React app being fully on the client side versus the application logic being fully on the server side like older server rendered web applications. Finding points everywhere in between, like I love that that space is being explored because it's gonna be ways to remove accidental complexity and different solutions in there will work better for different teams.
Comments