From Architecture to Adoption: Engineering & Scaling a Modern LMS with React

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

At JavaScript Mastery, we've built a scalable learning platform to serve millions of developers worldwide—and the process came with its own unique challenges and takeaways. Traditional learning platforms suffer from rigid structures, low retention, and scalability bottlenecks, so we set out to create a flexible, high-performance system that could grow with our audience.

In this talk, I'll break down how we engineered a dynamic MDX-based content system with React, enabling seamless integration of videos, interactive coding, and AI-powered quizzes.

I’ll dive into:

  • React Server Components & streaming rendering for a 40% performance boost
  • Next.js-driven SEO strategies that tripled organic traffic
  • Data-driven engagement techniques that significantly improved retention
  • Scaling lessons from serving a global developer audience

This is a real-world case study of the engineering decisions, challenges, and optimizations that took our platform from an idea to a widely adopted learning ecosystem. Whether you're scaling an LMS or any content-driven application, these insights will help you build, optimize, and grow your own platforms effectively."

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

FAQ

JavaScript Mastery is a platform founded by Adrian that educates millions of users worldwide through project-based YouTube tutorials and aims to build a learning platform specifically for developers.

Most online learning platforms feel ineffective because they follow a similar structure with video, text, and a non-interactive comment section, lacking the interactive and practical approach that developers need to learn effectively.

JavaScript Mastery improves online coding education by using project-based learning, MDX for interactive content, and features like quizzes and code sandboxes to make learning more engaging and practical.

Adrian faced challenges with traditional LMS platforms due to their cookie-cutter design, lack of interactivity, and inability to support modular and reusable content effectively.

MDX is a combination of Markdown and JSX that allows embedding of interactive components within content. JavaScript Mastery uses MDX to create interactive lessons with quizzes, assignments, and code sandboxes.

Adrian addressed scalability issues by moving MDX files to AWS S3, creating a structured system of content pieces, modules, and courses, which allowed content reuse without duplication.

The JavaScript Mastery platform uses a stack consisting of React, Next.js, Postgres, Drizzle ORM, TRPC, Zod, Tailwind, and TurboRepo to ensure a scalable and efficient development environment.

JavaScript Mastery ensures performance optimization by strategically rendering content, using React Suspense, optimizing assets, and disabling unnecessary prefetching to reduce load times.

JavaScript Mastery uses strategies like interactive quizzes, personalized learning paths, and engagement features similar to Duolingo to retain users and encourage frequent platform use.

Rendering strategy is important for JavaScript Mastery to balance server and client rendering, optimize SEO, and improve load times, ensuring a smooth user experience across different devices and networks.

Adrian Hajdin
Adrian Hajdin
28 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The speaker highlights challenges in online learning platforms and the necessity for a developer-centric platform. Insights on building a specialized platform with real-world case studies are shared. MDX is discussed for creating flexible content and organizing content pieces into reusable modules. The platform architecture involves a monorepo with TurboRepo managing a stack of technologies. Strategies for enhancing user engagement, user retention through streaks, and key takeaways like scalable architecture, strategic rendering, and user-focused development are emphasized. Performance optimization techniques such as React Server Components and asset optimization with WebP are mentioned. Strategies for privacy-aware metrics tracking, user learning metrics, and avoiding server-side rendering for better performance are also covered.

1. Challenges of Online Learning Platforms

Short description:

The speaker discusses the challenges of online learning platforms and the need for a specialized platform for developers. Adrian, the founder of JavaScript Mastery, shares insights on building a developer-centric learning platform and real-world case studies.

Hi everyone. How are you finding your time in Amsterdam so far? Good? Perfect. The weather is nice. So that's always amazing, especially for Amsterdam. But yeah, before I introduce myself, I wanted to ask you a question. I was wondering if at some point in your career, you had to learn something that your boss or your project manager asked you to do really fast, like fix that bug or implement that feature within your platform? You had to do something like that very quickly, right?

