Season 1 Episode 2 Aug 13, 2020

React 17, Ruby, Chrome DevTools, Mozilla Layoffs, and Hello Weather


Does Apple have an 800-pound gorilla rule over their indie iOS developers? And why exactly does React 17 have no features?


In this episode, we cover Ruby 3 typing, GitHub running Ruby 2.7 in production, and Chrome DevTools CSS overview. We also speak with Jonas Downey, design lead at Basecamp, and co-creator of the Hello Weather app, about a Twitter thread he wrote titled, “Here’s a little tale about what it’s like to be an indie iOS developer working under Apple's 800-pound gorilla rule." Finally we chat with Dan Abramov, software engineer at Facebook, creator of Redux, and co-author of the Create React App. We’ll chat with Dan about React’s decision to release React 17 with no new features.


Saron Yitbarek

Disco - Founder

Saron Yitbarek is the founder of Disco, host of the CodeNewbie podcast, and co-host of the base.cs podcast.

Vaidehi Joshi

Creator - Base.cs

Vaidehi Joshi is a software engineer, creator of the Base.cs blog series, and co-host of the Base.cs podcast.


Jonas Downey

Jonas Downey is a principal designer at Basecamp, and the design lead for HEY, Basecamp's new take on email. Jonas is also the co-creator of Hello Weather, the weather app for iOS, Apple Watch, and Android.

Dan Abramov

Dan Abramov is a software engineer at Facebook, creator of Redux, and co-author of the Create React App.

Show Notes

Audio file size





[00:00:00] LS: Hey, DevNews listeners. This is Levi Sharpe, the producer of the podcast. We really want to benefit from your feedback on the show. So we’re gifting anyone who submits a review on Apple Podcasts, a pack of Dev stickers. All you have to do is leave a review on Apple Podcasts and then fill out the form in our show notes so that we have your mailing address for the stickers. Thanks for listening.




[00:00:31] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of CodeNewbie.


[00:00:41] VJ: And I’m Vaidehi Joshi, Senior Developer at Dev.


[00:00:43] SY: This week, we’re talking about some Ruby news, Chrome DevTools’ CSS overview, and Mozilla layoffs.


[00:00:50] VJ: And then we’ll be speaking with Jonas Downey, Design Lead at Basecamp and co-creator of the Hello Weather App, about a Twitter thread he wrote titled, “Here’s a little tale about what it’s like to be an indie iOS developer working under Apple’s 800-pound gorilla rule.”


[00:01:05] JD: So now if you’re a weather app developer, you’re basically competing with Apple using technology that you formerly have and now don’t.


[00:01:12] VJ: Finally, we’ll speak with Dan Abramov, Software Engineer at Facebook, Creator of Redux, and co-author of the Create React App. We’ll chat with Dan about React’s decision to release React Version 17 with no new features.


[00:01:27] DA: And so with React 17, we wanted to enable this other way of upgrading, which we’re calling “gradual upgrades”.


[00:01:35] SY: Our first news item is Ruby 3 Typing. So Ruby 3, we’ll have a new language for type signatures called RBS. The signatures will be written in .RBS files, different from Ruby code. One of the benefits of this is that you don’t have to change Ruby code to check type. So just for context, we know that statically typed languages are great for larger projects, but often less flexible, and then dynamically typed languages are great for rapid development but scaling them can be difficult. So Matz had promised four years ago actually and said that Ruby 3 is going to support static type checking. And it sounds like that is finally happening. So congrats to the Ruby community. You’re going to get some static type checking going on.


[00:02:18] VJ: I’ll be curious to see if people start adopting it and how quickly, because that’s like a pretty big shift. So whenever there’s a good shift, it’s like a paradigm change, you know?


[00:02:27] SY: Right. And it seems like something that was kind of going to happen eventually because community members have been doing this on their own. There’ve been multiple type checkers that have been created and now it’s going to come from the Ruby core team itself. So it’s going to be like official this time.


