19 Takeaways From React Conf 2019

Originally posted on my personal blog

Well React Conf ⚛️ is officially over. There were a lot of great talks, human beings, activities, and of course food. I'm still digesting the whole event but, as far as conferences go, this has been the best one I've attended so far.

The developer community can often be intimidating. The volunteers and organizers did an incredible job making everyone at the conference feel welcome. I was impressed at the lengths they went to make us all feel like we belonged. There were even some introvert activities on the second day. Have you ever painted a minifigure (think Warhammer) at a conference? I have now! So for all those involved, thanks!

This post is going to be a reflection of some of my favourite React Conf takeaways. Every single talk was worth watching, so I recommend you check out the recordings for day one and day two. I've included timestamps to all the talks at the bottom of the post.

You might be surprised by some of the items on the list. I was too! Not everything is technical but there is a common thread weaving throughout.

1. Developer Experience In Service of User Exeperience

After Tom Occhino said it, I couldn't stop thinking about it. I couldn't stop seeing it in all the talks. I realized what I love so much about developer tools and the frontend.

React aims to create a developer experience that allows us to easily learn to do powerful things, to launch and iterate by being productive, and to scale the software we make. These things alone make me like React. I feel like Facebook is doing a pretty good job on delivering.

What is the point of all this though? Well, that's simple. It's to serve the user experience. We do what we do so that we can make our users productive. We should aim to help them get what they want done in elegant ways. Although what we help them achieve may not always be simple behind closed doors, it should always feel that way to them.

Because React is a gateway techhnology with 63% of JavaScript developers using it, the team are taking things like community very seriously. They have adopted the Contributor Covenant and are welcoming criticism. As a community we should be able to accept criticism without having to defend ourselves. Elbert Hubbard said "To avoid criticism say nothing, do nothing, be nothing." What React is doing, and why, is important. This will naturally draw in criticism and allow the technology to grow. It will allow us as a community to be better.

2. Accessiblity and Performance and Concurrent Mode, Oh My!

Have you ever had issues with focus while using React? I have. Focus is really important for many reasons. It helps people navigate their way through a page. This is extremely important for people who don't use a mouse. This topic will come up again later, but it was nice to see the React team wanting to make accessibility baked in.

One of the things that got me thinking the most during the conference was performance. Facebook has to deal with performance issues that most of us never will, but the lessons they have learned can still be used to make the user experience better. It doesn't matter how fast a page loads if the perceived performance is slow.

An example of this is selective hydration which Yuzhi Zheng explained during her talk. You may have heard of Suspense as well, which will improve user experiences all over the web.

Concurrent Mode

Imagine making a filterable list tied to a user input. With React, you'd probably have to debounce or throttle your updates to the list unless you're okay with jank.

Concurrent Mode will enable React apps to be more responsive by giving React the abiility to interupt blocks of lower priority work. This allows things like user input to get more priority over things like re-rendering a list. React will be able to work on several state updates concurrently. This will help us remove jarring and too frequent DOM updates. It will also allows us to give priority to interactions like hover and text input. We know that users expect these to be handled quickly or else they will feel laggy.

The React team have shared many examples of concurrent mode patterns that I recommend you check out.

3. CSS-in-JS-at-FB

I was interested to hear Frank Yan announce that Facebook is building their own CSS-in-JS library. At first I thought, don't we have enough of them? This gave us an opportunity to learn more about some of the problems Facebook faces at scale and the creative ways they are solving them.

Maintaining CSS can quickly get out of hand. Let's look at the following example:

.blue { color: blue; }

.red { color: red; }

<span class="red blue">
  Which color will I be?
</span>

In this example, it would be nice if the text would be blue. That class comes second in the class declaration so we should be able to expect it to take precedence. But it doesn't. The .red class comes second in the cascading style sheet so that's what we end up with. If these classes were in different style sheets, the order in which they are loaded in the page would matter.

