Live data from Hacker News

Twitter.com's HTML, which is produced by React Native for Web, explained

giuseppegurgone.com

111–120 of 163 posts

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#111
post #79

Lots of classic HN dismissals here, though I am glad we as a community have finally gotten past the anger around requiring JS to use the site. In my mouth, Twitter is probably the best, most responsive web app I've ever used. It is not trivial to make a responsive infinite scroll that remembers your place on back, live updates gracefully, has useful shareable URLs, keeps memory usage low, loads quickly, etc. To me it…

Agreed. I’d love to hear some alternative examples to Twitter’s web app or how one could build it faster.

Also I’m curious if the original Twitter lite was well engineered. I generally share all the criticisms above about the web but I thought Twitter’s Scala back end actually made the response fast and resilient. I mostly use the iOS app but never had problems with the mobile (until recent changes).

https://blog.twitter.com/en_us/topics/product/2017/introduci...

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#112
post #31

Twitter's website is absolute garbage, the feed is unresponsive, tweets fail to load, it's just terrible. If you're modeling your frontend off of anything please do not pick Twitter because their web experience is awful.

Are we using the same website? Twitter is none of the things you mention for me.

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#113
post #15

The classic mistake of thinking role=button replaces . It doesn't (as mentioned in the linked PR comments). Native HTML buttons are supported by all user agents and assistive technology and provide keyboard and focus requirements by default [1]. The "short answer" they give as to why they did this (a flexbox bug) links to a comment from February saying this was fixed in Firefox 63. https://developer.mozilla.org/en-US…

I think years of only development has destroyed most developer's knowledge of semantic HTML elements. There are over a hundred elements with various meanings, but to a visual user, they all look the same. With a renewed interested in A11Y people are still starting to rediscover these, but it's still slow.

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#114
post #31

Twitter's website is absolute garbage, the feed is unresponsive, tweets fail to load, it's just terrible. If you're modeling your frontend off of anything please do not pick Twitter because their web experience is awful.

My only complaint about Twitter on desktop web is that the feed auto updates itself. And it always happens just when I'm watching a video or I'm about to click on something...

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#115
post #31

Twitter's website is absolute garbage, the feed is unresponsive, tweets fail to load, it's just terrible. If you're modeling your frontend off of anything please do not pick Twitter because their web experience is awful.

I pulled some raw twitter yesterday for the first time in a very long while. The amount of general purpose, world-wide javascript junk was hard to look at.. not as densely scrambled as Google js output in the past, but the number of special cases for "media in Taiwan" or whatever else, just went on and on.. per-tweet

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#116

Amusing anecdote involving div soups: Back in 2010 in one of my CS classes, the professor maintained a Google Sites to communicate with her students and upload slides. At the end of the semester, she wrote a list of students who must take the finals to get at least a passing grade. The thing is, you view it Chrome, the list displays normally, a handful of students. But you view it in Firefox and it's an empty list. O…

Wouldn't be surprised if this was an output of a WYSIWYG editor. These are notoriously bad for outputting garbage HTML, especially since multiple edits to the content can leave behind unneeded elements. Browsers are incredibly tolerant of invalid HTML (will do things like add closing tags), but they aren't all the same. When you generate garbage HTML, it's easy to see the differences between browsers and their attempts to correct it.

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#118
post #100
post #90

Earlier quoted context omitted.

About 90% of my interaction with Twitter is is clicking a link from HN. When I do so, there's about a 1/3 chance that tweet doesn't load.

I was under the impression this was an intentional dark pattern to get users to sign up / log in to twitter? The reason I believe this is because if you get that failure and back out and click the link again it works 100% of the time.

Tweets don't load a significant amount of the time even when I'm logged in.

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#119
post #79

Lots of classic HN dismissals here, though I am glad we as a community have finally gotten past the anger around requiring JS to use the site. In my mouth, Twitter is probably the best, most responsive web app I've ever used. It is not trivial to make a responsive infinite scroll that remembers your place on back, live updates gracefully, has useful shareable URLs, keeps memory usage low, loads quickly, etc. To me it…

> Twitter is probably the best, most responsive web app I've ever used What machine are you running it on? I'm a regular Twitter user and it is hands down the slowest most unresponsive webapp I use: worse than Slack or Gmail. Fwiw probably the best complex responsive webapp I use is YouTube (loathe as I am to compliment anything produced by Google's web frontend teams as the rest of their webapps have been consistent…

What universe are you living in? Slack and GMail are horrendous compared to twitter. Twitter loads almost instantaneously. Only web app that correctly handles infinite scroll.

Re: Twitter.com's HTML, which is produced by React Native for Web, explained

#120
I am increasingly of the opinion that we need to ditch HTML in order to protect and advance the open web. We've lost something valuable in this brave new HTML-as-a-compile-target future. The original intention of HTML was to serve as a a lightweight, semantic language that people could use to produce documents that were more-or-less structurally understandable (by both humans and computers). Now it's so muddy that we may as well be downloading binary files. (Sometimes we are.)

Gone are the days when you could disable custom CSS and still kinda-sorta navigate the web. These days, it is en vogue to tightly couple what we're seeing on an HTML page (a product listing, a social media post) with instructions about how to render it (250px wide, black background, blinking marquee text). This is great for the tech companies that are producing these HTML blobs, because they have a lot of control over what they're showing to their users. It's only good for the users if they're 100% happy with how the data is being presented. I don't know about you, but I'm rarely happy these days. To say nothing for users with more stringent accessibility requirements.

I wonder if there's a future where we all use a different kind of web browser -- one that doesn't accept any styling instructions from the websites it's visiting. It would probably need to be built on top of accepted data types for various things, like product listings or social media posts. That way, it wouldn't matter whether I was looking at a product on Amazon, Ebay or Etsy. I could tell my browser that I want all product listings to be rendered in dark mode, with a thumbnail preview image instead of a full-sized one, regardless of what site I'm currently on.

Google is already in the process of trying to become this kind of "browser". It has the advantage of being the "front door" of the internet in doing so. It aggregates, and homogenizes, similar documents from various companies and presents them in a uniform way on the results page (eg, hotels, flights, word definitions).

I don't want to rely on Google to do this for me. I want the documents of the web to be semantically meaningful to the point where my browser can make opinionated decisions about how to style the information I'm downloading.

Post reply on HN