Explore My Notes

The React cheatsheet for 2020 | freeCodeCamp

A very hand overview of the core concepts in React, from JSX to fragments to hooks. Includes quick reference to the core hooks and how/when to use them e.g. useState, useContext, useMemo etc.

📆 16 Jun 2020  | 🔗

  • JavaScript
  • React
  • cheat sheet
  • guide
  • React hook
  • useContext
  • state management
  • JSX
  • fragments 

Var, let, and const, what's the difference | freeCodeCamp

var is globally scoped and hoisted, which can lead to unintended side effects. let is block-scoped and can never be redeclared within that scope – much harder to break, but need to be careful about passing it to where it's needed and aware that it is still hoisted, albeit with no value (not even null). const works similarly to let, but you cannot update the value (though you can update internal values).

📆 16 Jun 2020  | 🔗

  • JavaScript
  • const
  • let
  • var
  • variables
  • JavaScript
  • scope 

Images good to the last byte | Evil Martians

An exhaustive guide to image optimisation, compression, formats, and quality on the web.

Quality can be boiled down into the following traits: sharpness, colour accuracy, and rendering artefacts/pixelation. But the quality needed is determined on the context. If the image is the main focal point, quality should be kept high; if it's a background or secondary feature, dial up the optimisations. If the image needs to by particularly dynamic (animation, scalable, etc.) then vector > raster.

The human eye/brain perceives variation in luminance and contrast far more than colour variation. Different browsers use different image rendering engines. CSS pixel values are physically larger/smaller depending on screen resolution and size. For example, the same "size" image (1000px wide) on a Retina display will actually use 2000 pixels in width, meaning every single "px" is equal to four screen pixels. That means your image will be scaled-up, potentially changing quality. The article contains an excellent explanation of how browsers upscale images.

That's why SVG is so powerful. It scales perfectly because it's just math. The absolute values of each pixel are drawn for the render context, not the other way around. But that increased data means SVG gets large. More complex images are huge. Compressors like svgo are massively useful for counteracting that. Article contains a list of raster compressors and automation tools as well.

In general, PNG files are larger than JPEGs, but JPEGs can't do transparency. PNGs often have fewer artefacts so render text more crisply. WebP is as sharp as PNG, but smaller than both previous file types, and can be compressed much further than JPEG without obvious loss of quality. It's still not fully supported, though, and can't be saved to desktop (though that could also be a security benefit). Weirdly, single-frame AVI video files are often the best for quality/compression if you can ignore tenuous browser support.

GIFs are terrible, APNG is much better and animated WebP has some advantages, but again video > animated image in all cases. Both MP4 and WebM are more efficient.

📆 16 Jun 2020  | 🔗

  • Frontend
  • SVG
  • web performance
  • images
  • contrast
  • upscale
  • vector
  • raster
  • compression
  • optimise
  • PNG
  • JPEG
  • WebP
  • video 

Colour theme switcher | Max Böck

Max has a pretty brilliant colour theme switcher on his website. I agree with him that "dark mode" is only the tip of the iceberg and with CSS variables we can now theme sites very easily. There are also some great easter eggs in here. It's the kind of thing which leaves you wondering how you didn't come up with it first.

Five theme options, each named after a Mario Kart level, with text reading "fact: all good design is derivative of Mario Kart".
Koopa Beach is my favourite, both as a theme and as a track 🐢

Plus, Max's site is just a pleasure to use/read. Some great ideas on display throughout.

Debugging is twice as hard | Brian Kernighan

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Brian Kernighan, co-creator of Unix.

Clean up your online presence | Deseat.me

Not entirely sure what permissions you have to give it, but Deseat is an interesting idea that could come in handy when tidying up your web presence. It (somehow) compiles a list of accounts that you have and gives you a one-click "delete" option, which I assume fires off a data deletion request.

📆 16 Jun 2020  | 🔗

  • Technology
  • social media
  • uninstall
  • unsubscribe
  • delete
  • web
  • tool 

The great divide | Chris Coyier

The infamous frontend divide, the feeling that JavaScript-everywhere has caused a schism in what a frontend developer is. Should they be split into JavaScript Engineer and UI Engineer? CSS, accessibility, design patterns, semantics, UX engineering are all still skills that are needed but they don't necessarily align with JS needs or wants. It's two different brain states (or is it?). Some people will bridge that divide, but should we be requiring it?

Two “front-end web developers” can be standing right next to each other and have little, if any, skill sets in common. That’s downright bizarre to me for a job title so specific and ubiquitous.

I love this sentiment on using complex toolchains to reduce overall system complexity:

Sometimes it feels like releasing cougars into the forest to handle your snake problem. Now you have a cougar problem.

And there are some clear benefits to JavaScript "getting big" and being used everywhere.

A front-end developer with a strong JavaScript skill set is wildly empowered these days.