This problem might seem simple with such a naïve example but it can get out of hand quickly. Facebook has aimed to resolve things such as specificity wars, themeability, and accessibility with their new library.

A couple of interesting specifics from the talk:

• Developers can code in pixels but have their work compiled in REMs
• They have created safety by implementing type checks (catch and fix typos, detect and remove unused styles, avoid cross-browser pitfalls)
• Display accessibility errors to developers

• Components can have default styles that can be overidden (including type safety!)
• Rules are deduplicated which allows smaller CSS files (Facebook went from 413kb to 74kb in their recent frontend rewrite)

Atomic CSS

Each class creates a unique property value pair. This is used to optimize the components

.c0 { color: blue; }
.c1 { color: red; }
.c2 { font-size: 16px; }

// Generated Component (Pre-Optimized)
const styles = {
  blue: {color: 'c0'},
  default: {color: 'c1', fontSize: 'c2'},
};

function MyComponent(props) {
  return (
    <span className={styles(
      'default',
      props.isBlue && 'blue',
    )}>
      Hello World!
    </span>
  );
}

This example shows how the CSS is atomic. It also shows how the color of a span could be set with props. However, this code gets optimized further.

// The styles block is no longer needed
function MyComponent(props) {
  return (
    <span className={styles(
      (props.isBlue ? 'c0 ' : 'c1 ') + 'c2 '
    )}>
      Hello World!
    </span>
  );
}

At of these things are extremely interesting and I look forward to them releasing their library in the future.

4. Data-Driven JavaScript

Have you ever wondered how to make your pages feel faster? Become interactive sooner? Of course you have! Ashley Watkins has too. She really got me thinking how I could use adjust my data-fetching approach to make a better user experience. I had already started to get excited about Relay but she added fuel to the fire.

Phased Code Splitting

You can bet the folks at Facebook have been working hard to ensure their FMP is as fast as possible. One of the ways they are doing this is "Phased Code Splitting".

With this approach, you can take a single blocking download and deliver it in phases. For example, if you consider the Facebook post, you could break it into 3 phases.

1. Loading
2. Display
3. Analytics

Each of these phases can have their own code fetch and render. All the data required for the FMP can be fetched at the same time the loading phase fetches its code.

Time to First Meaningful painted

To make your user experience as good as it can be, you should be thinking about first meaningful paint. This is basically how long it takes for the primary content to appear on the page. There are many metrics you can look at and measure to improve your load times, but FMP sticks out.

Relay allows you to make streamed queries with GraphQL. This will allow you to mark certain data as critical and other data as less critical. You can then get the most important stuff from the server first and show that while fetching the rest of your data. With this approach, you can render content as it arrives!

Data-Driven Code Splitting

This one blew my mind a bit. Relay is powerful, no question there. Relay has a new feature that lets you expand your queries to express which component code you need to render specific data types. 🤯 You can think of your code as data. As the server is resolving your GraphQL query, it can let the client know what component code it is going to need to download so it can get it faster!

Ashley's talk was pretty incredible and she promised that these things are just the beginning. I haven't used Relay yet but I'm excited to get started and I bet you will be too (especially when you hear more about what it can do).

5. Solving World Hunger

Day one started of with a great group of talks from people that work at Facebook. They were exciting from the technical perspective. We got to see a lot of upcoming features in the ecosystem to help us improve the user experience.

Tania Papazafeiropoulou switched gears a little bit to educate the attendees about world hunger and a cool product she's working on called OLIO. It helps people share food instead of wasting it and its powered by, you guessed it, React.

It was upsetting to find out that 1/3 of all food produced is wasted. On top of that, we could solve world hunger with just 25% of food waste from the US, UK, and Europe. These sobering statistics make solving world hunger possible and it was awesome to hear about a team working to do that.

This talk didn't get me hyped about new React features but it reinforced what makes React great. React (and React Native) enabled Tania's team to build out their product quickly and start making a positive impact.

