Hi, I'm Tony Alisea, a developer with over 25 years of experience. CSS won in the 90s due to its separation of structure and presentation, cascade concept, and powerful selectors. JavaScript developers fell out of love with CSS when they started using frameworks to construct the DOM. Instead of looking at the DOM holistically, we began to think in terms of componentization. CSS has continued to grow and add extraordinary features, such as CSS nesting and cascade layers. CSS layers give more control over the layering of CSS styles. Container queries allow us to respond to the size of the container instead of the viewport. The has pseudo class enables selecting parent elements. CSS is now more component-friendly and improves the user experience.

Welcome to the session on communicating technical information to non-technical audiences. Today, we will explore how to apply your existing communication skills to share technical jargon. Understanding your audience through asking questions, making observations, and doing research is key to successful communication. When communicating with non-technical audiences, consider their baseline knowledge and avoid making assumptions. Use jargon when it is understood by all and explain unfamiliar terms when necessary. Analogies and stories can be effective in explaining complex concepts. Visual aids and experiences can enhance presentations. Clarify the purpose of communication to avoid misunderstandings. Utilize resources like written communication, podcasts, and videos to educate team members. Include others in technical conversations to learn and build something bigger. Effective communication requires context and understanding. Utilize the course 'Technical Communication for Non-Technical Audiences' on Pluralsight for further guidance.

Hello, JS Nation! Today, I'll show you how I created gamified karaoke using Web Speech API. The Web Speech API has two parts: speech recognition and speech to text. It was originally built for karaoke but can also be used for forms and dictation. There are some quirks with the speech recognition API, such as limited microphone input and variation in implementation and privacy concerns across browsers. The speaker demonstrates how to implement speech recognition in a karaoke application and tests its error matching capabilities. Other interesting points include voice interface design considerations and the value of engaging in fun and unproductive side projects.

Hi everyone! I'm Rohit, a founding engineer at Tria. We are working on bringing the world to Web3 using names. My talk is about gaining performance and taking runtime to build time. There is an upward trend in libraries towards build time optimization, especially in React. Build time optimization improves performance, reduces bundle size, and provides more predictable software. Babel is a free and open source JavaScript transpiler that allows leveraging latest JavaScript features and moving computationally heavy logic from runtime to build time. Building a Babel plugin involves checking for a style prop inside an HTML tag and searching for aliases or token values. The visitor pattern is used to define the JSX type of node and access its path and attributes. The plugin can be customized for different utilities by defining aliases and tokens in a config file. Helpful resources for understanding and building custom Babel plugins include the Babel handbook, Babel docs, astexplorer.net, and the speaker's Twitter account.

Let's talk about writing your first Vip plugin. VIT, rollup, and Vip plugin are important tools in front-end development. Rollup is a bundler that can bundle JavaScript files into a single file. VIT goes through all the plugins and transforms files to JS modules. VIT and rollup have similar plugin architectures, allowing the use of existing rollup plugins in VIT. I'll discuss three plugin properties: resolve ID, load function, and more. Let's take a deeper look at the transform function. The resolve ID function determines the ID of the file or module, and the load function reads the file or module and returns its content. The transform function actually transforms the file or module into something else. For example, it can modify the code depending on the file extension. We can transform the result object into code by using object keys and map. This allows us to extract specific data and include it in the output. By making the code flexible, we can add additional information like 'built at' and utilize it for various purposes, such as displaying branch name or commit hash during deployment. You can implement various functionalities in the Vip plugin, such as reading Markdown files, implementing file-based routing, and creating domain-specific languages.

Hi, my name is Kirill and I have a little obsession with UI components. Let's talk React, specifically React 19 Server Components. I will show you how to build a polymorphic data table using server components. We explore mixing server and client components and applying the composition pattern. We discuss polymorphic components and separating client logic to render custom components without breaking client functionality. The component can be used in different environments, morphing into server or client components accordingly. This talk focuses on building a polymorphic component with minimal bundle size and access to both server and client APIs.

My goal with this talk was to answer the question of why we have another test runner. The talk breaks down the history of web testing into three chunks: the click-through era, browser war one, and browser war two. It discusses the motivations behind browser test runners and node test runners, highlighting Karma as the first node-based runner that gained popularity. The rise of node-based test runners like Ava, Tape, Mocha, and Jest is attributed to their stability and ease of use compared to Karma. Jest faced challenges with module loading and transpiling, but its non-opinionated abstraction made it a suitable choice. The shift towards environment-aware runners like VTest allows for safer testing and aligns with the need for transpilation across different environments. Lastly, the talk touches on the future of test tooling and the implications of AI on testing.

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.

This talk covers seven steps to secure React apps, including dependency management, validation, secrets management, code exposure, content security, security implementation, and additional security measures. It emphasizes the importance of understanding dependencies and risks, using tools like NPM Audit and Socker.dev. It also highlights the need for dependency validation and package namespace, as well as input validation using libraries like Zod and Valobot. Secrets should be managed using tools like .env and a secrets manager, while code exposure can be minimized by separating server-side and client-side code. Content security policies and tools like Next Safe and Helmet are recommended for implementation. Additional measures include deep code analysis, code execution monitoring, and strict content security policies.

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.