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.

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 there. I'm Teodor, a web developer building Proxima, an open source analytics platform. In June 2021, a wildfire burned down a huge area near my house in Athens. I had an idea to build a low-cost, open, and accessible device to monitor and alert authorities of fire outbreaks. JavaScript is event-driven and perfect for IoT applications. DeviceScript is a versatile framework for writing code targeting IoT development boards. We can expand device functionality by adding sensors for temperature, humidity, gas, and flames. We can establish a mesh network using Painless Mess for wider coverage. LoRa can be used for off-grid emergency setups. AI and ML techniques can be applied for failure forecasting and running inference on the device. The VALS BME 688 gas sensor can improve detection accuracy. USC team is working on a model to predict high wildfire danger areas. Innovation thrives at the intersection of ideas and technology.

Hello, everyone. Today we are going to explore AI-powered end-to-end testing. Unlike unit tests, UI testing has a huge layer of obstructions between the source code and the rendered UI. The source code includes HTML, CSS, and TypeScript, which are transpiled into JavaScript and bundled with tools like Webpack. AI can generate tests effectively for standard websites or blogs, but it may struggle with niche applications behind strict authorization or on-premise tools. AI-powered end-to-end testing for complex scenarios requires our guidance. We use meaningful data test IDs and follow the page objects model pattern. Additionally, we rely on useful tools like the end-to-end test helper in-browser extension and the continue IDE extension. Now, let's proceed to the demo, where we will create tests for the Pokemon application, including the ability to filter by name or type. We will navigate to the Pokemon details page and use our extension to manage settings and prompts. Additionally, we will create the details page object together and generate the test file. The Pokemon details page has 105 elements. We can view the elements for debugging purposes, including page object name, Pokemon details page, and system message. We will copy the page object and save it to a file. We need to make it exportable. Then, we will use the extension to create an end-to-end test and pass the context. I will use all the open files, including the page objects and the test case itself. I will send them to EI along with the predefined prompt. There is a system message and additional information we need to be aware of. The test runs successfully, and that concludes this part.

I'll speak today about the temporal proposal, which adds modern date and time handling to JavaScript. Temporal is an API that'll be available in browsers soon and will add a built-in library for dates and times, avoiding the need for external libraries like Moment. It offers strong typing with different types for different data, such as calendar dates with or without time. Temporal objects are immutable and designed to work with JavaScript's internationalization facilities. It addresses deficiencies in the global date object and introduces types like instant and plain types for accurate representation of time and dates across time zones. With the old date, representing a date without a time can be problematic, especially in time zones where midnight is skipped due to daylight saving time. Temporal introduces types like plain date, plain time, plain year month, plain month day, and zone date time to accurately represent different scenarios. Additionally, there is a type called duration for arithmetic operations and unit conversion. Now that I've introduced you to the cast of characters in temporal, it's time to show how to accomplish a programming task. We'll start with an easy task: getting the current time as a timestamp in milliseconds using the instant type. To convert between Temporal types, you can either drop or add information. The two zone date time method is used for conversion and requires adding a time zone and a time. Although Temporal objects are immutable, you can create new objects with replaced components using the with method. Migrating from the old date object to Temporal offers a more reliable solution and avoids potential bugs. Check out the documentation for more details and enjoy using Temporal in your codebase!

Hi, everyone! My name is Yash Varma, and I'm a software engineer and computer researcher. I'm an open telemetry enthusiast, working on creating a vendor-neutral observability framework. Today's talk is titled as Observability Matters, this time for frontend. We'll cover the evolution of ZEP, the understanding of observability, current state of front-end monitoring tools, core essence of front-end observability, and front-end observability direction. Observability is about understanding what's happening inside the system based on its internal behavior or output. Front-end developers often lack observability compared to back end developers. Synthetic monitoring and real user monitoring are two common tools used by frontend developers. Front-end observability allows us to understand application performance for different users and situations, connecting the dots and gaining insight into core web vitals and user sessions. It's time to adopt observability as a culture and break down silos between front-end and back-end to better understand the entire user experience.

Hi, I'm Ben, the CEO of Freestyle. We're building Cloud State, a JavaScript runtime that allows you to write your entire application in TypeScript. We believe that bringing all the layers into TypeScript natively can greatly improve team efficiency. By marking a class as 'at cloud state', it becomes persistent and can be deployed without a SQL database. Connecting to the front end is as simple as accessing the functions directly. CloudState enables the sharing of back-end data infrastructure as packages, eliminating the need for web servers and endpoints. Freestyle chat is an open-source chat solution that can be easily integrated into applications. Cloud State has the potential to transform databases like Node.js did to servers, making development better for JavaScript users.

Expect Type is a library for type-level testing in TypeScript. It allows you to write tests for your types, ensuring that they stay what you want them to be as your code base evolves. The library supports a wide range of TypeScript features, including type guards, advanced features, and generic type testing. It also integrates with various test frameworks, including VTest. Best practices include testing only helpful things, making generics specific, and running tests as part of CI pipelines. Understanding error messages and fixing type errors are important aspects of using the library.