Snippets

This is an interesting discussion on the possibility of standardizing a way to request that the browser not load or delay loading images or objects. The key point that developers from the BBC stress is that for a non-zero number of users, JavaScript fails to run yet is enabled, so having a way to ensure they can still view images is important. As excellent as they can be, relying on on JavaScript solutions and serving non-functional markup can lead to broken pages in those cases since we don’t truly control our webpages.

See also: A standard way to lazy load images - WICG

Hajime Yamasaki Vukelic has come to the conclusion that, if you’re dealing with a really big number of DOM nodes that need to be updated in real time, frameworks are usually incredibly slow on top of the already-slow DOM operations you have to do. The solution they settled on is to avoid frameworks altogether for these scenarios and use vanilla JavaScript. Also of note are that repaints and reflows are going to be big bottlenecks regardless of what you use.

• If you are looking for performance, don’t use frameworks. Period.
• At the end of the day, DOM is slow.
• Repaints and reflows are even slower.
• Whatever performance you get out of your app, repaints and reflows are still going to be the last remaining bottleneck.
• Keep the number of DOM nodes down.
• Cache created DOM nodes, and use them as a pool of pre-assembled elements you can put back in the page as needed.
• Logging the timings in IE/Edge console is unreliable because the developer tools have a noticeable performance hit.
• Measure! Always measure performance first, then only fix the issues you’ve reliably identified.

There’s an age-old problem with algorithms that can learn that some advocates don’t seem to fully grasp: without human ethics built in, the potential for harm can be enormous. Isaac Asimov was onto something with the three laws of robotics.

Shooting the moon: In one of the more chilling examples, there was an algorithm that was supposed to figure out how to apply a minimum force to a plane landing on an aircraft carrier. Instead, it discovered that if it applied a *huge* force, it would overflow the program’s memory and would register instead as a very *small* force. The pilot would die but, hey, perfect score.

[…]

Something as apparently benign as a list-sorting algorithm could also solve problems in rather innocently sinister ways.

Well, it’s not unsorted: For example, there was an algorithm that was supposed to sort a list of numbers. Instead, it learned to delete the list, so that it was no longer technically unsorted.

Solving the Kobayashi Maru test: Another algorithm was supposed to minimize the difference between its own answers and the correct answers. It found where the answers were stored and deleted them, so it would get a perfect score.

How to win at tic-tac-toe: In another beautiful example, in 1997 some programmers built algorithms that could play tic-tac-toe remotely against each other on an infinitely large board. One programmer, rather than designing their algorithm’s strategy, let it evolve its own approach. Surprisingly, the algorithm suddenly began winning all its games. It turned out that the algorithm’s strategy was to place its move very, very far away, so that when its opponent’s computer tried to simulate the new greatly-expanded board, the huge gameboard would cause it to run out of memory and crash, forfeiting the game.

The quest for easy to implement concave corners on boxes is still ongoing, although there are some options open to us as the linked article explores.

“We went out with the original Material Design with what was a very fresh and very opinionated style. We wanted to get attention,” says Matias Duarte, the head of the Material Design group at Google. “And it was so strong and so opinionated and so successful, a lot of both the designer and developer community took it as a ‘gospel,’ perhaps is the right word.”

[…]

”We spent two years telling people ‘this is how to make Material yours,’” Duarte says, “and it didn’t work.” But he doesn’t blame developers. The problem is that Google didn’t provide the right tools. Specifically, he believes Google’s guidelines didn’t separate out the styling of the button from its function. Google wants apps to work like other Material Design apps, but it never meant for all Android apps to look like each other.

A huge amount of what a developer is doing is in their head. As we write code we need to keep a mental model of how parts of the application that have already been written and are yet to be written interact with the part that we are writing at that moment. We need to have a solid picture of exactly how the code is working as a whole and maintain that picture. It’s not easy, it requires a lot of concentration and has to remain in place while we think of creative and efficient ways to solve the problem at hand.

Developers can appear very unproductive at times, sitting staring at the screen with our headphones on and very little in the way of keyboard clackety-tap. This however is when we are doing our thinking, when we are building up, adding to and rearranging the mental model of how our code will work. This is the biggest and hardest part of development.

Imagine how it feels to have that interrupted at random by a telephone call or somebody walking over to talk to you.

Standard drop-down menus that contain sub-menus very often have no concept of user intent, and this can lead to a repeating frustration that most of us have likely run into: straying off course by even a single pixel can cause the sub-menu to close instantly. Ways around this include adding a delay to try and account for user error, but that doesn’t feel as snappy. Amazon has a really clever solution that accounts for user error yet responds instantly:

At every position of the [pointer] you can picture a triangle between the current mouse position and the upper and lower right corners of the dropdown menu. If the next mouse position is within that triangle, the user is probably moving their [pointer] into the currently displayed submenu. Amazon uses this for a nice effect. As long as the [pointer] stays within that blue triangle the current submenu will stay open. It doesn’t matter if the [pointer] hovers over “Appstore for Android” momentarily – the user is probably heading toward “Learn more about Cloud Drive.”

And if the [pointer] goes outside of the blue triangle, they instantly switch the submenu, giving it a really responsive feel.

So if you’re as geeky as me and think something this trivial is cool, I made a jQuery plugin that fires events when detecting this sort of directional menu aiming: jQuery-menu-aim.

See the source link for more.