I believe Uber eats is currently doing that. Recently I noticed an option to pay $1.50 extra for "Priority delivery" which may be a combination of what you mention as well as modifying the delivery algorithm in your favor.
I've ported a template compiler to Rust before. The reality is you still end up with something slower than native JS because of the overhead serializing and parsing the JSON in WASM memory. This is something that will be helped by the interface types proposal[0] if it is implemented but I was surprised that this use case didn't work as well as I thought it would.
Consider the requestAnimationFrame API. It will give you a 60hz timer (even higher on high refresh rate displays) but is used for a ton of animation related tasks as well as games. That said it effectively can be used as a timer which in this case would likely be precise enough.
What do you do in the case where a ton of website's use this API for legitimate animations?
I would think fonts specifically would have a large negative impact that would affect first contentful paint given that tons of sites load a few common fonts.
The student's input is rendered for teachers to make it easier to grade submissions without opening them in an external tool.
As someone who used blackboard in college I can tell you it's a mess. Neither teachers nor students like it. It integrates with a ton of 3rd party libraries to be "helpful" by embedding content like this but ends up with a ton of different, inconsistent and often broken experiences.
Not sure if this is still the case but in some areas Comcast used to limit the cap to 100gb unless you bundled TV with your internet plan, then it went up to 1tb.
Oh man I remember using the Netfirms free tier! The internet was so different back then, a company wasn't afraid of giving free compute resources on subdomains of their main site.
They posted about this on HN before, basically they are VC funded and would like to make their money back by providing community support and paid features.
Mozilla's Position:
"Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed."
https://mozilla.github.io/standards-positions/
I used to use Mullvad but switched to AirVPN. Mullvad was extremely slow in the US (under 25mbps most times) where I have found AirVPN to be able to reach ~750mbps. They also publish the congestion on their servers which is very handy for reaching high speeds.
Living in Phoenix for several years and working in Chandler (the headquarters for the self driving car division where my office was actually on the initial training route before they allowed passengers) I can say the cars suffer from being overly conservative. I don't think this is a bad thing for self driving cars, in contrast Ubers cars (before they were banned from the state for disabling collision detection and killing someone) drove aggressively. Ubers cars needed to be taken over to stop from hitting pedestrians crossing at intersections and continually drove at least 5mph above the speed limit.
In Phoenix everyone drives fast on the highway, but Waymo cars drive 5-10mph under the speed limit. There are some unprotected left turns across 4 lanes they may try but being conservative they crawl across and eventually get stuck in the middle. This is probably a good thing for now and as confidence with the engineering team on the hardware and software goes up it can likely be tuned.
I did an internship at a company building aviation hardware and software. Since everything was safety critical we used formal methods and things moved at a snail's pace.
When verification becomes the most important thing everything changes. The design specification doesn't make sense? It will take months to get it changed, write whatever code you can convince someone verifies against the design. Compile times are longer than an hour? Not a problem since the majority of the job isn't writing code but instead doing code reviews, verifications and writing tests. In fact writing code was about 15% of that job for the lowest level engineer. It was a whole different world than unregulated codebases are.
My team has recently focused on adding JSDoc to most of our codebase and I've been thinking, JSDoc provides essentially all the benefits (and more) of typescript from a maintainability aspect and contains none of the headaches (outdated definitely typed definitions, fighting with types...). As long as you use something to validate the JSDoc comments (like the JSDoc eslint plugin) they are extremely helpful in ways very similar to typescript. Language Servers like that in VSCode (tsserver) will inherit types from JSDoc comments and provide useful annotations with both the types and descriptions. They can even be used to show code examples or statically generated into webpages.
If your only argument is to use typescript for maintainability reasons doesn't using JSDoc extensively both solve and improve upon that goal?
These features are all great but Atom has some big issues to fix that have been around for years. Things like the finder reindexing files every time the window loses focus: https://github.com/atom/fuzzy-finder/issues/88
Additionally the Atom-IDE packages and what will happen with them, many of them have PRs that have been merged in to fix bugs but never published to the package (for about a year now). Although Facebook dropped support for Atom-IDE it still has nearly 1 million downloads and largely works well but can no longer be contributed to since the repo is archived and the packages aren't up to date.