[00:02:43] VJ: Next up, GitHub is running Ruby 2.7 in production. Eileen Uchitelle, Staff Engineer at GitHub, posted an update on this on Twitter. She said, “It took 30 plus gem upgrades, 15 plus gem patches, and fixing 11K plus warnings. The upgrade shaved an impressive 20 seconds off production boot time. I’ll be writing a post about our experience soon.”


[00:03:09] SY: That is a lot of upgrades, a lot of patches and a ton of warnings.


[00:03:13] VJ: Yeah.


[00:03:14] SY: I cannot imagine.


[00:03:16] VJ: It must have taken them quite a long time and it probably was a huge team effort because that is no small feat.


[00:03:22] SY: Just working your way through each of those warnings, oh my goodness. That must be so intense. Also, I love that the 20 seconds is such a big deal to us, you know what I mean as like developers? If I said that to someone outside of tech, they’d be like, “And?” Like they would totally not appreciate how amazing 20 seconds off is. So yeah. Kudos to Eileen and her team for making that happen.


[00:03:45] VJ: Yeah. I’m super excited to read the post about what that was like.


[00:03:49] SY: Next in Chrome DevTools. You can now get an overview of the CSS used on the site. You can see things like the colors, fonts, media, queries, and unused declarations on the page. To access this, you open DevTools, go to settings, open experiments and enable CSS overview option, and then reload.


[00:04:08] VJ: Have you checked this out, Saron? Have you played with it at all?


[00:04:10] SY: I haven’t. I’ve seen the little screen. What is it called when it’s a screenshot, but it’s alive? Screen capture?


[00:04:19] VJ: Screen capture? Screen caps? Yeah. I was like, “A moving GIF.” But it’s more than that.


[00:04:25] SY: What? You say JIF not, GIF?


[00:04:26] VJ: Yeah, like the peanut butter.


[00:04:28] SY: Oh my God! Oh my God! I don’t know if I can do this with you anymore. Anyway, so I’ve seen it, but I haven’t actually tried it myself. But from what I’ve seen, it looks really beautiful. For a Chrome DevTool, you know what I mean? Chrome DevTools aren’t like ugly or anything, but they’re very like functional. It’s very like made to work, not so much made for like aesthetics.


[00:04:49] VJ: Yeah.


[00:04:49] SY: But this thing is like really pretty.


[00:04:51] VJ: Yeah. I haven’t played with it on production app yet, but I was just like clicking around on a different website looking at it. It’s pretty interesting. I can imagine it being super helpful, not just for developers, but for designers and everybody.


[00:05:05] SY: I can also see it being a friendlier on ramp to DevTools like for folks who are just beginners and getting started, maybe aren’t really quite comfortable using them. If that’s one of the first things they see, that feels really approachable, too. So I can see it being a nice introduction to the world of view source sores and DevTools.


[00:05:24] VJ: Yeah, totally. Finally, this week, Mozilla announced a significant restructuring of the Mozilla Corporation. This restructuring actually included a very large round of layoffs, 250 positions were eliminated. And from a 1000-person company, that’s about a quarter of their workforce. They also released a press release that announced that this change was because of reduced revenue due to the global pandemic. In addition, an internal memo to Mozilla employees this week explained that the company was going to be shifting gears to refocus on the Firefox organization and growing their core browser through user experience. And the company is also reducing investment in developer and internal tooling, as well as feature development on its platform. Their internal memo explained that they were going to be pivoting to focus on privacy and security products, as well as some of their ongoing projects like WebAssembly, Pocket, and Hubs. And they’re going to be setting up a new design and UX team and a machine learning team to help them support these new priorities.


[00:06:32] SY: Wow! That’s really interesting. And I think I saw, I don’t know if it’s all of MDN that got cut, but I know a significant part of MDN got cut. It was really unfortunate because they’ve got some great docs. They’ve got some really beautiful, really accessible content on there and it’s unfortunate that that part of the team is being affected.


[00:06:53] VJ: Yeah. It’s pretty wild that they’re cutting a quarter of their workforce because…


[00:06:58] SY: That’s a lot of people.


