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

Flutter 2

developers.googleblog.com

Post reply on HN
Print view View original

701–710 of 780 posts

Re: Flutter 2

#701

Post by amelius »

dmitriid wrote: post #466
amelius wrote: post #421

Earlier quoted context omitted.

If OS vendors wanted web-apps to succeed, they could have done a lot more than they have done so far. E.g. better integration, or improved web standards to optimize for certain cases.

No matter how "better you integrate", there's one big core issue: the DOM. You simply cannot make the DOM behave as smoothly an as reliably as a native app. And no, no amount of "improved web standards" can help with that.

The DOM is just a kind of retained mode graphics, which can be fast depending on implementation. Also the DOM in most browsers is already sufficiently fast for many applications. It will never be as fast as native, but if you think that it needs to be then you are missing the point.

Re: Flutter 2

#703

Post by fizdoonk »

oblio wrote: post #233
pier25 wrote: post #178

Earlier quoted context omitted.

Dart is extremely easy to pick up if you've written in any C style language. Someone in our team had a small Android TV app working in 2-3 days with WebSockets, web views, some animations, etc.

Syntax, semantics, code organization and best practices, libraries, frameworks, debugging and debuggers, IDE support (preferably multiple IDEs for multiple platforms), LSP support, linters, profilers, disassemblers, dependency license checkers, dependency vulnerability scanners, package managers, package repository with support for private repos and proxying/mirroring, should I go on and on and on? Your toy app takes…

have you actually tried it? its ecosystem provides all of that

Re: Flutter 2

#704

Post by dmitriid »

amelius wrote: post #701
dmitriid wrote: post #466

Earlier quoted context omitted.

No matter how "better you integrate", there's one big core issue: the DOM. You simply cannot make the DOM behave as smoothly an as reliably as a native app. And no, no amount of "improved web standards" can help with that.

The DOM is just a kind of retained mode graphics, which can be fast depending on implementation. Also the DOM in most browsers is already sufficiently fast for many applications. It will never be as fast as native, but if you think that it needs to be then you are missing the point.

> The DOM is just a kind of retained mode graphics, which can be fast depending on implementation.

It's not, and can't be. There's literally no implementation of DOM that can be fast. There's literally no conceivable implementation of the current Web that can do, for example, fast animation on a list of elements without horrible hacks (like cloning elements, taking them out of the layout, hiding the original elements and then animating the new elements).

> It will never be as fast as native, but if you think that it needs to be then you are missing the point.

And what point would that be in the context of "If OS vendors wanted web-apps to succeed, they could have done a lot more"?

Re: Flutter 2

#705

Post by signal11 »

tiborsaas wrote: post #489
hamandcheese wrote: post #458

Earlier quoted context omitted.

> Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? I mean... yes? There is a ton of incidental complexity (i.e. unrelated to the business domain) involved in creating nice user experiences. If dev salaries weren’t so high then sure, more companies would probably spend the money to repeat the same work across severa…

+1 Furthermore users don't care about the technology used to build the application if it works, that's the unfortunate reality.

Users are not knowledgable enough to know what technology was used to build a product, but many have repeatedly complained about non-native UIs.

Heck, Lotus Notes went from being a market leader to an also-ran and user complaints about UX to corporate IT departments definitely played a role in convincing those departments in switching away.

More recently, this also happened with many mobile apps made with cross platform/HTML5 toolkits. They got low review scores and low user engagement across many firms, prompting a switch to native.

Re: Flutter 2

#706

Post by grizzles »

Hope they bundle a native webview with flutter with a consistent api across platforms. The web will always be a unique case, but that would be epic for other platforms. I'm not coding so much these days but I still want it. :)

Re: Flutter 2

#707

Post by perryizgr8 »

mdoms wrote: post #197
yagodragon wrote: post #112

We're all complaining about how js is a bad language, tooling is a mess, and how the web is fundamentally built for documents and makes it hard to create app-like experiences. Now, Google comes and creates a whole new UI toolkit from scratch, couples it with a very beautiful SDK and component framework and offers a far better programming language than js could ever be but we're still nagging. I was also pretty disapp…

I just visited flutterfolio.com. The very first thing I tried to do is enter a username and Tab to the password field. But Tab just catapulted my input focus to the browser address bar. I mean, come on.

Also, try to select any text on that page. This is Flash all over again IMO.

Re: Flutter 2

#708

Post by saagarjha »

birthday wrote: post #589
ryandrake wrote: post #436

Earlier quoted context omitted.

I don't even fully understand why "cross-platform UI development" is such a holy grail. Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? Is it that hard to find developers who know more than one programming language? With a lot of these frameworks and higher level abstractions, if you go off the toy-app happy path,…

Just imagine trying to build a mobile startup company and having to write 2-3 copies of your app (Android, iOS, Desktop). No thanks! Nobody needs native UI. It's time we get passed that!

People with disabilities frequently do.

Re: Flutter 2

#709

Post by saagarjha »

gurkendoktor wrote: post #669
mwcampbell wrote: post #563

Earlier quoted context omitted.

> but UIKit doesn't even have a standard button class Doesn't anyone else use UIButton? Granted, the native iOS app I developed was intended primarily for blind people, so I didn't really make it visually polished.

Yes, the visual polish is what I mean. It's not rocket science to style UIButton, but the lack of a good default style means that mediocre native apps often have weird/inconsistent highlighted button states, and so on.

But at least they are semantically buttons and not the UI equivalent of a to VoiceOver…

Re: Flutter 2

#710

Post by themacguffinman »

danShumway wrote: post #584
themacguffinman wrote: post #526

Earlier quoted context omitted.

Supporting new and unique APIs/inputs/etc like WebVR is a pretty classic cross-platform problem and it's usually addressed by allowing native hooks. Flutter has MethodChannels which let you call native methods in the underlying "platform host". It also supports "PlatformViews" which let you embed native widgets. It doesn't really need to have instant parity with "native" web apps at everything. Maybe Flutter is a poo…

It's not just about building special experiences. I want to be able to browse normal websites in VR -- VR and uncommon user agents introduce a new set of user inputs that Flutter will need to handle if it doesn't want its websites to just break if someone loads them up in a headset. Currently as a web dev, if I want my website to be usable by a voice assistant, I don't have to do anything. If I want my website to be…

It's true of course that as a cross-platform toolkit independently built on top of another platform, Flutter will have to consider new controls, gestures, and changes in many platforms. You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. There's been far more handwringing over the web's deficiencies as compared to native OS platforms; why reinvent the wheel with some crappy dynamic language called JS, why rebuild everything with a custom style language and layout engine? Yet Electron and web apps continue to dominate because the trade-offs can still be worth it.

The web is not really adopting hordes of new input modes like WebXR every year, there'll be plenty of time for Flutter to consider new stuff like that before it approaches relevancy in mainstream product development. Accessibility features like voice assistant support don't necessarily come free either. Rich web applications usually don't produce simple/accessible DOM structures even if you're developing with web-native tooling. Flutter or not, accessibility practically always requires some level of manual annotation in web apps, which is Flutter's primary use case.

> Not on the web though. I mean, for obvious reasons on the web we can't just expose native OS methods for websites to call.

I meant native-to-the-web. Flutter's MethodChannels & plugin system works on the web too. If there are browser APIs that you need to use, you can setup hooks to call them from within Flutter.

Post reply on HN