Scrollmark is a new browser benchmark designed to test the scrolling performance of the browsers under heavy load. It rewards browser engines that have an efficient DOM renderer and compositor.

Even though "scroll" is part of the name, scroll performance is only part of what is tested.

Sometimes I just am looking to add a small amount of interactivity or state onto an HTML page, perhaps in a Wordpress plugin or a Github pages site. I don't want to have to set up a full-fledged JavaScript framework like Svelte or React just to get simple templating to work, because chances are that I'll spent more time with the setup than I would with the actual page itself.

Using ES6 template literals can be a good substitute to get much of the funtionality of a full view library while sticking with native JavaScript. Here's an example of a simple photo gallery:

Often, the process of naming a software service or component starts with "I have a service that does x, what should I name it?", and ends with "Let's use the name of an ancient diety who is vaguely associated with x". For instance, a service responsible for user data might get named "Athena" (goddess of wisdom and knowledge), while a service that is responsible for notifications might get named "Hermes" (the herald of the gods).

Many teams and companies have adopted conventions that result in similarly "fun" names being used around the organization, from the names of constellations to birds to TV shows. There's even an entire website dedicated to the universe of all the naming schemes out there.

I recently started a new role at Wish as an engineering manager for the Merchant Growth team. I've never held a formal leadership role in my career before, and I wasn't sure where to start. A friend of mine recommended the book The Making of a Manager by Julie Zhuo, which I eagerly picked up as I was just starting to learn the ropes.

I recently wrote a blog post on the Riot Games Engineeering blog titled "Animation in the League of Legends client". The client frontend is powered using the web frontend stack, and I'm glad to have had the chance to share some of the challenges and learnings for shipping high-fidelity animations on that tech stack. Though there's a lot more to learn, my biggest discovery is that underneath the abstractions of HTML and CSS lies a high-performance hardware-accelerated 3D renderer, that when used properly is capable of some really sophisticated things.

Read the post at the Riot Games Engineering Blog »

TL;DR: Sprinkle a quick window.q = this into your JS file for a quick and easy way to debug from your browser's dev tools.

Modern JS techniques generally prohibit application code from adding or modifying global variables, so the scope of various classes that contain an applications state and functionality are not directly accessible from a browser's debug console. This is an annoyance for debugging.

Ember.js computed properties are a powerful feature of the Ember.js framework that is essentially an abstraction around a property getter (with built-in caching). The body of the computed property is evaluated whenever the value is requested; the returned value is cached until one of the other properties that is depended on changes. For instance consider the following simple Ember object:

let Person = Ember.Object.extend({
  firstName: 'Betty',
  lastName: 'Jones',

  fullName: Ember.computed('firstName', 'lastName', function() {
    return `${this.get('firstName')} ${this.get('lastName')}`;
  })
});

Person.get('fullName') evaluates to 'Betty Jones'. The value is cached until firstName or lastName is changed. But for this to work, we need to manually list out the properties that fullName depended on. Listing out all of the properties a computed depends on like this can be a fairly tedious task. It can be tempting to skip a few, espeically if you can say to yourself that certain properties would always change together. For instance, say we want to add another computed property:

Person.reopen({
  json: Ember.computed('fullName', function() {
    return JSON.stringify({
      firstName: this.get('firstName'),
      lastName: this.get('lastName')
    })
  })
});

Whenever firstName or lastName changes, fullName is assured to change. It seems like we have just saved ourselves some typing, right? Though the output would be correct for now, this post is about why this is a bad idea, since this will not always be the case. There is a big gotcha that can happen if you do this, which manifests itself as computed properties not getting updated.

The full text of the Trans-Pacific Partnership has been released, and there has been much discussion about it, some of it a bit misinformed. I decided to take a closer look at the chapter on Intellectual Property. It's an important chapter that governs trademarks, patents, copyrights, and their enforcement (including on the Internet). I am about as far as one can get from being an international trade lawyer, but I believe that I was able to make a reasonable assessment of the section. The language was sometimes difficult, but precise. Here is a summary:

I was recently faced with the challenge of animating a Bezier curve using the data manipulation and visualization library D3.js, which I eventually accomplished for Shopify's live map of orders. We start off with a fairly rudimentary code to generate a spline:

text-outline or text-stroke is a convenient CSS property that, as of January 2015, has very limited support on major browsers. This is a bit of a shame since it is highly useful in certain circumstances, such as overlaying text on top of a background image and still ensuring that it is easily readable.

Photo by JustSomePics, CC-BY-SA.