[00:06:59] VJ: Yeah, that really supports their statement that they’re going to be shifting priorities and it seems like a big enough shift to make such a resounding impact on the structure of the entire organization.


[00:07:10] SY: I also think that it’s interesting that the reason for these layoffs is the pandemic, because I don’t know what your assumptions were, but my assumptions were like, “We’re in tech, we’re safe.” You know what I mean? Like we do things remotely. We use the internet, like the internet is not going down, like we’re fine. Like I’ve always kind of felt a little protected and insulated by the pandemic and by just economic downturns in general. So it really kind of took me aback and was really like, I don’t know, humbling, I guess, is a word to realize that like, “No, one of our huge internet entities has been like hugely affected by the pandemic enough to be cut by 25%.” That’s a really big deal.


[00:07:50] VJ: Yeah. And it also sort of brings up the question of how a tech company that is also operating as a nonprofit can truly be sustainable in the world of big tech. Right? And it’s interesting because we just talked about a story where Chrome added this feature to their dev tools and now we have Mozilla who’s saying that they have to cut some of the products and features around internal and developer tooling. So I wonder how much of that is because of these larger for-profit big tech companies and browsers that can invest it and maybe are making it harder for Mozilla to do the same thing.


[00:08:29] SY: Yeah. Mozilla has got a lot of competition. I mean, Chrome is basically taken over, and Safari, I think is number two with about 20% of the share of browsers. The Firefox, it’s pretty low on the chart, unfortunately. As much as we love Mozilla, we really need them to be stronger and to really build out that tech and hopefully have a more promising future and something that’s more sustainable.


[00:08:53] VJ: How does Mozilla make money?


[00:08:54] SY: Yeah. So, I mean, that’s such a good question. When we talk about like a nonprofit in sustainability, like the question is like, “How do you actually become sustainable?” And Mozilla makes a lot of their money from royalties, from what browser search partnerships and distribution deals. So they’re very much relying on other companies and their deals with them and their partnerships with them to generate revenue and make themselves sustainable.


[00:09:17] VJ: You can totally see how that might not be sustainable in the long-term because it’s totally relying on external forces to keep the ship afloat.


[00:09:25] SY: Yeah, absolutely.




[00:09:35] SY: Coming up next. We chat with Jonas Downey, Design Lead at Basecamp and co-creator of the Hello Weather App, about a Twitter thread he wrote titled, “Here’s a little tale about what it’s like to be an indie iOS developer working under Apple’s 800-pound gorilla rule.”






[00:10:04] SY: Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?


[00:10:21] Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. They’ve just launched Vonage Voyagers, an exciting new program, which rewards engaged community members with training, mentorship, and awesome limited edition swag. If you apply before August 15, you can make it into the September crew. Find out more at




[00:10:54] SY: Today, we’ve got Jonas Downey on the show, Design Lead at Basecamp and co-creator of the Hello Weather App. Hi, Jonas. Thanks for being on the show.


[00:11:03] JD: Thanks for having me.


[00:11:04] SY: So tell us a little bit about who you are and a little bit about your Hello Weather App.


[00:11:08] JD: Yeah. I’m a product designer, software designer, developer kind of person. I’ve been doing that for quite a long time, almost 20 years now.


[00:11:17] SY: Wow!


[00:11:17] JD: And about I’d say five or so years ago, my friend, Trevor and I started working on the idea for a little weather app, mainly because we were frustrated with all the other weather apps and felt like, “Why couldn’t we just have a weather app that was easy to read and easy to deal with?” So we had some ideas and thought like, “Let’s take a shot at this.” We, at the time, were web developers and didn’t know much about native development. So we wanted to get into that. So we just did it as a little fun side project and then it kind of grew into relatively popular app that turned into a little mini side business, Apple featured us several times and it’s been pretty successful.


[00:11:49] SY: Nice. Good for you.


[00:11:50] JD: Yeah. it was fun.


