Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

601–610 of 748 posts

Re: We're forking Flutter

#601

Post by divan »

satvikpendem wrote: post #556
chrismorgan wrote: post #462

Earlier quoted context omitted.

If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean im…

Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.

Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?

Re: We're forking Flutter

#602

Post by wruza »

divan wrote: post #525
wruza wrote: post #393

Earlier quoted context omitted.

This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately. When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.

I disagree with this so much for two reasons: 1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far. 2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinio…

Native doesn’t mean web. I meant just an input as it works everywhere on a platform, input core.

Partially agree on the web sentiment, it just lacks a proper model, both positioning and styling, for what we call apps.

Re: We're forking Flutter

#603

Post by zigzag312 »

DeathArrow wrote: post #495
lolinder wrote: post #400

Earlier quoted context omitted.

If Flutter is a car, Python is at least four different models of car, plus three models of light truck and one airplane. The scope of Python's standard library is just enormous.

And Python is written in C, unlike Flutter which is written in Dart.

Flutter engine is mostly written in C++.

Other parts are written in Dart like you said.

Re: We're forking Flutter

#604

Post by FpUser »

wruza wrote: post #389
malkia wrote: post #364

Earlier quoted context omitted.

Python is an engine, flutter is the whole car.

I doubt that complexity of a language is comparable to that of a widget library. After the text input cell and scrolling window it’s basically dumb geometry/drawing code all along.

The code behind "intelligent", performant and scalable Tree/Greed widget can be quite big and complex and include concurrent/parallel code.

Re: We're forking Flutter

#606

Post by fauigerzigerk »

amelius wrote: post #598
deergomoo wrote: post #251

Earlier quoted context omitted.

I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…

Do you hear people complain that __websites__ have different aesthetics? I used to share your opinion but since the web I think it is great that designers can have original designs and I started to worry about more important things.

I agree. What doesn't get enough attention in these often dogmatic debates is that there are some native conventions that are hugely important for usability while others are mostly irrelevant.

E.g, I have to use a Java app on the Mac that uses Ctrl+V rather than Cmd+V for paste as well as other Windows/Linux keyboard conventions. This is extremely jarring.

Web apps never do that. Browsers are pretty good at using native conventions where it matters by default. Of course web devs sometimes go out of their way to vandalise the browser's perfectly good defaults - e.g. by overriding scrolling behaviour.

Surprisingly, some of Apple's own native apps (such as Numbers) break platform conventions in ways that makes the app extremely inconvenient to use.

Re: We're forking Flutter

#607

Post by wruza »

1oooqooq wrote: post #587
wruza wrote: post #456

Earlier quoted context omitted.

Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing. Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.

it's not a native widget. you can type styles on whatsapp which is not possible on native input. whatsapp is the poster child of this technique btw.

Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within

. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know.

So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.

Re: We're forking Flutter

#608

Post by ototot »

I believe this kind of issues happen in Google everywhere. Not sure who to blame for, but it’s definitely a severe crisis Google is facing. Google should spend time fixing it.

Re: We're forking Flutter

#609

Post by m3talsmith »

deergomoo wrote: post #215
divan wrote: post #120

> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…

> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb. A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through th…

The developer could use the cupertino framework for iOS releases, but usually choose not to.

Re: We're forking Flutter

#610

Post by account42 »

divan wrote: post #601
satvikpendem wrote: post #556

Earlier quoted context omitted.

Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.

Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?

Existing food delivery apps are not only indexable by google but actively make sure to spam the top google results for all possible food related searches. You couldn't have choosen a better example to disprove your argument if you tried.
Post reply on HN