6. Making REST Feel Better (and Safe)

RESTful APIs aren't a new hot 🔥 concept. They were formally defined in 2000 and have been used with success since then. That being said, REST does have some things that make it challenging.

Facebook answered these challenges with GraphQL. GraphQL gives us an understandable definition of our data. It gives the client the power to get only what it needs. This is a pretty great way to get faster render times as you don't have to download as much data!

Tejas Kumar summed up the differences quite nicely (see his talk for more depth):

REST

• ❌ No formal spec
• ❌ Guessing games (will an unallowed request respond with 400, 401, or 404?)
• ❌ Meaningless conversations
• ❌ No contractual agreements

GRAPHQL

• ✅ Formal spec
• ✅ No guessing games
• ✅ Meaningful discussions (things that impact users)
• ✅ Strong contractual agreements

Many of us love GraphQL but sometimes it isn't an option for our APIs. Tejas and his team have developed a tool to take some of the pitfalls away from REST. It includes code-generation from Swagger and OpenAPI specs.

I don't believe I do Tejas justice but his talk left a lasting impression on me. Seriously, go watch his talk!

7. Under React's Hood (Building a Custom Renderer)

If you've ever given a demo of something you coded before, you know it often goes wrong. Sophie Alpert took the risk and educated us on what it takes to build a React renderer.

I don't consider myself a React expert (yet 😅). I have never looked at the React codebase. I always assumed it would be beyond me. As I continue to learn and master React, I will continue digging deeper and will eventually get to the codebase itself. Sophie made it seem a lot less intimidating as she built her own custom render in real time on the React Conf stage.

Other than learning how awesome Sophie is, I feel like I came away with a small understanding of how React renderers work. She didn't leave me scratching my head. Everything was explains simply but also demonstrated clearly. What more can you ask for from a live coding demo?

May the Demo Gods forever be in your favour Sophie!