[00:11:51] VJ: So last week, you wrote a really popular Twitter thread titled, “Here’s a little tale about what it’s like to be an indie iOS developer working under Apple’s 800-pound gorilla rule.” Can you tell us a little bit about the story behind that thread?


[00:12:06] JD: Yeah. So throughout the five years of developing Hello Weather, we started to notice that we’ve been getting more and more squeezed in a bunch of different ways being on the app store and trying to make a business out of it. And part of the thing is when we started, we didn’t really intend to turn this into a business and then it sort of evolved into one. So I think if we’d started from scratch and said like, “Well, we’re going to try to make money with this,” maybe we could do something different. But the whole idea with it was that it would be a fun kind of side project and maybe make a little side money. Problem is in order to run a weather app you have to pay for it. The services aren’t free and the data is not free. So we have to figure out a way to make it sustainable so that we don’t go into debt trying to run an app. So lately, there’ve been a lot of different changes in the category and just in general that have made our lives harder. One of the things is just that developing an app now versus five years ago has gotten to be a more complex proposition because there are so many more offshoots of what apps do. So five years ago, you can make an iOS app and it was just an app and that was it. Now you need to make a little constellation of apps. You need a watch app and an iPad version and widgets and you need serious support and there’s all these little things that are sort of like baseline expectations. When customers show up, they expect you to support these things. And that creates a lot of pressure on a small team to develop all these different little bits. So we’ve kind of been struggling with that a little bit. And then recently in the weather category, there was sort of an upheaval with our main weather provider, which is Dark Sky.


[00:13:34] SY: So why was the Dark Sky component such a big deal? Because we know that Apple bought Dark Sky. They closed their API, but why can’t you just use a different API? What’s so special about the Dark Sky API?


[00:13:47] JD: Dark Sky was a really popular API because it was priced really reasonably and had some unique features that other providers didn’t have. So the difference with their pricing model was that they charge pay-as-you-go pricing, which is like if I make a request to their API, they charge me some hundredth of a cent or something per request. Most other providers don’t do that. They charge by tiers. So they’ll say, “For this month, you’re going to pay $300 and you get 10,000 requests,” and that’s it. As a small upstart independent app, it’s nicer to have pay-as-you-go because you may not have $300 a month to pay at the beginning to start your app. A lot of developers love Dark Sky for those reasons. The challenge specifically with Dark Sky getting acquired was that Apple acquired Dark Sky and then shut off their API for developers to use and embedded Dark Sky’s technology in their default weather app. So now if you’re a weather app developer, you’re basically competing with Apple using technology that you formerly have and now don’t.


[00:14:45] SY: That sounds annoying.


[00:14:46] JD: Yeah. It’s a little bit challenging.


[00:14:48] VJ: So when Apple came out with their own weather app, I believe it was iOS 14, and they were using Dark Sky’s API, you mentioned that it made it difficult for developers like yourself to compete. Can you tell us a little bit more about how that impacts you as an indie developer?


[00:15:04] JD: In this category or any category where Apple makes an app, you’re sort of starting from a baseline of a little bit of a challenge, because if someone buys an iPhone and there’s a weather app on there, in order for you to be successful, you have to provide a compelling reason for someone to pay for another app. Right? Like if the default weather app is good, like why would someone bother paying for another one? And we kind of know that going into this. It’s not like we’re surprised by that problem. The issue in this case is that since Dark Sky did novel things like real-time precipitation and some extra features like that, when Apple bought them, that sort of raises the bar for all weather app developers. So now we have no choice but to support the equivalent features. Otherwise, we’re going to seem like we’re less of a compelling sell than the default app. And every year as Apple makes their default apps more powerful, you could see this also in the notes app, for example, anybody who’s competing in that category either has to match them or do something more sophisticated in order to become competitive in the same way.


[00:16:03] SY: So this reminds me of the claims that people have made against Amazon for a really long time and especially came out in the House Judiciary hearings where they said that Amazon finds items on their site that are doing really well by third-party vendors and then it takes those items. It makes those versions of them for themselves and it does it really by underselling and taking a loss for a long time to kind of out-compete these third-party vendors and kind of ends up squeezing them, and it makes it really hard for those companies to compete. They’re different examples, but does it feel like a comparison, a correct comparison between Amazon and Apple?


