How to test vanilla JS performance | Go Make Things
Did you know about console.time()
and console.timeEnd()
? I did not.
Did you know about console.time()
and console.timeEnd()
? I did not.
Whenever I create a fetch
event inside a service worker, my code roughly follows the same pattern. There’s a then
clause which gets executed if the fetch is successful, and a catch
clause in case anything goes wrong:
fetch( request)
.then( fetchResponse => {
// Yay! It worked.
})
.catch( fetchError => {
// Boo! It failed.
});
In my book—Going Offline—I’m at pains to point out that those arguments being passed into each clause are yours to name. In this example I’ve called them fetchResponse
and fetchError
but you can call them anything you want.
I always do something with the fetchResponse
inside the then
clause—either I want to return
the response or put it in a cache.
But I rarely do anything with fetchError
. Because of that, I’ve sometimes made the mistake of leaving it out completely:
fetch( request)
.then( fetchResponse => {
// Yay! It worked.
})
.catch( () => {
// Boo! It failed.
});
Don’t do that. I think there’s some talk of making the error argument optional, but for now, some browsers will get upset if it’s not there.
So always include that argument, whether you call it fetchError
or anything else. And seeing as it’s an error, this might be a legitimate case for outputing it to the browser’s console, even in production code.
And yes, you can output to the console from a service worker. Even though a service worker can’t access anything relating to the document
object, you can still make use of window.console
, known to its friends as console
for short.
My muscle memory when it comes to sending something to the console is to use console.log
:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.log(fetchError);
});
But in this case, the console.error
method is more appropriate:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.error(fetchError);
});
Now when there’s a connectivity problem, anyone with a console window open will see the error displayed bold and red.
If that seems a bit strident to you, there’s always console.warn
which will still make the output stand out, but without being quite so alarmist:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.warn(fetchError);
});
That said, in this case, console.error
feels like the right choice. After all, it is technically an error.
See, view source is a human right. Since the beginning of the web, thousands, probably millions, of users have bootstrapped their way to technical understanding through exploring the way the existing web is put together. I did. You might have done. And you, we, should be able to. And more than that, we should be encouraged to. For fun, for experience, for education, for revolution.
James is right. And he’s made a script to encourage further exploration.
welcome.js adds a friendly message to the console when it’s first opened, as well as links for users to find out more about the console, and programming in general.
Here’s a nice Christmas gift from Jason and the archinauts at the Internet Archive: tons of games for living room consoles of the early ’80s, all playable in your browser, thanks to emulation in JavaScript.
The slides from Anna’s terrific talk at the Responsive Day Out.
This is an excellent resource from Anna. She’s documenting the browser capabilities of games consoles.
Hey look; Anna’s in a CSSquirrel comic! And for good reason: Kyle is as impressed as I am with Anna’s research into browsers on gaming devices.
There’s also a call for more community device labs. I approve.
An excellent in-depth article from Anna on the many gaming devices out there that have both an internet connection and a web browser.