Hello, everybody. How are we all doing? I'm going to talk about Rome, OpenTelemetry, and identifying performance bottlenecks and issues in React applications. The pillars of observability are logs and metrics. Logs are structured messages that warn, indicate, or error. Metrics include throughput, latency, custom and core web vitals. Traces allow us to see through the pathway of our application and identify bottlenecks. One common open standard for collecting these signals is open telemetry. React's client instrumentation is experimental and mostly unspecified. The open telemetry demo provides an example of front-end tracing in React, giving you a unique service name and basic metrics. The demo shows an HTTP POST request with the pathway and timing. The open telemetry project is still working on core web vital metrics and other enhancements. Real user monitoring (RUM) fills the gaps in open telemetry, capturing missing information. In conclusion, we discussed the importance of capturing logs, metrics, and traces and provided resources for further exploration.

I'm Zebe, a JavaScript developer with a focus on security. Let's talk about the risks of consuming NPM packages, particularly malicious ones. We explore how to obtain and run malware, as well as evaluate and analyze JavaScript malware in Node.js. Malware can be delivered as pre-compiled bytecode, and defenses involve tools like npm audit. Hardin JavaScript and Lafamote are security tools that protect JavaScript applications and dependencies. Lafamote puts each package in its own compartment and provides tooling to create access policies. It prevents stolen cookies and restricts access to sensitive globals. Limited time offer to help set up projects with Lafamote.

React.js is a new language for JavaScript that provides a more efficient and flexible way to build user interfaces. It uses a virtual DOM and JSX syntax. React.js is compatible with TypeScript and has certain requirements, such as Node.js and npm installation and knowledge of HTML, CSS, and JavaScript.

My name is Aurora, a web developer from Norway. Today, I'll be teaching you how to elevate speed, interactivity, and user experience with React components. I'll be coding a project task manager and improving it using Next.js, Prisma, Azure SQL, and Tailwind CSS. We will review the code, starting with the important layout component. We will also learn how to improve navigation and data fetching, enhance visual stability and user experience, fix search functionality, and add category filters with loading states. Additionally, we will explore the use of React 19 hooks to enhance interactivity. Finally, we will optimize rendering and achieve improved Lighthouse scores for better performance. Overall, this Talk covers a range of techniques and tools to enhance React projects and deliver a better user experience.

Hi, welcome to Shining Offline. I'll share how using the offline first approach saved us in the mobile urban lighting system. We'll discuss Kismet, the Bayless system, and the transition to a progressive web app. The system handled work orders, but the manual process caused unnecessary effort. In 2015, we built a native iOS app, but faced challenges with updates and communication. Eventually, we convinced the client to switch to a progressive web app. The new PWA's design improves usability and uses maps and services from the city's own infrastructure. Implementing the offline-first principle addressed many issues, and providing offline maps required using MapLibreGL app protocol. Offline communication with the iOS app endpoint and managing conflicts were also discussed. Offline-first requires significant effort but leads to user satisfaction. iPads are the devices of choice.

Hello, everyone. Today I'll talk about boosting React Native app performance. We'll explore optimization techniques, practical strategies, tools, and examples. Performance is crucial for mobile apps. Slow apps lead to frustration, abandonment, and revenue loss. We need to maintain 60 frames per second and overcome performance challenges. Let's understand the React Native architecture, legacy model, and the new architecture with JSI, fabric renderer, and turbo modules. Performance issues in React Native arise due to the single-threaded nature of JavaScript. The React Native bridge can be overwhelmed by large payloads, so using JSI for direct native communication is a more efficient solution. Profiling tools like Flipper, Chrome dev tools, React dev tools, Xcode instruments, and Android profiler help identify bottlenecks. Offloading heavy computations to web workers or JSI can improve JavaScript performance. Enable Hermes engine for improved performance. Optimize flatlist usage, delay non-urgent tasks, and prevent memory leaks for better app performance. Use initial numToRender and maxToRenderPerBatch props, memoize render item, and clean up side effects for optimized rendering. Preload and cache images, delegate gesture processing to the native thread, and continuously test the app under real-world conditions for smooth rendering and fluid UI.

