Hacker News Reader

Flutter is probably meant to be the native toolkit of a platform. I don’t think there is anything wrong with code-once toolkits that don’t use native widgets if they spend the effort to be accessible and have good UX.

I’m personally falling into the belief that we’ve fooled ourselves regarding UI. That one single UI library could actually be the ideal choice for every possible app, and that we just need to keep trying until the absolute perfect set of tradeoffs appears. I think this is enticing because UI is very hard and full of problems you would have to solve over and over if you had multiple UI frameworks, whereas these things could be amortized if there were less.

I don’t think so. I do think the UI ecosystem, as it slows down, could become more modular and share more core components. I expect to see “base” rendering libraries, like Skia or Pathfinder, powering next generation UIs, and hopefully someone will also make a cross-platform library to provide accessibility and IME primitives for Windows TSF/macOS/etc. I think smaller bits like that can clearly be minmax’d to ideal conditions for given use cases. But if you were hoping for a future of “just use the native toolkit!” I think it’s not likely, at least not until software slows down a lot more. Even then, lowest common denominator libraries like wxWidgets often end up being disliked by users and developers alike, due to the compromises needed for them to accomplish their goals. I’ll admit the story has gotten better with React Native and its success on mobile, but even that is not a perfect story: performance on Android was apparently not good enough for Discord, which may in fact be a pretty good signal for why something like Flutter is a good idea anyways: it can mature over time on existing platforms and then possibly even become the first class toolkit for something.

I do agree that most developers should prefer native over vanity, but it’s a false dichotomy, as there are plenty of valid reasons to not do native. No more is this clear than Windows, where virtually nobody does “native” anymore. (It can still be OK, but it’s not great. Having true HWNDs for every component is a great way to have things flicker whenever you delete/create new widgets.)

If only the users/customers weren't so fickle.

> I do think the UI ecosystem, as it slows down, could become more modular and share more core components

I think things like Flutter will take another few years to become performant compared to even Electron/Tauri/Webview+JS

Yes, it is sad that we redesign UI (even web UIs) every so often, but it is an unforgiving world. I am not sure if it is the fickle users or the product manager(s) to blame, but we seek fancier and fancier UI with every update. There are exceptions like the craigslist website, but those are rare.

I agree with all other points.

> I am not sure if it is the fickle users or the product manager(s) to blame, but we seek fancier and fancier UI with every update.

It's not fanciness, it's maturation.

Compare YouTube from 2006: https://web.archive.org/web/20060202021427/http://youtube.co...

to now: https://web.archive.org/web/20210430000812if_/https://www.yo...

The new design puts content first. There are no superfluous borders, backgrounds, or gradients. Every visual element exists for a good reason. This is good, functional, accessible, design.

And YouTube of 2006 is a conservative example, we (well, most of us) can remember the UX/UI atrocities that existed back then.

> hopefully someone will also make a cross-platform library to provide accessibility and IME primitives for Windows TSF/macOS/etc.

I'm planning to do this for accessibility. I don't think I have the expertise to cover IME though. Do you think they both need to be done in one library, or can they be decoupled?

I believe IME can be completely separate, though I'm not 100% certain. It might depend a bit on the platform.

Certainly on Windows, IME and accessibility are separate; IME is done through TSF as you mentioned, whereas accessibility is done through UI Automation.

> Just use the platform like it was intended to be used. You're not special. You're not smarter.

If you assume that they are not less smart than the average engineer, then a reasonable assumptions is that they weighed the trade-offs and went with what worked best for them, and you're missing some context (or give different weighting to importance of native widgets - which comes at a cost).

There are pros and cons to using native widgets or cross-platform libraries/UIs that go back to when UIs and platforms became a thing. I know of the SWT vs. Swing debate in the Java world some decades ago - there are likely many precedents before then. All I know is there is no right answer, just trade-offs you have to weigh.

Or they have evaluated their potential solutions without understanding the choice they are making. For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't).

If you look at a screen produced by, say, Flutter and compare it to Aplpe's native toolkit you might conclude that you can produce the "same" thing with Flutter as you'd get with Apple's native toolkit. To boot you can do it in less time.

The thing to consider is: Did you really produce the same thing? Maybe you produced two things that look the same, but aren't even close to equivalent in many other important ways.

This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale.

In the initial meetings where you talk about making new component libraries, someone who worked on the old one says, "We reinvented the wheel last time, then standards changed, and we couldn't keep up. We need to take current standards into account before doing anything new, including accessibility."

