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 why they did this (a flexbox bug) links to a comment from February saying this was fixed in Firefox 63.
> > The "paragraph" role isn’t mapped to a <p> tag because it’s an HTML conformance error to include block-level children within the [article] element
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.
I think years of <div> 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.
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's the real proof point for RN web and web workers.
> 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 consistently poor for so long)
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.
I'm living in a universe where Slack and Gmail are horrendous yes. That's why I brought them up as examples of low bars. Twitter is somehow even worse.
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.
Wait, what? What's horrendous about Gmail? It's one of the few sites that's predictable, gets out of my way, has a smooth workflow, and doesn't leave me shouting, "WTF? Why would you do that?"
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.
Try opening a few Gmail tabs on a machine that's more than a few years old or has a relatively low amount of memory. It might be an okay experience if opening Gmail is literally the only thing you're doing with the machine.
my favorite is when I open a thread from a tweet partway through and try to scroll before the page finishes fully loading. it dumps you way back at the top
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).
Maybe not trivial but these are all solved problems - media queries, http get requests and history state manipulation are all mature and well understood. In common with 90% of the web twitter’s performance and memory usage is utterly abysmal. We’ve been trained to accept this kind of thing but it doesn’t have to be this way. Im prepared to accept that there are complications that i don’t know about but Twitter is not that complicated a front end and it shouldn’t be beyond the wit of a tech company the size of Twitter to make something that y’know actually shows a tweet when you click a link to see a tweet.
In my experience, Twitter is only bearable on a Zen 3 or equivalent processor with at least 16GB of memory. Anything less than that is almost guaranteed to slow to a crawl if you're doing something other than reading a single tweet and closing the tab immediately afterwards.
Try out Nitter, a Twitter web frontend that doesn't require JS. Same content but way faster, leaner, and nonsense-free (excluding the tweets themselves).
> 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.
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?
React Native web is really all about code sharing between web and mobile in my mind. Say Twitter were to build their website in plain ReactJS, if they did that then there would be no easy way to transfer components from web to mobile, yes they are both written in React, but regular React isn't 100% interoperable with React Native.
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.
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. 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.
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.
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?
An important distinction that often gets lost is that React itself is an abstract, standalone layer above web and native. It handles deciding what to render and when. When you learn the concepts of React, you're learning this layer.
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.
Adding to this - jsx (the templating that react and other libraries use) is compiled down to calls for React.createElement (this is configurable). And jsx is a sort of superset of html so it's not exactly html tags, it just looks a lot like it.
React, react-native and react-native-web are really interesting. Classic react (for the web) was built with a plugin based rendering system. Classic react's renderer targets HTML and the DOM. React-native swaps out the renderer for one that renders to native elements (for example, instead of a <div> you would use a <View>, which then renders a native "box" using system primitives). They are both running the same react code, just with different renders. There's a whole system in react-native to be able to wrap native APIs and access them via javascript, but at the end of the day, both systems are running the same react (just different renders).
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.
React Native for web is, as the name implies, React Native components used for building websites. The idea is that you can share code between your native apps and your web app.
It's simply React (for web), but for native, ported for web. Would be cool to see a react-native-web-native port to use react-native-web for native apps!
React and React Native are separate tools, and they don't play with each other. You actually need to build two separate apps and you don't get much of any re-use. For example, you can't use Material UI for React in React Native, and you can't build a React component library and just pull it into React Native.
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.
This isn't really accurate. Presuming you're using react-native-web [1] (the most popular version of RN targeting the web, although there are others), it's essentially just a set of components and APIs, fulfilling RN's API, which sit on top of React DOM.
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.
Almost holding my breath for the time we see a version of react native for web getting packaged into a container that mimicks a native mobile app. And back then I thought that I've seen it all when apps built with scalajs-react-native appeared on Android.
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.
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.
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.
Flutter web has issues with accessibility. They do support screen readers once you enable accessibility by pressing a button, but its rather bad right now. Also scrolling is emulated and doesn't feel great.
I've recently been playing with flutter and I like it more than react-native. React-native feels kind of a hack job, and the resulting program isn't really that well optimized (both performance and size wise). Flutter seems like more thought out solution where react-native was afterthought for react. Both are very productive environments however.
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.
The problem with Flutter is that the result is absolutely unusable on web due to rendering to canvas. They implement maybe 2% of the non-appearance features that browsers do for native elements. I haven't heard of the HTML renderer but if that is coming it could be a compete game changer for the viability of Flutter-web outside of games.
I'd like to say imho that Fluttter seams to have the reverse issue from react-native in that it isn't tuned for website rendering. Since Flutter has to redraw it's canvas for animations and user interactions, it can be slow for websites where the browser window is fairly large.
Same here, with the same conclusion. React may not be my favorite web framework, but the native ecosystem blows everything else out of the water.
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.
… yeah. It’s not great. The corners aren’t even rounded. But my gut feeling is that it’s mostly a failing of the Facebook Devs, not React Native Desktop.
More: it doesn't remember window size, takes up to several seconds to apply a custom background to a group chat, and requires a measly 1.1 GB of memory (3.6 GB of real memory) to fail to do all that.
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.
Last time I used Qt Quick, native looking widgets were outside of its scope. You're meant to define the styling you want for all of your widgets, and Qt will render them consistently across platforms.
Out of scope for Qt Quick, perfectly in scope for Qt Quick controls. It looks very native on all the platforms I’ve tried, likely due to their experience with Qt Widgets.
Nice, thanks for pointing this out. Qt Quick Controls weren't around, or at least weren't available on the platforms I was developing against, like 9 years ago.
Cross-platform frameworks work great for basic CRUD apps but when you start to do things more complicated it can be a headache. Sometimes hardware and features you want to leverage are specific to the platform.
With React Native you can just use file.ios.js or file.windows.js etc if you want to do something different entirely for a platform. You can also check the platform with a function for minor adjustments. You can also handle these differences in a RN extension if they involve native code.
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.
> With React Native you can just use file.ios.js or file.windows.js etc if you want to do something different entirely for a platform. You can also check the platform with a function for minor adjustments. You can also handle these differences in a RN extension if they involve native code.
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.
Not really as you'll have to do that work anyway if it doesn't exist. It's better to do a small extension than to duplicate all of your other shared code just to do that change.
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.
Point being these are leaky abstractions. You have to have some measure of knowledge as to how the underlying platform works in a professional context.
The abstractions depend on the dev. The knowledge needed is considerably less to make an extension vs making a full native app.
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.
I'm a solo developer, and I have a project that totally can do it. I've done the proof-of-concept in an afternoon, but am mostly focused on web stuff atm.
Granted, it leverages NativeScript, but it's really not that hard once you have that.
I wonder if Apple would ever throw their hat in the ring, I don't think they appreciate Facebook and Google dominating the space when they try to push developers to use Swift
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.
> 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.
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.
Sure. But I think the framework would need to emit a proper tag rather than the tag soup that it seemingly emits now. I can't see a win in expressing something in an idiomatic way, to have it translated to an unidiomatic output that mimics the behavior of the original idiomatic code.
Like, if you're typing the Text version, you already know it's going to be a H1. So just write that.
laziness. they could just not use a tool that generates reams of bullshit markup but that would require thought and effort to understand and work with the material of the web.
Maybe they fixed it? For very long time you couldn't show a specific tweet in a long thread with more than ~20 tweets, it would default to the topmost one with the relevant usually hidden behind "show more"
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.
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).
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?
React-native-web is more or less a component library that re-creates react-native's API. Some will disagree, but react-native's API is much nicer and cleaner than HTML and CSS. It's like they took the best parts of HTML and CSS and left out the 30 years of cruft.
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).
This is genuinely what I see 50% of the time I go to Twitter. Every other big website can keep their site loading >99% of the time. The fact that Twitter can’t is beyond me, and speaks to their incompetence.
Been to Reddit lately? It's gotten better to be sure, but I have to reload or dance around with the back/forward buttons so often simply because I attempted to visit a page.
This is old, but I thought another hilarious unforced error was when you could click on a tweet link, and it couldn’t fit the 140 character message in your initial view!
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.
I rarely experience any of these issues and think their front end is quite good. Just their a11y / keyboard nav stuff is some of the best I've seen. Some questionable design choices but that's more of a product thing
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.
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)
GTA online has had slow loading times for years until a fan reverse engineered the game to find a bad serialization issue which basically created a n*n computation.
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
Tweets not loading, with an error, except after several tries, is a commonly-reported problem. I've seen it for years, across multiple browsers & devices, happens all the time.
You literally can't use the site properly when you're not logged in (and I mean basic clicking on retweeted/quoted stuff shows a login page, clicking on people's names shows a login page etc.) - how is that good? (I mean sure, build your walled garden as you please, but then you have no business showing in search engine results.)
I've been encountering this a lot today, because apparently the MTA (and the Metro North) have decided that Twitter is their official news distribution channel [0]. They're posting updates there more frequently than they are on their official website, and because we're in the middle of dealing with a hurricane, they're pushing me to interact with Twitter to figure out how to get home tonight.
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.
governments should be strictly prohibited from requiring privacy-invasive (tracking, deanonymizing) technology for any service, let alone emergency services. a gov website requiring google fonts, apis, captcha and tracking is not in accordance with the basic civil right of being free of government surveillance (via said 3rd-parties).
It's close, but browser support & integration was never good enough, and that lacks the ability to carry on a dialog or to attach one's own post to someone else's, which people clearly want.
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.
Agreed, it's very heavy for no reason given it's doing pretty much nothing. It's buggy, slow, sluggish at times, with delay on clicks and scroll. It's really a terrible UI given how simple the problem is, and how much money they got.
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?
The thing that drives me crazy is that it breaks a basic feature of the browser, which is that if you load a bunch of tweets in your feed and then ctl-f to search for something, it doesn't work (on Chrome, at least); it doesn't find stuff that's on the page.
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.
Yep, it breaks a ton of standards and UI expectations, I don’t know where people get off saying it’s good for accessibility. (Sorry, a11y.) Don’t reinvent the back button!
You're so right about this. Also their UX is absolutely horrible in my opinion. It's one of the worst designed sites both in terms of usability and load time (half the time it doesn't even load on my mobile on kiwi browser).
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 .
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...
I wish they still did server side rendering for your feed. They switched to all client rendering a while ago and it takes a lot longer to load now. I wonder if the loading speed tradeoff was consciously made or if it was just a fait accompli after some rewrite or another.
I feel like an idiot trying to read threads on Twitter. I seriously get confused on where one begins, ends and everywhere in between. It's WAY too complicated of a layout for nothing more than a chronological list of text.
I have no affiliation with this site(1) but it is godsend if you're trying to read twitter threads. Makes you wonder why they can't have this in-built in twitter instead of what it is now.
Which is probably a good thing. Neither of those sites wants you to "stay engaged" and keep scrolling forever. Old reddit was the same, but of course the redesign is infinite scroll.
They have been trying to kill their web experience longer than most other modern platforms have been alive. The latest iteration of that is requiring a Twitter account to see any posts at all now.
Can't find the tweet now. Someone created a static HTML page with all their tweets, over 8 MB of HTML. It rendered faster than a single tweet by Twitter.
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
The tweets not loading is clearly intentional. They want you signed in, preferably on a native client where they can track more invasively.
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.
I built one of those. Twitter's API isn't going to do you any favors. There is no publicly available API to get the replies to a tweet. So building out a full thread is hard. Then once you figure out how to use their internal API you'll quickly hit rate limits </3
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.
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.
> Ideally iOS and Android would simply expose native apis via browser and allow one to toggle access to said apis per site.
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.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...