Flutter for Linux

So those bindings are official part of Gnome project or not?

As for C++ it looks pretty official to me, it is even considered an internal resource:

https://developer.gnome.org/references#api-bindings

As for being done with me, who cares when the official web site sends another message.

Don't kid yourselves. Web target is very much early alpha for Dart.

There are so many obvious problems with it:

- Everything relies on 1500 nested custom elements with hardcoded transforms to put them in place

- This breaks default browser interaction with the page entirely. Because what may look like a page is actually a bunch of absolutely positioned controls with absolutely positioned canvas inside them.

- Scrolling, one of the most important things in a browser, is broken. It's janky and slow (manually re-implemented?). I'm guessing containers have to be explicitly marked as scrollable with correct sizes, because resizing the browser window does not make content scrollable (try it with the demo you linked).

- Text is broken. Because it's rendered onto a canvas. So, all text interactions + accessibility is broken. Fonts are rendered incorrectly. I mean, on the demo page you can't even copy code other than through the "Copy All" button.

- Navigation is broken. Navigating the demo apps (which have more than one page) is not reflected in the url, so the back/forward buttons are broken

- Keyboard navigation is broken. Nearly none of the elements can be tabbed to. Except some buttons in demo pages. I guess they are explicitly marked as such?

- When elements can be navigated to by keyboard, they can only be activated by Spacebar. Even though Enter also exists. I'm pretty sure forms cannot be submitted by pressing enter, either.

- iOS-style date pickers are clipped in Safari

- 2D transformations demo is broken in Safari

It's just me spending five minutes on the demo site.

The effort is certainly commendable. It's not beta yet. It's possible you may want to scrap this and go the Figma route. They implemented their own rendering engine in WebGL: https://www.figma.com/blog/building-a-professional-design-to...

-

It's not so much that they will drop it but they may loose interest in it and let it die off naturally. It all depends if they can convince enough people to use it. I've not actually seen or used any flutter apps yet. I'm sure they exist if you go looking for them but it's early days. Most stuff out there is not flutter based.

Google needs to work on untangling it from Dart and start actively working on Kotlin support. Dart is actually compiled to native code and the most of the UI stuff is basically written in C++. Kotlin has a native compiler already, so that's not necessarily a show stopper. And given the huge amount of Android Kotlin developers out there, it's kind of an obvious thing to do. Yet they choose not to work on this.

Fixing this would result in a lot of existing developers having an easy transition to flutter that are currently not planning to go there.

The reasons they are not doing this are entirely political and can be summarized as "not invented here".

Kotlin is a problem for them because it's 1) popular 2) the main language for Android development and 3) controlled by a company that is not Google.

Flutter is their attempt to fix this. They can't kill Kotlin because it's popular but they can try to replace it and nudge developers away from it. The problem for them is that Dart is not good enough. It's a hard sell and effectively a downgrade if you are used to Kotlin. They've been trying to fix that by adding features to Dart that are clearly intended to narrow the gap.

Fuchsia exists for the same reason. Yes there are technical reasons for it as well but the real reason is control over the ecosystem. The combined strategy is risky and dependent on the success in the market of their pixel phones. So far this is not looking great. Google convincing OEMs to jump on the bandwagon is going to be very dependent on them being able to launch a fuchsia phone. I'm pretty sure none of the OEMs is keen of having more Google control and oversight. So effectively, Google would have to launch a Fuchsia phone, make sure it becomes popular, and then twist the arms of all their OEMs to abandon Android. Failing to do that would result in a new phone platform with tiny marketshare that users, developers and OEMs can safely ignore. The mere prospect of that is the reason I expect it will never make it to market.

Flutter may or may not survive that decision. What's going to be interesting is what everybody else does. Flutter and react native are so far the two dominant cross platform approaches. React native could get a lot more interesting with things like wasm opening up that space for Kotlin and Swift developers. A lot of Kotlin developers favoring React Native over Flutter would be a big problem for Google.

I like the architecture that Flutter has chosen where the only thing you need from the OS is a canvas and everything is painted by Flutter. It gets you a good programming model and predictable results regardless of target.

The downside is that in order to produce iOS or Android looking UIs someone needs to create every iOS and Android standard widget, with the same behaviour. If those widgets change in future versions of the OS, or new ones are created then more work needs to be done.

This is fine in the current project setup - the work is worth it to Google, but without a corporate backer that's the sort of thing that will fall behind.

Why is this style of programming frowned upon in Javascript yet idiomatic in Flutter?