So the next thing is that I'm assuming that you then went through the docs, watched some YouTube tutorials, or even if you were really stuck on it, maybe bought a course. But I'm assuming that what happens for me typically when I try to cram all that knowledge in about a week, we typically forget what we've learned. So that happens to most of us, it is completely normal.

So my thought is that it is no wonder that that happens, considering that most online learning platforms feel almost identical. There's a video, there's some text beneath it, and a comment section that nobody seems to reply to. There's YouTube as well, which is amazing for interactive content, but it's more or less the same thing. Video at the top, some description then, and then comments. And as developers, we're used to interactive docs, especially nowadays. A lot of these DevTools are creating docs that you can actually move around through and select your options for technologies and things just work instantly.

There's also Stack Overflow and Code Sandboxes. We learn by doing. And most learning platforms still haven't evolved to support that. And I mean, it's no wonder, I get it. Imagine a platform trying to support somebody trying to learn how to play chess, maybe bake sourdough, coat in rust, or raise a petiguana all at once. You just can't do it all. So that is because you would need to accommodate for all of these different types of learnings. You would need a baker to assist to throw a live chat, a chess board widget, syntax highlighting for every language ever made, and Terrarium Simulator, I guess. So there's a lot of stuff that you would need that a single platform can't do it all. I think we can all agree with that, and they shouldn't. Not a single platform should cater to every single audience.

So that's why I think that we need a learning platform made for developers. So, hi there. I'm Adrian, the founder of JavaScript Mastery, where we educate, thankfully now, millions of users worldwide through project-based YouTube tutorials. And today, I want to share my take on building that learning platform. And not just how we build it, but I want to share some real-world case study of how we are approaching it.

2. Building Flexible Content with MDX

Short description:

Lessons on building flexible content with MDX for a learning management platform.

The architecture, scalability, performance, obstacles we encountered, and then retention, how to actually keep users to come back to the platform every day. And honestly, most of these lessons that I'm going to go over today apply to any content-heavy app. It's not just learning management systems. It's not just CMSs. Anything where you have to manage a lot of content, some of the things that we're going to go through today, you'll be able to put to use.

After struggling with trying to use different LMS platforms, again, they all fell into the same cookie-cutter design, I wanted to build content the way that I build apps. Flexible, modular, reactive, if you will. So, do you think that there is a specific format that would allow us to achieve that level of flexibility with code? Maybe different kind of text formats, like Markdown. Markdown was, of course, the first thing that we tried, but it still felt a bit too limited. No interactivity, no logic. More like a blog post.

Then, we tried different CMS platforms, which were better, but still no native ways to embed interactive components or add some state into the lessons that people are learning. Then, I gave MDX a shot. It's Markdown plus JSX. Can I get a raise of hands of how many people have heard about or used MDX before? That's about half, I would say. Mostly for blogs, I'm assuming, right? Most of you maybe have your own blogs running on MDX or documentation pages, docs. Yeah, it's a lot of docs. It's an amazing technology that allows us to basically inject real components anywhere. In our case, for a learning management platform, that's quizzes, call outs, assignments, video players, code sandboxes, all live, interactive, and context-aware, which is a completely different story than just having a video and a piece of text.

3. Optimizing Content Organization with MDX

Short description:

MDX simplifies content creation by enabling flexible component embedding and structuring content pieces into reusable modules and courses, enhancing scalability and developer experience.

MDX helped us with that. Suddenly, content creation felt more like coding because I could embed any kind of custom component, or if it didn't yet exist, we built it in React and then used it within lessons within the MDX structure. Is that it? MDX solved everything? Thank you for coming to the TED talk. Well, not really, of course. We quickly hit walls with scalability. Why? Because we were managing all of these markdown files locally. I had dozens, if not thousands technically, of individual MDX file lessons that we were storing locally. Whenever I wanted to reuse a lesson in another course, I had to copy and paste it. Not really an intricate system that will allow us to reuse specific lessons or content. Things very quickly got pretty messy.