8. Localization (It's Important!)

As a native English speaker, I have to admit that localization isn't the first thing that comes to my mind when developing a product. Thankfully I am aware of this and am going to take it more seriously in the future.

I think localization often gets missed because we focus on users who are just like us. There is no reality where your users will be exactly like you! That is why we need to do user testing, get user feedback, and be more inclusive to all types of humans.

Last year, Nat Alison asked the question "is React translated yet?" When she originally posed the question, the answer was no.

Why does this matter? Well, Nat put it pretty nicely. If React is only accessible to English speaking people, how many people aren't able to use the tools to build amazing products? How much are we losing out on by only having English speakers shape our digitl world? Only 20% of the world's population speaks English. If we don't help others use React, we all suffer!

It is incredible what Nat and thousands of people have accomplished in the last year. There is still more work todo and you can help if you are bilingual!

9. The Accessiblity Marathon

Just like localization, accessibility can be difficult. You have to think differently when you are developing for accessibility. You have to think about a broader audience, about people who might be different than you. Sometimes that is difficult but we can all do it.

Running a marathon 🏃🏻‍♂️ is another example of something that can be difficult. According to RunRepeat, 1,298,725 people finished a marathon in 2018. They didn't wake up with the ability to do that. They started small and worked their way up to it.

That's how we can approach accessibility. Taking an approach like this will remove some of the feeling of overwhelm if you are starting from square one. One of my favourite things about React Conf was learning about software development, and the world, from new viewpoints. Brittany Feenstra was one of the people who helped me expand my perspective and I want to think more about accessibility going forward.

I'm not going to complete the accessibility marathon over night but I can do a little more each day going forward. Thankfully, there are a lot of good tools to help me along the way.

10. You Don't Need Redux (Right?)

In 2019 there are many different ways to manage React state (even vegetarian friendly options).

With so many options out there it can be hard to know what is the right choice. Unfortunately the right choice will depend on you. Just remember, developer experience is in service of user experience. Knowing that, I liked to approach my state management by going as simple as possible and changing as I outgrew my original decision.

I am very happy that React has so many options built within it now. With Context and Hooks, you can do quite a lot without ever needing to pull in another dependancy.

In order to move fast and break things, you have to be willing to throw out work you've done before. You need to fall in love with the refactor and move past decisions that worked for you when your product was different. I think the many options for React state reflect this. Some of the options require a lot of boiler plate, some don't. Some are baked in, some aren't. Pick what feels right for you now and adapt later if you need to.

11. Time Travel To 1999

The last talk of the day had me interested from the title alone. What was it like to program in 1999? I was only nine years old then. Some people were coding by nine. I was not one of them. 😢

This talk was another one that really needs to be watched. Lee Byron delivered a well-polished gem. He walked us through a time when PHP and the LAMP stack were the go to tools for web development. For those that weren't coding in 1999, he explained the evolution that lead Facebook to develop tools like React, GraphQL, and Relay. For those who were coding then, nostalgia.

I have always respected the engineering work done at Facebook but this talk put everything in perspective. Working with React has felt like a privilege and now I know where that privilege came from. I'm inspired by the work people like Lee have and continue to do for the community.

12. Even Dev Tools Are About UX

The theme of the conference continued to be elaborated on as Brian Vaughn kicked off day two. If you build things with React, you've likely used the React Dev Tools. They have definitely helped me dig myself out of messes I've created.

The React Dev Tools got a full rewrite that gives us:

• Better performance
• New API support
• New UX features

See, even the dev tools focus on great UX!

I was impressed by the changes the team made to help navigate unfamiliar projects. Although you may thing of code you never touched as unfamiliar, we all know that even our own code can seem foreign with time. We can now see how prop flow through components, filter our component trees, deeply inspect components, and use hooks with the dev tools. One of the other things I loved seeing was the suspense toggle. That's a feature that seems extremely simple but will quickly become invaluable.

Along with shared profiling, the new dev tools make it easier to find why things rendered. There are similar tools out there but now we can get insight on your renders directly in the dev tools.

There are a ton of other great additions and I recommend you go explore them for yourself.

13. Suspenseful Data (Relay is Awesome)

I think I'm probably late to the Relay party. In fact, I'm late to the GraphQL party. In my side project I have been using GraphQL and I really enjoy it. After this conference I'm looking to explore Relay and take advantage of the power the combo provides.

React Suspense wants to enable us to show some of a UI without waiting for all of it to become ready ⏱.

Let's take a look at a basic example of a component that shows a loading state (using Suspense) when it is fetching data:

const Composer = (props) => {
  const data = useQuery(graphql`
    query ComposerQuery {
      me {
        photo {
          uri
        }
      }
    }
  `, variables);

  return (
    <div>
      <img src={data.me.photo.uri} />
    </div>
  );
}

const Home = (props) => (
  <Suspense fallback={<Placeholder />}>
    <Composer />
  </Suspense>
);

In this example we have a Composer component that fetches a URI to my profile picture and then displays it. You can see in the Home component that we have wrapped Composer within a Suspense block. Then, while the data is loading, Placeholder will be rendered. This pattern can be thought of as Fetch On Render.

Using this pattern, the loading sequence will be as follows:

As you can see, this allows us to easily handle data loading. We can provide a better user experience by falling back to a loading component, like a placeholder or spinner.

The pattern above already provides a lot of benefits and flexibility to do cool things. However, the Facebook team didn't like that you had to render to figure out what data the component needs. In order to get over this, they have started to use a pattern they call Render As You Fetch.

Essentially, to enable Render As You Fetch, the Facebook team has decomposed useQuery into two pieces. It is separated into preloadQuery and usePreloadedQuery. What exactly does that mean?

preloadQuery

This API will fetch data and give a reference to the results. It doesn't give you the actual data.

You would call this API in the same event handler that would display new UI. For example, if a user clicks on a link that will trigger navigation to a new page, the event handler where we handle the click will use preloadQuery. Hovering over something to open a tooltip would be another example of where you'd call this API. The onHover event handler would call preloadQuery.

usePreloadedQuery

This API takes the results of the preloadQuery call. It doesn't actually do any data fetching itself. It looks at the current state of the preloadQuery. If it is ready, it displays the results. If it is not ready, it suspends. If the query has failed, then we can throw an error.

No matter what happens, usePreloadedQuery will never trigger a new fetch. This makes it efficient and predictable.

Using these two APIs instead of useQuery will provide a loading sequence that looks like the following:

I definitely recommend you listen to Joe Savona explain the concepts I've summarized above. He does a better job and gets more in-depth. This was one of my favourite talks because I'm excited by the possibilities this pattern enables and can't wait to try it myself.

14. React is Fiction

Jenn Creighton gave my favourite philosophical talk of the conference. She background in creative writing. Creative writing has always been something I loved. Like Jenn, I once fantasized about becoming an author. There was a concept she explained during her talk that translates to coding in an interesting (and unexpected) way.

Show, don't tell

Let's look at two ways to convey the same meaning (courtesy of Jenn).

She is tired.

Her footsteps are heavier than before, the weight increasing as she trudges towards the bed, collapsing face-first onto the mattress.

Same idea, right? She is dead tired. Which one is more powerful? Well that's obvious. As software engineers we often fall into the pit of telling. We abstract, abstract, abstract away until we are DRY 🌵 as can be.

Most of the time, I do try to avoid repetition in my code. The principle makes sense but, like the rules of writing, sometimes we need to break the rules of software development. Let's compare two different pieces of code achieving the same result.

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => (
        <Link to={link.to}>{link.name}</Link>
      ))
    }
  </nav>
);

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
  ];

  return (
    <>
      <Nav links={links} />
    </>
  );
}

