Skip to content

Latest commit

 

History

History
27 lines (15 loc) · 2.58 KB

20191115.md

File metadata and controls

27 lines (15 loc) · 2.58 KB
Raw

Perf ection 😍

Performance is an area of code that I feel I have neglected. Beyond debugging React hooks and a light understanding of big O notation in algorithms, I couldn't really tell you the first thing about performance. Being given the chance to work on the performance of runpkg has been the push I've needed to start caring.

So far I have:

  1. implemented a service worker to cache requests to unpkg.
  2. implemented a web-worker to move a large recursive processing operation off the main thread.
  3. dove into the chrome dev tools performance and identified another operation blocking the main thread.

WebWorker

The webworker was pretty gnarly to make, whilst there is documentation it seems to be pretty sparse on implementation. I looked to react-hooks-worker for more implementation details specific to React it was pretty useful but I had some issues e.g. event handlers for messages.

I got about 3 hours into this webworker experiment trying to get things going (don't worry I'm an extremely tenacious learner) before I learn that esmodule support is pretty much non-existent... 😬. Sorta one of those 'oh-crap, that's why it doesn't work' moments. If you know runpkg, this is Formidable's proof-of-concept for no-build JavaScript and as such this lack of support kinda screws it up.

While debugging this lack of esmodule support I went through two possible solutions: 1. produce a package which provided a bundle for this recursive javascript operation, or 2. simply copy and paste the code and convert it to a script, or 3. find some way to bundle an esmodule in the browser (if that's even possible). I'm not proud but I went for the second, more hacky option. I feel this was justified as a large majority of this code was split out to reduce file size and improve readability but largely it required the least work of the three options.

So around 1pm I had a working prototype 🥳, possibly up to 500ms taken off processing benchmarks, but more importantly freeing up the main thread to do rendering.

But wait there's a still a problem...

The main thread is still blocked by something else.

But I have a limited amount of time to write on that so you'll have to wait for another day.

I guess the big TILs from today are that no-build doesn't solve everything and working at the edges of the browser can be scary and frustrating.