Files multiplied, app size grew, and the developer experience was out of the window. We decided to re-architect everything. Instead of files and folders, we started thinking in terms of entities and relations. First, I moved all the MDX files out of the repo onto the AWS S3 bucket, which made the content updates independent from deployments. They're fetched on demand and rendered at runtime, not at build time, because when we had them locally, the builds were taking so long to go through. Then I built a simple model of how we can structure all of those lessons. The most little piece is the MDX file, and we're calling that a content piece, which is just an individual file stored in S3. Then we have modules, which are essentially collections of content pieces, and then courses, which are collections of modules. No more duplication. Courses could reuse modules, and modules could reuse content pieces. So instead of copy-pasting content everywhere, this gave us true reuse. Like component composition in React, but for content.

Then things were pretty simple at that point, but I decided to take it a step further by developing something we call learning paths. The way that they work is that users take short surveys and share what they want to learn about and at what stage of their learning path are they right now. Based on that and their desired tech stack, we then can programmatically generate custom paths, mixing everything we talked about so far, individual MDX lessons, modules, and courses, all together to form a linear learning path depending on the user's current state and where they want to go. If you think about it, it's all about composability in React. Just like in React, we could reuse, override, and avoid any kind of duplication. The takeaway here is that you should treat content as structured data, not as static code. And again, this is not just applicable to LMSs, this is applicable to any kind of a content-heavy application. So at this point, the architecture felt simple, it finally made sense, but that took a lot of iterations to get it right.

4. Enhancing Platform Features and Architecture

Short description:

The architecture involved a monorepo with TurboRepo managing a stack including React 19, Next.js, Postgres, Drizzle ORM, TRPC, Zod, Tailwind, and chatCN for shared components. The T3 stack components provided full type safety, fast iterations, and minimal glue code for seamless integration. Additional features included interactive code sandboxes within lessons, live code previews, short quizzes after lessons, and AI-generated questions for retention.

But we were finally at a stage where it felt right. So let me tell you a bit more about how the architecture worked and how it felt. Everything lives inside a monorepo. So we decided to use a monorepo structure managed with TurboRepo, which really gave us an amazing developer experience with build caching and shared packages that we could reuse. Reuse where? Where we'll split it into two different parts. The admin side for analytics and content creation, and user side for browsing, learning, and progress tracking. So we were able to reuse these different pieces of UI, as well as logic, across both platforms within this monorepo.

The core stack is of course, React 19. But as a full stack framework for React, it was Next.js in this case. Then Postgres as a relational database, Drizzle ORM for schema modeling, TRPC and Zod for full type safe APIs that allowed us to bridge between two different parts of our monorepo. And then Tailwind and the chatCN for shared components. This stack might feel familiar if you already heard about the T3 stack. How many of you have heard about this stack or used it or used at least some pieces of this stack in your apps? Okay, I can see some hands right here. So it's fairly popular and it's amazing for quickly prototyping applications and getting them to market so you can test them and prototype them. In this case, for us with Zod and TRPC, that has been a game changer because we got full type safety across both applications with fast iterations and minimal glue code that we had to add to make it all work together. So it just felt right.

And this architecture allowed us to append additional features to the platform itself. It was very easy to add them. So one of the first features that solves the problem that I talked about at the start, which is the rigidity of the typical learning platforms, we wanted to add code sandboxes, which are basically like interactive playgrounds that you can add or now embed directly within individual lessons. This allowed us to have live code with no setup and no context switching. If we presented a video about something at the start, we could immediately then follow up on it and people were able to test it out. Learners were able to experiment with the code and see live previews directly within the lesson that they were learning. We also wanted to help users retain what they learn. So after each lesson, we generate a short quiz to allow them to just recap what they learned. And here, we used a bit of AI because, yeah, what would an app be without AI these days? But again, we didn't just add it for the sake of adding it. We used it where it actually made sense. So we fed it the video details and the transcript and asked it to then generate nice questions and present it to people instantly. This worked out incredibly well. People loved it. So we were seeing immediately about 1500 quizzes completed daily.

