PodRocket - Killian Valkhof - Audio Edit
===

[00:00:00] 

Paul: Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. My name is Paul, and today I'm here with Killian Valoff. He is the founder at Poly Pain, and we're not here to talk about, necessarily about poly pain, but we're here to talk about browser APIs. And this is a fun topic because sometimes we get folks on here and we talk about what's built into these amazing tools that we have, and this is one of those pos we're gonna be talking about the ~internet, ~internet.

Ization API. Whew, that's a mouthful. I got a little confused there. And some of the other great things that maybe we're not taking the most advantage of. So welcome to the podcast, Killian. It's great to have you.

Killian: for having me. 

Paul: ~So poly pain. Before we get into things, what is poly pain? How'd you start it?~

Killian: ~sure. Yeah, so PolyPaint is a web browser, like Google Chrome, or Firefox, or whatever. Um, but it's a web browser that I built initially for myself, uh, more than a decade ago now, to help with responsive design. So it actually, it shows your website at all these different screen sizes and things like lights and dark modes, all in one overview.~

~And then anything you do is kept in sync across all of them. So it's really fast, uh, to validate that you're building the right thing as you're building it. Uh, as opposed to what you do in Chrome, which is build something, then resize your browser and check it and then build something else and then resize your browser and figure out that the initial thing you built actually broke now.~

~Uh, and then doing that entire dance over and over and over again. Uh, in PolyPaint, you just instantly see that. And then beyond that, uh, because it is a browser, I get to do all sorts of like weird and cool things to your webpages. Uh, so there's a ton of accessibility tooling in there because I, I have access to an entire page, so I can give you all sorts of like really specific.~

~Feedback on your structure or on performance or on, uh, Like the size of your clickable elements, like they need to be at least a certain width and height for them to be easily clickable. Uh, and like both Apple and Google and WCAG have different, uh, logics for that. So you can test against all of them and stuff like that.~

~Uh, it's just everything I can think of that makes it easier to build high quality websites. Uh, I put in there. Ja,~

Paul: ~So you, you just made a web browser here. Here's Killian. He made a web browser. Um, and, and now that you mentioned the, the use case of poly pain, it's funny, I've actually heard some YouTubers talk about poly pain before. I've definitely seen some people play around with it, um, on the YouTube. So if anybody's curious, there is content out there.~

~I can attest. I have seen it.~

Killian: ~en je kunt veel video's vinden op ons eigen blog ook op polypain .apps .blog, um, maar ja, er is deze lijst van browser -verdieners, wat zo is als Google, Microsoft, Apple en Kilian van Nederland. Ja,~

Paul: ~really started as like a frustration, passion project. Did you end up learning more about browsers than you would've thought? Was it an iceberg effect, sort of the Dunning Kruger effect where you're like, oh my~

Killian: ~er is zoveel in browsers dat je er niet realistisch is, Uh, and it can be like tiny stuff. For example, uh, in Firefox, if you type, like, potrockets .cmo, uh, instead of .com, but do it fast enough, Firefox will know that you, you know, you try to write, uh, dot com, uh, and it, it'll just fix it for you. And there's tons of stuff like that in browsers.~

~Uh, and the interesting thing for me is figuring out like, which are the things that I should also do and which are the things that I should explicitly not do because it's a developer browser. Uh, so another thing all browsers do is if you have a misconfigured server, where for example, uh, you have.~

~forwarding from HTTP to HTTPS for your naked domain, but you forgot to also do that for the www. version of your HTTP version. Even though your HTTPS version of www. does forward correctly. Uh, browsers will just... And all browsers do this. They'll just do this little dance, like, under the hood to figure out, well, you know, there's not a valid forward for this URL, so it technically shouldn't work, but we know that it's the same thing, so we'll just fix it for you, which is perfect for end users, right?~

~You don't want to go to like facebook .com and have it show a warning because they only have a proper forward for www .facebook .com. Uh, that would be a really bad experience, but in polypane, it actually makes sense to have that. bad experience because it tells you something about your own server configuration.~

~Uh, so it's, it's really interesting that I, you know, you keep bumping into these things where there's clearly a right choice for regular browsers and then maybe a different choice for like a developer facing browser.~