This seems like it will work great, but what if we want to add a nav item that is an action? For example a login button.

  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

Our Nav component doesn't handle this edge case. We could easily implement a method for it to handle it but this could easily get out of hand. We could refactor the Nav component to look something like this:

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => {
        return link.to
          ? <Link to={link.to}>{link.name}</Link>
          : <a onClck={link.onClick}>{link.name}</Link>
      })
    }
  </nav>
);

This would work but how many edge cases will we cover before it becomes harder to reason about our Nav component? We could rewrite the Header component another way.

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

  return (
    <nav>
      <Link to="/home">Home</link>
      <Link to="/settings">Settings</link>
      <a onClick={onSelectLogin}>Login</a>
    <nav/>
  );
}

I've simplified the example that Jenn delivered in her talk but I think it gets the point across. The second Header component is much easier to reason about. The abstraction didn't provide much benefit even though we might be repeating ourselves now. If we wanted to add an Icon component into one of the links, we don't have to handle all the edge cases in a Nav component anymore, we can just add it where we want it.

Jenn also quoted a great Neil Gaiman quote that I can't resist sharing.

Remember that, sooner or later, before it reaches perfection, you will have to let it go and move on and start to write the next thing.

I've been practicing getting to good enough while I've been building Wrabit, a mental health writing platform. Sometimes it makes me feel like less of a developer. Sometimes it makes me feel lazy. In the end, I'm going with what I can easily understand, what I can ship, and what I can always refactor later.

As Jenn said, refactoring is not failure. Her talk weaved creative writing with programming so elegantly, I'll definitely be watching it again.

15. UX-Driven Fluid Animations

I haven't gotten around to making too many animations. I envision a future where I take awesome UI designs from Dribbble (animations and all) and build them out for practice. Animations are definitely delightful bits of design porn, but we need to keep the user experience in mind even with these.

Like most of the talks, Alex Holachek got me thinking in a new way. I love UI interactions. They make me feel warm and fuzzy inside. When looking at them, I'm guilty of not considering all of the users.

