JavaScript

Ever wanted to paint realistic-looking brushstrokes in your browser? You’re welcome.

Yet another reason to not assume your JavaScript will always run, or if it does run, that it will run in its entirety:

I’m told: Yes, it’s 2016; of course Google executes JavaScript.

But I’m also told: Server-side rendering is necessary for SEO.

If Google can run JavaScript and thereby render client-side views, why is server-side rendering necessary for SEO? Okay, Google isn’t the only search engine, but it’s obviously an important one to optimize for.

Recently I ran a simple experiment to see to what extent the Google crawler understands dynamic content. I set up a web page at doesgoogleexecutejavascript.com which does the following:

1. The HTML from the server contains text which says “Google does not execute JavaScript.”
2. There is some inline JavaScript on the page that changes the text to “Google executes JavaScript, but only if it is embedded in the document.”
3. The HTML also links to a script which, when loaded, changes the text to “Google executes JavaScript, even if the script is fetched from the network. However, Google does not make AJAX requests.”
4. That script makes an AJAX request and updates the text with the response from the server. The server returns the message “Google executes JavaScript and even makes AJAX requests.”

After I launched this page, I linked to it from its GitHub repository and waited for Google to discover it.

[…]

It seems Google is not guaranteed to run your JavaScript automatically. You may have to manually trigger a crawl. And, even then, Google apparently won’t do any AJAX requests your page may depend on, or at least it didn’t in my case.

[…]

My conclusion is: Google may or may not decide to run your JavaScript, and you don’t want your business to depend on its particular inclination of the day. Do server-side/universal/isomorphic rendering just to be safe.

TL;DR: Re-use your DOM elements and remove the ones that are far away from the viewport. Use placeholders to account for delayed data. Here’s a demo and the code for the infinite scroller.

Infinite scrollers pop up all over the internet. Google Music’s artist list is one, Facebook’s timeline is one and Twitter’s live feed is one as well. You scroll down and before you reach the bottom, new content magically appears seemingly out of nowhere. It’s a seamless experience for users and it’s easy to see the appeal.

The technical challenge behind an infinite scroller, however, is harder than it seems. The range of problems you encounter when you want to do The Right Thing™ is vast. It starts with simple things like the links in the footer becoming practically unreachable because content keeps pushing the footer away. But the problems get harder. How do you handle a resize event when someone turns their phone from portrait to landscape or how do you prevent your phone from grinding to a painful halt when the list gets too long?

Stuff in Space is a realtime 3D map of objects in Earth orbit, visualized using WebGL.

The website updates daily with orbit data from Space-Track.org and uses the excellent satellite.js Javascript library to calculate satellite positions.

This has been in browsers for a little while now: you no longer need to animate smooth scrolling as there exists a native option for that. Of course, there’s a polyfill for browsers that don’t support it yet, along with a demo in the source link.

This is an impressive, if a little graphics-intensive, Canvas-driven effect.

A WebGL 2 demo that’s fun to watch as the particles move around.

An interesting look at what’s possible with WebGL these days. The graphics aren’t as detailed as they could be, but I suspect that’s more to make it run smoothly on lower end hardware than a limitation of the technology. More information in the source link below.

This is a really awesome use of <canvas>, Web Audio, and other web standards to create a globe that you can rotate to hear a mixture of radio stations from the coordinates you’re looking at.