You are correct, there are ways to do so. There are also soft-locks which are states which are just incredibly hard to get out of (heat death of the universe type scenarios some times). Pikasprey yellow is one youtuber who chronicles things in that area.
But I think the commenter above meant that Pokémon was a game which was possible to complete in a twitch plays style because it doesn't result in game over like an FPS or platform we would for example.
Further:
e: dialectal version of "det", i.e. "it"
öa, åa: adding an a on the end of a noun is a dialectal way of expressing "the 'ö'" and "the 'å'", respectively.
The cost of their actions is easier to frame if you know the details of their implementation.
If people just naturally like using FB that's fine. If FB is hiring experts for behavioral studies in order hypertune a pipeline that exploits blind spots in the way the human brain works... that's a lot less fine. And if the inputs are wider in scope than the general public realizes, it becomes even less ok.
People will always have free will and most would rather we don't try and override that by just making all social media illegal or something... but there's an inherent asymmetry in the resources social media companies have in dissecting the psyche vs individuals have countering that.
Forcing them to show their cards is one way to thrust the results of that asymmetry into the spotlight and better equip individuals who often don't understand the extent to which they're being manipulated.
I think developer speed is more important than optimising clock cycles unnecessarily. Generally writing to dom is much much slower than evaluting a few thousand expressions.
> I think developer speed is more important than optimising clock cycles unnecessarily.
Developer time is spent once.
Users will always have to pay the price of additional run time.
For. Each. Single. User. Always.
It scales!
Due to the scale of, e.g. slow front-ends, with millions of users, this takes a HUGE amount of time. Only to save a few hours or days to develop it better.
Having 1 million users each wait a single second is already 11 days. If they have to wait that single second for each interaction, it quickly adds up.
It is also bad for the environment due to scaled up inefficiency and resulting increase of power usage.
> Having 1 million users each wait a single second is already 11 days.
This will sound like a nitpick, but it's actually worse. 1 million users waiting a single second is 11,000,000 seconds, right? A day has 86,400 seconds. 11 million divided by 86k is 127.31.
That means million users combined just spent 127 days and 8 hours because of the "just one second" delay.
Ah that's what happens when I don't have my cup of coffee in the morning. I went from 1 to 11 million in a typo and didn't even reason. So yeah, it was 12,7 days, not 127. Guess I'll double check having my coffee next time I'm doing back-of-the-napkin math /facepalm
Although I 100% agree with you, the problem is that these costs don't affect the original developer; it is an externality; a lot like carbon pollution. It's cheaper for the organisation to optimise for developer speed, even if the cost of that is borne by all the users.
I’m not claiming that we should not improve that single second, but summing it is a meaningless operation. It doesn’t matter for a user how many other user spent time on it as well.
Killing flash was not about UX. The issues with it were technical.
Flash was not the UX for systems, but for fun little games and a means to tell a story in a way which wasn't available on the Web 20 years ago. This UX is fine as it is IMO. Cool even.
Sorry, but this is completely ahistorical. Before the iPhone came along (which did, thankfully, put the final nail in the coffin) there was a decade long battle between the web usability community and Flash designers over much more than just games. I know this because I worked on both sides of that divide in web agencies and beyond in the late 90s and early 00s. In all the tests I've conducted of these fancy scroll-driven UIs, users perform worse in navigation, information retrieval and comprehension tasks. It's boring to fight the same fights over and over again.
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write.
My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.
I agree, and the competition is at this point more between VS and other full-featured IDEs like JetBrains Rider, which is my tool of choice for .Net-development.
But, what I didn't know until this recent debacle, is how there is a theory that the reason the .Net-tooling in VSCode is so bad is the same reason we had this watch-debacle. There was some discussion on that in the other HN-thread: https://news.ycombinator.com/item?id=28968231
I think in this case it's more like "let's not implement something for one language".
In VS the Solution Explorer lists Project Items, not files. Eg it lists DLL References. This means the entire tree view goes through the IVsProject interfaces and you open Solutions and Projects, not folders.
VS Code works on files only and doesn't have a project system that can specify file nesting rules. The simple ask in the PR could be implemented, but it seems arbitrary and other languages will ask for their own rules. (Vue?)
But I think the commenter above meant that Pokémon was a game which was possible to complete in a twitch plays style because it doesn't result in game over like an FPS or platform we would for example.