Today's Talk discussed the performance impact of generated JavaScript and the importance of bundle size in relation to page load speed and user experience. The use of a build process, minification, and avoiding unnecessary polyfills were highlighted as strategies to reduce bundle size. API design considerations, such as avoiding deeply nested object lookups and using functions and objects instead of classes, were discussed in relation to minification. The concepts of down-compilation and transpilation were explained, with a focus on the challenges and benefits they present. The Talk also emphasized the need to avoid using TypeScript enums and instead use string constants, as well as the importance of compressing code and tracking bundle size changes. Bundle analyzers were recommended for visualizing bundle contents and component connections.

Hey, I'm Sid, and I work on the design systems team at GitHub. Let's talk about building accessible React components with a focus on screen readers. Use the correct HTML element for accessibility. For example, on GitHub, there are three tabs with options. These tabs are made using buttons. Let's see how a visually impaired person using a screen reader would access this website. What do they see? I'm going to enable the screen reader and walk you through what happens. When turning on the screen reader, it sets the context and tells you where you are. For example, on the React app, a button labeled 'Code' has focus and a menu popup. Inside the popup, there are several buttons with different labels. Something interesting happens. If I can't see the UI, I'm hearing buttons but no tabs. Screen readers cannot infer things like tabs from visual design. To provide this information, we can use the ARIA spec and its roles. By adding a role tab list to the div and role tab to each button, the semantics are conveyed. The role overrides HTML semantics. Screen reader identifies tabs, pronounces 'code spaces'. Default behavior of a tab is auto-focus. We can add aria-selected attribute to specify selection. Using React, I'm using an expression to set aria-selected based on the selected tab. The navigation into the tab panel is disorienting. There are separate groups for the tab list and tab panel, and there is a need for navigation between them. Use arrow keys to navigate within the widget. Remove tabs from the tab index, only the selected tab should be focusable. Implement arrow keys for navigation. Press tab to enter the tab panel. Press shift tab to go back up. Keyboard navigation is a common pattern extracted into a hook. Decide which keys to bind based on the widget type. Change selected tab on focus. Consider the ARIA authoring practices guide for keyboard interactions. Differentiate between instant and activated tabs. Follow the ARIA spec and use the APG as an informative resource. Screen readers may not always follow the ARIA authoring practices guide. Use correct HTML elements, add ARIA roles, properties, and states. Implement keyboard navigation. Use a GitHub example of notification settings with proper semantic elements. When selecting notification channels, the options are presented in a pop-up. The focus is on the first checkbox, indicating that it is the first option. The screen reader reads the status of each option. After selecting the desired option, the form can be submitted. The change is saved and the user is notified. The focus is recontextualized on the collapsed menu popup button. Not rendering the fourth option in certain conditions hides it from screen users. Removing the conditional and disabling the fourth checkbox until necessary eliminates this issue. Using IR disabled instead of disabled makes the element accessible for screen reader and keyboard users without affecting styling or click cancellation. You have to add your own class name and make sure it is disabled. It is accessible by keyboards. Voiceover on Mac uses 'dimmed' to signify IR disabled. Adding another span that requires at least one channel. Additional descriptions can be added using aria-describeby. SCREEN READER Only notify for failed workflows. Requires at least one channel to be selected. Dimmed unticked. Tick box. Now you know the label, why it is disabled, and that it's dimmed. And let's see if it's If I mean. Never. Menu popup collapsed. This flow seems more intuitive. You know all your options up ahead. One option was disabled, enabled something else, and it became enabled again. Much more clear. Feels like a better UI. We need to design with accessibility in mind. Accessibility isn't something that you can just sprinkle on in the end. We have to bring it way earlier in the stage. Be careful when disabling elements. Use RLDisabled. Short list of six things to consider. Links on my website. Follow me on Blue Sky.