And the new boss says, "That's a good call-out, but accessibility isn't a problem if nobody can even load the component list and scroll to the thing they want, and with the current ux and stats, we're getting close to using most of the available memory on devices just to scroll our content. We don't want to change the content we can scroll, we just want to make scrolling more efficient. Everyone agrees the current design is at its limits. We need to start over at the beginning. Accessibility is step 3. We're at step 0. Let's focus and move forward." And while they are right, they need to demo an map to an abled-person boss, so accessibility gets pushed farther back as technical things take priority.

Often, this leads to teams over time producing lots of things without accessibility, and you build new things from old things, and it just snowballs.

Suddenly a user appears, and they aren't served, and now a whole new bunch of juniors are scrambling to add accessibility to old things without breaking current usage.

> For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't).

When Sun or Google created their own, non-native toolkits designed to run on Mac OS/iOS, they were fully aware of what doesn't work. However, they balanced that con against the pros of the ability to write cross-platform code once (ground floor engineers), and on strategic level, they wanted to commoditize Mac OS/iOS into a dumb pipe (one of many other dump pipes to deliver code/content to), rather than a platform with inherent value - they consciously considered this to be more important than users' griping at the weird scroll-speed curves. One can create a shim for native widgets like QT does, but you'll be at the platform owners mercy when it comes to release cadence.

It's good business practice to commoditize your complement - seen in that light, the decisions are far from "not smart". Not great for some users, for sure, but they come from deliberate decision-making over control.

Engineers like it when everything works the same. It is also easier for product marketing: the new features will be available everywhere, and they’ll work the same. Less to document and keep in your head.

The advantage is mostly that it is easier to manage for the organization building the app. There is no real benefit for the users, in this case most likely slower, larger, and resource intensive apps, that avoid platform integration.

Also, the organization is ceding control to an other when they don't use their own stuff. That doesn't sit well when the needs of the other gets in the way of profits.

I assume most of the time it's the higher-ups deciding these things, not the engineers. The boss decides they doesn't like something about the native UI and asks the team to build something new, without understanding the deeper implications.

The real problem with Facebook at least is build times -- using the native stack incurs something insane like several hundred hour build times IIRC. So the native stack is just a non-starter once you get to a certain (ludicrous) codebase size.

Are you saying that the client includes all of the Facebook logic or something?? Surely displaying forms (essentially what a post is) and ability to scroll through a list and click on a button or view/upload a photo is the essence of the app?

Where's the magical bit that means they can't use a native UI toolkit?

It's always absolutely fascinating how complicated people can make scrolling and displaying forms.

This stuff was solved in the early 90s and everyone's bored now.

Infinite scroll was around in the 90's? Wow, I learn something every day on this site

You know, maybe sass isn't appreciated on this site, but it's pretty pathetic to imagine someone could unironically imply any part of UI was a solved problem in the 90's and not face a challenge here. UI engineering is a discipline which most software engineers grossly underestimate the complexity of

Yup. Browsers used to render all pages incrementally, so you could simply keep the HTTP connection open and add more HTML text to the page, and it would just get tacked on to the bottom. Then you had a CGI endpoint in a separate footer frame (sort of like an iframe but arranged in a Grid-like layout) with a "Read More..." form button for requesting more data. It worked really well and didn't even need to use JS.

Imagine trying to argue UI development was solved in the 90s and then telling me you use manual pagination as the follow up

> In Comments

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

You can still do this. I wrote a chess game that checks arg 0 for "cgi" (otherwise it uses a VT interface) and renders a new board in the browser every time the other player makes a move. It works with absolutely no javascript.

The magical bit is that they have hundreds and hundreds of cooks in the kitchen, who all need to justify their existence by creating tons and tons of little one-off UI screens for obscure features that hardly anyone sees or uses.

This kind of team structure also causes other strange-looking technology choices, such as CSS-in-JS: they have to do stuff like that because they literally cannot prevent different members of the team from writing CSS class names that collide.

I always thought this was some anti ad-block feature, huh.

I think that number of classes is the main issue. It's in the many, many millions.

Also, the app has sooooooo much more functionality than people realize. Plus, there is a lot of functionality that ships with the app but is behind a feature gate, meaning that it is turned off for the majority of users. There's lots of internal tools for adjusting feature gates on a per-user, per-region, per-whatever basis, in the name of user research as well as just safely deploying new features at scale.

Speaking as someone focused on code maintenance this isn't a good thing. If the highest complexity of your product exists at a level where users can't interact with it then you're spending a lot of dev time inefficiently.