5. Simplifying Analytics and Focus

Short description:

Users enjoyed quick recaps after lessons. PostHog used for analytics, tracking various metrics. Simplifying data helped in making informed decisions on feature and content additions.

And it seems that users really enjoyed that quick recap after a 30-minute lesson. For analytics, we used PostHog. I think at this point, besides Google Analytics, it is one of the best developer-friendly metrics platforms. We used it to track everything. So we tracked clicks, events, custom events, session replays, a lot of it. And it quickly became overwhelming.

Just because PostHog allows you to add all of these different dashboards with metrics, we added every single one of them. We were working with a lot of pieces of data, but we went overboard. We could not make sense of that data because we collected so much. We eventually brought in a growth marketer who then helped us simplify and focus on these actionable steps.

Because as developers, maybe we should not focus on trying to do every single piece ourselves. Of course, if we get the opportunity to have somebody else within the company do it, we should be focusing on what we do best, which is development. Once we simplified the data, it started making more sense. So we were able to make more educated decisions on the types of features or types of content that we want to add to our application. And this was great.

6. Balancing Features and Performance

Short description:

Chosen Markdown for content delivery, scalable system. Prepared materials, shared via newsletter. Slow performance due to feature overload, impacting user experience.

So at this point, we have chosen our system of content delivery for as Markdown. We have made it scalable by hosting those files somewhere else and came up with a system that worked. And we also had analytics and all of these interactive platforms that are going to make it easier for future developers to learn about something. So clean UI, tons of features. It was working great. And since we have a large developer audience, we were kind of ready to put it out there.

We prepared some materials. We shared it across a newsletter. And people were quickly starting to come in. But once we hit deploy and shared the link, we waited. People seemed to love the idea. But then they said that it feels slow. When we tried to add so many of these features, we kind of put performance at the back side. We were just trying to cram it up with many features. But then, yeah, it turned out to be slow.

On my machine, it worked well. But once we tested it under slower networks, older devices, a reality hit. Landing pages, for some users, took about 10 seconds to load. Lesson pages, about 15, because they had that huge Markdown file with different interactive elements. It was embarrassing. These are very terrible times. But that happened because we tried to fit so many features without necessarily thinking about performance at the same time, which is something you should never, obviously, do.

7. Strategic Performance Optimization

Short description:

React Server Components toolkit for better loading. Strategic content rendering for performance improvement. Added React Suspense, useHook, cache method for enhanced performance.

Especially because Next.js, out of the box, and React nowadays, with React Server Components, gives you a toolkit of different things that you can immediately try to use to make the loading better. Like SSR, SSG, ISR, React Server Components, partial pre-rendering. All of these tools are at our disposal. But the choice of which ones should we use is not binary. Lydia held a great talk just before today, talking about React Server Components and React Compiler. And there's a lot of different things that we can do if we know how to use it properly. But my mistake was trying to render everything on the server side. SEO is going to be great. Load times should be great. But that was just not the case.

A lot of things were happening on the server, blocking us to return the data, and it just wasn't working well. So we have to be strategic about rendering the content, not just think about it in terms of client versus server. So we mapped it, or the components in the pages, by intent. So we server rendered the lessons for SEO benefits, so people can search through all the content that we create. We client rendered the progress, the comments, the search, and everything the user interact with. And then we fully statically render the marketing pages.

On top of that, we also added a lot of different strategies to further improve the performance. We added React Suspense Boundaries to split the rendering into async islands, so maybe we can show something at the top, while the rest of the part is still streaming in. That also helped a lot with performance. We used React 19's useHook for progressive hydration with no layout blocking. This further improved the performance. A bit of React's cache method, which allowed us to memoize the heavy functions, especially the ones that are like fetching the user progress, which is very heavy and takes a lot of time to fetch for all the different kinds of users. So that also helped with performance.

