Whatโs Missing From the Web Platform?
๐ **Source:** [Whatโs Missing From the Web Platform?](https://www.youtube.com/watch?v=bdw10C0wxiQ)
> [!note]+ Document Notes
> tags: [web-platform, web-apis, browser-development]
> author: Syntax
> source: YouTube
> reference: https://www.youtube.com/watch?v=bdw10C0wxiQ
> date created: 2025-01-26 22:30
>
> # ๐ท๏ธ Title: What's Missing From the Web Platform?
>
<!-- deep-read:sections start -->
## ๐งฐ Action Inbox
- [H1] Research customizable select implementation โ current browser support #web-platform
- [H2] Test content visibility CSS property performance โ compare with virtualization libraries #css
- [H3] Explore Bluetooth/Serial APIs for device integration โ check Safari support status #apis
## ๐งญ Table of Contents
- [๐ Summary](#-summary)
- [๐ Main Content](#-main-content)
- [๐๏ธ Notes](#๏ธ-notes)
- [๐ References](#-references)
- [๐ฃ๏ธ Paraphrase](#๏ธ-paraphrase)
- [๐ฐ Newsletter](#-newsletter)
- [โ
Action Items](#-action-items)
- [๐งช Hypotheses](#-hypotheses)
- [๐ Methodology](#-methodology)
- [โ Questions](#-questions)
- [๐ฎ Future Research](#-future-research)
- [๐ก Implications](#-implications)
- [๐ง Learning Styles Assessment](#-learning-styles-assessment)
- [๐ Accessibility Assessment](#-accessibility-assessment)
- [๐ DEIB Assessment](#-deib-assessment)
- [โ
Logical Validity](#-logical-validity)
- [๐ก๏ธ DARVO Analysis](#-darvo-analysis)
- [๐ฏ Conclusion](#-conclusion)
### ๐ References
- [Syntax Podcast](https://syntax.fm)
- [Open UI Community Group](https://open-ui.org)
## ๐ Summary
- Comprehensive review of missing web platform features across DOM primitives, JavaScript syntax, APIs, CSS, and browsers
- Focus on practical developer needs like better form controls, TypeScript integration, device APIs, and styling capabilities
- Discussion covers current implementations, browser support status, and realistic timelines for adoption
- Key stakeholders include web developers, browser vendors, standards committees, and the broader web community
- Balance between idealistic wishes and practical constraints of web standards development
## ๐ Main Content
Wes Boss and Scott Tolinski explore the current gaps in web platform capabilities, examining what developers need most for building modern web applications. The discussion spans five main categories: DOM primitives, JavaScript language features, Web APIs, CSS improvements, and browser enhancements.
The conversation highlights the tension between developer desires for comprehensive native solutions and the complex reality of web standards development. Many proposed features require careful consideration of backwards compatibility, security implications, and cross-platform consistency.
Key themes include the move toward customizable, accessible UI primitives (like the new customizable select), the ongoing push for TypeScript integration, and the need for better device integration APIs. The hosts acknowledge their "idealistic" perspective while recognizing the valid constraints that slow standards adoption.
## ๐๏ธ Notes
#### โฑ๏ธ [00:00](https://youtu.be/bdw10C0wxiQ?t=0) โ [H1] Introduction and Context
- Key idea: Web platform has improved dramatically but gaps remain for optimal app development
- Evidence: "Last two or three years, we've gotten this massive swath of APIs"
#### โฑ๏ธ [03:45](https://youtu.be/bdw10C0wxiQ?t=225) โ [H2] Better DOM Primitives
- Key idea: Current form controls lack styling flexibility and good defaults
- Evidence: "Nobody uses those primitives aside from input type text and email"
#### โฑ๏ธ [05:23](https://youtu.be/bdw10C0wxiQ?t=323) โ [H3] Customizable Select Success
- Key idea: New customizable select demonstrates proper approach to modern primitives
- Evidence: "Full control over CSS without giving up accessibility and keyboard control"
#### โฑ๏ธ [08:15](https://youtu.be/bdw10C0wxiQ?t=495) โ [H2] Date Picker Complexity
- Key idea: Date pickers too complex for universal browser primitive
- Evidence: "Range inputs, prices for flights, not allow selecting certain ones - far too complex"
#### โฑ๏ธ [12:45](https://youtu.be/bdw10C0wxiQ?t=765) โ [H1] JavaScript Syntax Additions
- Key idea: TypeScript integration and pipe operator top developer requests
- Evidence: "Types as comments proposal - browser would treat TypeScript syntax as comments"
#### โฑ๏ธ [15:30](https://youtu.be/bdw10C0wxiQ?t=930) โ [H3] Pipe Operator Status
- Key idea: Long-requested pipe operator stuck in standards limbo
- Evidence: "Stage two and last updated 3 years ago - not looking great"
#### โฑ๏ธ [18:20](https://youtu.be/bdw10C0wxiQ?t=1100) โ [H1] Cookie Banner API Need
- Key idea: Standardized consent management could solve web's cookie banner mess
- Evidence: "Cookie banners coded poorly, dark patterns all over the place"
#### โฑ๏ธ [22:10](https://youtu.be/bdw10C0wxiQ?t=1330) โ [H2] Device Integration APIs
- Key idea: Bluetooth and Serial APIs exist but lack cross-browser support
- Evidence: "Safari says no way, Firefox hasn't implemented it"
#### โฑ๏ธ [25:40](https://youtu.be/bdw10C0wxiQ?t=1540) โ [H3] Native Reactive Templates
- Key idea: Browser-native reactivity would eliminate framework overhead for simple cases
- Evidence: "Variable in DOM, when variable updates, so does DOM"
#### โฑ๏ธ [28:15](https://youtu.be/bdw10C0wxiQ?t=1695) โ [H2] CSS Improvements Needed
- Key idea: Speed-based animations and strict mode could modernize CSS
- Evidence: "Specify pixels per second rather than duration"
#### โฑ๏ธ [32:30](https://youtu.be/bdw10C0wxiQ?t=1950) โ [H1] Browser Engine Diversity
- Key idea: Safari moving to Chromium would harm web ecosystem
- Evidence: "Do not want single browser engine - causes web to stagnate"
#### โฑ๏ธ [35:45](https://youtu.be/bdw10C0wxiQ?t=2145) โ [H2] AI API Considerations
- Key idea: Premature AI APIs could repeat web components mistakes
- Evidence: "Don't rush APIs based on current needs - people won't use them"
#### โฑ๏ธ [40:20](https://youtu.be/bdw10C0wxiQ?t=2420) โ [H3] Local AI Model Access
- Key idea: Browser access to device AI models could enable private, fast inference
- Evidence: "Chrome downloading small model, runs on machine - slow but promising"
## ๐ References
- [Customizable Select Specification](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select)
- [Open UI Community Group](https://open-ui.org/)
- [Web Bluetooth API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API)
- [TypeScript Types as Comments Proposal](https://github.com/tc39/proposal-type-annotations)
## ๐ฃ๏ธ Paraphrase
- Web developers want better native form controls that can be fully styled while maintaining accessibility
- TypeScript integration into browsers would eliminate build steps for many projects
- Device APIs like Bluetooth and Serial exist but need broader browser support for mainstream adoption
- CSS needs modernization through strict mode and physics-based animations
- AI APIs should wait until use cases mature to avoid premature standardization
## ๐ฐ Newsletter
**Web Platform Wishlist: What Developers Really Want**
The web platform has evolved tremendously, but key gaps remain that force developers toward complex toolchains and third-party libraries. The biggest wins would come from better native form controls (following the customizable select model), broader support for device integration APIs, and eventual TypeScript integration.
For WordPress developers, these improvements could mean simpler admin interfaces, better mobile experiences, and reduced plugin complexity. Native reactive templates could replace some jQuery dependencies, while device APIs could enable innovative WooCommerce integrations.
**Key Takeaways:**
- Test the new customizable select for accessible dropdowns
- Monitor Bluetooth/Serial API support for device integrations
- Consider how TypeScript adoption affects WordPress development
**Resources:** [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/)
## โ
Action Items
#### DevRel
- Developer advocacy: Create demos showcasing new web primitives, track browser support metrics
- Education: Workshop series on modern web APIs, progressive enhancement strategies
- Developer experience: Documentation gaps for emerging APIs, SDK updates for new primitives
- Developer marketing: Content series on web platform evolution, practical migration guides
- Community management: Gather developer feedback on missing features, browser wishlist surveys
#### OSPO
- Policy & Governance: Web standards participation guidelines, browser compatibility policies
- License Compliance: Review new web API implementations, open source browser components
- Security Management: Device API security assessments, permission model reviews
- Software Inventory: Catalog web platform dependencies, track polyfill usage
- Developer Support: Browser compatibility tooling, feature detection training
- Community Engagement: W3C working group participation, standards body coordination
- Strategic Alignment: Web platform roadmap alignment with product goals
#### Community
- Maintainers: Browser API polyfill maintenance, feature detection libraries
- Contributors: Web standards specification contributions, implementation feedback
- Sponsors: Browser engine funding transparency, standards development support
- Ecosystem: Cross-browser testing coordination, progressive enhancement advocacy
#### WordPress
- Core: Native web API adoption timeline, jQuery dependency reduction strategy
- Core Performance: Web platform optimization opportunities, bundle size impact analysis
- Core AI: Local AI model integration planning, privacy-first implementation
- Mobile: Progressive Web App enhancements, device API integration opportunities
- Playground: New web feature demonstrations, compatibility testing environments
- Community: Developer education on modern web APIs, best practices documentation
- Design: Native form control styling strategies, accessibility compliance with new primitives
- Documentation: Web platform feature coverage, browser support matrices
## ๐งช Hypotheses
- Native web primitives will reduce JavaScript bundle sizes and improve accessibility compliance
- TypeScript integration will accelerate adoption of type-safe development practices
- Device APIs will enable new categories of web applications previously requiring native apps
- CSS modernization will reduce preprocessing tool dependency
### ๐ Methodology
- Browser compatibility tracking across primitive implementations
- Performance benchmarking of native vs library-based solutions
- Developer adoption surveys for new web platform features
- Accessibility testing with native primitives vs custom implementations
### โ Questions
- How will AI APIs balance local processing with cloud capabilities?
- What security models will enable safe device integration?
- Can CSS strict mode provide meaningful backwards compatibility breaks?
### ๐ฎ Future Research
- Impact of local AI models on web application architecture
- Performance characteristics of native reactive templates
- Developer productivity gains from reduced toolchain complexity
### ๐ก Implications
- Practice: Simplified development workflows, reduced dependency management
- Policy: Browser vendor coordination on feature priorities, standards development funding
- Security: Device access permission models, privacy implications of local AI
- Education: Updated curriculum for modern web development, framework-agnostic approaches
- Funding: Resource allocation for standards implementation, cross-browser compatibility testing
### ๐ง Learning Styles Assessment
Reading level estimate: 12th grade
#### ๐ Visual learners
- Present: None in audio format
- Improve: Browser compatibility charts, API architecture diagrams, timeline visualizations
#### ๐ Aural learners
- Present: Full podcast discussion available
- Improve: Timestamped audio clips for specific topics
#### ๐ฃ๏ธ Verbal learners
- Present: Clear explanations of technical concepts, real-world analogies
- Improve: Glossary of web standards terminology
#### ๐งฉ Kinesthetic learners
- Present: Code examples mentioned
- Improve: Interactive demos of new web APIs, hands-on tutorials
#### ๐ง Logical learners
- Present: Structured progression through categories, cause-effect relationships
- Improve: Decision trees for API selection, compatibility matrices
#### ๐งโ๐คโ๐ง Social learners
- Present: Discussion format, community feedback references
- Improve: Developer survey results, collaborative wishlist building
#### ๐งโโ๏ธ Solitary learners
- Present: Individual listening experience
- Improve: Self-assessment checklist, personal project planning templates
#### ๐ฟ Naturalistic learners
- Present: Evolution metaphors for web platform development
- Improve: Ecosystem thinking about browser diversity, sustainability considerations
### ๐ Accessibility Assessment
#### Screen reader semantics
- Present: Audio content with clear topic transitions
- Improve: Transcript with proper heading structure, landmark navigation
#### Keyboard navigation
- Present: Standard audio player controls
- Improve: Keyboard shortcuts for timestamp navigation
#### Contrast and readability
- Present: Audio format removes visual contrast concerns
- Improve: High-contrast transcript styling
#### Text resizing and reflow
- Present: N/A for audio content
- Improve: Responsive transcript layout
#### Media and captions
- Present: Full transcript provided
- Improve: Synchronized captions, downloadable transcript
#### Forms and interactions
- Present: Simple audio playback interface
- Improve: Accessible timestamp jumping, chapter navigation
### ๐ DEIB Assessment
#### Cultural breadth
- Present: North American perspective on web development
- Improve: Global browser usage patterns, international standards perspectives
#### Inclusive language
- Present: Technical discussion with some informal language
- Improve: More careful use of ableist language ("that sucks"), gender-neutral examples
#### Neurodiversity support
- Present: Clear topic segmentation, consistent format
- Improve: Content warnings for strong opinions, summary bullets
#### Representation
- Present: Two white male voices discussing technical topics
- Improve: Diverse guest perspectives, broader community input
#### Psychological safety
- Present: Respectful disagreement, acknowledgment of constraints
- Improve: More explicit validation of different viewpoints, beginner-friendly framing
### โ
Logical Validity
#### Strong reasoning
- Deductive strength: Browser engine diversity argument well-structured (32:30)
- Inductive strength: Good pattern recognition from past API failures (35:45)
- Causal reasoning: Clear connections between missing features and developer pain (03:45)
- Analogical strength: Effective comparison to jQuery adoption (40:20)
#### Fallacies
- False dichotomy: "Just do TypeScript" vs complex standards process - oversimplifies implementation challenges
- Appeal to popularity: "Everyone uses TypeScript" - doesn't address technical constraints
#### Tone of voice
- Overall tone: Enthusiastic but pragmatic, acknowledges idealism while respecting constraints
### ๐ก๏ธ DARVO Analysis
- Deny: No denial patterns present
- Attack: Mild criticism of slow standards processes but constructive
- Reverse victim/offender: No victim/offender dynamics
- Emotional cues and rhetoric: Passionate advocacy balanced with technical realism
## ๐ฏ Conclusion
The web platform has made tremendous progress but still lacks key primitives that force developers into complex toolchains. The most impactful near-term improvements would be broader support for existing APIs (Bluetooth, Serial) and completion of in-progress primitives (customizable select, combo box). Longer-term wins like TypeScript integration and AI APIs require careful consideration to avoid premature standardization mistakes.
Developers should engage with standards processes, test new features as they become available, and provide feedback to browser vendors. The balance between developer convenience and platform stability requires ongoing collaboration between the community and standards bodies.
## ๐งฑ Refactor Appendix
### ๐ Literature Split Pad
Purpose: Stage CEE units that become Literature notes.
Split level: H3
### [H1] Customizable select enables accessible custom dropdowns
> [!quote] [What's Missing From the Web Platform?](https://www.youtube.com/watch?v=bdw10C0wxiQ) by [[Syntax]] via [[YouTube]]. Published 2025-01-26. Accessed 2025-01-26.
> "Full control over all of the CSS, what it looks like, without having to give up accessibility and keyboard control"
Demonstrates proper approach to modern web primitives - functionality with customization.
[view highlight](https://youtu.be/bdw10C0wxiQ?t=323#H1) #web-primitives #accessibility ID:rw_001
### [H2] Cookie banner APIs needed for standardized consent
> [!quote] [What's Missing From the Web Platform?](https://www.youtube.com/watch?v=
---
## Full Transcript
[00:00] Welcome to syntax. Today we're talking<br>[00:02] about what is missing from the web<br>[00:04] platform. The the web platform,<br>[00:06] JavaScript, CSS, browsers, runtimes,<br>[00:10] syntax, APIs, all of that stuff. The<br>[00:12] last I don't know, maybe two or three<br>[00:14] years, we've gotten just this massive<br>[00:17] swath of of APIs that if if you walk up<br>[00:20] to most developers and say, "Hey, like<br>[00:22] like what do you need? What's missing?"<br>[00:24] Uh, a lot of people will go, hm, like,<br>[00:27] man, things are actually in a pretty<br>[00:29] good shape, but there's still a handful<br>[00:32] of things that are are missing from the<br>[00:35] web, from us being able to build the<br>[00:37] best apps possible. So, what we're going<br>[00:39] to do is we asked uh we asked on<br>[00:41] Twitter, me and Scott have a huge list<br>[00:43] ourselves, a big wish list. We're going<br>[00:45] to go through all of the different<br>[00:46] things that we wish we had from like<br>[00:48] primitives in the UI, different types of<br>[00:51] syntax we'd like to see added to to<br>[00:53] JavaScript, different APIs we'd like<br>[00:55] added, um, Bluetooth, serial, NFC, and<br>[00:59] then CSS, browsers, as well as, of<br>[01:02] course, we'll talk about the AI access,<br>[01:04] um, and what those APIs might even look<br>[01:06] like in the browser. My name is Wes<br>[01:08] Boss. I'm a developer from Canada. With<br>[01:09] me as always is Scott Tinsky. Scott's a<br>[01:12] little hurt today. You want to give us<br>[01:14] the lowdown?<br>[01:14] >> I don't, you know, I'm always hurty. I<br>[01:16] feel like uh I feel like every other<br>[01:17] episode we do, I got some something<br>[01:19] going on.<br>[01:20] >> Some ailment.<br>[01:21] >> Some ailment. Yeah. No, I had I had an<br>[01:23] elective surgery done. I couldn't<br>[01:26] breathe. I had a deviated septum, so<br>[01:28] they had to go in and uh uh let I'll<br>[01:32] save any of the gory details. They<br>[01:34] opened things up and fixed all that<br>[01:35] stuff right up. Yeah. So I can breathe.<br>[01:38] Like I I was snoring and stuff and it's<br>[01:40] not like sleep apnnea. It's just because<br>[01:42] I broke my nose or whatever happened.<br>[01:45] Recovery is not usually that bad. I was<br>[01:46] supposed to be good by like Saturday,<br>[01:49] Sunday, you know, after a surgery on<br>[01:51] Wednesday. And for the most part, my<br>[01:52] nose feels great, but I had some from<br>[01:55] the trachea they put in. My throat is<br>[01:57] all jacked. So, I got I got throat<br>[01:59] numbness going on. I'm on some drugs,<br>[02:01] but I I feel I feel ready to go. I I can<br>[02:04] talk. Yeah, let's go. I'm I'm excited<br>[02:06] about this actually because I was<br>[02:07] looking over your episode notes and I<br>[02:09] had a couple of wild ideas myself of<br>[02:11] things that are are not likely. But um<br>[02:13] >> yeah.<br>[02:14] >> Yeah. I No, I'm I'm I'm curious because<br>[02:16] the web uh does seem like there's just<br>[02:19] awesome stuff all the time these days<br>[02:21] and I'm excited for what could be, you<br>[02:25] know. Yeah. All right. So, the first one<br>[02:27] we have here is better primitives um in<br>[02:30] the DOM, right? So, what that means is<br>[02:32] that like we have select, you've got<br>[02:35] like radio checkboxes, you've got uh<br>[02:38] date picker, things like that. But<br>[02:41] typically, nobody uses those primitives<br>[02:45] aside from maybe input type of text and<br>[02:47] input type of email<br>[02:49] >> and and then past that everybody's npm<br>[02:51] installing something and and using a<br>[02:53] whole bunch of JavaScript. And that's<br>[02:54] because like the the primitives suck<br>[02:56] like the input type of date sucks,<br>[02:59] right? That's not a good experience to<br>[03:01] be able to do it. You can't style it how<br>[03:03] you want. You can't have full control<br>[03:04] over it. So, the the web platform knows<br>[03:07] about this and they've been working on<br>[03:08] it. And the the first big one we've had<br>[03:10] in terms of a very good primitive is the<br>[03:14] customizable select. And what that<br>[03:16] allows you to do now is you can now<br>[03:18] create a drop down with a select<br>[03:22] element, but you have full control over<br>[03:24] all of the CSS, what it looks like, all<br>[03:26] of that great stuff without having to<br>[03:28] give up any of the downsides of like<br>[03:30] accessibility and keyboard control,<br>[03:32] things like that. As well as like you<br>[03:33] don't have to install a whole bunch of<br>[03:35] stuff, which is the customizable select<br>[03:37] is absolutely awesome.<br>[03:38] >> Huge improvement.<br>[03:39] >> Like this is almost like like moving<br>[03:41] into like headless UI as well. meaning<br>[03:44] that like headless UI is the browser<br>[03:46] will bring the functionality or your<br>[03:48] JavaScript library brings the<br>[03:49] functionality and you bring the divs,<br>[03:51] you bring the CSS and you can sort of<br>[03:53] render it out and and add whatever divs<br>[03:55] or spans or anything you want inside of<br>[03:57] there. Now that's great. And now they're<br>[04:00] working on like multi select as well as<br>[04:02] combo box, you know, be able to like<br>[04:04] filter, find people, drop down, and then<br>[04:06] a lot of people are saying like<br>[04:09] >> what other inputs do we need? Like date<br>[04:11] picker is the big one as well. are<br>[04:13] working on combo box. I I didn't catch<br>[04:15] that.<br>[04:16] >> Yeah, combo box is is being worked on<br>[04:18] right now, which is<br>[04:19] >> huge because you you want to be able to<br>[04:21] like filter um and select multiples, you<br>[04:24] know, and and<br>[04:25] >> uh select the three tags from this list.<br>[04:27] You want to filter and select the items<br>[04:29] and have a list of the tags that you've<br>[04:30] selected. Yeah, I'm always looking at<br>[04:32] open UI for ideas for a lot of these<br>[04:34] things because it's like a a W3C<br>[04:38] community group where they're<br>[04:39] researching just UI elements and and<br>[04:41] what could be and it's a good place to<br>[04:44] to list through the kind of things that<br>[04:47] we we would need. But yeah, I I think<br>[04:50] that the first one you have here as date<br>[04:52] picker. Yeah, we have a date picker.<br>[04:54] It's questionable. I don't I I I use it<br>[04:59] when I'm lazy. I'll say that. I I'll use<br>[05:01] the date picker when I'm lazy, but it<br>[05:03] ultimately isn't as functional or as<br>[05:06] useful as other, you know, JavaScript<br>[05:09] based date pickers. So, to me, I I think<br>[05:11] that there's just like a major<br>[05:13] opportunity there to improve that. Um,<br>[05:15] make it stylable, too. Like, come on.<br>[05:18] Uh, all this stuff I don't feel I feel<br>[05:20] like nothing should be added that can't<br>[05:22] be stylable anymore.<br>[05:23] >> No, I don't think anything will ever be<br>[05:25] added to that can't be styled like any<br>[05:28] longer, right? because<br>[05:30] >> those days those days have passed. If<br>[05:32] you're if you're making any new<br>[05:34] primitives to to the browser,<br>[05:37] you got to be able to fully control it.<br>[05:39] You got to be able to render out the<br>[05:40] different parts of it. You can't just<br>[05:42] like write<br>[05:43] >> video tag and then and then that's it,<br>[05:46] right? You should be able to have access<br>[05:48] to all of the like a default UI. That's<br>[05:51] a lot of people were saying that as<br>[05:52] well. It's like have good default UI<br>[05:53] that that's nice, but also give us full<br>[05:56] control over these these. So, I don't<br>[05:58] think we'll ever see a date picker. And<br>[06:00] I'll tell you why. Because a date picker<br>[06:02] is so complex, right? You you have range<br>[06:05] inputs. You want to sometimes you want<br>[06:07] to be able to put things on the<br>[06:08] different days, like maybe you want to<br>[06:09] put prices for like a flight or Airbnb.<br>[06:12] Um, you want to be able to not allow<br>[06:14] selecting of of certain ones. It is just<br>[06:16] far too complex for that type of thing.<br>[06:19] So, I don't think we'll ever see a date<br>[06:22] picker. And in that case, if you have a<br>[06:24] complex date picker, that's something<br>[06:26] that you probably should still reach for<br>[06:28] an external UI for.<br>[06:31] >> Yeah. Yeah. I think that probably<br>[06:33] tracks. It is one of those things that<br>[06:34] feels like you need more often than not<br>[06:36] and then every single time you're you're<br>[06:37] doing it, it's just, you know, uh<br>[06:40] >> Yeah.<br>[06:40] >> Yeah. Yeah.<br>[06:42] >> There's good ones out there. I think the<br>[06:43] idea with a lot of these primitives that<br>[06:46] we're getting, you know, like<br>[06:47] customizable select, accordians, pop<br>[06:49] over, anchor, a lot of these primitives<br>[06:52] are not meant to be like you'll just use<br>[06:54] this thing straight. It's like here is a<br>[06:57] primitive which you can then customize<br>[06:59] yourself or<br>[07:01] >> like shad CN is going to use these<br>[07:03] primitives in there and that means<br>[07:05] they're going to need a lot less<br>[07:07] JavaScript in order to make it work and<br>[07:09] you can simply just pop it in and you<br>[07:11] can you could just slap a select in<br>[07:13] there and then you can import some<br>[07:15] external CSS library and the thing will<br>[07:17] start looking pretty good.<br>[07:18] >> Yeah. Uh I have tabs on here. Uh, like,<br>[07:22] bro, tabs have been like the most<br>[07:25] common, one of the most common UI<br>[07:27] elements of all time. And how do we not<br>[07:30] have a tab HTML system? I mean, we have<br>[07:33] accordionss, details, and stuff like<br>[07:34] that. They could do anything with tabs.<br>[07:37] I I I feel like this is just long<br>[07:40] overdue, personally.<br>[07:41] >> Can't you do that with an accordion or<br>[07:44] like like a details?<br>[07:46] >> I mean, no. Not Not to the degree that<br>[07:48] you would want to. Like the thing is is<br>[07:50] that you you'd want it to just function<br>[07:51] like tabs, like how how they how they<br>[07:54] function. And<br>[07:55] >> you don't want have to hack it.<br>[07:56] >> You don't want to have to hack it. And<br>[07:57] and so for me, I I feel like this is<br>[08:00] >> the obvious one. But<br>[08:01] >> uh another one for me is like a file<br>[08:03] upload, at least being able to style it.<br>[08:06] And if it's like a like an image, you<br>[08:07] could preview it. Um anytime you want to<br>[08:09] like preview an image that somebody has<br>[08:11] uploaded, you got to you got to get the<br>[08:13] file reader API out. You got to read<br>[08:15] that thing into like like a binary blob.<br>[08:17] Um, and then you got to paint that<br>[08:18] thing. You you either then convert that<br>[08:21] blob into like a URL which you can then<br>[08:23] display as like an image or you can<br>[08:25] paint that thing to a canvas and then<br>[08:27] you can resize it based off of that. But<br>[08:30] so many times I've just wanted a simple<br>[08:32] file upload and then I want like like a<br>[08:34] half decent being able to style it. Um,<br>[08:38] >> the the default styling for the default<br>[08:40] file upload is one of the worst things<br>[08:44] on the web.<br>[08:45] It's it's I I've made so many drop zone<br>[08:48] components for dropping files and stuff<br>[08:50] like that. And it's like yeah, I always<br>[08:52] hate having to to like uh do that<br>[08:55] without an actual JavaScript based<br>[08:57] component. I actually do have something<br>[08:59] that is just a CSS version of that in in<br>[09:01] my graffiti UI library. Uh that is like<br>[09:04] a drop zone nicely styled, but it<br>[09:06] doesn't have the previews and stuff like<br>[09:07] that. So I can totally see one that I<br>[09:09] have here is toggles. Yeah, we have a<br>[09:11] checkbox and yes, Safari does have<br>[09:15] toggles. Just add it to Chrome, add it<br>[09:18] to Firefox, like uh do it already<br>[09:21] because the toggle is such a ubiquitous<br>[09:26] standard UI element at this point. The<br>[09:29] fact that Safari is the only one that<br>[09:32] has added it as an option uh to be<br>[09:34] default styled and stuff, just do it.<br>[09:37] Make it stylable toggles. Come on.<br>[09:40] >> Yeah, this is is so key because like<br>[09:42] like what are you going to do otherwise?<br>[09:43] You're going to make it not accessible,<br>[09:45] right? You're going to put a whole bunch<br>[09:46] of divs over top of the thing. You're<br>[09:48] going to hide the actual checkbox and um<br>[09:51] you got to spend a whole bunch of extra<br>[09:53] work trying to get that thing to be<br>[09:55] accessible. Um or you're going to<br>[09:57] install some third party component. Um<br>[09:59] toggle J. Such a a good primitive that<br>[10:01] we should we we need to have, right? We<br>[10:03] have progress. We have like the progress<br>[10:06] bar.<br>[10:07] >> That's you're almost there, right? Yeah.<br>[10:10] Yeah. All of these ones. And again, like<br>[10:12] Safari did it. So, uh it's not like<br>[10:14] nobody's doing it and it that that<br>[10:16] should be enough of a a good start. I<br>[10:18] don't know. Not adding this just feels<br>[10:21] weird to me at this point.<br>[10:23] >> I also have native drag and drop that<br>[10:25] doesn't suck. You know, the the drag and<br>[10:27] drop just kind of aesthetic that like<br>[10:29] ghosts it out in the way that native<br>[10:32] drag and drop works. like it's another<br>[10:35] one where it just feels halfass in terms<br>[10:37] of the implementation not matching how<br>[10:40] people actually want to use drag and<br>[10:42] drop in real life. So, you know, it's<br>[10:45] fine.<br>[10:45] >> That's never going to happen.<br>[10:46] >> It's never going to happen.<br>[10:48] >> If you take a look at Atlassian's<br>[10:50] pragmatic drag and drop, we had the<br>[10:52] developer on the show<br>[10:53] >> that drag and drop is such a can of<br>[10:56] worms that I think they did the right<br>[10:57] thing in that they they gave us the the<br>[10:59] correct browser primitives for dragable,<br>[11:02] droppable. They gave us the correct<br>[11:04] primitives for like drop zone where you<br>[11:06] are allowed to drop things. They gave us<br>[11:08] all of the JavaScript events for that<br>[11:10] type of thing. But there's so many<br>[11:12] things like what happens when you start<br>[11:13] dragging it? Does it leave the old thing<br>[11:15] behind? Yeah.<br>[11:16] >> And and then ghost it out or does it<br>[11:18] immediately like move up? Like if you're<br>[11:19] dragging an item from a list, should it<br>[11:21] immediately take it out of there? And<br>[11:22] what happens when you drop it? Does it<br>[11:23] make a copy of it? What? There's so much<br>[11:26] to it that I think that this is<br>[11:29] absolutely one of those things where you<br>[11:30] need to reach for a library. And I don't<br>[11:32] think there's anything wrong with that.<br>[11:33] >> I feel like you're going to hear a fully<br>[11:37] version version of idealistic Scott<br>[11:39] talking in this episode. I I I feel like<br>[11:42] there's a lot of people are going to be<br>[11:43] like, "Yeah, this doesn't work. This<br>[11:44] doesn't work." And I will admit to my<br>[11:48] ideas here. A lot of the ideas in here<br>[11:50] being just fully idealist, not thinking<br>[11:53] about edge cases, not thinking about<br>[11:56] reality. I'm fully living in my I just<br>[11:59] want this uh mode in this episode. But I<br>[12:01] I'll say that<br>[12:03] >> um in terms of syntax for the language,<br>[12:05] a lot of people said they want type<br>[12:07] annotations, which is they basically<br>[12:09] just want Typescript in JavaScript. Um<br>[12:12] and there are kind of like two movements<br>[12:15] for that already, right? There is a<br>[12:17] proposal for something called types as<br>[12:19] comments, meaning that you would be able<br>[12:21] to put your your TypeScript code in the<br>[12:25] browser um but the browser would simply<br>[12:27] just ignore it. meaning that it would it<br>[12:29] would treat the syntax of like the added<br>[12:32] TypeScript syntax. It would just treat<br>[12:34] that as a comment, meaning it would then<br>[12:36] ignore it. Um, so that's being worked<br>[12:38] on. Whether we'll ever get that or not<br>[12:40] um remains to be seen, but it seems to<br>[12:42] be that the the browser will not care<br>[12:45] about that or not will not use any of<br>[12:47] that that information. Uh what do you<br>[12:49] think? Should should TypeScript be added<br>[12:51] to it? Like it's in Node already, right?<br>[12:53] You can run.ts files in Node with no<br>[12:56] problem. install nothing and it just<br>[12:58] works.<br>[12:59] >> I feel like we are so far be belong the<br>[13:02] point of where Typescript was a question<br>[13:05] mark. I have not written non-typescript<br>[13:08] in just about I don't know when the last<br>[13:11] time I wrote JavaScript was<br>[13:12] >> seven eight years.<br>[13:14] >> Oh, it it has been it's been so long<br>[13:16] since I've made ajs file. I it's it it's<br>[13:20] actually wild because there was a point<br>[13:22] during this I mean this podcast has been<br>[13:23] around a long enough that uh typescript<br>[13:25] was uh competing with what was it flow<br>[13:27] and with reason uh there I mean there<br>[13:29] was there was no like guarantee that<br>[13:31] typescript is going to become the thing<br>[13:33] but typescript is not just the thing to<br>[13:35] me typescript is javascript at this<br>[13:37] point I I don't I don't see it any other<br>[13:39] way and I would be shocked if if people<br>[13:41] are out there writing javascript today<br>[13:42] like straight up shocked um especially<br>[13:44] because now it's so much easier to just<br>[13:46] run typescript whether you have bun or<br>[13:48] anything here.<br>[13:49] >> Yeah.<br>[13:50] >> So, like at this point, just do it.<br>[13:53] Yeah. It's got to be it.<br>[13:55] >> Yeah.<br>[13:55] >> This is one of those things where I I<br>[13:57] don't mind them taking their time<br>[13:59] because it's not that big of a pain in<br>[14:01] my butt to run TypeScript in the<br>[14:03] browser. The the amount of times I have<br>[14:05] to like, oh, I can't copy paste this<br>[14:07] into my like terminal. Maybe that's the<br>[14:09] thing is I just want Chrome DevTools to<br>[14:11] be able to strip it out for me when I<br>[14:13] sometimes paste TypeScript into that.<br>[14:15] But<br>[14:15] >> there is a world where Typescript is not<br>[14:18] it and type JavaScript looks like<br>[14:20] something else. So taking a look at that<br>[14:23] whole landscape, not necessarily like<br>[14:24] what it does cuz this this is simply<br>[14:26] just syntax, but um looking at<br>[14:30] how how what are the downsides to to<br>[14:33] TypeScript and and maybe we could make a<br>[14:36] some improved syntax and and allow that.<br>[14:39] >> Yeah. Why are we thinking about<br>[14:40] downsides? Just do it.<br>[14:43] No, that's the thing is that if you<br>[14:46] everybody said that with jQuery as well,<br>[14:48] you know, just just add jQuery to the<br>[14:50] browser.<br>[14:51] >> And they took their time and they<br>[14:53] figured out like<br>[14:54] >> like what actually works for the<br>[14:57] long-term health of the web. And I think<br>[14:59] that is fine.<br>[15:00] >> This is why you don't let me on any of<br>[15:01] these committees. I am I'm way too<br>[15:03] yellow at I'm just like yeah, I'm too<br>[15:06] far gone in that direction on<br>[15:07] everything.<br>[15:08] >> Type operator is one that I would<br>[15:10] absolutely love to see. So in<br>[15:13] JavaScript, if you've got like like<br>[15:14] imagine you have like a whole bunch of<br>[15:16] promises that are are chained um then<br>[15:18] then then then right like that's not the<br>[15:20] pipe operator but that allows you to<br>[15:22] read your code sort of like top to<br>[15:24] bottom or or sync a weight, right? But<br>[15:26] sometimes you're you're not dealing with<br>[15:28] with code that looks like that and you<br>[15:30] simply just want to take the output of<br>[15:32] something and then pipe that into<br>[15:34] something else and and right now what<br>[15:35] you have to do is you have to wrap those<br>[15:37] functions. So you you end up with this<br>[15:39] like sort of bloom and onion of<br>[15:40] functions where if you want to know what<br>[15:42] it does, you go to the middle and then<br>[15:45] you start like like stepping it back<br>[15:48] until you you reach the outsides. A pipe<br>[15:51] operator would be so nice to be able to<br>[15:53] just like run a function, take the<br>[15:55] output of that and immediately pipe that<br>[15:56] into the next function. And it's been a<br>[15:58] proposal for many, many years. I'm not<br>[16:00] sure we'll ever get it, but I would love<br>[16:01] it.<br>[16:02] >> Yeah, it it is one of those ones that<br>[16:04] just been hanging around. It does feel<br>[16:06] like some of these things just sit in<br>[16:08] limbo forever and I I mean again I the<br>[16:12] the entire like process of that needs to<br>[16:14] take time for the reasons we've already<br>[16:16] outlined. So yeah it's I it's something<br>[16:19] I would absolutely take. Um<br>[16:20] >> it's stage two and was last updated 3<br>[16:23] years ago.<br>[16:24] >> Oh okay cool.<br>[16:25] >> So<br>[16:26] >> wow<br>[16:27] >> not looking great.<br>[16:28] >> Yeah<br>[16:28] >> not looking great.<br>[16:30] >> Yeah just in limbo. Yeah.<br>[16:32] >> Next one is APIs. Um, these are APIs<br>[16:35] that we want to be added to the web<br>[16:37] platform. Um, one API, this is not<br>[16:39] something I want, but something that was<br>[16:41] really cool is I I just started up<br>[16:43] Riverside here with with Scott and he's<br>[16:45] like, "Yeah, your your video is a little<br>[16:46] choppy." And then Riverside popped up<br>[16:48] this little thing that says, "Hey, plug<br>[16:50] your computer in and you'll get better<br>[16:53] you'll get better PF, right?" Like<br>[16:55] browsers will sometimes throttle things<br>[16:57] in the browsers if you're on battery.<br>[17:00] And as soon as I plugged it in to power,<br>[17:03] that little thing went away. And that's<br>[17:04] the navigator.get battery API. And<br>[17:06] that's a<br>[17:07] >> beautiful, beautiful use case of that<br>[17:10] API. And those are the types of things<br>[17:11] where you we used to complain that like<br>[17:14] native had a lot of these APIs. And now<br>[17:16] we that's just in a website that works<br>[17:18] great.<br>[17:19] >> Yeah.<br>[17:19] >> But<br>[17:20] >> things we actually want, please. Oh,<br>[17:23] please. Oh, please give me an API for<br>[17:25] doing cookie banners. I am so sick of<br>[17:28] the web. You visit any website, you're<br>[17:30] blasted with a cookie banner and like<br>[17:33] they never remember what you want, you<br>[17:35] know, like accept all cookies or<br>[17:37] whatever and you got to sit there and<br>[17:38] think about what do I want? I don't<br>[17:40] care. Get it out of my face. I know that<br>[17:42] there's browser like extensions you can<br>[17:45] like you can ignore them and all that.<br>[17:46] Yeah,<br>[17:47] >> we need a set of APIs for opting in to<br>[17:52] cookies, opting consent integration,<br>[17:54] what people have consented to, saving<br>[17:57] that in the actual browser. We need<br>[17:59] those APIs like yesterday because the<br>[18:02] web is a mess with cookie banners.<br>[18:04] >> Yeah. And so many of the cookie banners<br>[18:06] are coded poorly or they feel like they<br>[18:09] they they're like dark patterns all over<br>[18:11] the place. It's like either Yes. Uh I<br>[18:14] want the browser to accept all my<br>[18:16] cookies or no this is dangerous. You<br>[18:18] don't accept it. Like the so many people<br>[18:20] are like the the way that they present<br>[18:22] these banners to you are not nice. I'll<br>[18:24] just say that they're not nice for the<br>[18:26] user in in in many ways. So yeah,<br>[18:28] standardizing it I I feel like at this<br>[18:30] point needs to have happened.<br>[18:32] >> You know what's a nice website that<br>[18:33] doesn't absolutely blast you in the face<br>[18:35] with cookie banners?<br>[18:36] >> Ooh, I got a feeling right. Yeah. Ooh.<br>[18:39] Yeah.<br>[18:40] >> This sentry at centry.io/sax<br>[18:43] is they got rid of all of their cookies<br>[18:46] on their website and they had like a<br>[18:48] massive project to go through. Like<br>[18:50] something as little as embedding a<br>[18:52] YouTube video requires a cookie banner.<br>[18:55] It doesn't mean that you have to get rid<br>[18:56] of all cookies, right? like like a login<br>[18:58] cookie, a recession cookie, those are<br>[19:00] fine, but like a cookie that tracks you<br>[19:01] across the web. Those you have to<br>[19:04] actually opt into. So, Sentry went on<br>[19:06] this huge thing to remove them from<br>[19:08] their platform entirely, which was<br>[19:11] absolutely awesome. So, you you should<br>[19:14] probably use Sentry for uh for your<br>[19:16] website, for your bugs, for fixing your<br>[19:18] code. They got this AI thing called Seir<br>[19:20] that will uh take a look at your bugs<br>[19:22] and automatically fix them and send you<br>[19:24] a pull request. It's fantastic. syntax<br>[19:26] centry.io/sintax.<br>[19:28] >> Yeah. Did you know, Wes, that like<br>[19:30] there's a billion companies that use<br>[19:32] Sentry? Like Claude, uh, Anthropic uses<br>[19:35] uses Sentry. Um, Disney Plus uses<br>[19:39] Sentry. There there's just like some of<br>[19:41] the Pelon uses Sentry. Every time I'm on<br>[19:44] my my dang Pelon, I think about that or<br>[19:46] Tonal. So, uh, shout out to all the<br>[19:49] companies using Sentry out there in the<br>[19:51] world. Um, next one I have here, this is<br>[19:54] uh I I don't know if this will be<br>[19:55] controversial, but identity. Oh, there's<br>[19:58] so many I don't I'm going to say I don't<br>[20:00] know how this would work. Technical<br>[20:01] details seem like a nightmare for this.<br>[20:03] We log in. Most of us are logged into<br>[20:05] our browser like it should be easy<br>[20:07] enough to use that state of login<br>[20:09] whether it is via pass key or whatever<br>[20:11] to use that login state on an app. Now,<br>[20:15] I get it. A lot of people are going to<br>[20:16] hate this idea because you want to have<br>[20:19] the individual app have the login and<br>[20:21] everything like that, but it does feel<br>[20:23] like there has to be some sort of way to<br>[20:27] use identity easy on your site and not<br>[20:31] have to reinvent the the off wheel on<br>[20:33] every single website.<br>[20:35] >> Just it just feels like there has to be<br>[20:36] some way to do that.<br>[20:38] >> Yeah. Some sort of like Pasy was<br>[20:42] >> not entirely that, right? But pass key<br>[20:44] was an attempt to make the pain of<br>[20:46] logging in<br>[20:48] >> much easier. And I love it when it<br>[20:51] works, man. Log into GitHub with a pass<br>[20:54] key.<br>[20:55] >> Absolutely love it. Right. But I I think<br>[20:57] that at the end of the day, this is<br>[20:59] going to be a a phone in your pocket<br>[21:01] thing. Um people are going to be able to<br>[21:04] sign in with the phone in their pocket<br>[21:07] >> or scan your retina or something like<br>[21:09] that. Yeah. Like why can't like like<br>[21:10] Face ID be the thing? I guess you're<br>[21:13] almost there with like sign in with<br>[21:15] Apple, right?<br>[21:15] >> You're Yeah, sure. But it's still at the<br>[21:18] end of the day what it's doing is it's<br>[21:19] creating a record in the database with<br>[21:21] the email address and whatever and then<br>[21:24] that is control like I don't know. Yeah,<br>[21:27] >> I don't know. I again idealistic Scott<br>[21:29] says, "Hey, we're reinventing the wheel<br>[21:31] so much here." Um yeah,<br>[21:33] >> one thing I have wanted for the longest<br>[21:35] time and I've actually written this<br>[21:37] function myself is get element by text.<br>[21:40] meaning that like you can select an<br>[21:41] element based on its ids or attributes<br>[21:43] or or based on the children it has or if<br>[21:46] it has a specific thing but you cannot<br>[21:49] select an element based on the text that<br>[21:51] is inside of it either in JavaScript or<br>[21:54] in in CSS. Um and I would love love love<br>[21:58] especially with a lot of these agentic<br>[22:01] browser things you know MCP server with<br>[22:03] playright you can select an element by<br>[22:06] text. I would love a native API for<br>[22:09] that. I don't know if we'll ever get it.<br>[22:11] Um, it was doable with XPath. Before we<br>[22:13] had<br>[22:14] >> not before we had document.query<br>[22:16] selector all not before we had document<br>[22:19] getelement by ID. We had this thing<br>[22:20] called XPath which was a way for you to<br>[22:23] select elements based on their XML<br>[22:26] indentation. And there was something in<br>[22:27] there that would allow you to select<br>[22:29] based on the actual text of the element.<br>[22:33] And that would be sick.<br>[22:35] >> Yeah. Did you ever think that we had uh<br>[22:37] X Path the same time we had XOXO? Do you<br>[22:40] remember X?<br>[22:41] >> What's XOC?<br>[22:43] >> He was like a a a 2000s era professional<br>[22:46] wrestler.<br>[22:48] >> Oh man.<br>[22:53] H<br>[22:54] >> Oh, I just Googled him. He's doing the<br>[22:56] sucket. You man.<br>[22:57] >> Yes, he he was he was the guy. He was<br>[22:59] the sucket guy. He was the guy. Oh,<br>[23:02] yeah. Yeah. I mean, he might not have<br>[23:04] been the only I mean, he's definitely<br>[23:05] not the only guy, but he was like he was<br>[23:08] Mr. Suck it, I think, for sure.<br>[23:10] >> I did not watch wrestling growing up. I<br>[23:13] had no idea, but we me and my friends<br>[23:14] would walk around school being like,<br>[23:16] "Suck it." And we had no idea what that<br>[23:18] meant, you know? Just just saying.<br>[23:21] Nobody knew what they were doing. Now<br>[23:22] I'm older. I'm like, "Oh, I probably<br>[23:24] shouldn't have been saying that."<br>[23:26] >> Oh, yeah. There was a time I think when<br>[23:27] I was in like ninth grade where I I<br>[23:29] don't think you could have not watched<br>[23:30] wrestling for that one year.<br>[23:32] >> I' I don't I've maybe watched like one<br>[23:35] or two wrestling and then what's the one<br>[23:37] where everyone beats the [ย __ย ] out of<br>[23:38] each other but it's real.<br>[23:41] >> Oh, I don't know.<br>[23:42] >> No, it's like it's huge right now.<br>[23:44] >> Backyard wrestling or<br>[23:45] >> Dana White. Um<br>[23:46] >> Oh. Oh, UFC. Oh, okay.<br>[23:48] >> Yeah, UFC. I went to a UFC party once.<br>[23:50] Holy hell. Not for me. That's awful to<br>[23:53] watch.<br>[23:53] >> I watch a lot. Well, I don't lately, but<br>[23:56] I did watch a lot of uh MMA. Uh to the<br>[23:58] point where I was watching like minor<br>[24:01] league circuit stuff and stuff. Um but<br>[24:04] yeah, no, I I I like combat sports,<br>[24:06] that's for sure. I don't watch uh<br>[24:08] professional wrestling, though.<br>[24:09] >> All right, this is probably high on my<br>[24:11] list with browser primitives, and this<br>[24:13] is just native reactive templates. Um,<br>[24:17] meaning that you have a variable, you<br>[24:19] put that variable in the DOM somewhere<br>[24:20] and when that variable updates, so does<br>[24:23] the DOM, right? Some sort of templating,<br>[24:26] some sort of reactive variables, whether<br>[24:29] that is with um like signals or whatever<br>[24:33] they choose to do. I would absolutely<br>[24:35] love something because I myself if I'm<br>[24:38] coding up something very quickly in in<br>[24:40] vanilla JavaScript, I'll always just<br>[24:42] make some sort of like rerender string<br>[24:44] where you watch the variable to change.<br>[24:46] It would be great to have that as a a<br>[24:47] browser primitive.<br>[24:49] >> Yeah, here's another one. Uh sync<br>[24:51] protocol. Wouldn't it be great if you<br>[24:53] had some kind of uh CRDT sync setup that<br>[24:56] you could just access like fetch? Now<br>[24:58] granted, there's got to be a server<br>[25:01] involved, so you'd have to have some<br>[25:02] sort of a sync server. Um, but like the<br>[25:06] again, this is never going to happen,<br>[25:07] but like a primitive for accessing sync<br>[25:11] with a CRDT or even creating that server<br>[25:15] >> like I mean we have websockets, right?<br>[25:16] >> That's what I'm saying. some something<br>[25:18] along a protocol like websockets or even<br>[25:21] even how about this in terms of the same<br>[25:23] world of a data or a local first or<br>[25:26] whatever just databases that don't don't<br>[25:29] suck built into the browser<br>[25:32] because what do we have we've got like<br>[25:34] local storage not really database got<br>[25:36] more of like a key value string store<br>[25:38] you've got index DB right<br>[25:40] >> um there's implementations of SQLite<br>[25:44] >> but you want something that's that's a<br>[25:46] little better Yeah. Yeah. Something<br>[25:48] along lines what they're doing with like<br>[25:49] Postgress in in Wom, you know.<br>[25:52] >> Yeah. Virtualization that doesn't suck.<br>[25:54] What do you mean by this?<br>[25:55] >> Yeah. Like virtualized lists, you know,<br>[25:58] all all the virtualized list solutions,<br>[26:00] especially in like react list or react<br>[26:03] virtualize or whatever that was.<br>[26:04] Virtualization for people don't know is<br>[26:06] that it renders you could you could have<br>[26:08] a wrapper that like if you have a list<br>[26:11] of 100 items and that wrapper is only<br>[26:13] like five items visible. the additional<br>[26:16] 100 items or 95 items are not going to<br>[26:19] render. Uh basically saving your browser<br>[26:22] from having to do that work. The problem<br>[26:24] is is a lot of these virtualization<br>[26:25] libraries then break search and then if<br>[26:28] you do command F on the page, it doesn't<br>[26:30] find the item because it's not being<br>[26:31] loaded. So like<br>[26:33] >> uh something that uh controls rendering<br>[26:36] in that way that still doesn't break<br>[26:38] command F. Um those types of things.<br>[26:41] >> Content visibility in CSS is supposed to<br>[26:44] do this. Um, so the it's a controls<br>[26:47] whether an element renders its contents<br>[26:49] at all along with forcing a strong set<br>[26:51] of containment allowing agents to<br>[26:53] potentially omit large swatches of<br>[26:56] layout and rendering work until it<br>[26:57] becomes needed. Meaning that like you<br>[26:59] have a list of 20,000 list items. Um,<br>[27:03] you can put a content visibility<br>[27:06] property on there and then the browser<br>[27:08] will defer rendering it until it thinks<br>[27:10] it it actually needs it. This is one of<br>[27:12] those things where I don't think we need<br>[27:14] APIs for this. Um, I just think that<br>[27:16] like like I've had I've had problems<br>[27:19] with content visibility where I took it<br>[27:20] off and my performance drastically<br>[27:22] increased. It was way better, right? I<br>[27:24] think that browsers just need to sort<br>[27:26] this out and then we can just we can use<br>[27:28] as much HTML and<br>[27:29] >> and you figure it out, right? You're the<br>[27:31] rendering agent.<br>[27:32] >> Yeah. Yeah. I don't why why am I figur<br>[27:35] you you should know if something is on<br>[27:36] the screen or not and and control how<br>[27:38] that works and<br>[27:39] >> Yeah, for sure. Um, Olly Williams, hype<br>[27:42] dev on Twitter says, "We want put,<br>[27:44] patch, and delete on form." So form<br>[27:46] elements in the browser can only do two<br>[27:49] things, get or post, right? And if<br>[27:52] you're building an API, you should be<br>[27:55] using the rest of those, which is put,<br>[27:57] patch, delete. I think there's a couple<br>[27:59] other ones, options. That's a stumped<br>[28:01] question for later. Uh, but if you're<br>[28:04] trying to build your app in a way that<br>[28:07] will ideally work without JavaScript or<br>[28:10] you're trying to build on like web<br>[28:11] standards and then using JavaScript to<br>[28:13] like progressively enhance, if you're<br>[28:16] updating an item and you want to like<br>[28:18] use a patch or like a put or if you're<br>[28:21] deleting something and you want to<br>[28:22] simply just have a button that deletes<br>[28:24] that item via a form submission,<br>[28:27] >> you're kind of out out of luck. You got<br>[28:28] to like you got to put that into a a<br>[28:30] post, right? and then you got to put it<br>[28:32] on a different endpoint of like delete<br>[28:34] item. So that would be that would be<br>[28:36] pretty nice as well.<br>[28:38] >> Yeah, I'll take that. I never understood<br>[28:39] why we have those verbs and they're not<br>[28:41] just all there.<br>[28:42] >> That's a great question. Like why why<br>[28:44] did they invent those as the browser or<br>[28:47] not? They didn't invent it as a browser.<br>[28:49] They built it as part of like networking<br>[28:50] stack.<br>[28:51] >> Yeah,<br>[28:51] >> but why did we never implement those in<br>[28:54] it? Um, another one from Carl. Um, Snorl<br>[28:58] TV says, "Text metrics get bounding box<br>[29:01] of individual characters.<br>[29:04] Being able to measure the actual size of<br>[29:07] it and we the textbox trim has been a<br>[29:12] fantastic addition to CSS. mean that if<br>[29:14] you've ever had that weird thing where<br>[29:16] your your your text is a certain height,<br>[29:19] but like the text is at the bottom of<br>[29:21] like the line height and it's not<br>[29:22] centered. Textbox trim takes care of so<br>[29:25] many of those use cases. Um, which<br>[29:27] honestly is probably better than having<br>[29:29] to measure characters. But there still<br>[29:31] are, especially in like an animation<br>[29:32] world, there's still lots of cases where<br>[29:34] you would want to measure how big a<br>[29:37] letter is. And right now, your only<br>[29:39] option is sparan wrap. Wrap every single<br>[29:41] character in a span.<br>[29:43] >> Yeah. Hell yeah. Um, for low lower level<br>[29:46] of connections, you have like Bluetooth<br>[29:49] listed here. Am I wrong? I thought there<br>[29:51] was a Bluetooth API. I I I haven't used<br>[29:53] this, by the way. Yeah.<br>[29:55] >> So, there is a Bluetooth and a web<br>[29:58] serial API which allows you to talk<br>[30:01] directly over obviously Bluetooth or<br>[30:04] USB. Um, and this is super handy for<br>[30:07] things like uh programming<br>[30:08] microcontrollers or being able to update<br>[30:11] the firmware on your headphones without<br>[30:13] having to download like some sketchy<br>[30:16] like install thing just to simply update<br>[30:18] the firmware, right? Um, and that's why<br>[30:20] a lot a lot of devices if you want to<br>[30:22] update the firmware, you you don't<br>[30:24] download an app, you don't visit a<br>[30:26] website, you you get the iPhone app,<br>[30:27] right? And the iPhone app is going to be<br>[30:29] able to do it. So there are Bluetooth<br>[30:31] and web serial fantastic APIs, but they<br>[30:35] have not made their way into standards.<br>[30:37] They've not made their way. Safari says<br>[30:39] no way. Firefox hasn't implemented it.<br>[30:41] So um that would be really nice to have<br>[30:45] control over those things. Sockets, you<br>[30:48] we have web sockets, right? And this is<br>[30:50] a security thing as well. you're not<br>[30:52] going to be able to access sockets<br>[30:54] directly. But, uh, when I was driving my<br>[30:57] Roomba with JavaScript and when I was<br>[30:59] flying the drone with JavaScript, both<br>[31:01] of those things communicate from the<br>[31:05] computer to the the wireless device over<br>[31:07] a socket. So, you open up a socket and<br>[31:09] then you just have these these lanes<br>[31:11] where you can send data back and forth.<br>[31:13] And in order to actually access that<br>[31:16] data in the in the browser, you need to<br>[31:18] create a server that runs on your<br>[31:20] computer. And you got to hot potato the<br>[31:22] data. So the data goes from the drone to<br>[31:24] a node server and then the node server<br>[31:26] sends it over a web socket so you can<br>[31:27] actually access it in the browser. NFC,<br>[31:30] RFID, again that those things would be<br>[31:34] fantastic in the browser, especially if<br>[31:35] you're trying to you're making like a<br>[31:37] progressive web app where you want to be<br>[31:39] able to<br>[31:40] >> scan something with RFID.<br>[31:42] >> Yeah, dude. NFC is so underrated in<br>[31:45] general. Yeah,<br>[31:46] >> it's it's really good. Look at this.<br>[31:47] I've got I've got like a a Yoto that<br>[31:51] I've been been hacking right here. And<br>[31:52] here's the the NFC card.<br>[31:55] >> And I've got this little<br>[31:56] >> um this is called a Prox Mark III little<br>[31:58] NFC RFID writer.<br>[32:00] >> Oh, cool.<br>[32:01] >> I've been using that for my Bamboo Lab.<br>[32:04] The little things that go on the spools<br>[32:06] of filament<br>[32:07] >> so you can write them. It's It's a wild<br>[32:10] world. Very fun. I'm gonna say Wes, uh,<br>[32:13] one thing I love about you, you always<br>[32:15] got some [ย __ย ] on your desk that's going<br>[32:17] on. That's That's cool<br>[32:18] >> a lot. Can I Can we play What are the<br>[32:20] most random things you can find on your<br>[32:22] desk?<br>[32:22] >> Yeah.<br>[32:23] >> Um, USB UART.<br>[32:26] >> Um, so this is connecting<br>[32:28] >> serial. My sister got like a some broken<br>[32:31] thing and I I soldered to it and I could<br>[32:33] see the boot logs of that device. What<br>[32:36] else I got here? Some glue. I have a a<br>[32:39] terminal screen.<br>[32:41] I love this thing.<br>[32:42] >> Oh, that's cool.<br>[32:43] >> Yes. Do you know the terminal screen can<br>[32:45] last for months because it doesn't<br>[32:47] update the data on it? It doesn't hit<br>[32:50] the web very often. So, it has a set<br>[32:53] number of screens that it changes<br>[32:55] between<br>[32:56] >> an e- in display for our audio<br>[32:57] listeners.<br>[32:58] >> Oh, yes. It has it's an e- in display<br>[33:00] and you set up essentially scenes and<br>[33:03] those scenes uh change every 15, 20<br>[33:05] minutes or whatever. But you can also<br>[33:08] say, "Hey, don't hit the web to update<br>[33:10] your data unless it's every like 4 hours<br>[33:12] or even every day or whatever." And<br>[33:15] therefore, because of that, just on this<br>[33:18] little battery in here, the screen just<br>[33:21] lasts forever. I mean, it's like got my<br>[33:24] calendar, all kinds of stuff on here.<br>[33:26] Just<br>[33:27] >> cycling through everything. Yeah. Love<br>[33:28] it.<br>[33:29] >> Love that. For some reason, I have an<br>[33:31] iPhone 3 um cuz one of my kids had it<br>[33:34] the other day and I was like, "Hey,<br>[33:36] that's history. Don't. Where did you<br>[33:37] find that? They probably went through my<br>[33:38] boxes and took it out. Salad spoon. I<br>[33:41] was I was writing or making some bins<br>[33:44] for my 3D printing. So, I was measuring<br>[33:46] the spoon and I never brought that back<br>[33:47] up.<br>[33:48] >> What? You got a blower?<br>[33:49] >> A Wolf Box blower. It's blowing. I got a<br>[33:52] a silicon soup thing that Do you have<br>[33:54] one of these?<br>[33:55] >> Silicon soup thing. No,<br>[33:57] >> you put it in the microwave and then you<br>[33:59] put your soup on it whenever you're<br>[34:00] microwaving it. And then if I need to<br>[34:02] carry it to my office, like I often do,<br>[34:04] you just pick up this and carry it into<br>[34:06] your office like that.<br>[34:08] >> Uh, that's what your sleeves are for.<br>[34:10] >> Bro, I've spilled so much soup. I I've<br>[34:13] I've burn Yeah, I got to have a silicon<br>[34:15] soup sleeve.<br>[34:16] >> I got the MadCSS logo, by the way. If<br>[34:19] you haven't checked that out, go to<br>[34:20] madcss.com. We're doing a major CSS<br>[34:23] battle tournament. It's going to be<br>[34:24] awesome.<br>[34:25] >> Yeah. Wow. The rest of the stuff on my<br>[34:28] desk is related to my surgery. I'll tell<br>[34:30] you that.<br>[34:31] >> I could go I could go all day, but I<br>[34:32] think that's enough. Let's talk about<br>[34:34] CSS. Things that we want in CSS, aside<br>[34:37] from some of the like primitives being<br>[34:38] able to style them. Um Nick Williams<br>[34:41] says a way to specify speed. Example,<br>[34:44] pixels a second for transition<br>[34:46] animations rather than just a duration.<br>[34:49] >> That's that's really cool, right?<br>[34:51] Because if you have an animation, you<br>[34:54] tell it, I don't know, 100 seconds or<br>[34:57] 300 milliseconds, 200 milliseconds, but<br>[34:59] you don't know how far that is actually<br>[35:01] going. And if you want all of your if<br>[35:03] you want them all to feel the same way.<br>[35:05] Same thing where like if you like cancel<br>[35:07] a transition halfway through, um it<br>[35:10] would be cool to get the physics of that<br>[35:12] rather than just break it in the middle<br>[35:13] of a bezier curve and then just reverse<br>[35:15] it from from there on out. That would be<br>[35:17] sick in CSS. Yeah.<br>[35:19] >> Yeah. Yeah. I agree. I I I don't know if<br>[35:21] yeah if I I'm dying for that but yeah<br>[35:24] more the merry<br>[35:24] >> CSS strict mode there's a lot of like<br>[35:28] baggage in in CSS right like what how<br>[35:30] long has CSS been around for 100 years<br>[35:33] so there's a hundred years of baggage in<br>[35:35] CSS and there are a lot of weird<br>[35:38] >> like oddities that you just kind of have<br>[35:40] to deal with because they don't you<br>[35:41] can't break backwards compat of the web<br>[35:43] but what if we could what like in in<br>[35:45] JavaScript we did it right you you just<br>[35:48] have like a use strict<br>[35:50] you can pop at the top of your<br>[35:51] JavaScript file. Or if you simply just<br>[35:53] use an ES module, then that's considered<br>[35:56] strict mode and all of the baggage of<br>[35:58] the weird web is is gone. You break<br>[36:00] those APIs. So, can't we also get strict<br>[36:03] mode, right? Turn border box um on by<br>[36:07] default.<br>[36:08] >> Yeah. And there there's so many dumbly<br>[36:11] named properties and stuff like<br>[36:14] I'm fine with breaking things if you if<br>[36:16] you have a version or a strict mode or<br>[36:18] whatever. I'm fine with that. Um, get<br>[36:20] rid of some of the croft uh stuff that<br>[36:21] you don't need. Uh, and make Yeah.<br>[36:25] >> Uh, one for browsers. Christopher<br>[36:28] Vanhton says, "I'd like to see Safari<br>[36:30] move to Chromium." You hear this a lot.<br>[36:32] A lot of people say, "Everybody just<br>[36:34] move to Chromium. It would be so much<br>[36:36] easier for me." I I'm going to tell you,<br>[36:39] you do not want that. We do not want a<br>[36:41] world where there is one browser engine.<br>[36:44] As easy as it would make your life to be<br>[36:46] able to just run one engine and run<br>[36:48] everything and it runs absolutely<br>[36:49] everywhere,<br>[36:50] >> you do not want a single browser engine.<br>[36:53] That's going to cause the web to<br>[36:54] stagnate. That's going to cause a whole<br>[36:56] lot of a lot of pain. You do need these<br>[36:59] things to compete.<br>[37:00] >> I want iOS Safari to be to be blank.<br>[37:04] That's it. That's it. Yeah. I don't know<br>[37:06] how like iOS Safari is the dumbest one<br>[37:08] to to debug and I have so many issues<br>[37:11] with it and there's so many like little<br>[37:12] things here and there with iOS Safari.<br>[37:15] You can get you can have normal Safari<br>[37:17] on WebKit. Keep the uh keep the variety<br>[37:20] going or whatever, but like iOS Safari<br>[37:22] or just give me effing Chrome with Blink<br>[37:26] on iOS, please. Like I'm so sick of of<br>[37:29] >> But give it to everybody though cuz<br>[37:30] otherwise like normies are not going to<br>[37:33] change their browser engine on iOS. I<br>[37:35] just Yeah, just for my own personal uh<br>[37:37] sanity,<br>[37:38] >> some countries have already done it. We<br>[37:39] talked about that a couple episodes ago.<br>[37:41] >> They shouldn't have to have the<br>[37:43] countries force the company to do the<br>[37:45] right thing.<br>[37:46] >> Yeah.<br>[37:47] >> Um AI access as a native API. Um I'm<br>[37:52] going to tell you, and I actually had<br>[37:54] several calls with folks that work on on<br>[37:56] Chrome, and I don't think we need this<br>[37:58] yet because I don't think that we have<br>[38:00] figured out what these APIs need to look<br>[38:03] like. And if you rush these APIs out the<br>[38:06] door based on like what we need right<br>[38:08] now, which is like prompting and<br>[38:10] streaming back text into a chat, then<br>[38:14] these are the APIs where you just people<br>[38:15] are just not going to use them because<br>[38:16] they're just well, these are not nearly<br>[38:18] as good as as what we have. But<br>[38:19] >> that's what happened with web<br>[38:20] components.<br>[38:22] Yes, we do eventually need, I think,<br>[38:26] some sort of AI access in the browser<br>[38:29] that will allow you. And my my idea is<br>[38:33] that eventually we're going to get to a<br>[38:35] spot where you will be able to use your<br>[38:38] computer's bakedin model if if you want<br>[38:41] to. Meaning that like hopefully in my<br>[38:43] ideal world this API would be you can<br>[38:46] use the local AI that lives on the<br>[38:49] device or you can swap that out for a<br>[38:52] model that you load in yourself kind of<br>[38:53] like transformers.js maybe you load like<br>[38:56] I don't know a gig model um into your<br>[38:58] application because it's well worth it<br>[39:00] for that. Um or you can hit like an<br>[39:02] external API for that type of thing. one<br>[39:04] API that will be able to do that and<br>[39:06] then if you can access your your like<br>[39:08] the iOS model or your Mac model or<br>[39:11] whatever that is on there then it<br>[39:14] becomes private it becomes free right<br>[39:17] >> yeah the user is paying for it in their<br>[39:20] battery in their device but it's it's it<br>[39:22] could be significantly faster like what<br>[39:24] happens when you can run inference on<br>[39:26] absolutely everything what happens when<br>[39:28] it's extremely fast where it doesn't<br>[39:30] take four five 100 milliseconds a second<br>[39:33] to come back. What happens when it's<br>[39:35] like an instant? Um, that opens up a lot<br>[39:39] of possibilities.<br>[39:40] >> Yeah, really cool. I I've been I've been<br>[39:42] thinking a lot about this kind of stuff<br>[39:43] lately. Yeah, for sure.<br>[39:45] >> Chrome is working on this. They have I'm<br>[39:49] in I'm in the beta um that you can like<br>[39:51] test it out. There's like local AI<br>[39:52] models and what it does is Chrome just<br>[39:54] downloads a small enough model and then<br>[39:56] it will run it on your machine and then<br>[39:58] you can just ask it for things. But it's<br>[40:02] slow. It's not very good and it's at a<br>[40:04] spot now where people will go cool demo<br>[40:06] but I'm not actually going to use that<br>[40:09] because it's it's not very good. I'm<br>[40:10] just going to use the the paid one.<br>[40:12] Yeah.<br>[40:12] >> But like even things like date picker<br>[40:15] input like natural language to date<br>[40:17] picker, right? The date picker of the<br>[40:19] future will simply just be me typing in<br>[40:21] February 18th 3 years ago or the last 40<br>[40:26] days starting from next Tuesday. you<br>[40:29] know, you'd be able to just type those<br>[40:30] in in natural language, have a model<br>[40:32] compute what that actually is, and then<br>[40:34] return to you some temporal durations<br>[40:37] that will match it.<br>[40:38] >> A AGI is me entering my credit card<br>[40:42] expiration date in any gosh darn format<br>[40:44] that I want and having it just<br>[40:48] understand it.<br>[40:50] Oh man, let me tell you about postal<br>[40:53] codes inputs in Canada. Holy hell. So,<br>[40:56] postal codes in Canada are uh like like<br>[40:59] a like a letter, a number, I don't even<br>[41:01] know. But it's so obnoxious because<br>[41:03] first of all, on iOS, you have to switch<br>[41:06] between every other letter. You have to<br>[41:07] switch between the keyboard and the<br>[41:09] number input. And sometimes they have to<br>[41:12] be capitals and you generally you put a<br>[41:15] space in between the first three and the<br>[41:17] the second three numbers or or digits,<br>[41:20] but sometimes you don't. And then like<br>[41:22] the validation on postal codes is a<br>[41:25] nightmare.<br>[41:26] >> Sucks. I sucks.<br>[41:28] >> We need AI for these things, you know?<br>[41:29] Like I I know a lot of you listening are<br>[41:32] big thumbs downers on our AI episodes,<br>[41:35] but like you got to you got to agree<br>[41:37] with me that like a like an AI local<br>[41:40] free private model that can parse data<br>[41:44] inputs for you or just like simply just<br>[41:46] like fix your validation errors that are<br>[41:49] oh I've put a space after my email<br>[41:51] address, you know.<br>[41:53] >> Yes, I I'll<br>[41:54] >> that seems like a good use case. I'm<br>[41:56] going to uh uh to echo David Kramer's<br>[41:58] sentiment lately and it's it's the the<br>[42:02] people in in January 2025 who are still<br>[42:06] loling about AI coding not being useful<br>[42:10] or good, bro. You are missing it. You're<br>[42:14] you're missing it entirely. I I think I<br>[42:17] think you you got to update your brain<br>[42:19] because<br>[42:20] >> yeah,<br>[42:21] >> things have changed. The the landscape<br>[42:22] has changed. Everything has changed. I<br>[42:24] can understand ethical in in those types<br>[42:27] of stances on things, but if you're if<br>[42:29] you're loling it because you think it's<br>[42:31] not capable, you are<br>[42:32] >> it's not good. It makes so many<br>[42:34] mistakes.<br>[42:36] >> Tailwind.<br>[42:37] >> Yes.<br>[42:37] >> I was thinking about that as an episode.<br>[42:39] What do you What do you think about that<br>[42:40] is like let's go on Blue Sky and ask<br>[42:44] what people's hang-ups are.<br>[42:45] >> Mhm.<br>[42:46] >> Um and like like not just like h it's<br>[42:49] actually really good cuz like there a<br>[42:50] lot of it sucks, right? freaking have<br>[42:52] you ever tried to like fix a CSS bug<br>[42:54] with AI? It's it's awful at that.<br>[42:58] >> There's all kinds of things. Yes. And<br>[43:00] some things take longer. Absolutely. Uh<br>[43:02] >> it's not worth it. And lots<br>[43:03] >> some things are absolutely not worth it.<br>[43:05] When I did the the hack week project, uh<br>[43:08] for our sin hacks, our CSS battles<br>[43:10] thing. Uh man, it was way faster to do<br>[43:13] all that by myself. Uh that that's for<br>[43:16] dang sure. But like<br>[43:18] >> there's a lot of things that it can save<br>[43:20] you a whole ton of time on for sure.<br>[43:22] >> All right, I'm going to I'm putting that<br>[43:24] on. I'm going to Blue Sky. I'm going to<br>[43:26] get absolutely destroyed. But we'll uh<br>[43:29] we we'll like put together all of like<br>[43:31] people's thoughts and like why they<br>[43:33] don't use it. Um and then we'll we'll<br>[43:36] just like kind of go through them and<br>[43:37] say like that's valid or that's I I<br>[43:39] think you are wrong there. Here's how<br>[43:41] you could you can fix that type of<br>[43:42] thing. And people when you are defending<br>[43:46] your stance on not using AI,<br>[43:49] >> would it hurt you to not be such an<br>[43:52] [ย __ย ] Like crazy. People are just<br>[43:55] yelling at people all like, "Look at<br>[43:57] this stupid loser who's using AI." Wes<br>[43:59] did something. Wes had some tweet about<br>[44:01] 3D on AI and and there's just some<br>[44:05] absolute loser on Twitter uh just<br>[44:10] calling him names for no reason. Like<br>[44:12] >> what was this?<br>[44:14] >> Somebody called me a name.<br>[44:15] >> Bro, you were quote tweeting them.<br>[44:18] >> Oh,<br>[44:20] I forget what that was.<br>[44:21] >> But you Yeah. You're<br>[44:24] >> to be fair, there is so many obnoxious<br>[44:26] people in this space.<br>[44:27] >> There are so many obnoxious people. Yes.<br>[44:30] >> And like people that have obviously<br>[44:31] vested interest<br>[44:33] >> in saying that this is the next thing<br>[44:34] and lots of people just straight up<br>[44:36] lying. Um, so I get it, but I feel like<br>[44:40] I'm not one of those people and I feel<br>[44:42] like I have a pretty good stance on this<br>[44:43] stuff.<br>[44:44] >> Yes,<br>[44:45] >> that's where we're at.<br>[44:46] >> Just be reasonable, folks, please.<br>[44:49] >> All right, last thing we got here is<br>[44:50] APIs in Node, Bun, Dino, whatever. Um,<br>[44:55] Justin White says, "I want the web<br>[44:57] speech API in bun or node."<br>[45:00] >> Yeah,<br>[45:00] >> I I agree. And I I don't know that that<br>[45:04] you want just like a straight up like<br>[45:05] that's that's what happened to Chrome.<br>[45:07] Chrome implemented the web speech API.<br>[45:09] >> Yeah.<br>[45:09] >> Nobody uses it cuz it sucks.<br>[45:11] >> Sounds bad,<br>[45:12] >> you know?<br>[45:12] >> Yeah.<br>[45:12] >> It's it's awful. Or like and we're<br>[45:14] talking both like text to speech and<br>[45:16] speech to text. Um and there's always<br>[45:18] going to be better models out there. Um<br>[45:20] so what we really need is yes, you<br>[45:23] should be able to use like the Siri<br>[45:25] voice built into the browser if you if<br>[45:27] you want, but you should also be able to<br>[45:29] load in additional models. And and I<br>[45:31] think that this gets wrapped up in some<br>[45:33] sort of AI APIs that are built into the<br>[45:36] browser that let us optionally use the<br>[45:39] things that are available on the user's<br>[45:40] device. Yes. You know what? In that same<br>[45:44] regard, like give us good<br>[45:48] uh text to speech. I just did a<br>[45:49] texttospech server myself and it's not a<br>[45:53] problem. I have a texttospech server<br>[45:55] running full-time on my my laptop and<br>[45:57] anytime I need text to speech, uh<br>[46:00] whether it is through my agent setup or<br>[46:02] whatever, it just pings my laptop. It's<br>[46:04] got the voice, it's got the whatever.<br>[46:06] And it's it's it's it's like really<br>[46:08] really good quality compared to uh any<br>[46:11] of the APIs that are in the browser. And<br>[46:13] it wasn't that hard.<br>[46:14] >> Bonsy buddy sounding,<br>[46:17] >> right? And and the voice it it's not<br>[46:19] like uh what's the one that we 11 Labs.<br>[46:22] It's not like 11 Labs good, but it's<br>[46:24] approaching that good. And it's it's way<br>[46:26] better than than a robot voice. I'll<br>[46:28] tell you that. I love text to speech.<br>[46:30] I've been using text to speech so much<br>[46:33] with my setup that's generating<br>[46:36] uh it it's taking research topics for me<br>[46:39] and turning them into personalized<br>[46:41] podcasts uh and those types of things.<br>[46:44] And setting that text to speech up has<br>[46:46] been such a nice thing for me in my<br>[46:48] learning capabilities cuz I'm not<br>[46:50] reading anymore. I'm not using the<br>[46:52] built-in Mac OS one that also sucks. Um,<br>[46:55] so yeah, Texas Beach, make it nice.<br>[46:58] >> Um, Alibaba just released a model called<br>[47:01] Quen TTS.<br>[47:03] >> Um, which is<br>[47:05] >> in my opinion as good as a lot of the 11<br>[47:08] Lab stuff. Um, and you can you can<br>[47:11] apparently you can run it on like<br>[47:13] relatively normal hardware. Like you<br>[47:15] could run it on your laptop if if you<br>[47:16] wanted to or you can 10 cents per 10,000<br>[47:20] characters, which that's a lot, right?<br>[47:24] You want to you want to read a 5,000word<br>[47:26] blog post? Oh, no. 5,000 characters.<br>[47:29] Yeah,<br>[47:29] >> it probably can get expensive, but it's<br>[47:31] it<br>[47:32] >> it's not that expensive.<br>[47:34] >> And you can train it on your own voice,<br>[47:35] which is again another ethical<br>[47:38] >> ethical problem.<br>[47:39] >> Yeah, I don't I don't need anything to<br>[47:41] replace my voice. I don't need anything<br>[47:43] like that. I just want to listen to<br>[47:44] somebody teach me things rather than um<br>[47:47] >> Yeah.<br>[47:48] >> Yeah.<br>[47:48] >> Beauty. All right. Let us know down<br>[47:51] below in the comments. What is the web<br>[47:53] missing for you? What do you want to see<br>[47:55] added? Cuz<br>[47:57] people are watching. People that do the<br>[47:59] standards are are constantly asking this<br>[48:00] question. They want to hear what do<br>[48:02] people actually want. Leave them down in<br>[48:04] the comments. Let us know down below<br>[48:06] what you know. Um let's do sick picks.<br>[48:09] Wes, you got a sick pick? I got a sick<br>[48:11] pick while you're waiting. Uh you know<br>[48:12] what? Uh, I was just talking to producer<br>[48:14] Randy the other day about like budgeting<br>[48:17] and stuff like that and it made me<br>[48:20] remember that I I've sick ppicked this a<br>[48:22] couple times before but not recently and<br>[48:24] it is new year. I lean really hard on<br>[48:27] budgeting software and uh it's important<br>[48:30] to to have a good handle on your your<br>[48:32] finances at all times. So, I I pay for a<br>[48:35] service called Monarch. And Monarch was<br>[48:38] like a good successor to like Mint if<br>[48:39] you used Mint, but it's so much better.<br>[48:42] And anybody who says Mint was like the<br>[48:45] pinnacle of this kind of stuff is just,<br>[48:47] you know, nostalgia, uh, whatever. But<br>[48:51] they recently redid their goals system<br>[48:54] because their goals were like one of the<br>[48:55] things that was lacking. The goals are<br>[48:57] so much better. They give you like sand<br>[48:59] key reports of where your money is going<br>[49:01] every month, every year, whatever. And I<br>[49:04] got to say, the whole thing is just a<br>[49:06] beautiful, well-made app. It alerts you<br>[49:09] for uh reoccurring transactions that you<br>[49:12] you can be cutting back on, and it helps<br>[49:14] with so much. And Courtney and I now go<br>[49:17] through this our budget every other<br>[49:20] weekend um and go through the accounts<br>[49:22] and are all working on it together. And<br>[49:24] it's such a nice great system. So check<br>[49:26] it out, Monarch. I'll have a link in the<br>[49:28] show notes if you aren't using it.<br>[49:30] >> All right, my sick pick. I've sickpicked<br>[49:31] this a couple years ago, but I do it<br>[49:33] again cuz it's one of those things I<br>[49:35] just absolutely love.<br>[49:36] >> Wow, that looks so cinematic on camera<br>[49:38] right now.<br>[49:39] >> Does it?<br>[49:39] >> I think it's probably cuz you're using<br>[49:41] the teleprompter. It's like giving a<br>[49:43] nice diffuse look. It's Wow, it's<br>[49:45] beautiful.<br>[49:45] >> Yeah, it's hitting the glass of the<br>[49:46] teleprompter. Anyway, this is a Sloanic<br>[49:49] rechargeable headlamp. I've had this<br>[49:50] thing for probably four years. It is<br>[49:53] freaking fantastic. I'll tell you tell<br>[49:55] you what I like about it. It's USBC<br>[49:56] rechargeable. It has a removable 18650<br>[50:00] cell, meaning that if if this thing<br>[50:02] dies, it's not e-waste. You know, you<br>[50:03] just you you buy one little battery, you<br>[50:05] replace it. Um, it is bright as heck,<br>[50:09] you know, like I'm always working on<br>[50:11] something where it's super dark and I<br>[50:12] just want to light the thing up or I'm<br>[50:13] at the cottage and it's like super dark<br>[50:15] and I want to see where the dog is. Um,<br>[50:17] go into the washer, make sure he doesn't<br>[50:19] get eaten by a wolf. It is awesome. The<br>[50:22] elastic on it has like out over four<br>[50:24] years, it is still in really good shape.<br>[50:26] It just is comfortable on my head. I've<br>[50:28] My kids have some really crappy<br>[50:30] headlamps I've gotten as gifts and they<br>[50:32] always take mine cuz this one is the<br>[50:34] best. So, if you are looking for a nice<br>[50:36] quality headlamp, it's a very dad<br>[50:37] purchase, but check out these Sloonic<br>[50:41] headlamps. Yeah. Heck yeah. Cool. Well,<br>[50:43] check us out on YouTube, check us out on<br>[50:45] your podcast player, all that good<br>[50:46] stuff. And we will see you next time.<br>[50:48] Peace. Peace.
<!-- deep-read:sections end -->