Paul: ~Dude, you don't want to hit hidden errors. And this, this is one of these podcasts. We said, we're not gonna get too much into the AI thing, but we have to hear on the negative side. Like this is where Claude or whatever will tell me, oh, well here's a fallback to your fallback, to your fallback. And I'm like, please, I am never gonna figure out what's wrong with the code.~

Killian: ~-hmm.~

Paul: ~surfacing those errors and that, that's an interesting example I didn't even know about. It was like about the.com rewriting. That's, that's pretty nifty. 'cause I'll tell you, I probably make that fat finger all the time.~

Killian: ~Yeah. And it's, it's really like someone spent a, a lot of effort on that because if you do it slowly, uh, it doesn't do the fix for you because, you know, if you do something slowly, it's clearly intentional. So that someone figured out like, what's the threshold for this being obviously a typo and, uh, yeah.~

~And I love that. I love it when people put that amount of effort in, in the tooling they build. Yeah,~

Paul: ~Well, you, you're the right guy to make something like poly paint then, if that's how you feel, Gillian. Yeah. Um, and, and it also perfectly segues into like mostly what we're talking about today, which is internal. Internal, uh.~

Killian: ~Internationalization.~

Paul: ~Boom. He got it. This is my second try. I'm gonna stop trying from here on out. Um, and ~everything we're gonna talk about today is also on YouTube.

Killian has ~like ~a 20 something minute talk up there. It's really easy to follow. So any of the stuff we're talking about specifics, you can go check out the YouTube video and we can put it in the link of the,~ uh,~ show notes,~ uh,~ if you want a second run rundown. ~Um, ~so in, in general. I think the topic is people don't use this side of [00:01:00] browsers and of superpowers that they provide us, and it's because of a bunch of different reasons.

I'd love to hear about some of ~the, ~the core reasons, but before we get into those reasons, what are these APIs? Why are they so important and why are they living in this Goldilocks zone? Killian of ~like, ~you guys should really look at these because the opportunity cost is so high.

Killian: Yeah. Yeah. So, ~uh, ~ internationalization, the is available on window .intl, which is short for internationalization, which I can say this well because I've done it many, many times in front of a mirror, or in front of a recording device practicing.~ or in front of a recording device practicing. Uh, Uh, there's other words that I can say really easily specificity.~

~Things like that, because, you know, you just have to at some point, you just have to sit down and say it a hundred times, and then, then, then you can do it. Um, but yeah, so,~ internationalization is an API that a lot of developers don't think to look at, because they think... You don't need internationalization when your site is just in one language.

Which makes sense, right? Internationalization is for doing things, ~uh, ~ internationally, [00:02:00] across multiple nations, across multiple languages, etc, etc. ~Uh, ~ but that's not really what the API is. The API is really just, ~uh, ~ this huge formatting library, a string formatting library. So, say you have some data. And you want to format that in a way that's readable to your users.

~Uh, ~then the INTL library lets you do that. ~Um, ~ and it lets you do that specifically in the locale, in the language that your user has. And that's the internationalization part. Like, you go from a date -time string, which is not, like, a date -time string is just, Numbers, right? It's not an American DateTimeString or a French DateTimeString.

It's, it's just a DateTimeString. ~Um, ~ and then to change that into a date that an American user or a French user or a Dutch user can understand. [00:03:00] That's where the internationalization part comes in.

Paul: Got it. So when you say it's their language, their time zone, their everything, are these because of files,~ um,~ language being cached on the browser that's available to them? As in, ~you know, like, ~is this browser API something where you could use all the languages? That sounds like a lot of data.

Killian: Yeah, so, ~um, ~ that's the neat thing. ~Uh, ~ and also, so the reason that I, ~um, ~ I gave a conference talk about this library is because It's poorly named, ~uh, ~so people run into an issue where they need to format a date and they think well, I need a date formatting library for that and they go off to NPM and they find one and they add many, many kilobytes of string formatting and then also many, many kilobytes of language specific formatting.

logic, ~um, ~and every user needs to download that, every user needs to parse that, etc. [00:04:00] Whereas with the INTL library, that's just built into the browser. ~Uh, ~ and it's not just for like the five most common languages, like every browser, ~uh, ~and the, the, the total number differs between browser, but like the baseline is every browser that you can install.