8. Enhancing User Engagement and Education

Short description:

Asset optimization with WebP, strategic rendering for better user engagement without pre-rendering. Importance of app speed on user engagement. Enhancing online coding education with user-focused development.

Of course, we optimized the assets, turned every single single wire PNG or JPEG into a WebP, and preloaded the ones that appear above the fold, and then lazy loaded the ones that appear below the fold. Some things that we should do before we go live in any kind of an app. We also disabled Next.js' prefetching to avoid downloading huge pages preemptively, because our MTXs had a lot of links within them and the platform was super interlinked. Behind the scenes, Next.js was prefetching a lot of stuff, so we had to disable it. And then later on, maybe we're going to do intent-based prefetching instead of just prefetching everything.

The result is that we went from FCPs of 4.6, so the first Contentful Paint, once something appears on the screen, and largest Contentful Paint from about 8 to 10 seconds. And very, very high bounce rate, because developers are, if we're going to be honest, are very tough crowd and they want things to load very quickly and to work smoothly. So a lot of people were just leaving the site without even trying to sign up. And that's okay. It makes sense, right? We went to about 0.5 seconds on FCP, 1.5 seconds to LCP, and the bounce rate dropped significantly, which means that people were more engaged with the app and using it more often.

Which I think is a great lesson. We all know about it. The faster the app is, the bounce rate is going to go down, but it really shows just how important it is for user-facing applications. And we achieved that without partial pre-rendering, which we'll also add soon. It was a new Next.js feature, but we still didn't upgrade to the latest version of Next.js. They seem to be coming up like every time that I open Twitter. So it'll take some time for us to upgrade to the latest version to be able to use this. But the point of the story here is that rendering shouldn't be binary. It should be strategic. You should really think about how you want to render specific content and what obstacles will that create for rendering other pieces of content on the same screen or on other screens. So at this point, everything is working well and performance was just one piece of the puzzle. But underneath everything, we had one question. And that is that how do we actually make online coding education better? The goal wasn't just to add as many features as possible. It is to make learning feel like building apps. MTX gave us that foundation. Composable, reusable, and interactive. The stack that we talked about also helped with that, allowed us to scale and move fast. And it worked well. Very soon we were able to hit 100,000 users within the first month, 18,000 learning paths created, and thousands of developers learning daily. So we went through a couple of obstacles, but at the end of the day, it is a continuous process.

9. User Retention Strategies and Key Takeaways

Short description:

User retention strategies through streaks and feedback loops. Key takeaways: scalable architecture, strategic rendering, focused analytics, and user engagement for retention.

And we're going to keep improving it and working on new stuff. For example, the next challenge is retention. So now that we're actually getting the users to come in and try the platform, we got to make them stay. We got to provide enough value for it to make sense for them to come back. We're going to approach it from an engineering standpoint, not just as a product lead, but trying to do maybe what Duolingo does best. Points, streaks, badges. We really learned that people want to have some kind of streaks. They want to have smart nudges. So if they're inactive, we kind of send them an email and bring them back in. And we want to create some feedback loops because even those small re-engagements, when compounded, have great impact. So these are some of the next steps because learning maybe isn't like Netflix. You got to put some effort to make people want to come and watch the next lesson.

Yeah. So to conclude the talk, I want to summarize it in a couple of key takeaways. Number one is that architecture matters. So start scalable from day one. Sure, it's not going to be perfect. Some things are going to have to be tweaked, but start with something scalable in mind and they'll build on top of it. The second one is that rendering is strategic. SSR, client-side, hybrid. You really should approach it from a strategic standpoint, not just make one decision or the other. Talking about analytics, measure what matters, not everything. Because if you could collect a lot of pieces of data, you just won't be able to make sense of it all. So rather start small, create a couple of funnels and track only the key points that matter for your users and your platform. And then, sole retention as an engineering problem. Try to come up with systems within the app so that you actually make people want to come back. Our goal always was never just to teach, but to build experiences that allow people to keep building additional stuff. And if this talk helps you build something like that too, well then it was worth it. So that's it from me. Thank you.

