> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms.
Of course it will.
If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.
Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.
Boom. You're operating close to the speed of light.
> They are both well known gaps that make integrations a pain in the ass.
Funny how you keep not saying what you mean across two threads. While accusing others of being ignorant, partisan, or never using something, it looks like you're just describing yourself.
Literally everything that runs in the browser is "aligned with the platform" since there's nothing but the platform that is running in the browser.
Meanwhile, "the aligned with platform" lit.dev is busy reinventing React, but poorly:
- uses non-standard syntax like `<div ?hidden=xxx .value=yyy .@click=zzz`
- special functions of the form "this particular function call even though it looks like a regular function call will actually throw an exception if used outside a very specific place inside a string". See "built-in directives"
- as a part of the mess that is Web Components in general is now busy reinventing React Context
and so on and so forth.
But yeah, sure, "more aligned something something"
Something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:
- could go ahead an do the same "doctoral research" that Casey Muratori did and retrace his steps
- could pool together their not insignificant salaries and hire Casey as a consultant
- ask their managers and let Microsoft spend some of those 15.5 billion dollars of net income on hiring someone like Casey who knows what they are doing
> might not be fully applicable to the development of mainstream commercial software that has to try to be all things to all people, including considerations like internationalization, accessibility, and backward compatibility.
Windows Terminal has none of that. And his refterm already has more features implemented correctly (such as proper handling of Arabic etc.) than Windows Terminal. See feature support: https://github.com/cmuratori/refterm#feature-support
I do take significantly more pictures than I would with a film camera, but this also affords me the freedom to take the pictures right there and then, and not agonise over whether "a shot is worth it".
And yet, I don't end up with thousands or even hundreds of pictures. Almost a full year of 365 challenge somehow taught me to look out for actual good shots, and not obsessively hold the shutter button to everything.
This is a commercial for-profit company, GitHub, taking some code and storing it in cold storage of some other commercial for-profit company, with no one, except these two parties have access to this code. And it doesn't look like GitHub even has the right to do it because it stores it for some purpose other than whatever is stated in their ToS.
I wonder if the whole kerfuffle around Copilot will end up spilling some light on this, too.
...provides prime-rate marketing bullshit in its marketing materials
> Thus I think it's actually a Github's generic usage grant in the ToS
If you refer to Section D.4, then:
- Arctic Vault is not "for future generations", but for GitHub only, since that section doesn't permit GitHum to just make copies willy-nilly for anything other than "as necessary to provide the Service, including improving the Service over time" and "make backups"
- This specifically makes GitHub "the owner" of that data, and not "some third-party" as you originally suggested
> Github does not own the Arctic Vault, there is an independent company behind it
Github are the ones doing all the archiving. So, in essence, they do own that. Piql are just the ones providing the storage: it's a commercial for-profit entity employed for backup by another commercial for-profit entity.
There are so many things that are not FUN, but have to be done anyway. And more often than not the not-fun things are the direct consequence of the "FUN" projects.
Of course it will.
If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.
Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.
Boom. You're operating close to the speed of light.