[00:16:41] JD: It does. These are similar situations. In this case, Apple kind of holds all the cards. So we’re at the mercy of what Apple decides to do. If they decide to buy out our provider, if they decide to buy out a competitor, they can do that. If they decide to change their built-in APIs, we can be susceptible to that. They also control the entire platform. So they decide what we are allowed to say, how we sell the product, what we can charge for it. They also drive traffic to the products they decide they want to market things differently. They can turn us on or off. So we’re really completely under their rule on top of being also dependent on other weather data providers. The end result is that year after year, we’re sort of scrambling around trying to do the things that we think Apple wants us to do and trying to figure out a way to continue to survive in this competitive space, which for a while was fun, but is increasingly not fun. It’s increasingly a squeeze and something that’s kind of feeling like a drag.


[00:17:35] VJ: So have you heard about things like this happening to other indie app developers at all?


[00:17:41] JD: Definitely. There’s lots of examples of Apple sort of taking over a vertical or a category with their own built-in stuff. Recently, I think it happened with Tile. Tile is that little widget that you can attach to a phone or something and make it find-able in case you lose your phone. Apple kind of took that idea and built it into their products. So it caused Tile a lot of trouble to figure out what to do next. There’s another developer called Luna who had made a screen-sharing app where you could share your Mac desktop on your iPad. Apple took that idea and built it into the iPads. And now you can just do that. So Luna got kind of broken by Apple doing that. And then in our category, in the weather industry, we have some friends who also make competing apps that are little indie developers, and it’s sort of a well-known problem. After I tweeted my thread, some people reached out to me and said, “Yes, we all feel the same pain and it’s hard.” Developers are a little bit afraid to talk about this, I think for the same reasons I just said that Apple sort of holds all the cards and you’re worried about making them upset. But it seems like when people are honest and are willing to talk about it, everyone’s sort of suffering the same challenge.


[00:18:49] SY: So what would you say is the solution to this? Because even though the Dark Sky situation happened recently, it’s not unique, right? It’s not a new problem. As you mentioned, indie app developers have been dealing with this for many years, across many different updates and upgrades. So what do we do?


[00:19:08] JD: Well, I think there are a few things. One is that I don’t know the market dynamics of having a platform provider also competing on the platform are fundamentally healthy. It feels monopolistic at some level where Apple, yes, they provide the platform and they provide software for us to develop on, and that’s great, but they’re also competing directly with us in a bunch of different ways and taking a cut of our revenue and doing a bunch of things that make it hard for us to exist. So it feels a little strong army at this point where maybe there are some regulations that need to happen. I’m not really sure what needs to happen at that level. For us, I think going forward, having learned what I’ve learned working on this, I would not, at this point, try to create any kind of business on a standalone mobile app. I don’t think it’s a viable model. You just really can’t make enough money with it to even pay a living wage, unless you have something else going on outside the store that sort of funds it. So if you have like an independent business and the app is just like a client of that. That can work. Or if you have maybe a constellation of mobile apps, like you have 10 different ones you’ve managed to develop and the collection of those creates enough revenue or something for you to be sustainable. That could work. But I don’t see enough of a return on the effort it takes to make a mobile app to really do it and it’s kind of a bummer because I love working on it. It’s a really fun platform to work on.


[00:20:28] VJ: What would you say to anyone who listens to this and just says, “Oh, this is just capitalism and Apple’s not doing anything wrong”? How would you respond to that?