Knows about at least 7 ,000 different locales.

Paul: Oh,

Killian: And a locale is a combination of a language and a country. ~Uh, ~ so you can imagine, ~uh, ~ you can speak French, but French speakers in France have a different way of speaking and writing than, say, French speakers in Canada. So there's a local which is Canadian French and a local which is French French.

~Uh, ~ so that, that's, ~uh, ~ the 7 ,000 combinations. ~Uh, ~ so a fair few of them are like English, but like Canadian English, American English, Australian English, ~uh, ~ UK English, et cetera, et [00:05:00] cetera.

Paul: And so all of these ship with the browser

Killian: Yeah, so they're, they're just built in. They're available wherever your users are. And you don't need to think about that. You don't even need to know what language they use to provide them with a formatting for their language. Because you can just ask the browser, like, what language should I use?

Paul: And does this compatibility layer extend beyond words?

Killian: and no. ~Um, ~ so what, what trips people up with the INTL library a lot is that they think it also does logic. Like, it will... ~Uh, ~ compare dates or it will infer language in some way, which it doesn't. It just, it formats strings, it outputs strings. You can't do like math with them. If you want to format time between dates, there's, you know, some steps you need to take.

~Um, ~ so I

Paul: So kind. So it's [00:06:00] mostly string focused. ~It's, ~it's mostly string focused. And if people really wanna lean into maybe replacing something that you would've shipped to the client,

Killian: Mm

Paul: are extra steps if you're doing business logic that maybe you need to,~ um,~ revisit. But the point is you should be using this, a standardize things so that you can have one central way.

'cause we've all been in the nightmare function of ~like. ~Checking if it's this type of string in this time zone and whatever. So just ~like, ~don't do that. That's where you use the internet utilization A API and then a and then ~you do your, ~you do your business logic. ~Um, ~what are some of the libraries that people commonly reach for?

And the one that we've touted here on this podcast we throw around all the time is data. FNS. It's just ~so, it's, ~it's permeated everywhere. What are some other ones? How do you see those getting replaced or. Being used in conjunction with this API in a more correct way.

Killian: Yeah. So I, ~um, ~ DateFunctions is the big one. Moments .js is the other one. ~Um, ~ there's one called Luxon, which [00:07:00] also does DateLogic. And then there's Numeral .js, which is for money, for currency things. ~Um, ~so all of these are excellent candidates to be like the more friendly wrapper around the INTL library.

Mm -hmm. ~Um, ~ and the reason many of them aren't are for backwards compatibility because the INTL library sort of snuck up, ~uh, ~ on everyone. ~Uh, ~ like it didn't land in browsers. Like, across the board, fully formed. ~Um,~

Paul: Okay.

Killian: so, if at any time, like in the past decade, you looked at, ~uh, ~ the INTL library, there might have been the thing you needed, wasn't implemented yet in, say, Safari.

~Uh, ~ and, you know, us developers being developers, we go, fine, then we can't use it. ~Uh, ~ and you move over to date functions and, and that just always works. So there's, there's, you don't have a reason to then, you know, redo your work, because why would you? Like, you don't get rewarded for, you know, redoing work, ~uh, ~you know, [00:08:00] date functions is in there.

It works. So, you know, you just keep using it. ~Uh, ~whereas now, ~uh, ~ at actually as of 2017, so it's been almost a decade, ~uh, ~ the entire Intel API has been redone. is supported in all evergreen browsers?

Paul: And do you think that segmented rollout is mostly to blame for why? I haven't heard of this all over the place on YouTube. ~Just ~just as a finger read.

Killian: think so. And, ~uh, ~ like I, I struggled to come up with a clear example now, but you see browsers in the past like four or so years having more structured, ~uh, ~rollouts where they all ship. A new thing like within months of each other. ~Um, ~and I think that really helps adoption. ~Uh, ~ because if it's in every browser, you can just forget that you need to think about it.

