I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API.
Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.
> poor sleep quality, headaches, stomach issues and back pain
While it's true that volatile-pay work is extremely stressful, this seems like a cherry-picked study to be able to write a flashy headline to people rightly concerned over a hot-button issue. They could have just as easily just said that volatile pay causes anxiety and stress, which IMHO you don't need a study for, just like we don't need a study saying that eating less increases hunger symptoms.
Anxiety and stress itself is a well-known cause of all these above issues, and there are a multitude of other work-related stresses than just volatile pay.
>Every API endpoint is a promise, and it's also a constraint on future innovation.
I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.
I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.
Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner.
For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.
Ha. Happens to be there is a script out there somewhere which allows you to extract the private key of any of your MFA codes from Authy through Chrome DevTools (it's an Electron app) so you can use it in whichever MFA solution you want.
Under President Arafat, the Fatah-dominated Palestinian Authority adopted the 2003 Amended Basic Law, which stipulates Islam as the sole official religion in Palestine and the principles of Islamic sharia as a principal source of legislation. The draft Constitution contains the same provisions. The draft Constitution was formulated by a Constitutional Committee, established by Arafat in 1999 and endorsed by the PLO.
External actors, hmmm... I believe you mixed that up with internal actors like Hezbolla and others, who have a tight grip on the countries political system.
Last time I checked the leader of Hezbolla, which is part of the government of Lebanon said: "There is no solution to the conflict in this region except with the disappearance of Israel."
While they might sound convincing that they might mean this for everyone's good (and it might be good for everyone, this is typical of Google in GCP and elsewhere trying to force more modern experiences because "they know better" than everyone unwilling to upgrade their platform.
I've used VueFormulate in the past, and it was extremely powerful albeit somewhat bloated. FormKit seems like a step in the right direction. Good Luck!
https://flightcontrol.dev gives you some sort of `your own Heroku on your own AWS acct` very interesting concept, also can be a replacement for Heroku.
https://fly.io has been amazing for me. Dunno how their docs used to look but IMHO today it is very detailed they are especially forward-thinking regarding documenting some nice edge use-cases for the platform.
> Vue offers an interface that is extremely heavily transpiled and modified before it actually resembles code that can run on the browser, and uses an entirely magic (read: opaque) rendering system
Not entirely true. If you're looking to code that "resembles code that can run in the browser" without that much "magic", Vue has an interface for directly declaring render functions, also for the possibility of using JSX.
Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.