QnA

Stack Evolution and Privacy-Aware Metrics Tracking

Short description:

Discussing stack evolution towards Drizzle and tracking metrics with Google Analytics and PostHog for privacy-aware users.

We've got quite a few ones. I'm gonna go from the top. Yeah, sounds good. So you kind of, you learned a lot. You talked about your learning journey, how you went about learning things, and oftentimes hindsight is 20-20. So let's rewind time. If you were going to start all over again with your new knowledge, what changes would you make to the stack? To the stack. Okay, that's interesting. The stack did evolve over time. So initially we started with a basic T3 stack, but eventually I think we used Prisma. Again, nothing bad against it. But we switched over to Drizzle. It seems that more developers are now switching over to Drizzle, not a major thing. But yeah, as I said during the talk, the TRPC and the Drizzle and that type safety, so with TypeScript for sure made a big difference. So I would definitely start with those right now. That makes sense.

And something which in the next question, we kind of talk about is developers, we go onto these websites, a lot of us, we're very privacy aware. And we don't usually allow cookies. We use web browsers that if anything, make it harder for builders, for developers to track the metrics on the websites we build. So how are you able to track the necessary metrics? This comes from Nico JS, so thank you for the question. That's a great question. So we used Google Analytics as well. If we want to eventually pair it up with Google Ads, they just make it a necessity to do that. We also use PostHog, as I mentioned. PostHog has something called cookieless tracking, which allows you to bypass some of the cookies fully legally, of course. So I think they handle the better part of that, allow this to track properly even without modern blockers. And it's also really interesting with cookies because there's a lot of stuff that is probably not great from a privacy perspective, but just knowing how a user's using your own website, it's not a privacy invasion in a lot of ways sometimes. Yeah, the data can be randomized. You don't have to get the names or the emails, you can take just the IDs and then make sense of it later on on a global scale, as statistics, instead of just individual use cases.

User Learning Metrics and Rendering Performance

Short description:

Discussing ensuring user learning, challenges in metrics implementation, and avoiding server-side rendering for improved performance.

And this is another good question, and it brings us back to the metrics piece, which is like, what do you have in place to ensure that users are actually learning and not just stumbling by? So we had a great talk from Matthias earlier about how they use metrics to kind of quantify human psychology. Do you have anything similar or maybe even different? Yeah, that's a great question. At this point, no. But it definitely sounds like something that would make sense to implement some kind of checks, right? The quizzes could be one point that doesn't let them proceed until they answer those questions, right? But sometimes it's hard because developers oftentimes just want to fast track to do something, so they skip things and we don't want to block them if they already know some content they've learned about before, right? Absolutely. Us developers, it's a tough crowd to build for, right? Super tough crowd. Yeah, as I speak with a lot of different dev tools that we post on the channel as well, the dev real people, marketing people, tell me that developers are the hardest crowd to market to. I like it because it gives me a job. Yeah, exactly. And same thing for us. We don't try to market the developers, we try to approach them through education. So our goal is always to provide value, to teach them something. And then we give them value, they learn about it, they're going to end up eventually using it within their tools. And that's the way to get to developers, not through paid advertising or marketing. Yeah, that makes sense. That makes sense.