~Uh, ~ if, if that makes sense. Whereas if, you know, if the cool new thing works in Chrome, but you have, ~uh, ~ users on [00:09:00] Safari and Firefox, then you're not going to use the cool new thing. You're going to use what works in all browsers. ~Um, ~and again, like once that's built, there's, there's zero incentive to rebuild it, ~um, ~generally. ~Um, ~so there's not really an upgrade path to, to all of this. ~Um, ~and then the other thing, it's like string formatting is often super specific. Like it's string formatting in most requirements are just like an assumed thing. Als je een webshop bouwt, heb je, ~uh, ~ een checkout nodig, je hebt een shopping basket nodig. Je projectmanager gaat niet uitleggen hoe je het prijsformaat. Maar ze verwachten dat, je weet, je gebruikt het juiste kredietsymbool, je gebruikt het kredietsymbool in het juiste plaats, wat anders is over, ~uh, ~ over landen. ~Uh, ~ zelfs met hetzelfde kredietsymbool. Bijvoorbeeld tussen Nederland en Frankrijk.

Hier in the Netherlands we put the euro sign in front [00:10:00] of the value, but in France they always put it at the end of the value. So if you do that differently and then present it to a Dutch or a French user, they would trust your site less, because you do something weird that no other site they visit do.

~Uh, ~ so that's stuff you should care about, but that isn't the case. really communicated anywhere in most projects. ~Um,~

Paul: It's table stakes.

Killian: you can say it's stable stakes, but it's also a thing that you don't really, it's like, you know, a, a, a fish doesn't know it's wet. I, I didn't know that the Euro sign, ~uh, ~ had such, you know, was, That the placement of the euro sign was so country -specific until I started testing with the INCL library and it did stuff I didn't expect. ~Um,~

Paul: Yeah.

Killian: and I'm sure you bump into that earlier if you build like an international webshop. ~Um, ~but, you know, preferably you bump into that [00:11:00] before users are bending your cards because they don't trust you. ~Uh,~

Paul: As

Killian: so that's, 

Paul: I was, I was just gonna support that and say as somebody who is from the Ununited States of America,~ um, I, ~I had no idea that currency switching thing was at the either end of,~ um,~ where you put the Euro sign.

Killian: Yeah, and it's, that's, that's like very cult, culturally specific. ~Um, ~but there's even like small stuff where you can probably say that it, it, It doesn't matter, ~uh, ~ things like, should there be a space between the currency sign and the value? ~Uh, ~ but that also differs per country, per locale. ~Uh, ~and as like partially a UX designer, I would like to think that, you know, that's doing that wrong.

over in, in many places does erode trust, ~uh, ~ because again, it's not the same as what you see everywhere else.

Paul: ~Right.~

Killian: ~Uh, ~and yeah, and at the same time, it's not something [00:12:00] I want to know for 7000 locales. I just want like a thing that fixes it for me, which is the INTL library.

Paul: Are there ways that you think the I-N-T-E-L library. Is not unique in how it is being under leveraged by the community at large from the browser. API family, or is that like your poster child kill of ~like, ~this one's the worst? Like people just,

Killian: think so. Yeah. ~Um, ~and I think that's because, you know, the naming doesn't map to the use case. ~Um, ~like you, if you have a problem. You think, you know, I, I get a date from my back -end service that I need to format. So my task is formatting a date. My task isn't, like, generating a local aware string that just happens to use a date as an input.

That makes no sense. ~Um, ~And there are other things that I think more developers should use, like all the new array functions, ~um, ~ that make it easier to find stuff quicker, or, ~uh, ~ you know, [00:13:00] even when to use sets instead of arrays. ~Uh, ~ those are all relevant, but they're not user -facing, right? ~Um, ~you're not, so if you use an array instead of a set in a situation where an array is slightly slower, you know, that's...

Too bad, ~uh, ~but if you like ship,~ uh,~ you know,

if 

Paul: the wrong currency symbols

Killian: with the wrong currency or, ~uh, um,~

Paul: that can affect your top line real

Killian: ~uh, ~ so there, there's, in my presentation, I give one very specific example, which is that between, ~uh, ~ most European countries and the U .S., ~uh, ~ we flip the day of the month and the month. ~Uh, ~ so if you have like a 0 -1, 0 -2, 2000, and 26, ~uh, ~ for me, that is the 1st of February.

