Flutter 2 • Hacker News Board

Re: Flutter 2

#541

Post by BystanderX » Thu, Mar 04, 2021, 12:59 AM UTC

Hixie wrote: post #520

BystanderX wrote: post #488

Earlier quoted context omitted.

So this is already a pretty toasty section of comments so let me put this to you. If you've already answered this elsewhere, please let me know. I would be surprised if someone heavily involved in the Web's development process for a long time didn't have some really sore spots about it. That aside: -- What do you think of the loss of opportunities for learning and customization that moving to an opaque system running…

> What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies? Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages. I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we…

Thanks for your reply.

> Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...

I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using HTML/CSS/JS, even if not perfect.

Perhaps if Flutter became mainstream enough that there's theoretically nothing stopping this from eventually happening for it as well. That's an interesting thought.

--

I suppose that leaves my last question, and it leans away from what might be a practical view from your position: Do you think flutter pushing for major market share while also trying to replace the core part of the web (HTML/CSS/JS -> Canvas renderer/wasm) is a good thing for the web's health and future?

(That's a good bit more philosophical, but I hope in #CURRENTYEAR we're starting to see value asking long-term questions like that, especially from inside of the giant companies. I'll stick to one of those kinds of questions)

--

> I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)

That is interesting, thanks for sharing that.

> I have not. A lot of people do like extensions though.

Also interesting, fair enough.

> Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.

Perhaps a good new question is what kind of tooling is available or planned for users to interact with Flutter applications? Such as what Devtools provide, or an expansion to them directly.

As a developer, the Devtools are absolutely critical to my workflow and ability to learn from and often fix issues I have with other sites.

