Contrary to what seems to be Google's belief, most websites are _not_ continuously deployed SPAs with a team of engineers who work on each release. The indifference shown to actual developers here is staggering.
The original goal of reducing news prevalence was to show less outrage/clickbait and show more friends and family content. Of course, hindsight shows that the move was of limited efficacy, but it's disingenuous to suggest that it was done in order to 'squeeze journalists'.
This is correct. Nothing overtly nefarious is happening here (above the baseline level of telling FB who your customers are in order to figure out how much ROI your campaign had).
> Facebook is effectively grading their own homework here and ignores other marketing campaigns that may have contributed to the action
One thing I'd add is that FB is _still_ incentivized to accurately attribute actions. Over-attribution (and thus over-estimation of ROI) would give FB more spend in the short term, but would hurt them in the long term by causing auction inefficiencies.
This is the reason direct action campaigns on Google are perceived to be low(er) value: last click attribution disproportionately favors AdWords.
It's much more reminiscent of BB-style forums where moderators were part of the community and would explain their actions at the time of enforcement. This is unfortunately un-scalable, and so larger communities turn to strictly enforced rules with zero flexibility a la Reddit or moderation via machine classification like FB, Twitter, and YouTube.
In my opinion bottom sheets are actually a far superior experience to the previous pattern of dialogs/modals or push screens:
- The user doesn't lose their navigation stack because they can tell the bottom sheet can be dismissed, they know where they "came from"
- The user keeps visual context on whatever triggered the bottom sheet, because they can still see what's behind it
- The user doesn't get forcibly navigated away from whatever they were browsing, they know that once whatever they're doing in the sheet is done, they can "go back".
My only complaint is that Apple added them to stock apps in iOS 12, so many iOS users got used to the pattern, but didn't provide an easy way to give the same experience for developers which creating a need for libraries like this.
Thank you as well Jeremy, for helping us realize how useful JS could be with a proper stdlib in underscore, or how JS could be evolved with Coffeescript.
Part of the magic of JS in those days was observing how one OSS project (see: underscore, async, Q, Backbone, Node, Babel, Browserify, etc) could have such a profound impact on the JavaScript ecosystem.
I've seen cases where Apple will actually decompile/debug your app and point you the exact feature / method / line that they find unacceptable. Despite all of my other complaints about iOS ecosystem, they _do_ keep their App Store walled garden fairly well tended.
React is usable without JSX, which is just syntactic sugar for `React.createElement()` calls. If it's the complexity of babel/tooling that turns you off, it's also possible to use _just_ JSX without other transpilation steps: https://reactjs.org/docs/add-react-to-a-website.html#optiona....
Excellent list! I'd also recommend adding "What is this?" to the list, and for extra credit, do some research on the vernacular / polite way to address strangers in public ("Excuse me" also works for this in a pinch, although not in all cultures!).
I actually prefer the butterfly keyboard's clickiness – coming from a mechanical keyboard, I always found the chiclet keys a tad too mushy. And the jarringly-short travel, while annoying at first, is easy to adapt to.
The thing that turned me against the butterfly keyboard were the reliability issues. I've had to get replacements for broken keyboards three times: spacebar stopped working, `f` ended up double typing every single time, and capslock (I remap to Ctrl) would 'stick' for a few seconds when pressed.