[00:20:39] JD: But I think that is true. But at this point, the tech industry has sort of devolved into two layers of capitalism. There’s like basically four or maybe five big tech companies that sort of compete with themselves and then there’s everybody else. And so if you’re a small independent company, I worked for a company called Basecamp and we’re about 50 people, we just created an email app. And if you are small and you want to compete against big tech in any category, it’s really difficult because they hold so much power over every facet of developing technology. At this point, if you want to host your app, it has to be on big tech. If you want to advertise, probably it has to be on big tech. If you want to sell it, you need to be on these app stores. And the big tech wants to take a cut. It’s very difficult to compete with them. And it feels like it’s reaching a point where the scale has shifted so far that it’s no longer really fair, which is why I was saying it feels monopolistic. If you’re one of those five companies competing against each other, maybe it feels okay. But if you’re anybody else, it feels very difficult.


[00:21:37] SY: So we talked about how difficult things can be for iOS developers when it comes to Apple, basically taking ideas and taking certain features away and incorporating it into their own thing. But is there anything else that makes working with Apple difficult for an iOS developer?


[00:21:54] JD: One big challenge we have is when they announced a new version of iOS or Watch iOS or Mac iOS, they generally add new capabilities and new features, but their rate of change is quite fast. So what happens is like in this example, iOS 14 is coming out probably in September or October and they announced it at WWDC in June. So there’s a few month window of opportunity to develop new stuff that meets what Apple is trying to do. This year it’s widgets. So they’re creating these new widgets for your home screen so you can see little snippets of information alongside your app icons. For us, we kind of want to be there day one when iOS 14 comes out, because if we’re not, we have our customers knocking on our door saying, “Where’s our widgets? Where are our widgets?” And then at the same time, we’re not up to snuff with Apple’s default app, which puts a lot of pressure on us year after year. That happens every year where we have a short amount of time to come up with a brand new idea, ship production quality software. But Apple’s tooling during this period is very rough. Like it’s beta software that tends not to work in a dozen different ways. It’s kind of broken. People are filing bugs all the time. In our case, we’ve been developing these widgets and I can’t even get them to load on a real device at this point. It just doesn’t work. So their circumstances are really tricky. It’s like we don’t get to work on what we want a lot of the time because we ended up working on what Apple has sort of decided is going to happen this year, and that’s slightly uncomfortable.


[00:23:23] VJ: Absolutely.


[00:23:23] SY: Yeah. Well, thank you so much Jonas for joining us.


[00:23:26] VJ: Yeah. Thank you.


[00:23:27] JD: Sure thing. Thanks for having me on. Coming up next, we chat with Dan Abramov, Software Engineer at Facebook, Creator of Redux, and co-author of the Create React App, about React’s decision to release React 17 with no new features.






[00:24:00] SY: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that. It allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], that explores code, technology, tools, tips, and the life of the developer. Find it at


[00:24:36] VJ: Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. They’ve just launched Vonage Voyagers, an exciting new program, which rewards engaged community members with training, mentorship, and awesome limited edition swag. If you apply before August 15th, you can make it into the September crew. Find out more at




[00:25:10] SY: And now we have Dan Abramov on the show, Software Engineer at Facebook, Creator of Redux, and co-author of the Create React App. How are you doing, Dan?


[00:25:19] DA: Hi, I’m good. Thank you.


[00:25:21] SY: So tell us a little bit more about who you are and what you do.


[00:25:23] DA: So I worked on the React core team. I’ve been on the React team for the past four years, I guess.


[00:25:30] VJ: So let’s get into the meat of this. The last major React released was Version 16, which was back in September of 2017. And in that version, you included many longstanding feature requests. So what was the thought process behind coming out with React Version 17 with no new features?


