BLOGUE
On March 14, 2025, I received confirmation that I would be a speaker at React Summit in Amsterdam. The largest React conference in the world! What led me to take on the challenge of speaking at an international conference? And what could I possibly have to say that would be worth discussing on another continent?
In 2024, I had the opportunity to give my very first talk at Web à Québec (now Interface) as well as at Agile Tour Québec.
Martin Nadeau, engineering manager at Nexapp, had given me the advice to submit my talk to several places, so I wouldn't have to start from the beginning each time. Since then, I have consistently applied this approach, among other things, by using my blog articles to create new presentations. This is what I decided to do in 2025: I also applied to different events with the same presentations I had already given.
So I applied to conferences in Montreal, Paris, Amsterdam and Berlin. All were for my talk "Prioritizing architecture over framework, the key to a solid Web application". Ultimately, only React Summit accepted my application. I should have expected it. Computer science events receive enormous amounts of applications; it is therefore normal not to be selected every time.
Adapting the presentation
The real work only began after my talk was accepted. Indeed, I had to make several changes to my presentation in its current form.
First, I had to adapt the content to put more emphasis on ReactJS. Initially, I structured my presentation to apply to all computer projects, regardless of the technologies and languages used. However, the programming committee asked me to incorporate more React into the examples by sharing experiences that illustrate what I explain.
The second point to change in the presentation I gave at WAQ for it to be presentable at React Summit was to translate it into English...
This change proved to be the biggest challenge I've experienced since I started giving conferences. Indeed, giving a presentation in front of a large audience is one thing. Doing it in a language other than my native language is quite a different matter. Even though my text was well-translated and I understand English perfectly, presenting live in a second language is much more challenging.
A third challenge I faced was having only 20 minutes to discuss my subject. When I gave this presentation at WAQ, I had 40 minutes to present. For half the time, I had to condense the content significantly while maintaining the core message.
The last challenge I had with this presentation was that it had to be recorded in advance. Although this removed enormous stress when I was in Amsterdam, I had much less time to prepare and practice. Moreover, a significant advantage of presenting in front of an audience is having reference points in the room. It is helpful to observe people's reactions during a presentation to adjust the intonation, pace, and other aspects of your delivery. Whereas remotely, I could only look at the camera.
Despite all these points, I rolled up my sleeves and gave a performance I was satisfied with. All that was left was the trip!
June 12
The first thing that struck me about my trip was the experience of arriving in Amsterdam on the first day. I was surprised to see how easily I could walk around. I had already watched videos on the subject, but it's very different to experience it. Being able to walk through the industrial district and even big boulevards without feeling in danger even once is something I've never experienced in America. Where there's a bike path, there's a walking path next to it. And for those who didn't know, you can go EVERYWHERE by bike!
I had forgotten that JSNation was happening that day. I couldn't attend the conferences, due to arriving too late. However, I still went to Circa Amsterdam to chat with the people present. It was the meeting point for speakers to go to a dinner organized by the event.
I also had the chance to discuss with Philip Chimento, developer on the engine behind JavaScript, who works on the new time management proposal in the language, Temporals. This new solution, which has reached Phase 3 of development, is expected to reduce the need for date libraries significantly.
Before taking the bus, I ran into Medhat Dawoud, a lead developer at Miro, as well as Thomas Steiner, an engineer at Google who primarily works on the use of WebAssembly (WASM) on the Web. He was saying that the calculation engine behind Google Spreadsheet was made in Java, then compiled to JS with WASM. Thomas also mentioned performance issues when the software has to do a lot of back-and-forth between JavaScript and the language compiled by WebAssembly.
On the bus en route to dinner for speakers, I spoke with Rita Castro, a software engineer at Volkswagen in Portugal and a member of the programming committee for React Summit. We discussed the job changes that we often see among certain software developers in recent years. She shared with me a phrase that brings reflection: "Job security is when you're not worried about finding something else if you decide to change jobs." In the sense that if you know you're relevant in your field, it won't take long to find. So, job security is not limited to the company you currently work for. If we look at the last year, where several companies have made staff reductions, it's possible that fewer people than we thought have this infamous job security.
The dinner was on the Kapitan Anna, an old paddle wheel boat. I dined there in the company of Nik Pash, Head of AI at Cline, with whom we discussed Vibe Coding, our approaches to using artificial intelligence in our work, and our learnings. For example, I explained to him that AIs are very bad at generating JavaScript scripts that manipulate a terminal. However, they excel at writing Bash scripts and converting scripts from one language to another.
Across from me was Tanner Linsley, creator of React-Query and the entire TanStack library suite. He shared with us his vision for distributing responsibilities among bundlers, libraries, and hosting services.
The central point of his proposal is that bundlers should define precise and standardized APIs. These APIs serve as a contract that libraries and hosting services must respect on their end.
This approach would create a three-layer independent architecture:
- Bundlers define clear and stable interfaces
- Libraries implement bundler APIs to ensure their compatibility
- Hosting services support the APIs of different bundlers to deploy applications
Libraries would no longer need to create specific tools for each platform (e.g., Fly.io, Vercel), and hosting services would only have to support the standards defined by bundlers. This standardization would significantly reduce complexity and workload for all ecosystem actors.
I also had a short discussion with Zoltan Kochan, creator and primary maintainer of pnpm. He was giving a talk at JSNation titled "Configurational Dependencies in pnpm." He pointed out a pretty interesting point to me.
As a first-time speaker, he didn't seem to appreciate his experience. He said that the subject was too niche to capture people's interest to the point of creating discussions afterwards. What I take away from this discussion is to always keep in mind to discuss a subject that generates discussion and general interest among people. That the audience leaves with an answer to the question: how could this serve me?
When the boat returned to shore, it collided with the dock and nearly collided with the ship next to it. What a way to end the evening with a BAM!
On the bus on the way back, a former Twitter employee who was not spared by Elon Musk's massive layoff waves shared with us that, according to him, at least half of the engineers did absolutely nothing or worked on projects that brought nothing to the product. For example, the company decided to program their payroll system internally. We agree that we're far from Twitter's objective! The major issue with this payroll software, in addition to its numerous computer bugs, is that it attempts to handle payroll for all the banks of their staff worldwide.
Throughout his story, I wondered if Twitter couldn't have outsourced its payroll management to a company specialized in the field, rather than developing a complex product internally that was full of bugs.
June 13
Friday, June 13, was the first day of React Summit; the "in-person" day. As my conference was on Tuesday, June 17, I was present that day as a participant. Despite this, I had access to the speakers' room, where I had direct access to the day's speaker!
React Compiler Internals
The opening keynote was given by Lydia Hallie, who presented the inner workings of the React compiler in development at Meta. Super interesting to see the different stages of the compiler! In its operation, we realize that the compiler also handles caching the return of a component's function: not just the values and calculations inside! Specifically, I learned that it will always be possible to utilize useMemo in an application that uses the compiler. However, the latter will analyze its usage and make additional optimization if it considers a more efficient solution.
My only regret regarding this conference is that I didn't get the chance to ask Lydia what tool she used to make her presentations, because it was delightful to follow!
Speakers' room
Afterwards, I was able to discuss with Mark Erikson, the leading developer of Redux since 2016, as well as the creator of Redux-Toolkit. Although Dan Abramov is recognized as the creator of Redux, he only worked on it for seven months before joining Meta. It's Mark who has continued the work since.
I shared with Mark the challenges I notice in people who start using Redux for the first time. How easy it is to do it wrong. This is one reason why he added extensive documentation. He shared with me how a good lib is designed in such a way that good practices come naturally. People are channelled towards the proper use of the library.
I then asked him what was next for Redux-Toolkit. Mark told me that there might be an infinite number of queries in the API. Adding a list of queries to pass to the hook would be beneficial. We had a nice discussion about it, during which I brought up the point that it might not be the library's or React's responsibility to manage that.
import { useQueries } from 'redux-toolkit'
const SomeComponent = () => {
// Ceci est du pseudo-code de l'implémentation
const responses = useQueries([fetchA(), fetchB()])
return <div>...</div>
}
He also discussed the possibility of creating custom "entity adapters." A bit like Redux middlewares.
I had the opportunity to discuss with Mark Erikson several times during the rest of the trip, and I found that he's a very thoughtful and friendly person to be around. Moreover, he currently works at Replay.io, a great product that helps find bugs on websites.
Sentry Booth
Between talks, I visited the Sentry booth to see the new features of the product. The answer was obvious: AI. More specifically, agent monitoring! We also discussed integrating Sentry into React Native applications, specifically regarding source map integration. With the latest Sentry integration tools, as well as deployment tools like Expo's EAS, these issues appear to be resolved.
I also left with a beanie!
Building Full Stack Apps with Bun
I then attended part of Jarred Sumner's talk, creator of Bun. He was presenting Bun's new capability: building a full-stack JavaScript project. So, creating a server that returns JSX. The bun build command can compile both the frontend and the backend simultaneously. This compilation is done on demand during development and must also be very fast. This solution already includes specific extensions for popular libraries, such as Tailwind CSS.
At the end of the presentation, he was asked why Bun was so fast at installing dependencies. It's because Bun tries to spend as little time as possible analyzing JSON: it converts it to binary. A second question raised an essential point in the React ecosystem: Bun doesn't yet fully support the React compiler.
While discussing with Jared after his presentation, he admitted to me that he doesn't consider himself a speaker. He gets invited to talk about his product, but his focus is really on software development. Another example is that even the most technical people can give great talks.
Lynx : Unlock Native for More
After a short coffee break, it was Xuan Huang's turn to present his talk on Lynx. Xuan has worked on big projects at Meta, including:
- ReasonML (now ReScript), which allows making React components in a more functional approach
- The optimization of HermesJS, which became the default engine behind React-Native
- Tech Lead of the React compiler team
Xuan presented the vision behind Lynx, an engine for native mobile development that leverages web development practices and tools. Lynx is more of an engine than a framework; it's not possible to develop mobile apps with it alone. Developers will need to use a specific implementation of Lynx to transform the written code into a format suitable for mobile devices. For example, TikTok utilizes React Native to develop all its mobile applications. Lynx is gaining popularity, and people in the community have started making their extensions in Svelte and even in Haskell.
Two elements in particular make Lynx super interesting for development:
- Styling works with CSS. It's also possible to utilize the full power of Web styles on mobile devices. He gave the example of Apple's Liquid Glass, which can be easily implemented in three lines of CSS code. There's also a way to use libraries like Tailwind with some additional configurations.
- Lynx is composed of two JavaScript threads: the Main Thread and the Background Thread. By default, all code is executed on the Background Thread. It's possible, using decorators in the code, to execute code in the main thread. The objective is to have a thread dedicated to displaying elements on screen as fast as possible.
SPA to SSR and Everything in Between
This conference, presented by Tanner, creator of React-Query as well as the TanStack suite, discussed the trend in web development toward Server-Side Rendering (SSR). However, he brought some perspective to web trends.
Indeed, he mentions that, according to the State of React 2024, 85% of developers work in Single Page Applications (SPA). So, if only 1 person out of 5 can use React Server Components (RSC), is the popularity of a topic on social media really that important? He doubled down by specifying that he believes SPAs are here to stay and that it's essential to continue creating relevant tools for these projects, referencing the various TanStack libraries. However, he ended by mentioning that RSCs were on the way for the TanStack Router.
How to Become a Staff Engineer
Shruti Kapoor, Staff Engineer (SE) at Slack and previously at PayPal, gave a presentation on how to become a SE. According to her, a SE must have an impact on the organization, whether technically, on the products developed or even on the people around them. This can be done through initiatives or simply mentoring.
She then shared how "NOT TO" become a Staff Engineer:
- You wait to be told what to do
- Your impostor syndrome is too strong. You must learn to silence it, because it will never stop. You just have to learn to ignore it more.
- Waiting to become a deep technical specialist.
- Not playing the internal politics game. It's something that will always happen.
- You don't like networking.
An important point she mentions is that all companies are different. It's therefore essential to tailor your strategy to your company's unique reality. To achieve this, you can ask yourself some questions:
- What are you evaluated against?
- Where are your gaps?
- Which project can you impact?
- Who is your support squad?
State of the React Community in 2025
Mark Erikson then gave a conference on the state of the React community in 2025. The reason he initially wanted to talk about this subject was the dichotomy regarding React's current state. On one hand, React has been very successful for several years (it's currently the most popular library for Web development). On the other hand, the community has never been as dissatisfied with the library's current state.
Many frustrations stem from misconceptions about the state of the relationship between Meta and Vercel. Mark took a moment in the presentation to explain that all React features are developed internally to meet a Meta need. It's deployed when they're sure it's a good solution.
Although a third of the React team left Meta to join Vercel, React Server Components (RSC) remain a Meta initiative. Since this solution requires some additional implementation, they pushed Vercel to develop this implementation for their product. And not the other way around!
Another major source of frustration stems from the React team's communication strategy, particularly the lack of documentation on the Single Page Application (SPA) approach compared to the Server Side Rendering (SSR) approach, as well as the time it took for the change to be implemented. Indeed, the community felt a real pushback from the React team regarding the documentation and justification of their decision. Another example is the absence of detailed documentation on RSCs, both in React's documentation and Vercel's.
Finally, the React team's vision was to create documentation intended for people starting out, providing new developers with an advantage in an ecosystem that already supports RSCs (Next.js). Hence, there is no documentation on how to start a SPA project on the site. Mark ends the conference by saying that this was a false assumption: documentation is not just for juniors. From experience, React's new documentation is a goldmine of information. Several articles serve as references to share advanced concepts or ways of thinking on specific topics.
Mark wrote a more complete article on the subject.
June 16
June 16 marked the second day of JSNation, a sister event of React Summit. This online-only day featured a series of talks focused on JavaScript.
2025 State of Javascript Testing
Daniel Afonso explored the use of testing strategies in enterprise. The latest approaches appear to follow the same line of thinking as Kent C. Dodds with the Testing-Library library, which involves creating tests closer to reality. This is what Vitest proposes with their new tool, Vitest Browser Mode. The objective is therefore to have UI tests as close as possible to the web browser, because this is where our applications are executed. This testing tool would replace Testing-Library, while keeping the same API. A point I find interesting on the subject is that Kent C. Dodds is 100% willing to declare the end of life of his library, if it helps advance alternative libraries!
I remain attentive to what's coming with this type of testing tool. More and more libraries are adopting this approach: Cypress Components, Playwright Components, Vitest Browser Mode. If these types of tests are fast to execute, this could favour their frequent use and thus strengthen the robustness of our test suites. Otherwise, the developer experience (DX) risks being greatly reduced, as with the use of Karma in Angular projects.
June 17
June 17 was intended to be the second and last day of React Summit. The day of my presentation!
Just like the second day of JSNation, this one was remote. Since my presentation was already recorded, my only responsibility was to be present on the event's Discord to answer questions... At least, that's what I thought. The week before taking the plane, I learned that I was going to participate in two discussion groups on the subject:
- Growing Senior & Tech Lead
- Future of Fullstack Development
During the event preparations, I had been asked if certain topics from a list interested me. However, I didn't expect to have to participate as a guest!
Growing to Senior & Tech Lead
The first discussion room I participated in was about advancing from developer to senior and tech lead positions. This topic was the most interesting of the two! Mainly because several audience members asked concrete questions about how to get there, the associated challenges, and so on.
A key point mentioned during the discussion was impostor syndrome; it will never truly disappear. It's therefore essential to learn to live with it and ignore it as often as possible.
Getting good field experience is another important point that came up. Because not all experiences have the same value. Does someone with ten separate one-year experiences have the necessary expertise to develop the reflexes of a senior? It's not about staying in the same place for a long time, but having sufficiently in-depth experiences to see the consequences of one's decisions, understand long-term maintenance issues, and develop a systemic vision of projects.
Thinking Like an Architect
Lucca Mezzalira started telling us about some issues that can be found in certain architecture roles:
- The desire to create a "modern" and unnecessarily decentralized architecture
- Having a "technology-first" approach
- Ignoring the project context (business needs, technical skills, organizational structure, etc.)
To avoid falling into one of these roles, he shared 11 tips to remember:
-
Understand what your company/product really needs
-
Start with the product's limits/boundaries
-
Identify the characteristics of your architecture: security, resilience, availability, data sovereignty, latency, cost
-
Know how to modularize the workload
-
Be pragmatic rather than dogmatic
-
The only two constants in software architectures are changes and compromises
-
The priority? Your users!
-
The balancing exercise (long-term vision vs immediate need)
-
Master your domain and understand the system
-
Communicate, include and document
-
Focus on what really matters
He ended his presentation with a short but inspiring quote: "Architect isn't a title; it's a mindset."
Reflections and Key Takeaways
This experience at React Summit brought me much more than I anticipated. Beyond the pride of presenting on an international stage, this adventure allowed me to realize many things:
- Meeting creators like Mark Erikson, Tanner Linsley or Jared Sumner reminded me that even the greatest specialists remain accessible and curious to learn from others.
- It's not necessary to be a master speaker to get on a stage and present a subject you master! It's enough to be passionate and have the desire to share your knowledge and experiences.
- Every team and company has its unique set of challenges. There's not one single "right" way to do things, but rather solutions adapted to specific contexts.
Thanks
I would like to thank the React Summit team for this opportunity, Martin Nadeau for his wise advice, and Nexapp for making my on-site participation in Amsterdam possible. Without this support, this experience wouldn't have been the same.
Thanks also to all the developers who enriched this experience through their exchanges and their perspectives.
For people who hesitate to embark on the conference adventure: don't wait to be an "expert". Your unique perspective and your field experiences have value. The tech community needs diversity in the voices that speak out.
Next step: continue writing, sharing, and maybe cross paths at a future conference?