But for Americans, that's the 2nd of January, because they do month -day -year, which is weird and makes no sense at all. And we do day -month -year, which, like, neatly, makes no sense at all. Increases in size as [00:14:00] you go along. ~Um, ~but the default behavior for most, ~uh, ~ date spewing things on the back -end is to Just use the American standard.

~Um, ~so if you then present a date formatted that way to someone from Europe, that is incredibly ambiguous until you get to, like, beyond the 12th day, and then you can deduce it because there's, you know, there's no 13th month. ~Um, ~but before that, things can get really dicey, especially in, ~um, ~ like, important communication.

Like, the example I gave was for the day. The date that, ~uh, ~ your kid was admitted to a primary school. So you, you want that, you want to know very sure which actual date that is and not, ~uh, ~ you know, be Kilian and have a weird knowledge of dates across the world and go, well, this doesn't make sense. It's probably the other one because they never bothered to validate their, their [00:15:00] output.

~Um, ~I just want to prevent. other developers from annoying users with that. Yeah,

Paul: big annoyance, right? ~Like if, ~if I get the date wrong by a month ' cause it's under 12, that is not fun. ~Um,~

Killian: yeah, that doesn't make anyone happy.

Paul: ~You know, ~Killian,~ it,~ it sounds like you really. Of course it's not, sounds like you have been looking at all these browsers, really figuring out what to distill for developers through the lens of poly pain. It led you down this path of going, oh my gosh, the I-N-T-L-A-P-I, huge opportunity. We're missing it.

Do you think that there's other areas, maybe they don't yet exist, maybe they're like, there's an RFC out for it or something. Of further standardization, further coalescing,~ um,~ stronger ties between the browser, fundamental APIs that are coming. They're on their way or they're not coming. And in the back of your brain, you're just like, guys, this needs, what are you doing?

Killian: ~Uh talk, ~let's talk about this.

[00:16:00] Yeah, so I think, I think we're doing pretty well. So if you look at the past decades, ~um, ~ before that, and like, I'm kind of, ~uh, ~ this isn't the full truth. But it's like, true -ish enough that I can get away with it. But it used to be that people that wrote specifications weren't the people that built the browsers.

~Uh, ~so, specifications for HTML, for CSS, for JavaScript were perfect. But then they weren't perfect. As, yeah, ~uh, ~as the, like, what, how should HTML work, how should CSS work, how should JavaScript work. But what ended up happening was that it didn't take the real world into account. So lots of those very early, like I'm talking 20, 30 years ago, things never were adopted.

Because they just, you know, they, they didn't make sense from the implementer's perspective, which in this case is people building browsers, or more specifically, [00:17:00] people building rendering engines. ~Um, ~but with HTML5, that kind of got flipped, because HTML5 was essentially like browser builders going, well, we, we need, let's, you know, document how the stuff actually works, instead of like the pie in the sky, Perfect representation that none of us actually implements.

~Uh, ~and from there you can sort of see, ~um, ~ an increase in specifications being written to things that developers already use the wrong tools for. ~Uh, ~ so, ~um, ~ you know, we use JavaScript to track the mouse, to when you hover over something, we change the color of the element you hover over. Okay, well in CSS, that's now hover.

~Um, ~ we use a lot of JavaScript and buttons or just diffs with onclick handlers to create accordions. ~Uh, ~ and they work differently on every site. In very subtle, but potentially annoying ways, especially [00:18:00] when you have, ~uh, ~ assistive technologies involved. So let's, instead of that, build a dialogue element that, or a details element that can expand and hide its contents and have that be an HTML primitive.

~Um, ~and you can see that happen more and more and more. A few transitions is a good one. You know, you want to do nice transitions between pages, ~um, ~ which ironically is something that IE3 already did, ~uh, ~ with like a meta tag where you

Paul: Oh no.

Killian: like sideswipe to the next page. ~Uh, ~I, I am that old. ~Um, ~ And, ~uh, ~ yeah, so instead of having you do lots and lots of JavaScript with fetching JSON and then rendering that manually and then playing your animation, like fully controlled by JavaScript and then changing the, ~uh, ~ the DOM in the right place and having to understand how flip works [00:19:00] and all this stuff, like, why not just have a browser?

