I’ve been working with JavaScript for a very long time and there are only a handful of things, not to brag which can make me go “oh shit, was this possible with JavaScript”. Partytown which is a JavaScript library does something interesting and something weird which you would not expect when you see it on the first go. Let’s take a look at what this library is and what this does.
If you’re new here, make sure to check out other articles as well on Technology, Programming, Metaverse, and much more.
Table of Contents
What is Partytown Library?
Let’s take a look at what library is and how this works. So if you understand JavaScript and Scripts, the third-party scripts which you inject for example Google Analytics is one. There could be Amplitude, Mixpanel, and so on. So all of these software, these are actually tracking software of some sort, right? Analytics and Data stuff like that. There could be another category of JavaScript that you are running that might not be that important, right? So these software are not important, not critical. What does this mean?
This means that they are not critical to the functioning of your app. So even if they are running a little bit throttled or a little slower, it wouldn’t matter. But it would be great if they don’t run at the main thread at all. Now let me just back this up real quick. What do I need by that?
So when you visit the website, the moment you hit enter there is a thread. There is a single thread known as the UI thread. You can call it a UI thread and this is the place where everything is happening with the rendering part. So the website which you see whenever you click on a button, the navigation which happens when you’re writing into the text area. All those events are executing on this made UI thread and the JavaScript, the .js file which you write that also runs on the same thread. This means that if you are running a piece of JavaScript code on this thread and at the same time there is some user action like a click or a scroll or you know input event or a keypress anything which involves the user. If your JavaScript is running at that time, the user input would be delayed. That would mean the user would see lag on your website or you know it will just not be as much responsive as you would want it.
Web Workers –
One way to avoid that is that JavaScript gives you the opportunity for firing up certain web workers. So these web workers, what they are essentially are, they are completely isolated from the UI thread which is the main thread of your application and they run in a separate thread. So that means whatever you run over here would not affect main thread performance at all. But at the same time, this web worker also provides you with the Asynchronous bridge. That means it is not synchronous, in one way. The other meaning of this is that these updates are not guaranteed to happen immediately. They might take some time. This bridge for communication is asynchronous.
So whatever calculations, whatever stuff you do in this web worker thread, you can do it. Then whenever you want to communicate it to the UI for updating or you doing anything with the DOM specifically, you would have to communicate those changes up the chain. So far, so good. If you understand this, you are ready for Partytown. So now let’s just go ahead and try to understand what exactly Partytown does?
What exactly Partytown does?
So what Partytown does is that then it can essentially take up all of these scripts whichever you say, then it can move the execution of all these scripts from the main thread to a web worker which might seem like an obvious thing to do before this as well, right? Why Partydown exists and why you know this makes so much sense now. Now what Partytown does is something really weird alongside running all these scripts on the web worker. Let’s understand what it does.
Now technically speaking, there is no problem in running a script in a UI thread versus a web worker. The only problem is when the script needs synchronous access to the DOM, this could be a window. (something), this could be a document. (something), and so on. And remember that because you are running this in a web worker, this window, documents, these things are not available. Even if you want to get access to them, you have to cross this asynchronous bridge. And of course, if this is asynchronous then you have to patch this code that is running inside the libraries. That’s not an option, right? Because these libraries are hosted somewhere else and it’s very difficult to patch a specific use case, and if I’m trying something like a document.getElementByID or document.title for example, then I expect this value to immediately return something.
Now how do you make asynchronous calls synchronous? This is what these guys figured out with a really weird hack. And here it is. So if you have used JavaScript before ES5 or ES6 which fetch was introduced. If you have used JavaScript before official fetch, you know that there was something known as an XML HTTP request. I mean that it’s still available today but what was possible before was that actually had the option to make synchronous network requests. And this is what changes everything. Because before fetch was available, you could make synchronous. That means it will block the thread on which the network request is being made. It is a synchronous network request. That means you can call a resource. For example /abc, /def, and actually wait for the request to go and then come back and you know you have the data with you and this whole process would actually block your JavaScript execution.
Now, this is, of course, disastrous on the main thread, on the UI thread, because if you do something like this then in this duration let us say this takes 10 seconds to happen, none of the things would work. Clicks, user inputs, scroll stuff like that all stop working for the next 10 seconds. But over here what these guys did is that they actually created a synchronous bridge within the library itself. Let me explain to you what happens.
Now very simply speaking, what happens is that let’s say there is a web worker, this worker has to execute a Google Analytics script inside this thread. And it receives a call which it is proxying somehow just imagine that. It is receiving all the calls from documents. It gets a call for the document. title and it has to return this response asynchronously because we know that this API, the library which is running it expects you to synchronously return the response. Here’s what it will do. It will perform an XML HTTP request to a certain path, whatever it is. I don’t know what’s the library specifies, but this bridge over here. This is a synchronous call to a network. It’s not to the main thread, it’s somewhere on the network. But again, the interesting thing about JavaScript is that alongside web workers, it also gives you the ability to inject a service worker.
Now the beautiful thing about this whole thing is that service workers also do not run on the UI thread, on the main thread. They run on a separate thread. But what the service worker can do is it can intercept this request. Because service workers have the ability to intercept the request made. So it intersects this request and now it tries to communicate on the asynchronous bridge. Now, remember in this case what is happening is that this XML HTTP request which you made you can think about this service worker as the front-end back-end right? So it’s kind of a back-end server that is sitting on the front-end itself because it’s intercepting the request and it is then forwarding that whatever we need asynchronously to the main thread. Then the main thread responds back and it responds back to this service worker and this service worker responds to this request. Now because this request was made with XML HTTP request in a synchronous fashion, you have this whole thread or this whole worker was waiting for this request to actually be resolved. So you have the data with you, you injected it back into the actual script which was requesting it. Of course, all of this is actually wrapped into JavaScript proxies JS proxies which allow you to actually intercept these document. (something) calls as well.
But this is the way the whole architecture of Partytown works, which is amazing. Because thinking about this part where you make an XML request and then intercept it with the service worker and then make an async request where the network request is synchronous.
It’s still very early days for Partytown but this can have a significant increase in performance if you use a lot of third-party scripts on your website. Of course, it’s an oversimplification. It involves a little bit more work in setting up the course policies and stuff like that for your whole infra to work properly, but if you are able to implement this as a developer it could save a lot of time which your users spend on the main thread. It can make your applications much snappier, responsive especially, for those startups and companies who have the requirement to push everything inside of every single marketing library of your website.
So yeah this is for today’s article. I hope you get something new to learn from this one. I you do, do tell me in the comment section.
This article has a great information. I will apply it to my daily Spanish classes.