The classic mistake of thinking role=button replaces <button>. 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 <i>why</i> they did this (a flexbox bug) links to a comment from February saying this was fixed in Firefox 63.<p><a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role#best_practices" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...</a>
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.<p>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's the real proof point for RN web and web workers.
> To the eyes of somebody who’s not familiar with the framework, the HTML produced by React Native for Web might look utterly ugly and full of bad practices.<p>To the eyes of someone familiar with the framework it is still full of bad practices.
Let me write it all down, it's a bit confusing. There is a React framework, created to produce Javascript backed applications running in the browser. Then there is a React Native, a wrapper to run those applications on mobile platforms by compiling Javascript apps to native code. And then here is a React Native for Web, a way to compile a Javascript React Native apps into... Javascript to run inside browsers?<p>Boy, that frontend ecosystem is really cursed.
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 <i>must</i> take the finals to get at least a passing grade.<p>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. On Firefox it would look like<p>> (MM/DD/YY) Here's the list of students who must take the finals:<p>><p>> (MM/DD/YY) [Next reminder...]<p>Sucks to be a Firefox user and be on that list.<p>A few years later, maybe 2015/2016, with a few years in the industry under my belt, I remember this curiosity and rechecked. Firefox is still not showing the list. I open developer tools to inspect and I'm greeted by an eldritch, decadent, and blasphemous nesting of divs. I did not try to understand it but it seems the stylesheet in use indents divs a certain amount and they abused this rule to get the list to the indentation they want. Probably it hit some limit in Firefox.<p>I've never used Google Sites so I can't guess whose fault is this. But it's unlikely my prof hand-wrote that HTML.<p>With this article, it seems to me that Twitter devs, for all their fancy dev toolchains, could only produce <i>slightly</i> better HTML than my professor. Perhaps the industry in general is really not much better than Google Sites, seeing our reliance on such bloated frameworks. What a sobering thought.<p>P.S. I did look her up just to check if this bug is still present. Her Google Sites is still up, she still teaches, but she seems to have taken down her earlier course pages.
So pardon my ignorance but I thought React was already for web and React Native merely a set of tools to help port React web apps to native mobile apps. What is the difference between React for web and React Native for web?
I've been searching a stack which could allow for a single codebase to be rendered in Android, iOS, and the web, and React Native + React Native Web might be the top choice for that. Other competitor includes Flutter, which used to only render canvas on the web, but right now it seems they have an option to render as HTML as well.<p>I bet the need for cross-platform stack might continue to rise in the future. It's just impossible for small team/solo founder to target 3 different platforms, while handling three different codebases.
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, <i>semantic</i> 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.)<p>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 <i>what</i> we're seeing on an HTML page (a product listing, a social media post) with instructions about <i>how</i> 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.<p>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.<p>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).<p>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.
It feels very unnatural to me to use React Native semantics and bolt on props for headings and the like; it seems like it would be better to write <H1> than <Text accessibilityRole="heading" accessibilityLevel={1}>, even just from a DX perspective.
???<p>This page is just an animation, and has nothing to do with "Twitter.com's HTML, which is produced by React Native for Web, explained"
rnweb saved my bacon in an app I did that was architected as a react app hosted within an iOS webview. the killer problem I was facing is that the webview didn't handle touches well within a scrolling context. so if you began your scrolling gesture by touching down on a button's box, it would often interpret that as a button press.<p>which was hella annoying and a classic "tell" that you are dealing with a web app trying to masquerade as a native app.<p>refactoring to use rnweb's <ScrollView/> and <Button/> made all that go away. Now I'd (boldly) challenge you to find a "tell" that this app is not native. (shelf.fm if you're curious).
Would one have to write custom CSS for the desktop version after the generator has spat out the css?
Mobile first, so thats not the issue but targeting the various classes generated would be a pain?
I consider any site that loads 3 seconds to display about 100 bytes worth of unicode text to be utter garbage.<p>I actually wanted to check the precise loading times before posting this, but would you look at this: <a href="https://i.imgur.com/VWOlNHu.png" rel="nofollow">https://i.imgur.com/VWOlNHu.png</a><p>I rest my case.
ohhhh finally an explanation for why my whole machine blips when I type into the search box and then I wake up 5 hours later in a stolen car with lost time
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.
React native I believe is the right approach given the current constraints, but I’d prefer that it would be possible to access native device apis via the browser.<p>Does Twitter really benefit a native app? Perhaps, but it’s certainly not <i>necessary</i>.<p>Ideally iOS and Android would simply expose native apis via browser and allow one to toggle access to said apis per site.<p>My conspiracy theory is that the only reason this isn’t already possible is due to vendors wanting more control.