API that says start transition, and then you make the DOM change, like instantly, and then the browser figures out the animation. ~Um, ~that's much nicer, and that immediately shovels away like hundreds of kilobytes of animation code that you no longer need. ~Um, ~ more recent example is a lot of websites do things based on the scroll position.

~Uh, ~ but handling the scroll position with JavaScript is pretty annoying because you want Java or you want scrolling to be off the main thread, ~uh, ~ so that your scrolling doesn't interfere with your JavaScript or your JavaScript interferes with your scrolling because that will lead to a janky experience.

~Um, ~but if you want to control things based on the scroll position through JavaScript, you sort of, you create a link there. ~Uh, ~so scroll -driven animations or scroll -linked animations. What if we move that to CSS where it can be fully off [00:20:00] the main thread and you can just, you know, JavaScript around and have fun.

~Uh, ~and have your nice scroll -based animations of things that slide in and scroll along, etc. Um,~ Um,~

and sometimes It's even, like, to the benefit of browsers, ~uh, ~so for the longest time, ~uh, ~ browsers have wanted and probably still want to get rid of things like window .confirm, window .alert, window .prompt. ~Uh, ~ because they are actually really weird. ~Uh, ~ because they let you as a website show native UI and you get to decide what to put in there.

Like that's very limited, like you can only put a string in there. But it's still, it's browser UI and that's sort of, ~uh, ~ like a holy separation between webpage content and browser content. ~Uh, ~ which is, for example, why I'm looking forward to seeing you in the next one. Bye bye. Bye bye. Bye bye. If you are in Chrome and a web page requests permissions for, say, your camera, the pop -up that [00:21:00] shows is like slightly above your web page content.

And it's slightly on top of, like, the address bar. So that it's, like, clearly visually outside of the website content. So that it's,~ uh,~ so that if you try to fake it as a website, like, give me all your, give me all the access, ~um, ~ then you can't replicate that exactly. ~Uh, ~ so there's, like, UI considerations there.

~Um, ~ so, and... Those three APIs also have the weird side effect of blocking the main thread. So they are blocking if you call window .prompt. None of your JavaScript executes until the user presses OK, which is weird. ~Um, ~but yeah, so that's how they work. ~Uh, ~ well, now we have the dialogue element, which is like, you want, you want dialogues.

You want to show like a pop -up that says, do you want to do the thing or not? Yes. Cancel. ~Um, ~ well, here you go. Here's, ~um, ~a way [00:22:00] to do that. And we fixed all the annoying parts. ~Uh, ~ the annoying part being. ~Uh, ~ if you do pop -ups in your page, then the chat widget is going to like fight its way to the front and destroy how everything looks because that's what like chat buttons and chat widgets do.

~Uh, ~ so they came up with a concept called the top layer. ~Um, ~and the top layer sits between your page and like the front of the screen. And you can't, you can't build up things in the top layer. You can only say like this element, send it to the top layer. And then if you're done with that, you can say this element, send it to the top layer.

And it'll just be like in front of your web page. ~Um, ~And so that solves a lot of problems really elegantly, because like, it's just HTML and CSS, but it's, so it's not blocking the JavaScript, ~uh, ~ it's not part of the browser UI. ~Uh, ~ and, ~uh, ~and the reason why you wouldn't want to do that because of like z -index fighting, ~uh, ~ they fixed that as well.

So it's a really complete solution for a [00:23:00] very specific problem, ~um, ~ that I also think is still being slept on. ~Um, ~and then there's, there's loads of stuff like that. I could keep going. ~Uh, ~ another one that is really cool recently is all the stuff around popovers.

Paul: Popover is, that's the one I was gonna throw out. What a lifesaver. Oh my gosh.

Killian: yeah, and then, like, popovers save you from having to know how React Portal works. Because popovers also live in the top layer,~ um,~ and then,

Paul: Interesting. That's how they stay separated ~and, ~and. And Okay. Very cool.

