Polyfills - HTTP203

[@Cuddlehead]

nothing quite as humbling as watching these guys have a simple conversation

[@HughGuiney]

What on earth is a TransformStream?? Google devs live in the year 3000…

[@evandroLG2]

Still today it is a super interesting discussion guys! Thanks a million!

[@googleplexer]

This is the best podcast I've ever seen. 🤘

[@zyst6]

Cool! I dig the code examples, they really helped this episode.

[@ViniciusRocha-bl1lk]

Thank you guys! I was thinking about conditional polyfills these days. Keep using code snippets please.

[@JorgeRafaelNogueras]

Thanks for the great video! I have a question about the solution you present at 7:35: doesn't that implementation mean that when you do a "new (await TransportStreamPromise)" in your code, you'll have to retrieve the polyfill module asynchronously every single time (even if you had already done so previously)?

[@dassurma]

No, once the promise is settled, it keeps its value. The promise body is only executed once.

[@JorgeRafaelNogueras]

Oh, I see: so you get memoization for free. Neat! Thanks for the info and for making this series. By the way, I really like the longer videos with code samples, like this one: keep up the good work! :-)

[@petecapecod]

You guys are wicked smart!! Great video love the code shots

[@MaxArt2501]

I find it weird to create a promise with `Promise.resolve().then` rather than `new Promise`. It looks like an abuse to avoid using `new`. Is there a specific reason to this?

[@dassurma]

I mostly used this because I wanted to use an early return. With the constructor pattern I’d have to use `return resolve(...)` which would have been arguably more confusing. But it’s not a big difference, so feel free to use `new Promise()` instead :D

[@freund17]

Additionally, you couldn't make the constuctor-function async - which is missing in the example by the way - which would prevent you from using "await". More so: thrown exceptions in the "then"-function automatically get converted to rejected promises; while I think this isn't the case for the constructor-function...

[@malipetek]

what about every library loads polyfills on demand and dispatch a event on global containing loaded module with its version and stuff. Other libraries then first attach event listeners when loading a polyfill on demand first look for loaded one and repeat same.

[@snapstromegon]

What about the following approach? self.TransformStream = TransformStream || (await import('/streams-module.js')); You can use this in an async iife (like some examples in the video) and it's short and only imports the polyfill, if it's needed. I know, that it's not the most beautiful code, but for most cases it should be absolutely fine and easy to read.

[@DenisTRUFFAUT]

I like it !

[@pavelagarkov2634]

It would throw an error 'Uncaught ReferenceError: TransformStream is not defined' in browsers that don't know about TransformStream

[@DenisTRUFFAUT]

self.TransformStream = 'TransformStream' in self ? TransformStream : await import('/streams-module.js');

[@neovov]

You're still overriding the global which is bad. Also, it won't work because the import statement will return an object you usually would deconstruct (either const {default: TransformStream} or {TransformStream}))

[@jakearchibald]

Having a property that's a promise or something else is unusual. It'd be better to wrap TransformStream in Promise.resolve. *Edit:* I misread the code above, see my later comment.

[@MarkJKellett]

Can you give more examples of using Streams to solve some real world problems? For me at least, some use cases don't immediately jump to mind.

[@dandan7884]

i thought you would talk about a server side + client side solution that may serve the polifyll version of an API in the first request and also catch errors on the client side, in case the browser actually doesnt support that API. this is hard stuff :( SyntaxError at 07:00, unexpected token await

[@dassurma]

Eh, you are right. The `then` callback should have been async! The problem with server-side loading is that you would have to do UA sniffing, which always feels brittle and costs more in case it goes wrong. But it’s definitely a valid alternative solution!

[@travelmoustache]

Can you make a blog post for this please? Fantastic idea, we should do some library for easier implementation maybe?

[@neovov]

I have mixed feelings about this video. On one hand you explain an issue and propose a fairly elegant solution ; on the other hand I feel that it lack some depth. I think some people may be lost with ‘self’ (if you haven’t had the chance to build a Worker you probably don’t have a clue of what it is), TransformStream (honestly, who have used it yet ? BTW, I’m interested in what you did with a TransformStream) and even async/await and Promise to an extend. I think there is room for another show where you too explain in depth one concept, with examples and slowly (you guys talks quite quickly ; for foreigners it may be hard to understand). Anyway, I would nitpick about one point: polyfill-ing isn’t always black and white. If you take the example of ReadableStream it is available in almost all browsers (*coughing* Firefox ?) but yet, their implementation are sparse, none support BYOB for example (Cache.matchAll is another example). Still, we can use your solution with multiple checks depending on the need when we want to use our API. Also, I don’t quite agree about TransformStream being used asynchronously ; most of the time the pipe is constructed in a synchronous function, converting to an async function might be challenging sometimes.

[@SalmanAbbas007]

I get what you're saying but my solution would support all browsers: If (!('TransformSteam' in window)) { document.write('

[@dassurma]

Except that browsers are blocking document.write() on 2G connections. If you wanna stay in script-tag land (which is totally fine!), then create the script tag dynamically and defer your code until `onload` has fired on the polyfill. This episode was specifically about ES6 modules, tho.

[@lucrativelepton]

Dynamic imports cannot be used in normal script tags, in Firefox. The entire script refuses to run 🙄 such a PITA...

[@raulcalvomartin2979]

What about loading the promise polyfill? Just kidding ;-) that’s a great idea thanks for sharing

[@kosamari]

WHAT IS THE JOKE ABOUT SOY MILK TELL ME

[@DenisTRUFFAUT]

I don't understand. Milk seems polyfilled, but not conditionally.

[@Richienb]

I think soy milk polyfills actual milk.

[@devvx-fe-gu1d3d0g6]

Why am I not surprised

[@mathewmcleod9958]

Super useful!

[@RafaelCouto]

This is how I would do it in the old days: var TransformStreamCallback = function (callback) { if ('TransformStream' in self) { return callback(); } var s = document.createElement('script'); s.type = 'text/javascript'; s.src = '/stream-module.js'; s.addEventListener('load', callback); document.getElementsByTagName('head')[0].appendChild(s); };

[@atomize]

Imagine the code involved in a solution to the issue they discussed, dynamically loading polyfills, without promises. Yikes. Thx promises.

[@425ryank]

Polyfills? Pollyfills?

[@business_max]

Noice Noice. Clean and Easy. Clean and Easy.

[@loic.bertrand]

Soy milk 😍🥛

[@griffadev]

Spendin that Google money on allsaints jumpers 💲💲