Or is the divide actually between frontend developers who give a crap about users and those who don't, regardless of tool stack? Some people prefer working on code than working with people, and that's okay, but when you're job is building stuff for people it leads to what I'd consider a poor work ethic (or at least a poor job fit). Right now, the industry seems okay with that, but perhaps it shouldn't be. As frontend becomes more focused on traditional engineering concepts, are we losing sight of its purpose: positive user experience.

The typos that changed lives | The Guardian

  • An elderly gent who inadvertently had his satnav set to "Rom" instead of "Rome" and wound up in the wrong country;
  • A pilot that incorrectly input destination coordinates causing a Sydney flight to Kuala Lumper landing in Melbourne;
  • A nurse who keyed the wrong drug code into a dispensary machine and accidentally treated anxiety with a poison used as part of the lethal injection, killing someone;
  • A Companies House employee who began the liquidation of a 150-year old engineering firm because they missed a pluralisation (Taylor & Son/Taylor & Sons), ultimately causing such loss of business that the highly-profitable firm ended up going bankrupt (though later successfully sued for £8million);
  • Nigel Lang, Sheffield, ended up being investigated for child pornography, unable to see his family for three weeks and left traumatised, contemplating suicide, because someone at the police station mistyped an IP address that would take years to clear up;
  • On the other end, Kasey Bergh and Henry Glendening (US) ended up meeting because Kasey mistyped a colleague's number, ultimately got married, and then when Kasey's kidney failed Henry was an ideal match, saving her life.

Understand JavaScript closures in minutes | freeCodeCamp

I always forget what closures are, even if I continue to use them. The article makes a case for considering closures as stateful functions which is quite neat. Basically, closures allow a function to return another function (or functions); each returned function will also have access to any data that the original function had access to. In other words:

const add = function(x) {
    return function(y) {
        return x + y;
    }
}
const add10 = add(10);
add10(10); // 20

That will output 20 because the internal function has access to both variables. It's a bit freaky but it means you can define functions as reusable abstractions with preset variable values really easily. As the article points out, that can be a lot more secure and can help encapsulate sensitive data/functionality, like so:

const manageBankAccount = function(initialBalance) {
    let accountBalance = initialBalance;
    
    return {
        getBalance: function() { return accountBalance; },
        deposit: function(amount) { accountBalance += amount; },
        withdraw: function(amount) {
            if (amount > accountBalance) {
                return 'You cannot draw that much!';
            }

            accountBalance -= amount;
        }
    };
}

const accountManager = manageBankAccount(0);

accountManager.deposit(1000);
accountManager.withdraw(500);
accountManager.getBalance(); // 500

📆 15 Jun 2020  | 🔗

  • JavaScript
  • closure
  • JavaScript
  • stateful function
  • security
  • abstraction 

Airbridge

A new calendar app without an implicit bias towards iOS is always worth celebrating. Airbridge certainly ticks the aesthetically-pleasing box and I quite like the idea of just defining time blocks as you go, rather than fitting things to a grid (which so often isn't flexible enough). Colour coding also looks great. No mention on whether you can sync calendars between accounts (a feature that would be incredibly useful to me), nor how much it is likely to cost once out of beta, but one to keep an eye on.

📆 15 Jun 2020  | 🔗

  • Technology
  • calendar
  • apps
  • Android
  • PWA
  • organisation
  • to do list 

Our skulls are out-evolving us | Katherine Reynolds Lewis

Over the last 250 years, our skulls have morphed in dangerous and troubling ways.

Nasal passages and jaws are narrowing, overbites are becoming more extreme, palates are rising, skulls are shrinking. The result is less face to fit everything into, meaning crowded dentition, breathing problems, and potentially insufficient space for growing brains. It could even be a root cause of elevating asthma rates, joint pain (particularly in the young), and allergies, whilst sleep disruption caused by narrow air spaces is already well documented at causing anxiety, depression, and behavioural disorders in people of any age.

Narrowing of facial features, in particular, seems linked with industrialisation; less-industrialised nations suffer from these issues less and the anthropological record show these conditions to be incredibly rare throughout human history. From about 250 years ago, morphological changes away from a consistently "broad, straight, wide" skull shape seems to have accelerated. One possible reason is the sudden introduction of bottle-feeding and soft "baby" food that may cause our chewing muscles to underdevelop. Environmental pollutants are a second potential factor (obviously).

The impact is most serious in children. Studies cited have shown links with sleep issues in young kids can reduce their functional abilities by the equivalent of two years (!) and result in lower average lifetime earnings. It increases mood swings and makes kids cranky, less able to focus, retain information, or be creative. It's also a key risk factor in childhood obesity.

Parents know sleep is important, but they rarely realize how proper sleep relies on a wide dental arch, tongue on the roof of the mouth, and long lower jaw.

Treatment using centuries-old techniques has positive results:

Within a month, Micah’s sleeping improved and his behavior transformed. Previously, he cried at doctor’s appointments, balked at going to school, acted cranky, and hid behind his mom around guests. Now, he smiles freely and runs up to his grandparents for hugs.

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.