How to the fancy animations work for someone using a Nokia 6? At $283.97 CAD from Amazon, I could afford that many times over before the new iPhone. I'm guessing a lot of other people are in the same camp.

Alex helped me remember to think more about the average. Average phones, average data speeds. Build for average and high end will always be fine.

Also, event.preventDefault() will do bad things to your scrolling.

16. Iterating on Real Experiences

If you couldn't tell, there was tons of variety in the talks this year. Luca Demasco kept things fresh by showing us the process of iteration as he developed the Wick Editor with Zach Rispoli.

The Wick Editor is a free and open-source tool for creating games, animations, and anything else your mind can come up with. When Luca showed off the current version, I was really impressed with the UI. It seemed intuitive and had plenty of functionality. That wasn't always the case.

Luca and friends got to where they are today by constantly iterating. They didn't just iterate for the sake of iteration either. They brought Wick into many different environments (schools, libraries, etc.) and brought the interface in front of many different users (beginner, intermediate, young, old). They took a laser focused approach and gathered feedback that helped make Wick what it is today.

The honesty in the process inspired me as I think about how to iterate on my own product. How can I launch something quickly and iterate with intention? I don't have that experience so sometimes the confidence escapes me but its a process I'm excited to take. Seeing people like Luca share his experience encourages me and I'm grateful for the honesty that was shared by everyone during the conference.

17. The Complexity of Simple Things

Do you use react-select? No? You probably do but you just don't know it.

The component has over 18k stars on GitHub. It has 1.5 million downloads per week. That's a lot.

You might not think that one simple React component could be all that complex. You would, of course, be wrong. Jed Watson has developed a React component that is beautiful and serves its purpose well. It has plenty of functionality and works great out of the box.

Jed travelled a long (and sometimes arduous) road to get react-select to where it is today. He shared great insights on what its like to develop a massively popular open-source project. He also showed how simple things can often be quite complex.

I was inspired by Jed when he showed off the evolution of react-select to v2.0. He reiterated the importance of refactoring and the wonderful things you can accomplish if you stop chasing perfection.

18. Beautiful Transparency

Government spending is an important topic. We deserve to see where our tax money is going so that we can keep the government accountable.

Lizzie Salita demonstrated that government websites can be performant, easy to use, and beautiful. I was actually quite surprised when she demoed the USAspending.gov spending explorer. Compare that to the Canadian version and you'll get an example of how much React can shape the user experience.

I'm slowly starting to get my feet wet with regards to politics. While I have always tried to stay informed enough to vote, there is so much more I can do. Having tools like USAspending.gov in your hands makes it easier and more interesting. I think we should continue to develop tooling like this to enable everyone to stay informed so that we can all be involved in shaping our future.

19. Wonder-Driven Development

The last talk of the conference really blew my mind. Like Alex Anderson, I am a big fan of space 🚀. Alex has built an insanely complex starship simulator called Thorium.

The Thorium simulator empowers many organizations like the Lion's Gate Space Center to provide STEM-related activities for all kinds of people. These space centres allow students to grow through group activities that are highly interactive and educational.

There have been more than a few presentations and people at React Conf doing highly inspirational things for good causes. Alex's work sticks out because his passion leaks out of every word he says. He loves what he is doing and is an extremely talented engineer. He's using the technology available to him to build great experiences for kids and adults alike.

My favourite take away from Alex's talk (it's going to take me a while to fully digest it) is the concept of wonder-driven development. Have you ever wondered about the possibilities of technology? What about what you are capable of? 🤔

These types of questions drive us to build fun, enjoyable, and truly beautiful experiences. These types of questions allow engineers at Facebook and companies all around the world to shape our world with technology.

I've learned so much from everyone I came across at React Conf this year. I'm grateful that I was able to attend and am feeling full of wonder and excitement.

I can't wait to see what that wonder drives me to develop!

---

