Twitter.com's HTML, which is produced by React Native for Web, explained
giuseppegurgone.com
giuseppegurgone.com
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
I believe you are misquoting here. "The element" refers to the paragraph element, meaning that valid HTML5 doesn't allow block-level elements within <p>. This is supported by what follows the quote:
> in React Native for Web both Text and View support block-level children.
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.
We have not. It still sucks.
As for the twitter responsiveness experience... You must be living in an alternate universe.
URLs can be unique ids for scrolling to.
Simple Ajax function to attach cards on scroll.
Poll or get pinged by SSE to pull updates, swap by url as Id
Loads fast if you simply render html and lazy load the images. Css is almost instant.
We can do better with so much less. Unfortunately we now have front end engineers everywhere doing web development.
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 consistently poor for so long)
There's nothing "correct" about Twitter's infinite scroll: back button is never quite sure where in the timeline it should bring you. Occasionally the top or your last position, but most frequently a random tweet somewhere in between.
But the major issue isn't UX: I don't find it as bad as some here say. The real problem is the abysmal performance. Not just the load time (the page loads blank, then starts loading actual content) but then after everything is loaded every single interaction comes with enormous UI lag. Literally an active click-wait-click-wait cycle.
The only issues I remember having are that sometimes label autocomplete is flaky and sometimes the new emails take too long to show up.[1] It has good support for vim-like keyboard shortcuts as well.
Don't want to sound like a shill, but I've found Gmail to be an outlier.
[1] There was also the April Fools "mic drop" feature where you could accidentally mute a conversation but I didn't experience that personally.
Although google has had a huge problem with keeping accounts separate in the same browser, but that’s not a gmail thing.
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...
Sure, Twitter from 2011. Backend handling might be faster today but that's decoupled from the frontend bloat and UI anti-patterns.
To the eyes of someone familiar with the framework it is still full of bad practices.
Boy, that frontend ecosystem is really cursed.
This is where React Native for Web comes into the picture, RN for Web patches that gap of interoperability between web and mobile, what Twitter likely has behind the scenes is a custom UI library that provides all the elements you see on Twitter, if they had chosen ReactJS for the web, they would have to maintain two libraries, however with React Native for web, they only have to maintain one.
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
> (MM/DD/YY) Here's the list of students who must take the finals:
>
> (MM/DD/YY) [Next reminder...]
Sucks to be a Firefox user and be on that list.
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.
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.
With this article, it seems to me that Twitter devs, for all their fancy dev toolchains, could only produce slightly 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.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.
I assume they also make the html complicated to make it hard to scrap the site.
Then there are layers that decide how to render. Regular React has a renderer that accepts HTML tags spits out HTML for the browser. React Native has a renderer that accepts more abstract tags (<View>, <Text>) and spits out native views for apps. There are other projects that make renderers for making PDFs, animations, etc.
React Native for Web is basically a renderer that accepts the abstract tags React Native uses (<View>, <Text>) and spits out HTML. React Native does not really help you directly port a web app to native, but React Native for Web is designed to directly port a native app to the web.
React-native-web is basically a classic react component library that aims to be 100% compatible with react-native. You can literally do "npm install react-native-web", then "import {View, Text} from "react-native" and just start writing react-native code in a classic react-project. It's nearly feature complete, and pretty incredible. Really the only downside is that (obviously) react-native-web can't use those 3rd party libraries that use that "native API wrapper" features of react-native. That being said, a lot of packages are starting to offer react-native-web compatibility by writing web-specific "polyfills" for the native components.
https://www.typescriptlang.org/play?#code/DwEwlgbgfAsAUAAgcA...
More accurately, JSX is shaped like HTML, and some of the the transforms for JSX to JS have built in special handling for the standard HTML tags.
To be followed by "React Native for the Web for Native for the Web" to port those apps back to the Web..
At some point they will just emulate a browser into a PC into a browser to make your code more portable
So if you want a fully cross platform React experience, you need React Native from the get-go and to compile it for web when you want web.
So anything you could do in React, you can also do in RNWeb, as it's a superset of React.
Of course, you'd need to use the RN components if you want to share code between web and native mobile. But there's nothing stopping you reaching a high degree of code re-use, and/or using React components for the web-only portion of a RNWeb project.
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.
The only thing Flutter has going for it is the batteries included aspect, which can be a bad thing as well. I prefer the flexibility of the React stack, being able to match different libraries vs a framework. E.g. maybe you want a more native router, use Wix's native navigation, otherwise use react navigation. Maybe you love reactive programming, use observables, otherwise maybe generators for side effects.
The apps Flutter produces don't feel right, RN does have a more native feel since it uses native primitives. Kinda like wxWidgets vs QT. I'd rather use native controls than trying to mimic the look and feel of native (and keep up w/ changes). This is especially noticeable on iOS and even more so on web.
React Native was definitely not an after thought, it's simply another bridge. I've had great experience with all the bridges. RN for Windows / Mac (both the MS fork and Catalyst), and RN for Web.
I've made and work with a production React Native Web / React Native website and apps. It's been very pleasant to maintain apps and a website (desktop & mobile site) with one codebase.
No, just no.
You can model your codebase so the function stubs are the same, but the implementation differs based on platform. So you can use it the same way in the rest of your code.
I run this setup in production and I share about 95% of code between platforms for a complex cloud storage app (file manager, uploading, etc.)
Basically isolate what's different, and abstract it to a common interface.
Well if you need a specific widget or library that react native doesn't support by default you have to write bindings, and unless your business logic is very basic it happens most of the time. You might be lucky somebody already did write some bindings for you. As someone that used Titanium in the past, React Native suffers from the exact same problems.
Most of the time there will already be a 3rd party extension, but it's really easy to make them. You will need some slight native experience, but you would need more for a full native app.
With Titanium it wasn't easy to do these extensions, with RN you have direct access to the native platforms and code. You can go as native as you want in one or all platforms while sharing the code you want to.
RN is useful if you're a solo dev, like myself, or a small team and you want to support all platforms.
I have enough knowledge to get all my apps in production, enough to make extensions for the platforms, and quite a bit in web to remake native features on the web. I am not what I consider an Apple or Android dev though, far from it.
I can learn from a middle out approach when it comes to all platforms. Similar to compilers and such, you can always go lower level to understand more and more, but it's not needed to get your vision out.
Desktop support is approaching “okay” (judging by the almost kinda somewhat native feeling flagship app Facebook Messenger on macOS), which puts it many kilometers ahead of any alternative.
The main alternatives for native feeling apps seem to be Xamarin Forms and Qt Quick, the former seems hard to do special things with and the latter has a pretty confusing and convoluted setup process. Neither has real web support.
You mean "horribly slow, loses scroll position, can't reliably load and display images, bad click targets everywhere" flagship app?
This is the failing of both React Native Desktop and of the Facebook Devs that couldn't even make a rather primitive chat work properly.
From personal experience, I've had great success targeting the 3 platforms you mention in a single RN codebase, with a very high degree of code re-use.
Granted, it leverages NativeScript, but it's really not that hard once you have that.
const renderEl = flex("UserList", [
label("User", ["Alice"]),
label("User", ["Bob"]),
]);
Ofc, there will be certain elements that are native only, or require really special stuff to create.
You can create a project by running: "npx ult ProjectName"
You could use Expo, but I didn't want to be locked into the Expo environment, I wanted native extensions, and I wanted desktop platforms.
For web it uses a lite forked CRA project tailored for React Native Web. For native it runs the proper commands and sets up all the platforms for you.
Currently ReactXP is the default as it's more stable and feature complete, but RNW is supported.
In the future RNW will be default as ReactXP is abandoned and RNW is the clear winner.
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.
You've described the Gemini protocol and Gemtext markup. Gemtext is explicitly designed to leave presentation up to the user agent.
const H1 = props => <Text accessibilityRole="heading" accessibilityLevel={1} {...props} />
Like, if you're typing the Text version, you already know it's going to be a H1. So just write that.
You can't link to a specific tweet. 'Nuff said
What? https://twitter.com/Twitter/status/1433462575438643206
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"
which was hella annoying and a classic "tell" that you are dealing with a web app trying to masquerade as a native app.
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).
The idea is that since react and react-native API's differ so much, it's not really feasible to have one code base cover native and the web. React-native and react-native-web allow you to use the same code. I'd say I'm at about 90-95% code reuse. You can throw in little platform specific changes inline (Platform.OS === "web" ? <This> : <That>) or use platform specific extensions for things that really differ(MyComponent.android.js, MyComponent.ios.js, MyComponent.web.js or MyComponent.native.js for example).
If you’re not making an app would you still use react native web over old stool react for the reasons above?
I actually wanted to check the precise loading times before posting this, but would you look at this: https://i.imgur.com/VWOlNHu.png
I rest my case.
(I'm not even a Reddit user, but it shows up in search results and I get linked there.)
For a while I thought it was some weird blocking from Privacy Badger.
Apropos of that: the MTA is using threads now, and I can't click 'show thread' without being redirected to a login screen. I don't want to create an account because I find twitter painfully shallow but also addictive, as well as generally untrustworthy (I don't want them to have my phone number).
I don't think that any part of the government should be using twitter the way the MTA is; but so long as they are, I think Twitter would do well to get out of the way of the distribution of vital info.
Any move to develop it further to add those sorts of things would have run into the same problem other protocols have for the last 20+ years, which has made them even more difficult to develop and promote than they already were: keeping huge numbers of users captive has become per se valuable, thanks to having as-complete-as-possible spying-generated profiles on people and massive datasets being important both to the money-spigot of the modern online ad market, and for developing machine-learning solutions to dominate other "verticals" (against any competitor who lacks the same massive, spying-obtained datasets, so is at a huge disadvantage). Application-level open protocols make tracking & spying harder, so companies chasing those datasets really don't want them around. The few that survive in common use do so under constant threat, protected only by luck, by already being "good enough", and by having already established a large presence before that sort of business model really took off.
[EDIT] incidentally, pioneering the inclusion of an open, cross-site social network as a first-class browser feature is one of my crazy ideas for how Firefox could save itself from irrelevance—but like most of the other ideas I have to save them, it's probably too late anyway.
It might go away if you log in. I wouldn't know.
It's unbelievable incompetence coupled with unbelievable not-giving-a-damn attitude.
I would think that your first visit loaded a resource/set a state somewhere which let's the second visit go through.
Much more likely to be a programming error then a purposeful decision by a PO as the end result is objectively terrible. I cannot imagine anyone getting convinced to register to a webpage that cannot even load. It's not that content is hidden behind a pop-up or anything, it just errors out (at least for me, but I'm not the parent comment author)
Some issues are fucking hard to detect and an initial page load breakage that only happens sometimes (likely a race condition that cannot be replicated in testing) is an example of that
This is particularly frustrating, because my normal use case for this is that a bunch of new stuff loaded, which throws everything that's on the page already out of order, so then I can't see something that I know was there, that I was just looking at, and now searching for it doesn't work, either.
It's not like they have 1000 of concurrent events like facebook, and their frontend should have nowhere the complexity of their backend. I don't understand how it's even happening.
The most absurd aspect of it is that how slow loading a single tweet is. The timeline could have the excuse of a slow and complicated backend call (but it doesn't, the backend is actually doing ok), but several seconds for one single tweet?
It's insane how bad it works on a page that would have been perfectly fine to be simple and static.
I have zero interest in retweets, replies, threads, hearts, etc.
That said, I fully agree - the website is literal garbage despite its insane simplicity, and there would be 0 reason to trust that their web tech works well because they have never demonstrated such a thing.
The biggest irony is they have the best designers in the world (i.e. the guys who created bootstrap) but god I hate the tech they have used to make twitter.com because of that "something went wrong" retry button error message .
Does Twitter really benefit a native app? Perhaps, but it’s certainly not necessary.
Ideally iOS and Android would simply expose native apis via browser and allow one to toggle access to said apis per site.
My conspiracy theory is that the only reason this isn’t already possible is due to vendors wanting more control.
Basically you get a PWA for free with your app. All "native" features that you have can then use web device apis if they exist.
Basically React Native Web allows you to have a lite version of your app that lives on the web.
That way if you preferred Vue, Angular, Ember, Elm, etc you could use that.
You can use something like Solid or JSX lite to maintain standard components that are compatible with most of those frameworks and web components.
Even if you use web components that doesn’t change the fact that web apps don’t have access to native apis without compilation.
Not when the different stores are so lucrative. Imagine that initially Jobs wanted people to stick to web apps and reserve native apps for Apple teams. fast foward 13 years, Apple made billions with their appstore.