What's Up Wednesday #36 - Programming Music, Why is a birch white, How people get rich, Why most websites are so slow

What’s Up Wednesday #36 - Programming Music, Why is a birch white, How people get rich, Why most websites are so slow

Happy Wednesday everyone!

„This is the precept by which I have lived: Prepare for the worst; expect the best, and take what comes.” -Hannah Arendt

🎧 This week I programmed music. With Sonic Pi you can write code that outputs music. There is a great tutorial and a lot of videos of people live coding (e.g. this one recreating a Daft Punk song. Check it out at http://sonic-pi.net

For anyone who never coded, SonicPi is a great language to start with. SonicPi’s creator gave a great TED talk why you should learn to code, even if you do not want to become a professional programmer. Programming is a creative tool that you should add to your tool belt in the same ways as you should be able to write even if you are not a professional writer (e.g. journalist/author). And I agree with that strongly. There is no limit to what you can explore, create or test with code.

🌳 Do you know why birch trees have white bark? It is protection against rapid warming of the cambium layer. A lot of far northern timber has light-colored bark which reflects sunlight. The rapid heating from very cold after sunrise can damage or even split the bark of dark-colored species. This is called sunscalding. source

🤑 Interesting how time changes how people got really rich.

In 1982 the most common source of wealth was inheritance. Of the 100 richest people, 60 inherited from an ancestor. There were 10 du Pont heirs alone. By 2020 the number of heirs had been cut in half, accounting for only 27 of the biggest 100 fortunes.

In 2020 roughly 3/4 by starting companies and 1/4 by investing. Of the 73 new fortunes in 2020, 56 derive from founders’ or early employees’ equity (52 founders, 2 early employees, and 2 wives of founders), and 17 from managing investment funds. This seems like becoming rich is now possible for more people. You don’t need to be from a crazy rich family. Nice!

👻 Slow websites are something everyone has encountered. Addy Osmani from Google makes a strong case on why web devs should cut back on Javascript. Rendering a webpage has two bottlenecks. Download speed of all files and execution time of javascript code. Many websites ship so much javascript, slower devices need a very long time (> 20s!) executing it. In the meantime, the website can not be used and just makes the users angry. Any web dev should read his full post on medium. Here is the tl;dr:

  • To stay fast, only load JavaScript needed for the current page. Prioritize what a user will need and lazy-load the rest with code-splitting. This gives you the best chance at loading and getting interactive fast. Stacks with route-based code-splitting by default are game-changers.
  • Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure.
  • Learn how to audit and trim your JavaScript bundles. There’s a high chance you’re shipping full-libraries when you only need a fraction, polyfills for browsers that don’t need them, or duplicate code.
  • Every interaction is the start of a new ‘Time-to-Interactive’; consider optimizations in this context. Transmission size is critical for low-end mobile networks and JavaScript parse time for CPU-bound devices.
  • If client-side JavaScript isn’t benefiting the user-experience, ask yourself if it’s really necessary. Maybe server-side-rendered HTML would actually be faster. Consider limiting the use of client-side frameworks to pages that absolutely require them. Server-rendering and client-rendering are a disaster if done poorly.

Related posts