Killian: then, ~uh, ~ you know, from that comes anchor positioning, which is like you have a popover that you want to show somewhere, but you want to show it like attached to the button you just clicked. So how do you link that? Well, you link it with anchor positioning. ~Um, ~there are still things you lose there compared to like what native applications can do. So in native applications, if you have like a context menu, ~uh, ~ the context menu can actually like be [00:24:00] outside of The main window,~ um,~ which isn't something you can do in a browser, but that's, you know, that's a choice.

You probably don't want popovers to like peek out of the bottom of your browser window

Paul: Pro. Yeah, probably not.

Killian: be, it would be nicer, but also potentially confusing because that again, cross the boundary between like web contents and browser UI. ~Um, ~ but all those things like dialogue and pop over, et cetera, ~uh, ~ anchor positioning, ~um, ~ invoker commands, which are like, what if you can just add an attribute to the button to say this opens the pop over rather than having to wire up all the JavaScript, all that is fairly new.

~Uh, ~ so you can be forgiven for like not having implemented something that landed in browsers like half a year ago. ~Um, ~ whereas like I said earlier, INTL. Has been baseline widely available since 2017, just almost a decade. ~Um, ~so we should all just [00:25:00] go for that whenever we have something to format.

Paul: Biggest win killing, telling us this is the biggest win. People wake up, but all the other stuff is cool too, 

Killian: very cool. Yeah.

Paul: ~And, ~and you mentioned Native,~ um,~ I'm not sure ~I, I, ~I'm outta my depth here, so I just gotta ask the question. ~Do you, ~do you see the browser war? epic of mankind right now in any way, delving down into trying to pull native APIs into the browser surface ~from, ~from the host,

Killian: in what sense?

Paul: ~like, ~like through web assembly,~ uh,~ through native GPU acceleration. Like I know there's been projects in the past that try to like paint every single dom transformation as a CSS. ~Uh, ~array, ~you know, ~like stuff like that.

Killian: Oh, yeah. ~Um, ~I mean, so there is, ~uh, ~ WebGL and now WebGPU, which I am very unfamiliar with, so, ~uh, ~ I can't really help or, you know, give any, [00:26:00] any sort

Paul: Strong opinion,

Killian: opinion on that, ~uh, ~ other than that I think, like, WebGPU, which I am very unfamiliar with, so, ~uh, ~ I can't really help or, you know, give any sort of strong opinion on that, ~uh, ~ other than that I think, like, WebGPU, Is becoming more interesting as sort of like the version two of how they should work.

~Uh, ~ and then also because we've now all realized that GPUs are very useful for something other than drawing pixels. ~Um, ~I think a lot of interest is going to go there. ~Um, ~and then for all the rest, like, I'm sure there are really legitimate uses of like WASM and WebAssembly. Thanks for watching! ~Uh, ~ probably that I use, that I don't even realize that I use, ~uh, ~ on, on websites out there.

~Um, ~but they all seem like hyper -specific and not necessarily something you would expect. And up adopting on like a general web page.

Paul: Yeah, that's the general read. We've, ~you know, ~I've been getting, when we talk about web assembling stuff, it's always very pointed use case and it's, you're trying to find where it, it would make sense. So I was just curious,~ like,~ because you're at this more agnostic layer of. [00:27:00] Making poly pain, like what?

What's out there? But ~it's, ~it's a similar read. You're giving a similar read on, on that stuff. And where we stand, at least right now, it's March, it's 2026. Who knows what we'll bring. ~Um, well, ~Killian, we're running up on time here, and I just want to remind viewers, Killian, every, everything we've talked about here, you can see in even more detail.

~Um, ~if you want to talk about specific APIs and INTL on the YouTube video, which we'll link down below. ~Um, ~if people are listening right now and they're wondering like, oh my gosh, this sounds cool. ~Like, ~I don't wanna rip out moment js, I don't wanna rip out date, FNS, ~um. ~But I wanna do something here. I wanna take something that Killian talked about and move forward with it.

What's like the lowest bar to entry of? Just ~like ~using the I-N-T-L-A-P-I in a way that's not a toy example on an app that you could imagine people integrating.

