Hacker News Reader

Comment by madeofpalk | Hacker News Reader

What are some examples of good 'impossible to tell' UIs built with flutter on desktop or web?

My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them.

A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of abstraction you put on top of that hackish foundation, you are still running it in the program (browser) designed to show text. So you can select buttons, navigation controls, images, sound players, etc. And it feels very native to web users.

But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. Sure, you can "opt-out" with recent CSS controls for selection, but it's again, a hack - the default choice of "everything is selectable" is made by default for you by the browser. What does it even mean - select button widget? Why would you enable this complicated selection functionality for your UI that allows users to select navigation buttons with a blue selection box? Of course, if your app needs this functionality - you can add it. But otherwise, it would be labeled as a very stupid UI choice. Yet, feels native to web.

Another example is zooming. Because UI apps written in web stack can't completely hide the fact that what they are doing is essentially trying to morph text primitives into complicated UI widgets (makes sense for 2024, right?), and the browser is essentially a text viewer, everything is zoomable and feels "native" to be able to zoom a web app. And yet, this rarely works as intended. In any other UI framework, making zoom functionality requires thinking about what and how you want to zoom and why. OS text size preferences are well handled by flutter, but sometimes you do want to add your own zoom functionality. In web though you just blindly zoom everything, often blowing off the layouts and that feels very "native" to web.

My point is, that I don't think UI frameworks should try to match the nativeness of web, especially when they start targeting the wasm platform. These couple of decades of proliferation of web frameworks built on top of HTML/JS/CSS should just wane in history as a dark period of software engineering.

> But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider.

You say "insanely stupid", I say wonderful.

Everything you apparently hate about the web is what makes it good for users. Content is primary, and my user agent can resize it, restyle it, copy it, extract it, link it, read it to a blind person...

If you want to make a binary blob app, just make that. Stop trying to break the web.

> You say "insanely stupid", I say wonderful.

Yes, that's the most common response. I've heard stories about "how wonderful when you can select everything" multiple times, and that's, of course, just shows how human rationalization works.

And yet, this "feature" or "UI choice" is not even a choice. It's just a byproduct of using the wrong stack for the task. Like, nobody ever sat and asked, "Do we want our apps to have everything as a selectable feature?" before shipping this "feature". It just happened, and then, of course, millions of humans, having no actual choice over it, naturally rationalized that as a "wonderful" feature.

It didn't "just happen" the early architects of the web designed a system to make it easy to share and remix content and subsequent generations of companies and their UX designers have so far failed to fully claw back user freedoms.

Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.

Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...

Those are some of the most niche use cases I've ever heard, and that is stretching it even on HN, much less anyone in the non HN bubble. Things like screen readers work just fine on non browser apps that don't have selectable text, for example.

Copy-pasting UI elements to ask for help on support forums is absolutely not a niche use case. You're asking for a world of even more terrible screenshots in support channels. Truly cursed software.

Who exactly is copy pasting UI elements? I have literally never heard of anyone copy pasting UI elements of all things over just taking a screenshot of the page, so please provide an actual example. And even if you were able to copy and paste, how would you preserve the layout of the UI since only text is selectable?

What are some examples of good 'impossible to tell' UIs built with flutter on mobile?

Bolt [1] and Bolt Food [2], for example. One of the apps is built with Flutter, another one is native. Can you tell which one and explain how you noticed it?

https://www.youtube.com/watch?v=3X8COSnscbQ [1]

https://www.youtube.com/watch?v=VOgrdt5WQcI [2]

LOL Bolt is a React Native shop.

Just Google "bolt react native" they have jobs and articles about their usage but also any library inspector will tell you that.

Nope, one of them is Flutter (I know team PM personally). Which one?

Dude. They're even on the React Native showcase page.

I don't know what to say but you're massively mistaken.

Uber use React Native too BTW. Lots of other big tech companies also, I don't know of any that use Flutter in a big way. Just some toe dipping

Bolt Food is on the showcase page, not Bolt itself, which would be odd not to add both if indeed they were both RN, so seems like one is RN and the other is not, which is basically what the above commenter was saying initially. None of what you said really invalidates their point, because again if you search for RN jobs for Bolt, why would you not also assume it's for the one on the showcase, ie, Bolt Food? Bolt is the company name after all, not just the app name.

You were right. After your comment, I went back to my friend at Bolt and asked again. Bolt Food is on RN, Bolt is native. The conversation we had about Flutter back then was about his other project and not Bolt Food.

Selecting everything is what every UI toolkit should support. In the 90s it may have been acceptable to show an error MessageBox with a non-selectable message but it shouldn't be acceptable today. What needs to be selectable is defined by users not developers and the union set of those requirements is "everything".

Browser zoom also only ever breaks if you are fighting the Browser's layout engine instead of embracing that. Just don't do that and it works fine.

Of course most web "apps" shouldn't be apps in the first place but if they must be "apps" at least stop reimplementing a crappier version fo the native browser functionality.