Live data from Hacker News

Flutter 2

developers.googleblog.com

551–560 of 780 posts

Re: Flutter 2

#551

Earlier quoted context omitted.

I don't understand why more resources aren't being put into Qt and making that easier to use or building a more "web-developer-friendly" abstraction layer on top.

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,…

you release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers.

You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working.

You implement the feature over on Macs as well copying the Win strategy. But a recent Mac OS update causes a bunch of permission popups that mess with another thing. Now you're messing around with that, and your internal users are pissed (cuz they're all on Macbooks).

There is no Linux version, luckily.

I mean... OK, yeah, you still have to deal with platform differences even when using Electron. But you are in the same boat with like.... Slack, Discord, etc etc. You get _all_ that shared knowledge, a unified code base. And in theory you throw any of your engineers at the problem and they can try very hard googling "Electron [issue] windows".

I also bemoan the fact that _even Slack_, with its billions of dollars, didn't feel the need to have a native application. But I do get it, especially when there's a lot of pressure to ship.

Re: Flutter 2

#552
post #515

Earlier quoted context omitted.

Or give Ionic react a try

I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves. Some examples from the top of my head: - various performance issues (e.g.: memory leaks which haven't been fixed for years [1]) - their push/pop router navigation seems like a rea…

-the push/pop router navigation is insane, it by default keeps all views in memory all the time for react it will reload every view with any state change by default.

Re: Flutter 2

#553

The idea sounds very appealing, especially to an indie developer: being able to ship your app on multiple platforms from a single codebase is kind of the holy grail. Unfortunately, the result is.... I tested this Flutter example[1], on a 16" MBP with and i7, and it is janky as it can get, it feels like I'm using a 15 year old computer. From the code it looks like the whole thing is... rendered on canvas? I'll pass. […

I can't highlight text on any of the example pages. I want to like this idea so much but wow

Re: Flutter 2

#554

Earlier quoted context omitted.

I don't understand why more resources aren't being put into Qt and making that easier to use or building a more "web-developer-friendly" abstraction layer on top.

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,…

The blog exactly answers this.

------------------------

Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.

By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.

Google Pay also reports that their engineers are far more efficient, with a huge reduction in technical debt and unified release processes such as security reviews and experimentation across both iOS and Android.

Re: Flutter 2

#555
post #545

Earlier quoted context omitted.

There is no default in Flutter. Everything is a widget that you have to deliberately choose. https://api.flutter.dev/flutter/material/SelectableText-clas...

If `Text` and `SelectableText` exist, I would call that an opt-in. The default is "Text" (not selectable) and a modifier can be applied to opt into using "SelectableText". It would be different if they were called "UnselectableText" and "SelectableText".

Isn't that just semantics?

Seems like every dev using Flutter for more than a few days would know that both `Text` and `SelectableText` exist and pick the one that's relevant to whatever kind of text they're adding. At that point, it's the dev's fault for making a conscious decision to make text selectable or not (if they choose wrong); not really the language's.

Re: Flutter 2

#556
post #432
post #400

Earlier quoted context omitted.

Would have been be nice if they provided a way to use Kotlin Native as a language for Flutter instead. Not a JVM Kotlin of course, because it's too slow for the native mobile apps. Or, even better, Rust. That would be very impressive.

If you prefer Kotlin you may find https://developer.android.com/jetpack/compose more to your tastes.

Could any Android dev veterans chime in and comment on JetPack? This is the first time I'm hearing about it and I'm not sure I like it. It looks like a weird blend of HTML, CSS and JavaScript event handlers and I'm starting to wonder: Why not use web technologies from the get-go then and make use of the lessons learnt there?

This reminds me, I'm getting the impression that with every new UI framework that gets released, we're just recycling ideas learnt on the web and re-living its paradigm shifts:

1. First, in the early days of the web, we defined UIs declaratively but mixed structure and looks (`Hello, world!`).

2. Then we separated content structure (HTML) and styles (CSS) (or even XML and XSLT)

3. Later on we added dynamics and discovered event handlers (JS)

4. Then we realized we could use JS for everything (content, styles, dynamics) and imperatively create & manipulate UIs by manipulating the DOM (document.createElement, jQuery, d3).

5. Finally it dawned on us: That's not a good idea, either, because 1) we're mixing business logic and styling and 2) the DOM is global state. So we switched back to the now classic separation of using HTML for content, CSS for styles and JS for dynamics. But this time we try to keep individual components (their state, their DOM and their business logic) neatly encapsulated (React, Angular, Web Components).

Re: Flutter 2

#557
post #435
post #290

Earlier quoted context omitted.

It takes work to make it non-selectable. In Flutter, it defaults to non-selectable. Most of the time a dev isn't thinking "I'd better make this selectable," because they simply aren't going to think of all the reasons someone might select text. They'll think of the obvious-to-them cases, and leave all the other text as unselectable.

It doesn't really default to anything. There's a widget for selectable text and a widget for non-selectable text.

OK, but the Flutter gallery has zero selectable text, as far as I can see. Seems like a great case of where developer decided "doesn't need selection, let's let the user drag to scroll with their mouse instead".

Re: Flutter 2

#558
post #233
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…

The fact is that even considering all those points, Flutter+Dart is still much easier to learn than Swift+iOS and Kotlin+Android (even separately). And I'm not even considering Desktop.

Re: Flutter 2

#559

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,…

> 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…

Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.

Re: Flutter 2

#560

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…

We're nagging because the apps suck and stick out like a sore thumb. Maybe Flutter will be the one to get there and be the holy grail of cross platform UI development, but the developer community has been burned by this promise so many times, we're going to have to see the final product before getting excited. Just because a project is ambitious doesn't mean we should all jump on board, particularly when similar proj…

[deleted]
Post reply on HN