This is a great resource that lists which ServiceWorker features are supported by which major browsers.
These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven’t yet. The concept is inspired by Jeremy Keith’s links and CSS-Tricks, among other things. Enjoy.
A great discussion thread at the Web Incubator Community Group on creating a standardized way requesting that the browser lazy load images.
- 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.