[CharlesW]

For me, Flutter mobile isn't there yet either. I can see where it might be great for games with completely custom UIs, but I find the uncanny valley of pretend native controls a very uncomfortable place to be.

Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.

[twawaaay]

Every technology is a set of tradeoffs, including Flutter.

For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)

What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.

[dmitriid]

> Users do not necessarily care if the application looks pixel perfect

They do care. They just don't know the words "pixel perfect".

However, everything is an improvement over the standard state of corporate UIs

[cxr]

> For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care

Have you measured it, or did you stop after the Form A Hypothesis step?

[eberkund]

Isn't what you're describing basically React Native? I think the Flutter devs wanted to try a different approach to address what they felt were the shortcomings of React Native which brings along its own set of tradeoffs.

[izacus]

Sure, but most common mobile apps ARE completely custom UIs which insist on their own branding and look. The UI designers usually really hate if they have to use standard components and are unable to express themselves.

Flutter just recognises that.

[satvikpendem]

Agreed, most apps I use already don't use native controls, like Slack, Discord, Spotify etc, and I don't want my apps to do so either since I have a custom design. I think people on HN think users care about platform UI when we see that most users really don't notice or care.

[nicoburns]

That depends on what kind of controls though. Many apps will their own buttons, but most are using the native text input control (and often the native scroll for screens / screen transitions.

[kitsunesoba]

On iOS it's not too difficult to build a fully custom UI with just UIKit. You want a totally custom button? No problem, don't fight the styling inherent with UIButton, just subclass its parent class UIControl instead which is a blank canvas, but still gets you 90% of the perks of a standard UIButton with minimal effort. It's pretty easy to write entirely custom widgets with unique behaviors too.

It's a bit more messy to do that with Android Framework, and because of that I see more of an argument for using Flutter there than on iOS. Jetpack Compose seems to be a lot better in that regard though.

[lta]

I thank the flutter team very very much for not using JS. We're already overflown with this stuff and a bit of variety and competition cannot hurt.

I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome

[TobyTheDog123]

You're definitely not alone in this. One of the core reasons my team chose Flutter was the fact we would not have to spend much time setting up development environments and making sure we were always using the latest and greatest framework.

[cxr]

Odd thing to say, since you definitely have to set up a Flutter/Dart development environment—you don't just get it for free.

The only real way to escape this at all is to settle on the browser as your runtime, so there's a certain irony to what you're saying.

[TobyTheDog123]

I never said we didn't have to set up an environment, but that the environment is

1. Installing Flutter 2. flutter create 3. flutter run

Instead of installing/configuring/setting-up npm, typescript, eslint + rules, react + rules + types, prettier, react-native-web + rules + types, a rendering framework + rules + types, webpack, jest, and whatever else.

You do, basically, get it for free.

[cxr]

You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.

Again, it's definitely not free (or "basically" free, either). Step 1 negates that statement. You have to set up a development environment. It takes some non-zero amount of effort.

In contrast, the browser is already there. It already runs JS. You don't have to do anything to make that happen[1]. And in saying it takes nothing, that's not merely "basically" nothing; it's literally nothing.

> Instead of installing/configuring/setting-up npm [and a bunch of other crap]

What if I told you that while you're free to opt for doing any/all of those things, none of it is actually necessary, let alone a good idea? (Or point out that TypeScript is not even JS, for that matter?) That you're totally allowed to ignore the GitHub busyworkers and write actual (i.e. straightforward, standards-compliant) JS—in contrast to much of what's available for NPM/NodeJS, where you are most often encouraged to write "JS" that's incompatible with what's in the standard (and what the browser makers actually implement)?

1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>

[TobyTheDog123]

You seem to be suggesting that instead of installing a piece of software and running two commands is somehow inferior to writing untyped, unscalable javascript, hard refreshing the page each time to see your changes, loaded in yourself with script tags. This is the oddest argument of all (I can use that word too)

There is a reason people made these countless frameworks and solutions, but the benefit Flutter provides is it's an out-of-the-box fix, and yeah, installing some software and running two commands is an out-of-the-box fix.

In addition, the entirety of your argument just flat-out ignores the cross-platform aspect of it, targeting only the browser instead of mobile and desktop platforms as well.

> You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.

I truly don't understand this odd exercise in linguistic gymnastics, as these are both simultaneously and entirely true. You can resolve this yourself.

And yes, it's still (basically) free.

[cxr]

> I personally dislike the whole JS ecosystem

Are you sure? The "whole JS ecosystem" you're aware of is likely to be the trendy (e.g. NodeJS+NPM) one*, which bears indicators at just about every turn that many/most of the folks working in it don't actually like the language themselves which results in lots of their energy being spent trying to fight with it which in turn produces the sorts of things that I'm guessing you like least. (For example: `package.json` is a tastemakers' invention and didn't appear anywhere in the spec.) This gives a skewed impression of what JS really even is; the dominant culture you see on GitHub is not the inevitable outcome of settling on a decision to standardize on JS.

(This isn't to say that the suggestion from the original comment you're replying to was a realistic/reasonable one in context.)

* in other words, not the "whole" JS ecosystem—you probably aren't looking at use of JS in, say, Gnome for example

[miffy900]

> I don't understand why Flutter's creators are so seemingly religious about Dart

I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.

Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.

In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.

[kitsunesoba]

I don't think it's necessarily an error to reimplement widgets, with a caveat — the reimplementations need to be good. Really good, at least as good as native widgets and preferably better. An example of this is Sublime Text/Merge, which feel excellent despite being built with a bespoke UI framework.

This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.

[deergomoo]

> I find the uncanny valley of pretend native controls a very uncomfortable place to be

Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?

The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.

[wg0]

Someday maybe they can switch the embedding shells to not draw but instantiate the native controls. That'll be really game changer.

This attempt to draw every single control is too much effort with apparent inconsistencies.