[00:25:53] DA: So with React 17, we wanted to enable this other way of upgrading, which we’re calling gradual operates. So this is not technically a feature of React. It’s not like we’ve added something to React. It’s more for strategy that we want to consciously support now, whereas previously we considered that that was not really a supportive way to use React. The gist of the strategy is that you would update most of your app to the new version, but maybe you have some screens that use those legacy outdated components that nobody maintains. So maybe like in our case, for example, like Facebook is rolling up a new website and there are some dialogues that have not been ported yet. So they use components we did in 2014. So those are the cases where you kind of want to sandbox them and to have them use an older version of React instead. So of course it’s not optimal. We’re not saying that it’s a good idea to, like in general, have multiple versions of React on the page, but sometimes it is a compromise. You can take four parts of the screens that are rarely used where it’s acceptable to take some performance hit, but then have this Island of codes that is managed by all the version of React. And so coming back to your question, what is the point of this React 17 release, is that we intentionally kept it very minimal, but we fixed a few things that were preventing this strategy from working. So like the big one was events did not work really well when you have multiple Reacts on the page, because event propagation was not working between different versions of React. So this is the primary thing that React 17 fixes and this is why have this released very minimal so that even very old apps that are written in 2014, it’s still upgrade to it without like rewriting anything. And then that would allow us to be a little bit more than a progressive in React 18 with actually removing those long deprecated APIs because we know that even the apps that use those, they can still operate the modern parts of their code base. They can still upgrade it to React 15 but then they could stay on the React 17 forever for some of the older routes and like parts of the code base that will never be outdated.


[00:28:29] SY: So you talked about the upgrade strategy and doing this idea of a gradual upgrade instead of an all-or-nothing upgrade. How did you as a team realize this problem and decide that Version 17 was going to be the version that you would tackle it?


[00:28:45] DA: I think the big realization just came from like Facebook itself was in the middle of a website rewrite and it is a very significant change because it used to be like a PHP website with some sprinkles of JavaScript, whereas now it’s primarily like driven by React. We wanted to make it a little bit stricter in like actually removing some of those APIs that was supposed to not be used anymore and we just realized actually how expensive our usage is in some of the older parts of the code base. And we also saw that nobody actually maintains those parts anymore. And so it’s just not feasible for us to remove them. And so we really wanted to find a compromise that would allow large code basis like ours to incrementally migrate the future versions.


[00:29:37] SY: So when there is a new release being announced, the first thing that people look for of course is features and new features. So I’m wondering when you think about other tools and frameworks, do you think that other people should be focusing more on structural issues than just focusing so much on features?


[00:29:55] DA: It comes down to the level of adoption. Because like when the React was smaller, when the community was smaller, it was easier to do breaking changes more often. Like for the breaking changes we did, we always provided code mods. So like you could migrate your code automatically, except for a few cases where the behavior is different. But for the most part, we need to make sure that we have a viable strategy. And I think for tools or like frameworks that are a little bit more experimental, maybe a little bit more in the research area, they do have the power to actually release an incompatible version with no way forward because they can say that may be like version like X was a dead end, but we rethought the strategy and now we have Version X Plus 1, like we shouldn’t like shun them for that because it is an important part of their progress is just being able to make mistakes. That is largely the purpose of this like research level projects is to be able to do that. Whereas for more mature, those, I think, it is very important that like update strategy is one of the primary things we think about. So it is a hard balance to strike. I think it’s important that there are tools on either side of the spectrum. I’d like to think that React, it is fairly conservative, even though like the reputation of React ever since is like everything changes to weeks. I don’t think that’s actually true. I think at least for like, if you don’t jump on alpha versions of libraries, which like people tend to do sometimes. But as long as it is on a stable version, it’s like React itself, it breaks things pretty rarely, even if you take like a library like React or Chart, which a lot of people complain about. If you look at the stable version history and skip all the alpha releases, it actually hasn’t changed as often as people imply sometimes. There’s like a yearly or even multi-year gap between major releases.


[00:31:58] VJ: So when do you think React users can expect any new features? And do you know when we might be able to expect a React Version 18?