As I mentioned before, these are just a few of my takeaways. There were many libraries, techniques, and philosophical ideas shared throughout the two day conference. I wish I could have captured them all! If you go next year you'll know what I mean.

If you'd like me to expand on any of these ideas I'd be more than willing to. Reach out and let me know!

Finally, it would be a crime not to mention Devon Lindsey. She gave us laughter, candy, and introvert activities. The conference wouldn't have been the same without her.

Le Talks (With Timestamps)

For your viewing pleasure, here is a breakdown of the two day conference. Watch all the talks and follow the speakers!
️

Day One

• Keynote @ 00:33:07: Tom Occhino & Yuzhi Zheng
• Building The New Facebook With React and Relay @ 01:09:45: Ashley Watkins & Frank Yan
• How Our Team Is Using React Native to Save The World @ 01:43:46: Tania Papazafeiropoulou
• Using hooks and codegen to bring the benefits of GraphQL to REST APIs @ 02:39:03: Tejas Kumar
• Building a Custom React Renderer @ 03:11:21: Sophie Alpert
• ⚡️Codemod-ing Away 4MB of JavaScript @ 05:02:33: Spencer Miskoviak
• ️⚡️️️️️git is hard but time travel in git is easy @ 05:09:20: Monica Powell
• ️⚡️️️️️Typescript, GraphQL, and Code Generation @ 05:16:25: Salvatore Aiello
• ️⚡️️️️️Why React is Eating the World @ 05:22:55: Adam Wolff
• Is React Translated Yet? @ 05:32:58: Nat Alison
• Building (And Re-Building) the Airbnb Design System @ 06:07:13: Maja Wichrowska & Maja Wichrowska
• Accessibility Is A Marathon, Not A Sprint @ 07:33:32: Brittany Feenstra
• The State of React State in 2019 @ 08:05:17: Becca Bailey
• Let's Program Like It's 1999 @ 08:35:14: Lee Byron

Day Two

• React Developer Tooling @ 00:32:00: Brian Vaughn
• Data Fetching With Suspense In Relay @ 01:00:31: Joe Savona
• Automatic Visualizations of the Frontend @ 01:32:17: Cameron Yick
• React Is Fiction @ 02:32:13: Jenn Creighton
• Progressive Web Animations @ 02:57:48: Alexandra Holachek
• ️⚡️️️️️Programming = Hit Records @ 05:03:06: Jay Johnson
• ️⚡️️️️️Comonads On Your Everyday UI Tools @ 05:10:50: Juan Paucar
• Creating Games, Animations and Interactions with the Wick Editor: A UX Talk @ 05:27:53: Luca Damasco
• Building React-Select @ 06:01:52: Jed Watson
• Promoting Transparency in Government Spending with React @ 07:32:39: Lizzie Salita
• Wonder-driven Development: Using React to make a Spaceship @ 07:57:17s: Alex Anderson

Comments

[xarv]

Great article !

[Morgan Kenyon]

I enjoyed the article. I realize you're just the messenger, but the REST v GraphQL bullet points are one sided. They just took things that are pain points in REST and ignored calling out any of the GraphQL pain points.

There's a more balanced approach to comparing REST and GraphQL.

[Anthony M.]

Totally! Nothing is truly black and white in the world of software development. I'm just getting into GraphQL so I'll likely experience some of the pains later on but am enjoying it thus far.

[Morgan Kenyon]

Here's a great article describing some of the GraphQL pain points I've read before.

blog.logrocket.com/5-reasons-you-s...

[Eugene Karataev]

Thanks for the post. Number 14 resonated with me deeply, because I always see over-abstractions and unnecessary complex code to keep DRY. Moreover, I had the exact same situation with Nav component and array of links at my daily job 🤣

[Anthony M.]

My pleasure Eugene! I feel you. Sometimes we value theory over practicality. It can be hard but I guess understanding tradeoffs and when to use them is a sign of maturity as an engineer!