But I don't believe you're correct, honestly feature flag rollout, even among insanely specific cohorts, isn't actually a hard problem and it's essentially been solved at this point - it isn't easy, not by any measure - but the components and how they interact are rather easy to comprehend. Facebook's main complexity (IMO) is from trying to build essentially a full OS on top of the browser from which to serve a variety of integration apps into their platform and, while I'm not a board member of Facebook or at all familiar with their earnings, that particular goal seems to have been, essentially, a dud.

Being able to play farmville with your friends may have been a decent income source once upon a time but it's very far from what their core competencies now are. Facebook now primarily uses API hooks into other native standalone apps for that particular class of data collection, but their pure web based collection seems to be where they really get value. The fact that they can see precisely where users are going on the web is, IMO, their main value proposition at this point - the social network stuff needs to exist to support that and ease the process of identifying users - but anything related to games seems utterly unnecessary and that core platform they have could be vastly simplified while still delivering the same value to the company.

That all said, they've invested a whole lot into their existing platform so I can see why business would be very very hesitant to try anything that might rock the boat, if they can sustain their platform being fast and responsive they can minimize their corporate risk.

They aren't saying that the feature gating code adds to app size, but rather that there's a lot of code behind feature gates (for tests/staged rollout/locale-specific features/etc) that most users won't see which still add to app size.

Fail fast and KISS are pretty celebrated virtues of sustainable project development. I understand that on the scale of Facebook you have issues with project management but if there is a significant amount of code that is locked to specific cohorts of users aren't you opening up the door to unprofitable levels of complexity and long running poor investments?

I'm sure a lot of developers on here try and minimize their use of integration branches in the day-to-day (they are necessary for some things but keep them short and sweet) and try and get in-progress features into master ASAP - that's largely due to the fact that maintaining multiple copies of the same basic logic can quickly become extremely difficult to manage.

Localization is a really big exception to this but that's why, whenever possible, you'll see game companies limit localization to strings only - including logical statements in the realm of information to be localized can make security issues extremely fun to track down along with causing frequent usability breaks in less used localizations.

I don't know - whatever the reasons for it and no matter the resources FB has - this stuff increases in cost exponentially and if they do have a really fragmented codebase it's likely that the majority of their labour goes into process definition and QA to make sure that they don't break the Swahili language version of the landing page for China when they change their contact us link.

Fail fast works on the web, where you can redeploy the app with the next page refresh.

It works poorly on mobile, where users are not keen to reinstall an app every few days, and some do not update for months and years, because of lack of space, scarce bandwidth, old hardware, or just neglect.

It doesn't just apply to the web though - it can even apply to OS design. On the web it's usually (ab)used to leverage users as the metric of whether something is failing, but in theory fail fast is just about learning that something isn't working through any means - whether that be user reports, automated tests or proofs of concept.

Additionally, at least where Facebook is concerned and IIRC, they actually do heavily utilize out-of-app data in their mobile app. There is a good deal of code, but a lot of the UI ends up being tweaked by data that's being served to the client.

Almost as if the user is the product instead of the app. The app is doing everything in the background to monetize the user

I don't disagree with the sentiment - but I still think the app is poorly tuned if it's been allowed to accrue this much complexity in the relatively non-essential UX that we all interact with through the web. My point is that the complexity of FB's landing page is unmaintainable and misaligned with business goals - if we view those goals to be about data collection and not actually running a social network then the misalignment is actually worse.

Literally, Facebook reverse engineered Android's vm solution to monkey patch in a longer method table instead of reducing the method count. I have no idea why but their massive amount of client code seems very important to them.

Part of it is FB’s company culture — generally the ethos has been to enable engineers, technical precedent be damned, and to never say no to a product idea. It is really impressive and a major part of why FB can move so fast despite being a very large corporation.

Lol you are very naive if you think all Facebook does is show posts and messages. You need to track the users, collect sensitive date, and all the other malicious stuff

Errrrr. I make games, like, big games… compile times are a problem but it’s in the realm of 12hours at the absolute most.

Are you saying Facebook would take more time to compile natively than an open world game including baking maps?

That is simply not true. Building the entire client app from source takes about a half hour.

The problem they're trying to solve isn't "Writing apps in Swift is too hard". The problem is "Writing your apps twice is expensive and throttled by Apple's ecosystem". Most app purveyors will target iOS first because iOS users tend to be more affluent and willing to spend money. Google obviously doesn't like that for their own competitive reasons, but the rest of the market is also loathe to give Apple so much power over the app market that they can charge monopolistic fees. And since Apple has no interest in making it easy on everyone to work with their competitors, dev tool makers are forced to use hacks like react-native to meet their needs.

Move fast and break things!