This is a detail, but it's imo illustrative of how refined Apple UI is and how easy it is to get it wrong.
The design of how the Dock scales and animates follows a very simple principle: if the mouse is outside the dock, and you move towards an icon vertically, entering the dock does not shift that icon around. Because that would make it feel "jello" and uneasy, like this imitation.
- you first need to lay out the scrollable content normally, without a scrollbar
- then you need to detect whether it spills over, and whether a scrollbar is needed
- if so, you need to lay out all the content again, in a slightly smaller area
- if the content ever shrinks, you need to detect this too
- and if the content only _just_ fits, then it is possible that without a scrollbar, it doesn't need a scrollbar, but if there is a scrollbar, it needs to be scrollable. Chicken and egg.
This is actually pretty nasty to get right. Now factor in layout models like flex box, which also require part of the content to have a "pre layout" pass done in order to estimate "natural size", and it can get quite gnarly. And if you want to mix vertical and horizontal layouts... oof.
I got an equivalent of HTML/CSS box+flex working in Use.GPU but it took plenty of iteration.
I think the lesson here is that UI is always more complicated than you think. There are countless little tricks and mechanisms that you would only ever notice it if they didn't work. When they do, it is so "obviously" right you literally can't tell.
(As an aside, whoda thunk that a generation raised on participation trophies would be easily triggered???)
Yes, scrollbars are not completely trivial, but what you describe used to be a solved problem on desktop UIs, and the reason for making scrollbars invisible were purely aesthetic.
- Make vague generalizations about white people, men
- Blur the distinction between non-credible fringe groups and some of the most credentialed institutions around so you can play the underdog
- Ascribe all actions taken in name of minorities as the express wishes of those minorities, even if they are ineffective or destructive
- Frame it as redress for hundred years of "history" (read: the specific grievances of North American colonialism)
- Wrap it all up in a blue=good red=bad American apple pie with a Trump bow while simultaneously deriding others for being too set in their ways
There are colleges that are demanding _diversity and inclusion loyalty pledges_ with adherence to a _specific socio-political agenda_, and you think "science is political" is just stalling from people who have lost perspective?
It's only a spectator sport if you're not downstream from those changes though.
I also think ageism is only part of the problem, it's stubbornness in general. Even if you're younger, it's difficult to translate hard-earned experience into respect because many engineers are infatuated with their own designs and algorithms. I've had people reject my advice even though I literally worked 2 years on app dedicated to solving that specific problem we were having. Of course they had egg on their face at the first demo. And they're still using that broken code.
*is a game developer with a particular focus on "RETVRN TO TRADITION" where anything that isn't super lean-and-mean is bloated and inefficient and ridiculous, and only exists because web developers are misguided, miseducated, etc. WebRTC could do what he wants, but then he'd have to build a WebRTC->pure UDP gateway.
I can sympathize, but, even in the original discussion on Twitter it's clear he is ill-informed of the relevant security fiascos that made all these complicated protocols necessary, or the messy legacy constraints they must operate under. Infrastructure is not magic, and tying together e.g. application-level concepts with DNS-level concepts would be a recipe for misery IRL.
I also find it funny he considers the string/text-based parts of HTTPS to be unworthy of a secure protocol, when in fact, the whole reason that approach is considered so dangerous is because of programmers with his attitude who underestimated the difficulty of secure parsing. The niche of "LangSec" is all about solving this problem properly by treating input processing as a formal parsing problem with formal grammars.
Is it really necessary to attack Casey with this two bits sarcasm? You can disagree and still be polite for the sake of me taking you seriously, if not for his.
>The application event loop coalesces these damage rectangles and initiates an optimized operation: it only redraws views whose bounds intersect the damaged region, and also passes the rectangle(s) to the drawRect:: method. (That's why it's called drawRect::).
So, according to this, you need an explicit run-time mechanism to optimize the interaction of parents with children, with some form of coalescing.
Antithesis:
>This is another reason why it's advantageous to have a stable hierarchy of stateful objects representing your UI. If you need more context, you just ask around. Ask your parent, ask your siblings, ask your children, they are all present. Again, no special magic needed.
...except here, where OP says you don't need any special magic to deal with parent/child relationships: just reach up/down/left/right and do your thing!
Synthesis:
The reason one-way data flow became so popular is exactly because the second view is a trap, or at least, a local maximum. If you are really doing complicated orchestration in your hierarchy, then you will end up reinventing the first wheel, to avoid expensive/inefficient parent/child/parent thrashing cascades.
React does in fact have a good solution for this, in the form of contexts. These also allow you to reach up and go talk to parents, in a controlled yet composable way. The way I describe them is "singletons but with scope". An underappreciated benefit is that you can extend a parent context and pass it down, replicating some of the benefits of inheritance, without the messyness of subclasses.
Where React falls short is that parents can't respond to children without re-rendering themselves, which ironically makes implementing e.g. nested tree widgets hard, even though the result is all tree-shaped.
Functional effect systems which can re-join after forking, and gather yielded values, do not have this issue, and I wish React would explore this avenue instead of the all the React 18 stuff they've been doing lately... it feels too much like they are leaning into the same Facebook "dumb read-only UI" style that the article correctly laments. They are straying away from React's original appeal, which was that it was "just the V in MVC", and instead becoming very opinionated on how server side and client side should be combined. Meanwhile the challenges of how to replicate complex legacy desktop UIs remain mostly unaddressed, with the official advice about event handlers, state and effects falling short by a mile.
This explanation is useless imo because it expects the reader to already understand the weirdest part:
"If I have a function A -> B, how could I possibly get something that goes in the direction F B -> F A out of it?"
The answer to this is: given e.g. a function that accepts a B, i.e. `B -> ...` you can compose it with `A -> B` on the _input side_, to get a function that accepts an A, i.e. `A -> B` (+) `B -> ...` = `A -> ...`.
Once you've managed to get that across, you can start talking about contravariant functors. But expecting people to just intuit that from the condensed type signature is pedagogical nonsense.
...and you will show your users stale data, which is a non-starter for a chat app. You will then need to implement some custom push/invalidate mechanism, based on a custom interpretation of the DB event log.
The entire point of the Fire* style of database is that these trade-offs are not worth it in the long run, that few development teams have the skill and time to implement this themselves, and that databases can and should solve this for you.
I have little love for Cloud Firestore, it's a trash fire riddled with poor decisions, but if you don't even understand what the problem is with that SQL query, you don't understand the expectations users have nowadays of front-end applications.
Why would a SQL query show stale data? Inserts and selects are fine, the only thing needed is signaling. You can use Firestore for that, or just a separate thin layer on a much more capable database backend.
> "that few development teams have the skill"
This is the fundamental problem. There's no magic answer to a lack of skill.
Because the way that you will ultimately have to scale something like PostgreSQL for example is going to end up with eventual consistency which Firestore doesn’t have to deal with.
There's no reason for eventual consistency. Firestore is backed by BigTable and Spanner (both strongly consistent just like Postgresql). There's nothing magic about this - it just provide a pub/sub channel on the watched keys and automatically does a SELECT loop in the background once an INSERT triggers that key.
You can do the same thing on a simple by selecting by a `chatid` in a table that'll get the latest messages/inserts. Again, the only thing needed is the pub/sub layer, not an entirely different database.
There are two common social perspectives: information sharing vs emotional harmony. From one perspective, the other seems rude or insane. If your message is corrected or added to, this is a chance to be less wrong. But it is also a chance to be embarrassed and seen as less knowledgeable than you seemed.
Status seekers tend to assume the latter perspective, and therefor label such comments as rude, dismissive, conflict-seeking, etc. even if the OP had no such intention.
This is also 95% of what "help i'm being harassed online" comes down to.
Oh this explains so much. I've been raised in the optics that one should always share information in order to make the world better, didn't even think there were other reasons to, like, talk in public.
Since you’re not aware, a very common reason to talk in public is to gain something from one’s talking. The situation at hand looks a lot like that, and in particular gaining something at the expense of someone else in this case. If every ShowHN ended up directing everyone to an alternative project, no one would bother making Show HNs. Hence why it’s questionable about whether the top comment makes the world a better place, etc. That’s also why someone not apparently related to the library at hand could make the same comment without it being negatively received because they don’t appear to have anything to gain from it. I would instead encourage the poster to make their own Show HN the next day rather than hijacking an existing Show HN.