Killian: Yeah, so what I think is useful to keep in mind. ~Um, ~ like the INTEL API lets you format the following things. Dates, numbers, and that includes things like currencies, and [00:28:00] sizes, ~uh, ~ lists. So if you have a list of things, and you don't want to array loop over them, you can use intl .list format. To create like a nice, ~uh, ~ A, B, and C, ~uh, ~ or, or C, ~um, ~there is the segmenter API, ~um, ~which if you're building like a, a, a Twitter style UI and you want a little widget that shows how many characters you have left.

Then you will need to count those characters. ~Uh, ~and the Segmentor AI, ~uh, ~ API lets you do that. So it lets you count in a given string, like the characters, the words, and the sentences. ~Um, ~and the interesting thing there is that you might be thinking now, well, there's just string .length. But .length doesn't count characters.

It counts Unicode, Car codes. So if you have an emoji, which is, ~uh, ~ usually, like, ~uh, ~ a ligature of a [00:29:00] number of different character codes, ~uh, ~ you get a length that you don't expect. So there's the emoji of, like, a family, like a mom and a dad and two kids. ~Uh, ~ that's, like, one emoji. But if you do .length, you get 11, because it's constructed out of 11 characters.

Which makes sense if you build Unicode, but it doesn't make sense if you're a human. Because you, you see one emoji, so you go that, you know, there's one character here. The Segmentor API understands that, and... If you ask it how many characters are in this, they call it graphemes, which is like a graphical character, as a user would perceive it, it will go like, there's one there, you know, you can see that, I can see it, there's one there.

And it also does it for words, which again in English is pretty easy, like you just, You know, break a string or split a string on spaces. ~Uh, ~ but there's plenty of languages that don't use spaces. ~Uh, ~ and then you're out of luck. But [00:30:00] the Segmentor API does know how words work in 7 ,000 languages. ~Uh, ~ so you can build interesting UIs in, in that way.

And then the last one that, ~uh, ~ again, is very specific. ~Um, ~ there's a collator, ~uh, ~ which don't ask me what the word means exactly. Thanks for watching! But, ~uh, ~ that will let you sort strings in a local -aware way. So say you have an index of, ~uh, ~ first letters. So A, B, C, etc. ~Um, ~by default, all the sorting UIs will use American English.

Or, more specifically, They will use the Unicode code points. So, A to Z comes first, and then all the weird characters in all the other languages that aren't English. ~Uh, ~so, if you have, ~uh, ~ for example, Spanish, then there's the ñ, which is the N with the little squiggle on top. ~Uh, ~ it will put that after Z.

Because, you know, it has a really high Unicode code point, so it's, it's clearly, if you sort it, that should be all the way back there. But in Spain, that sits [00:31:00] right between the N and the O. ~Um, ~so that's where a Spanish person will look for the ñ. ~Uh, ~so if you then, if you use collator to sort, ~Uh, ~ that will just work and it will also work for like all the weird Icelandic characters or the AE character in Danish or, you know, whatever.

~Um, ~so those are the ones like, ~uh, ~ if you have something to format, a date, a number, a list, ~uh, ~ or something to sort or count, segment or collater, you can just use that. Instead of something else, ~uh, ~ like right in the moment. And you don't lose anything because it's already included in the browser. Like there's no download cost.

There's no, ~uh, ~ interpreting cost. ~Uh, ~ you can use it for the very specific thing that you're trying to format right now. ~Uh, ~ and still use the, like the logic side of date functions and moments. Elsewhere.

Paul: Good entry point and it's ~like ~pointed. So it's like something that you can grab on and just [00:32:00] surgically go on bit by bit.

Killian: Exactly.

Paul: Um,~ Um, ~thanks for those suggestions and Killian, thank you for your time, like giving us this knowledge. ~Uh.~

Killian: My pleasure.

Paul: There's very few people that sit in this intersection of ~like ~all the browsers and then going ~like, ~okay, but how does it look for devs?

What are devs doing? So I hope that we can have you on again in the future to like also check ~on ~on poly pain and like

Killian: happy

Paul: how you're integrating with the market and stuff. ~Um, ~but this has been great. I've definitely learned a lot myself about,~ uh,~ these APIs, right? I've, we talk about some browser APIs here in the podcast, but this one in particular hasn't come up yet.

So ~it's, ~it's been a pleasure.

Killian: Yes. Likewise. Thanks for having me.