And the last one. What was the most common issue for the degraded performance when you're rendering everything on the server? It's like the first easy win for people. The first easy win is don't render everything on the server, right? Initially, like especially with Next.js, server-side rendering, basically, they made it the go-to default choice. Everything was rendered on the server by default. But you have to come in and tweak some things a bit, render something on the client, maybe, especially if it's interactive because it puts a lot of load on the server, especially for heavy MDX files that we had to bring back. So it just wasn't the best choice. Again, try to be a bit strategic. Try not to necessarily render everything on the server. Well, that was a very articulate way to say it depends. If you do want to ask him more questions, he will have a space at the speakers Q&A, so definitely do that. Remember, as you leave, please put your headphones on the chair you're on. It just helps the people who are coming in after you. And we're going to have a short coffee break. We're going to have many talks for the rest of the day. So we'll see you soon. Thank you, everybody. Have a great day.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
25 min
Principles for Scaling Frontend Application Development
Top Content
Watch video: Principles for Scaling Frontend Application Development
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Building a Web-App: The Easy Path and the Performant Path. Why Are They Not the Same?
JSNation 2023JSNation 2023
31 min
Building a Web-App: The Easy Path and the Performant Path. Why Are They Not the Same?
Misko Havry introduces himself and discusses the impact of JavaScript on performance. The concepts of reconciliation, hydration, and resumability are explored, along with the importance of clean code and compiler optimization. The Talk includes demos of application components and showcases the power of code extraction. The QUIC framework is highlighted for its ability to optimize code loading and prioritize interactions. The service worker is used to selectively download components for improved performance. SEO and debugging in QUIC are also discussed, along with comparisons to other frameworks.
A Saga of Web Rendering Woes
Vue.js London 2023Vue.js London 2023
28 min
A Saga of Web Rendering Woes
This Talk discusses the problems faced in building and rendering web applications, different rendering methods and strategies, and the benefits of the Yamstack architecture. It covers server-side rendering, static site generation, incremental static regeneration, and edge rendering. The speaker demonstrates how to build a static site using a Hello CMS and the JAMstack architecture. Other topics include connecting Storyboard with a Nuxt application, mock data, hybrid rendering, and handling I18N with a static site generator.
Supercharging Your Dev Experience With Turborepo
React Day Berlin 2022React Day Berlin 2022
26 min
Supercharging Your Dev Experience With Turborepo
Top Content
This Talk explores the benefits of using TuberApple, a tool for supercharging the development experience. It highlights the advantages of monorepos, such as code reuse, shared standards, improved team collaboration, and atomic changes. TuberApple, specifically Tuburepo, offers efficient task execution through caching and optimized scheduling. It simplifies monorepo development by allowing parallel execution of tasks and seamless coordination of changes. Tubo, another tool within TuberApple, enables smart task execution, declaring task dependencies, and efficient caching in monorepos.
Handling Data at Scale for React Developers
React Summit 2022React Summit 2022
23 min
Handling Data at Scale for React Developers
This Talk discusses handling data at scale for React developers, including scaling databases and the need for search. It explores different ways to fetch data in React, such as using useEffect, fetch, and setState. The Talk also introduces Suspense for data fetching and how it improves user experience. It covers controlling React Suspense, handling search, and using render-as-you-fetch. The Talk concludes with a discussion on the RFC status and fetching in event handlers.
Scaling React-Three-Fiber Applications beyond the Hello World
React Summit 2023React Summit 2023
20 min
Scaling React-Three-Fiber Applications beyond the Hello World
Watch video: Scaling React-Three-Fiber Applications beyond the Hello World
WebGL has evolved from showcasing technology to being used in everyday applications like Google Maps and Figma. React and 3.js can be used together to build WebGL applications, allowing for reusable components and declarative development. Building complex 3D graphics applications requires efficient data structures, algorithms, and rendering techniques. The Flux CAD editor uses React, 3.js, and React ReFiber to handle complex engineering documents and optimize GPU utilization. Optimizing the render loop and GPU performance is crucial for improving WebGL application performance. Instance rendering can be used to optimize text rendering in WebGL applications, achieving efficient rendering of thousands of 3D characters.

Workshops on related topic

React at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
WorkshopFree
Isaac Mann
Isaac Mann
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.