Snippets

This is pretty excellent tool. (Note that it cannot be used on sites that disable iframe embedding, however.)

Today I needed a quick tool to compare the loading progression (not just loading time, but also incremental rendering) of two websites, one remote and one in my localhost. Just have them side by side and see how they load relative to each other. Maybe even record the result on video and study it afterwards. That’s all. No special features, no analysis, no stats.

A basic functionality [Readability] almost-clone. This service will try to search for the body of the content to a URL, and represent it stripped back and with minimal styling.

Usage

Send your URL to https://read.isthe.link via a query string, and so long as the URL is publically available (i.e. not behind login), then the page can be re-rendered:

https://read.isthe.link?url=https://remysharp.com/node

The page will be cached for a period of time, so subsequent requests will be faster.

Usage with private URLs

You can POST a body to the service and it will give you a hashed URL to redirect to. For example:

Issues & feedback

All feedback, suggestions, pull requests to github (please): https://github.com/remy/read-body

MIT Licensed

Every so often we come across parts of our designs that could really benefit from a smooth build animation or transition. Fortunately, we use a lot of SVG for delivering our vector graphics, so we have a great deal of animation flexibility at our disposal, and one tool we’ve enjoyed using for helping us animate our SVGs is SnapSVG, by Adobe. Snap is great, but takes a decent amount of JavaScript skill and tinkering to churn out an animation.

While working on some projects last year, we realized that if we had a more user-friendly, markup-based approach to configuring our SVG animations, we’d be more productive, and our clients could easily work with their own animations after hand-off as well. So we built an open-source tool!

Introducing LayerSnap

LayerSnap is a script that builds on top of Snap SVG to build simple SVG animations by editing the SVG markup’s attributes. It comes with a suite of pre-set build transitions like “fade”, “move-down”, “enter-left”, “rotate-right”, etc. It also has an “anvil” transition, because no animation toolkit is complete without an anvil transition. These transitions can be configured via an attribute on every group (g) element in an SVG, and a special syntax allows you to combine each transition with a host of configuration settings for their speed, delay, easing, looping, repeating, and even interactivity.

Demos, Docs, and more

• To get started with demos and documentation, check out the Layersnap project homepage
• The source code is on Github and NPM
• To file an issue for us to look at, or help us with a bug fix, please visit the issue tracker.

This is our initial release of LayerSnap, so we expect it’ll have some issues here and there to work out. We’d love your help in testing it out. LayerSnap has a couple of dependencies (a CSS file and Snap SVG’s JavaScript), but you’ll notice our project demos include jQuery and some other utilities for cueing animations when they enter the viewport as you scroll. jQuery isn’t required by LayerSnap, but if you’re already using it in your project, you’ll find a helper script or two in the LayerSnap repo makes it easier to auto-run your animations.

The idea here is: push the container to the exact middle of the browser window with left: 50%;, then pull it back to the left edge with negative -50vw margin.

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?

I just noticed the delightful little animation on the Mozilla Hacks site title. It’s triggered by hovering over the title with a pointer, or if you’re on mobile, long pressing it to focus it seems to be the equivalent.

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.