Stencil is a compiler that generates Web Components (more specifically, Custom Elements). Stencil combines the best concepts of the most popular frameworks into a simple build-time tool.
Stencil takes features such as
- Virtual DOM
- Async rendering (inspired by React Fiber)
- Reactive data-binding
and then generates standards-based Web Components with these features baked in.
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.
There’s something appealing about the roundness of this font, especially at heavier weights.
This is a great resource that lists which ServiceWorker features are supported by which major browsers.
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.