The meme format is awesome, but JSON differentiates strings with ".

{ "key": 1337 } vs { "key": "1337" }.

You might be thinking yaml? (Though it supports ' and " for explicit string types, technically)

But integer vs float? Good luck.

I didn’t really care about this thread until I read this comment.

The Who were kinda silly (eg: Boris the Spider) in their early years.

Timestamp in UTC

But for time of day, use local time and store separate column with the timezone name. Don’t use timezone offsets since that doesn’t work with DST. You’re better off with something like America/New_York because God knows what 2030 will look like.

And if timezone are abolished, or DST, that’s even more reason to store the timezone name.

Your dad is right. On desktop, navigation is on the left. On tablet, you shrink it to a rail. On mobile it should be a dismissible nav drawer.

The top menus, especially the flyover(on mouse hover), are bad for accessibility because they convert a non-committal action (hover) to a context changing one (focus). It’s a uniquely web-only invention and thankfully falling out of usage. (Unless you mean menubar/toolbar. Those are fine but extremely rare on Web.)

Yeah, that’s a big simplification and I get it. But the async syntax itself syntax “sugar” for Promises. It’s not like C# or Java/Android where it will spawn a thread. If you take a JSON of 1000 rows and attach a promise/await to each of them, you won’t hit the next event loop until they all run to completion.

It’s a common misconception that asynchronous means “run in background”. It doesn’t. It means run at end of current call stack.

Prior to that, the browser had window.setTimeout and its callback for delays and animation and such - but that’s it.

And you STILL have to call setTimeout in your async executions or else you will stall your UI.

Again async is NOT background. It’s run later. async wraps Promise which wraps queueMicrotask.

Here is a stack overflow that explains it more in detail.

Preventing the ui thread from waiting on native IO is what async was created for.

Citation needed. async just a wrapper for Promises. IO isn’t related, just commonly used with it.

https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-async-functions-abstract-operations-async-function-start

NodeJS’s IO and fetch are just promises. (And NodeJS used to use callback(err, response) before adding promises.).

I don’t code much C++, but then I’d lose alignment with: x = *p; and I feel that would bug me.

I’m looking at Google Style Guide for my next project and it says either is fine, just don’t declare more than one per line.

Async prevents locking a thread during this wait.

That’s a very common misconception. async is just a scheduling tool that runs at the end of event loop (microtask queue). It still runs on the main thread and you can still lock up your UI. You’d need Web Workers for actual multi-threading.

async/await is just callback() and queueMicrotask wrapped up into a neat package. It’s not supposed to replace multi-threading and confusing it for such is dangerous since you can still stall your main/UI thread with Promises (which async also wraps).

(async and await are also technically different things, but for the sake of simplicity here, consider them a pair.)

You don’t need Typescript, you need an linter (eslint).

=== is your basic equality like most languages. == will implicitly cast type.

The breakdown is here: https://262.ecma-international.org/5.1/#sec-11.9.3

Modern JS says to never use == unless you’re comparing against null or undefined.

Did well with Brother laser printer. Canon was okay.

I had setup a friend’s HP printer and noticed he was constantly switching to WiFi Direct in order to print. I did him the favor of connecting it to the AP, so he wouldn’t have to manually switch all the time.

The moment it got online, the printer locked itself down and refused to continue print until he paid for a subscription service on the ink.

We don’t like when people add color to our monochromatic text.

Good ol’ Alt+1``3``0.

I guess Beyonce has no love for Extended ASCII.

That’s a strawman. I don’t need 1000s of lines of JS to swap a UI. I can do it in 1 line with Web Components: oldElement.replaceWith(newElement). And those modules can be lazy loaded like anything else.

This is just DX in name of UX, which is almost never a good idea.

And maybe you’re fine with throwing a server computation for every single UI change, but I’m not made of money and I much rather have stuff on a CDN.

C’mon, what’s not to like about bonding every UI action against a remote server? What’s a few milliseconds anyway? I’m sure it works fine over cellular networks. I mean, it works great on my dev machine! /s

PascalCase default exports for Classes

camelCase named exports for functions

ALL_CAPS named exports for constants

I just recently worked on fixed point 8.8 and basically the way fractional values work, you take an integer and say that integer is then divided by another one. So you represent the number in question with two numbers not one. 0.3 can be presented in a number of ways, like 30 % 10, or 6 % 20.

The problem is the way 0.1 is represented and 0.2 represented don’t jive when you add them, so the compiler makes a fractional representation of 0.3 based on how 0.1 and 0.2 were expressed that just comes out weird.

That’s also why 0.3 + 0.3 is fine. When you wrote 0.3, the compiler/runtime already knew how to express 0.3 without rounding errors.

You can use Dev Tools to see a page’s full accessibility tree:

Chrome: https://developer.chrome.com/blog/full-accessibility-tree/#full-accessibility-tree-in-devtools

Firefox: https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/#features-of-the-accessibility-panel

I haven’t really looked for anything that will present that to you as an Add-On/Extension but it’s theoretically possible.

We’re kinda getting it back with the Accessibility tree

In theory, if the page is compiled right, you can read everything right from there. You could also interact with it.