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

Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

developers.googleblog.com

Post reply on HN
Print view View original

201–210 of 467 posts

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#201

Post by rpeden »

ehsankia wrote: post #90
ergothus wrote: post #77

No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs? That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding…

GWT lived for over a decade (how many web libraries do you know that have survived for for that long?), AngularJS is still in maintenance mode, Dart died when it didn't get browser support and Typescript was obviously the better alternative. At the end of day though, I look at if Google itself is using it extensively, because that's when a library will have the best support/longevity.

GWT is still pretty alive, too.

It hasn't seen a release in a while because the developers contributing to it have been working on making it work with Google's recently open sourced J2CL compiler. From what I've read, builds of though are available but no official release yet.

I use React and Angular these days, but even back in 2010-2011 GWT felt pretty "done". At least for the things I needed to use it for.

Starting a new project with it now probably wouldn't be a career-enhancing move, but it was a pretty decent way to build really complex web apps at a time when the JS ecosystem was a lot less mature than it is now.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#202

Post by kaycebasques »

mraleph wrote: post #68
jwiley wrote: post #38

Earlier quoted context omitted.

'main.dart.js' in the example Flutter KENKEN app linked in the blog post: Chrome - 359kb Firefox - 990k I agree that Chrome is becoming more and more a proprietary channel for Google products, which is probably what its original intent was all along.

It's actually the very same main.dart.js (dart2js compiler does not have ability to target a specific browser, its output is supposed to work in every supported browser). 359kb is its compressed size, 990k is its uncompressed size. Firefox shows compressed size in the "Transferred" column and uncompressed size in "Size" column. In Chrome by default you see compressed size only, but if you click "Use large request row…

Use large request rows in Chrome DevTools to see transfer size and uncompressed size: https://developers.google.com/web/tools/chrome-devtools/netw...

Disclosure: DevTools technical writer

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#203

Post by aasasd »

vetinari wrote: post #34
saagarjha wrote: post #11

Earlier quoted context omitted.

I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.

> If you want your app to look like an Android app on both platforms Funny thing is, that it is emulated on Android as well.

Like Android has any consistent UI at all. On my phone, two apps would have the same widgets only by accident.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#204

Post by eitland »

Hixie wrote: post #64
eitland wrote: post #22

Earlier quoted context omitted.

Are you saying this isn't a web framework but rather a Chrome framework??

(I'm the Flutter TL.) We support targeting the Web (that's the tech preview we released today), and we support targeting Android, both of which ChromeOS support. We also support development on ChromeOS.

Hi Hixie and thanks for replying!

>> Flutter apps can now target the chrome browser (preview at this point)

> We support targeting the Web (that's the tech preview we released today),

Sorry for asking that way, I see my first question wasn't too well received by some other people here - and I can kind of see why - but I hope with the added context it makes it more clear why I asked.

I reread the article now in the morning and I see FF and Safari mentioned. I'm just so tired of everything that for some reason doesn't work in my main browser :-/

Good luck then!

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#205

Post by skybrian »

pier25 wrote: post #188
skybrian wrote: post #178

Earlier quoted context omitted.

I look at it differently. When someone compiles a game to webassembly it's seen as an accomplishment, right? It doesn't mean you would normally write web apps this way, particularly if you're targeting consumers internationally and need web pages to load fast. But being able to make a desktop or mobile app work in a browser should be useful, particularly for businesses. Sometimes you're not targeting the whole world…

> When someone compiles a game to webassembly it's seen as an accomplishment, right? Yes, but browsers do not have game engine APIs. They do however have a layout engine, text editing and rendering, accessibility features, and a very long etc. Basically anything you need to make an app with text, images, buttons, etc. Don't me wrong, I'm sure Flutter for the web is a technical marvel. > Some markets are more sensitiv…

I don't know what it's intended for or who will find it useful. Just saying that it's not a binary choice (either useful or useless for everyone).

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#206

Post by mkozlows »

mevile wrote: post #100
ergothus wrote: post #77

No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs? That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding…

You didn't even mention the Closure library which was released and then practically abandoned. We invested so much into Closure where I worked, with the promise that this is what Google used internally, when suddenly Angular dropped out of Google and that sucked up all the oxygen in the room.

I mean, okay, but which other things that you would have selected would still be a good choice today? Would you be happy if you'd gone with Ember or Backbone?

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#207

Post by chupasaurus »

seabrookmx wrote: post #189
sandGorgon wrote: post #182

Can someone from the Google team comment on what's going on - https://techcrunch.com/2019/05/07/kotlin-is-now-googles-pref... > Android development will become increasingly Kotlin-first,” Google writes in today’s announcement https://techcrunch.com/2019/05/07/google-launches-jetpack-co... > Google today announced the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers who want to use…

There's been activity porting the Android Java components to Fuschia. I have no inside information (not a Googler) but that leads me to believe that if Fuschia becomes the next mobile OS from Google it will support both. So same goes for Android I would assume. Why does an OS need to have a single stack? You can write desktop apps in a zillion different languages and Frameworks after all.

s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.

> You can write desktop apps in a zillion different languages and Frameworks after all.

You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#208

Post by seabrookmx »

chupasaurus wrote: post #207
seabrookmx wrote: post #189

Earlier quoted context omitted.

There's been activity porting the Android Java components to Fuschia. I have no inside information (not a Googler) but that leads me to believe that if Fuschia becomes the next mobile OS from Google it will support both. So same goes for Android I would assume. Why does an OS need to have a single stack? You can write desktop apps in a zillion different languages and Frameworks after all.

s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about. > You can write desktop apps in a zillion different languages and Frameworks after all. You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Elec…

Me not knowing how to spell the name of a plant/colour/operating system has something to do with my recollection of recent tech journalism?

I appreciate the correction of my spelling (honestly) but this is a bit of a stretch.

Your API/ABI point is also completely off topic. My comment points out that on the _same_ OS you can use different technologies, like Electron or Qt. I'm trying to point out that having both Kotlin and Dart/Flutter as options isn't bad or unprecedented like the parent comment seems to allude to.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#209

Post by tylerhou »

chupasaurus wrote: post #207
seabrookmx wrote: post #189

Earlier quoted context omitted.

There's been activity porting the Android Java components to Fuschia. I have no inside information (not a Googler) but that leads me to believe that if Fuschia becomes the next mobile OS from Google it will support both. So same goes for Android I would assume. Why does an OS need to have a single stack? You can write desktop apps in a zillion different languages and Frameworks after all.

s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about. > You can write desktop apps in a zillion different languages and Frameworks after all. You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Elec…

> s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.

Is this necessary? Also, you definitely shouldn't be throwing stones while living in a glass house. s/mobiles/mobile

> You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.

ABI only matters if you're linking code or directly running bytecode on another platform. If you're targeting another platform, you're almost certainly going to recompile libraries/your application to target the new platform, so you won't run into ABI issues. Especially because most desktop platforms (read: x86) have bytecode incompatible with mobile platforms (read: ARM).

Also, Qt and Electron are abstraction layers over OS interfaces. As long as the OS supports the required primitives you could presumably rewrite Qt and Electron to target the new platform. Although it might take a fair bit of work, people have done so.

In fact, a quick Google search reveals that you're completely wrong about Qt not working on mobile: https://doc.qt.io/qt-5/android.html

Post reply on HN