Same lol

First time?? Damn ur missing out

Please invite me to the party!

I too was triggered by the trinity.

Fun Fact: LOLed is supposed to say "Laughed Out Loud" but it just says "Laugh Out Louded"

Web workers aren't allowed to interact with the DOM because otherwise it will create race conditions between worker and main thread. And that can become very messy and cause difficult to find bugs.

Yet another reason why NextJS is the best.

Its in beta and Nextjs also has as experimental flag extrategy=worker for scripts that seems to do the same ?

@@cau8777 I believe this is because PartyTown isn't v1 yet. They don't consider it to be a full release.

Is that why I only have the issue on my vanilla js webpage? Nice.

Partytown is actually Adam Bradley, but yea, Misko is a legend 🙂

You really don't need this package at all. Browsers have web workers built in, hell you can make it faster than partytown by running each API on its own webworker thread asynchronously.

It makes you wary, not weary...unless the thought of using it makes you tired.

@@x1expert1x How do I do this? What should I google?

@@myartikool What are you talking about? everything you need to google is in the comment he made, if you need someone to pick out the terms for you maybe programming in general just isn't for you, or using a computer for that matter

@@dabbopabblo geez, no need to get so aggresive, if you're not going to help the guy better to say nothing at all

Hwo outhb on?

web workers cannot access the dom, so probabaly something related to that

that's what the forward section of the video was for

@@calimio6 I suspected as such, but @2:06 he has _document.body.appendChild_ which seems to be working fine. Maybe it has to do with what Yuri suggested, and we should look into that more...

@@weeb3277 That would only matter if @Fireship unit tests his example code

Don't you just love it when everyone needs to make "data informed decisions" but no one knows what data to look at or what decisions to make lol

Thats what's I did lol but I'm sure someone can tell me why I shouldn't do it that way

I thought something similar, but setTimeout will keep it on the main thread and may not be as performant as executing in another thread via a web worker (which is what Partytown uses under the hood). But it's not guaranteed, since as many here have pointed out, it adds a lot of complexity and even the marshalling between threads may not be worth the price, depending on how often it has to communicate with the main thread.

@@ibgib I add a script tag in the setTimeout so whilst it's still executed on the main thread, it's not blocking interaction until it's called, which can be whenever you want. I don't need intercom at page load. Unless I've misinterpreted your meaning.

@@toxaq Oh very cool on the dynamic adding of the tag. I am speaking of the nuances of the JS event loop which will run the setTimeout task as soon as the current execution of the main thread is done. So if for some reason you have some other tasks, e.g. microtasks from async calls still ongoing in your main thread, the setTimeout script loading callback may be executed prematurely. If you were able to shift the work to a web worker and work on another thread, then it may be more suitable. These are all of course general statements and it entirely depends on the total context. Also, it seems that there is additional marshalling magic in Partytown that seems to add complexity which many here are complaining about, but the additional magic somehow improves beyond simple web worker functionality. It sounds like I'm not telling you anything you don't know, I just can't tell for sure if you understand the event loop aspect of what I'm talking about. It was magic for me for a long time, and of course since I don't work with its internals every day, is still somewhat magical.

@@ibgib appreciate the reply. Understood on the event loop. I investigated partytown but it seemed like I would then be responsible for breakages if at any time Intercom changed something that wasn't compatible and as such the delayed loading seemed like the best option in terms of not owning the responsibility but getting enough of the benefits.

You can, what's stopping you?

There can be CORS issues with some third party scripts which mean you have to proxy them and correctly set it

Introducing a dependency on service workers would certainly be a dealbreaker for those already getting significant benefits from keeping their JS in their CDN

Really wanted this to work, but just couldn't get it working with tag manager or analytics snippets. Believe it was a cors error and had to give it up. Would be great if it worked!

So what I think but it might be not true is that it if u have lot of people on your website and u have lot of these requests it might be expensive for the server to work if I'm not wrong worker's work in the background which means in the server

You can't use 3rd party scripts on webworkers. For security reasons it won't work. That said, this is as same amount of work as optimising and offloading things to delayed execution with deferred js. Just another fancy way to pollute html in reality- real world dependencies would be far smaller except JS bloat of trackers, plugins and unnecessary code that gets bundled without tree shaking in some cases.

Deferring doesn't prevent it from still causing JS blocking time, because lighthouse waits for *all* javascript to load before concluding the test. And async calls would just add more time onto that.

That's what he said. The page will load, but won't be interactive until the script has finished

@@NorthLaker I don't understand how this is better than defer

@@379rale defer will make the script load after the html has been parsed, but will still block any interaction. Partytown will execute the entire script on another thread not impacting the performance or responsiveness of the page itself at all.

@@379rale Defer, as the word implies, is serial execution. This is parallel. Provided you have your ducks in a row and don't mix things up, its free performance.

Static caching through Cloudflare would help, but it costs $5/month and will never get 100s (or even green scores) across the board. The problem is that most Turdpress themes are made by designers, not devs, so they’re packed with all the bloatware that designers need to make a site without a developer. To get greens you need a developer involved, designers don’t know enough about CSS, JS, or web optimization in general. To get 100s you need a good developer on your project, they can’t optimize a project they don’t know about. I know a guy who’s site has 100s across the board, want me to put you in touch?

Umm yes

What're you loading that your FCP is blocked? Images? Videos? Is it a pure React app?

I may be wrong, but from what I understand without research, web workers is a browser feature that allows for JS scripts to be executed on a different thread. JS is single-threaded, but browsers allow for multi-thread execution (provided the user's CPU is multi-core which they pretty much always are nowadays).

@@tobias-edwards doesn't even have to be multicore because OS has a scheduler

Fireship simply goofed up with the example. Partytown moves all logic to service worker which allows your code running on main thread to get all available resources while all non-essential third-party bloaters get send to party in their little service worker town ;) It's pretty neat and as you might've guessed the intended use has nothing to do with replication of async/defer functionality.

What kind of terrible prank are you trying to pull on your users?

@@BurgerKingHarkinian no no no terrible prank. I just wanna hide my bad backend skills.

Of course it would be included in the PRO subscription on his website

You can use comlink instead for that.

do you want Fireship to do everything from you? go read the documentation and figure it out yourself

They can’t interact with the DOM, this is basically a web worker wrapper that allows limited DOM interaction by forwarding DOM calls from the worker back to the main thread and vice-versa.

@@liquidsnakex ah i see. thaanks. seems pretty good