(It could be pointed out that native applications don't tend to have that functionality, so it shouldn't be expected.. but in this context we're talking about effectively removing it from the Web, which does)

Re: Flutter 2

#542

Post by iainmerrick » Thu, Mar 04, 2021, 1:06 AM UTC

vorpalhex wrote: post #446

tofuahdude wrote: post #429

Earlier quoted context omitted.

What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base? We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.

I was with a team that went the React Native route. At first it was fine until we had to go slightly off the rails.. and I was rebuilding .so files based off random gists and updating linkage assemblies. React Native works until it doesn't and then you are getting into very detailed platform specific territory. A lot of the cross platform promises were untrue - we quickly learned the importance of QAing both builds a…

I have had the exact same experience. I’m not a big fan of React or React Native, but I can see that it does increase code reuse; but...

As you say, platform-specific glitches will always crop up so you’ll always need a bit of native work. If you’ve thinned out native development team this can make things hard. Instead of a team of 5 or 10 native developers working on bread-and-butter UI stuff, you only have enough work for 1 or 2, but it’s all grungy stuff like talking to low-level frameworks and working around platform bugs (or React Native bugs, of which there are plenty). That’s not a recipe for clean and maintainable code.

A related issue is that React and React Native aren’t 100% compatible. You can’t just move existing React code directly over as you might elect. It is possible to write code that works on both, but it isn’t trivial.

QA definitely needs to be done separately on each platform.

Re: Flutter 2

#543

Post by jkrems » Thu, Mar 04, 2021, 1:07 AM UTC

tvolkert wrote: post #124

kureikain wrote: post #50

I want to love Flutter. But once looking at it, it's a no go. It's the new flash. Really, you cannot copy the text anymore. React native is my goto solution now.

Flutter team member here. In Flutter, the developer consciously decides which text should be selectable (and thus copy/paste'able), so while it's true that text is not inherently selectable in a Flutter app, text that the app developer decided to make selectable will be.

Is the goal to get full parity with native text selection? I went to the plasma demo and tried to double/triple click on text and it didn't match what text selection is supposed to do, at least on macOS. Which makes it a bit jarring. Right now it seems to be a bit "uncanny valley".

(Disclaimer: I work for Google but not related to Flutter.)

Re: Flutter 2

#544

Post by WoodenChair » Thu, Mar 04, 2021, 1:07 AM UTC

ryandrake wrote: post #538

tiborsaas wrote: post #485

Earlier quoted context omitted.

> Is it that expensive to separate your business logic from UI and write the small UI layer Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic. Ideally, I want to write it once that I want a row of buttons what colo…

Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing…

> Guess I never realized this was a controversial approach to take!

It’s not about controversy. It’s just that in most apps, the UI is far more than 10% of the code base.

Re: Flutter 2

#545

Post by jkrems » Thu, Mar 04, 2021, 1:10 AM UTC

fastball wrote: post #508

mdoms wrote: post #271

Earlier quoted context omitted.

Yes I have, which is why I know text can be selected by default in every web environment.

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".

Re: Flutter 2

#546

Post by JamesSwift » Thu, Mar 04, 2021, 1:10 AM UTC

drewda wrote: post #335

blacktriangle wrote: post #132

Earlier quoted context omitted.

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…

On this note, I have 60% fond memories of Appcelerator Titanium and 40% frustrating memories :)

Man those are some rosy glasses you got. I've got 20% fond memories, 80% frustrating memories : )

Re: Flutter 2

#547

Post by raihansaputra » Thu, Mar 04, 2021, 1:10 AM UTC

The_rationalist wrote: post #451

throwaway123x2 wrote: post #293

Earlier quoted context omitted.

Oof remember when PhoneGap was the next big thing? RIP

Pure nonsense, phonegap has been renamed Cordova and is widely used. The Electron of smartphones is Ionic which is a sexy and performant superset of Cordova. PhoneGap (Cordova + Ionic marketshare) has a bigger marketshare than flutter and react native! Source: https://www.appbrain.com/stats/libraries/tag/app-framework/a... Ionic is a gift and it will only get more widespread, the myth that chromium is slow is increas…

Ionic has released Capacitor as the successor for Cordova. And it's still compatible with Cordova plugins so all the work from Cordova days is not wasted. Ionic is definitely a gift.

Re: Flutter 2

#548

Post by azinman2 » Thu, Mar 04, 2021, 1:14 AM UTC

Do they render everything themselves to pixels? If so, then does that mean any native integration with, say, a screen reader won’t work? Copy paste using native UI? Any future native offerings that work on top of the view hierarchy and components (really important for accessibility, to start)?

Re: Flutter 2

#549

Post by JamesSwift » Thu, Mar 04, 2021, 1:17 AM UTC

awesomepeter wrote: post #338

jaegerpicker wrote: post #220

Earlier quoted context omitted.

Are you a native mobile developer? I am (was I'm moving to ML/AI/Data engineering) and I don't think flutter is in any way easier or nicer than the native toolchains for mobile. Both Swift and Kotlin are better languages than Dart IMO, the IDE and tooling is far superior for both also. Flutter is faster but once to deploy a substandard quality of app for sure but matching the quality of a native app? That takes just…

If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.

If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.

Re: Flutter 2

#550

Post by iainmerrick » Thu, Mar 04, 2021, 1:17 AM UTC

buu700 wrote: post #536

iainmerrick wrote: post #534

Earlier quoted context omitted.

Well, if “viable” means “doable but really fiddly”. C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier). C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself. So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option . What other language are…

I'm not commenting on any other platforms, but I maintain a few C/WebAssembly libraries and they work exactly as expected without being unreasonably large. C-in-JS has been viable for a number of years now.

I realise it works, I just don’t think it’s really useful for what was asked for, a way to write common cross-platform business logic for a platform-specific UI.

Unless there are some great new tools I’m not aware of, C on WebAssembly seems about the same as C on Android. You can compile stuff just fine, and run it, but actually connecting it up to any substantial UI written in JS/Java is going to be incredibly tedious.

For a computation library with well-defined inputs and outputs, and that “just works” and doesn’t need any debugging in situ, it makes a lot of sense. But I think business logic by definition is going to need a much richer interaction with the UI, and that’s what makes it hard.