WhoBuilt

React Native EU is the place to be

Dec 18, 2023· 12 min· 258 views·Watch on YouTube

Speaker

At React Native EU 2023 in Wrocław, Matt Hargett discusses with Callstack host Jacob how to move React ecosystem code into other languages, make the business case for risky innovation, and get value from the conference.

Make innovation serve a business goal

Hargett describes moving React ecosystem code from JavaScript into other languages, drawing on a project deployed to hundreds of millions of users. He says innovation proposals need a clear business outcome and deadlines that make progress visible.

Reduce risk in short milestones

Hargett recommends two- to four-week chunks with demonstrable checkpoints. In one React-to-Lua effort, a colleague translated 2,000 lines and got the tests passing; about 90% mapped directly from JavaScript. For earlier React Native work at BlueJeans, a two-week demo gave the team a clear point to continue or stop.

Be candid about risks and scope

Hargett says teams should name risks upfront and use early milestones to test them, such as benchmarking performance with hard numbers. Small, bounded experiments can make failure inexpensive and informative. Iterative work can also stop when the business no longer needs later features.

Value the in-person community

Hargett praises the venue, catering, and terrace at React Native EU, including hammocks that helped him manage jet lag. He says the key benefit is meeting people in person, including peers he might not otherwise encounter.

Find contributors and practitioners

Hargett encourages attendees to consider contributing to React Native, noting that starter tasks offer an accessible entry point and core contributors from Callstack, Meta, Microsoft, and Amazon are available to talk. Application developers can also meet practitioners who have shipped apps to large user bases and discuss real-world tradeoffs directly.

Takeaways

  • Tie an innovation project to a concrete business goal and deadline.
  • Break uncertain work into short milestones with observable results and a clear stop decision.
  • State the risks early, then design milestones to test them one at a time.
  • Treat a failed, low-cost experiment as useful evidence for the next decision.
  • Use conferences to meet maintainers and practitioners who can share direct experience.

Mentioned in this talk

Search inside this talk

What was claimed 3

Related talks