[00:32:06] DA: Yeah. So our past estimates have not been particularly accurate. When we initially introduced like Suspense for data fetching as a sort of a prototype, and as a conceptual introduction, we did it, I think, it was 2017, or maybe it was 2018, but we thought that it will be ready by the end of the year. And it’s 2020 now and we’re still working on it. I do want to be clear that we’ve made a ton of progress. It’s pretty hard to communicate in like roadmaps or issues because a lot of this was like research work and actually then trying to put it into production and learning from mistakes is so much, like you have to kind of spend so much context just to explain like the dead ends and the mistakes that we’ve made and how we fixed them. Ideally by the time it’s stable, like we’ll just present the thing that actually works. Right? And so I think like a lot of people are frustrated that, “Oh, it doesn’t seem like there’s any news.” Whereas in practice is we’ve experimented a lot, we’ve learned a lot. This scope has expanded a lot because we learned that actually like solving this problem shows like three other problems, which doesn’t mean that the approach is bad. It just means that it’s a bigger project than we thought and we’re really only comfortable like getting into cycle release when we have like sufficient coverage of all of those problems. We’re still in the thick of it. I would like to think that if we charted our progress from like the beginning of some of those ideas to where we are now, I think it’s fair to say we’re like 75% there. But like in terms of concrete timeframes, I’d like to think that we would have something within a year, but that’s as much as I can speculate. In the design process, there’s like different stages where in the beginning you have a lot of unknown unknowns where you don’t even know what problems you’re going to run into, and eventually they turn into known unknowns where you know what problems you have and then you solve them. So I think we’ve solved most of unknown unknowns, and we have only like one or two significant ones that might expand in scope. But other than that, we have a pretty clear roadmap on what are the next things we need to fix before this is actually ready for open source. But again, people can still try experimental releases. So we have like a page for the experimental releases. They include the features that are going to get into 18 and people can try them at their own risk. This is what we’re running in production. So we run our experimental releases in production. But I think like within a year, we probably should have something, but I also don’t want to offer promise because those are pretty challenging problems, but I think that once they’re solved people would definitely see their value.


[00:35:13] VJ: Are there any other features that you really hope to see down the line that we haven’t covered yet?


[00:35:19] DA: The thing I’m most excited about in general in like our direction, like we haven’t given any talks about this idea or anything, but one thing we realized as we were working on Suspense for that affection is that the way most apps do data fetching is very inefficient in part because like either you have this problem where you have to do all data fetching at their browser handler level. So you have to kind of put a bunch of logic that really corresponds to the specific pieces of the UI, but you have to move it upwards so that you can fetch it all in one go. So like it makes the code structure a little bit unnatural or you have the opposite problem where maybe you’re putting the logic close the components that use it, but then that means that you have a waterfall. So like a parent component fetches something. When does the child component fetches something? So the waterfalls are really inefficient. It’s like you have to choose between being efficient, but then compromising on the code quality or being inefficient but then the code is a bit easier to understand and modify. This problem, there are solutions to it. Like in the open-source community, Apollo is the most popular solution, which is like completely fine. But I think there are some lessons that like other tools could learn from Relay, which is what we use at Facebook. It’s not as popular because it has a steeper learning curve, but it has a few interesting sides and like one of them is that it uses a compiler to automatically gather all the dependencies from the tree so that you write code in a natural way. You specify what data is needed close to the components that need it, but like the requests are actually efficient because they’re batched together. So you don’t have waterfalls and you don’t have many parallel requests going at the same time. So we’ve been thinking about how we can take the lessons learned from Relay, but apply them broadly to like arbitrary React code and React data fetching code. And we have some promising progress on one research project where the idea is basically to move more of data fetching to the server. Like say in Instagram, for example, if you imagine like Instagram feed, if you think about like post components that render like an image and a bunch of comments, you don’t really create posts locally. You always have to talk to an API, like when you’re scrolling, for example, talk to the server, the server gives you JSON and then you render like a bunch of new posts. So if you think about it, like why did we even download the code for the post component if that is really only necessary together when we talk to the server anyway? So what if we could move that component to the server and never actually download it in the JavaScript bundle? This is the direction to which we’re actively investigating. It’s probably one of the things that I’m most excited about, but it is still very much in the research phase. So we’ll see how it goes.


[00:38:26] SY: Thank you so much, Dan, for joining us.


[00:38:28] VJ: Yeah. Thank you.


[00:38:29] DA: Thank you.


[00:38:40] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight by Josh Pitts, Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513. Or email us at [email protected] Please rate and subscribe to this show on Apple Podcasts.