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

361–370 of 467 posts

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

#361

Post by la_fayette »

coldtea wrote: post #307
la_fayette wrote: post #253

Earlier quoted context omitted.

I tried flutter. The available plugins cannot compete with the cordova or react native plugin system. For most apps a PWA or cordova-based web app is enough... Many apps are data-intensive and don't require fancy animations... My clients are more than happy with what the web has to offer.

> I tried flutter. The available plugins cannot compete with the cordova or react native plugin system. The "available plugins" are not the right way to compare old frameworks and new ones. Of course a new framework like Flutter will have fewer. But also not everybody needs to use "available plugins", you can do a hell of a lot with just the SDK.

I can only disagree. Flutter is primarily a UI framework. The "functionality" of a mobile application requires access to core features of the mobile platform (e.g. accessing sensors, bluetooth, nfc, contacts, camera, ...). The platform feature access is made available via plugins also when working with flutter. This is the same for RN, Cordova, Xamarin etc. There is no SDK in flutter, Android is the SDK. Flutter has no direct access to Android SDK APIs...

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

#362

Post by willtim »

macspoofing wrote: post #350
romanovcode wrote: post #304

Earlier quoted context omitted.

Also slow.

Flash was fast. Much faster than JavaScript+DOM at the time. In fact, it was only within the last few years that browser JavaScript and rendering engines became more performant.

Which bit was fast? My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble. Eventually the machine died of fan failure and I had to spend an entire afternoon doing brain surgery on it. I wasn't surprised when Jobs subsequently banned it from the iPhone!

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

#363

Post by macspoofing »

McDev wrote: post #8
bradhoffman wrote: post #3

I’ve given Flutter a try with one of my client’s apps, and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms. I’d be curious to hear where other developers think Flutter is a good framework to use instead of developing native code.

Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you ), it seems to be an inevitability at this point. In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just…

>Lots of businesses are desperate for cross platform mobile dev

I would expand that to mobile AND desktop. It annoys me that multi-platform development typically means only iOS and Android.

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

#364

Post by kristoffer »

Nokinside wrote: post #360
kristoffer wrote: post #352

Earlier quoted context omitted.

No need for the tone. That is really easy as you say. What you seem to have overlooked are the implications of doing this. You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications. So ... no thanks! I do contract work for a company licensing Qt5. I'm hoping for Flutter or something else to kill Qt in the long run.

> No need for the tone. I think I'm allowed for the tone when you respond with the following: >You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications. The above is completely wrong. You develop and distribute your closed source software and link it with QT libraries like you would do normally. Nothing is needed from the customers. Your closed sou…

You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause).

Do you see any possible security problems with the above?

Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.

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

#365

Post by ajconway »

the_duke wrote: post #354
ajconway wrote: post #337

Earlier quoted context omitted.

The biggest advantage of React Native is that it makes use of native UI. You won’t be able to embed a browser, or a performant video player into a Flutter app (on iOS, at least).

Sure you will: https://pub.dev/packages/webview_flutter

Great news!

But, looking at the iOS implementation, it seems that it severely affects performance. Might work for simple apps (but then again, so does React Native).

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

#366

Post by flohofwoe »

Apocryphon wrote: post #294
pjmlp wrote: post #245

Earlier quoted context omitted.

Internal politic wars at Google, with management having popcorns to see who wins at the end. If you are confortable with Qt, JavaFX, Xamarin, there is hardly anything to see with Flutter, plus they are based on programming languages that you actually want to have on your CV, instead of one that was dropped from Chrome and rescued at last minute by AdWords team. Plus, even Fuchsia is not so focused on Flutter anylonge…

I’m sure those are all great cross-platform solutions, and Qt in particular has been around forever and predates smartphones, but you never hear about high-profile app examples that use them. Unlike React Native, which has lost more high-profile companies that previously tried them than I’ve ever heard of any firm using Xamarin. I wonder why is that. Doubtlessly you can make great apps with say NativeScript, or in Pa…

> but you never hear about high-profile app examples that use them

The entire UI of Maya (Autodesk) has been implemented in Qt since Maya 2011. I guess that's about as "high-profile" as it gets.

Not that I'm a fan of Qt, IMHO it's a bloated mess. But that doesn't mean high-profile apps don't use it ;)

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

#367

Post by est31 »

chrisseaton wrote: post #112
est31 wrote: post #102

Earlier quoted context omitted.

May I introduce to you: preparsed Javascript sent over the wire: https://github.com/binast/binjs-ref

Isn’t that just an AST? That still has to be parsed and compiled. It just makes parsing a bit faster.

From the README:

> Current advanced prototypes already show JS parsing improvements of 30%-50% on all the most common frameworks, just by changing the format, and we believe that we can increase this improvement much further.

30% is more than a bit :).

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

#368

Post by pjmlp »

pax_americana wrote: post #345
pjmlp wrote: post #245

Earlier quoted context omitted.

Internal politic wars at Google, with management having popcorns to see who wins at the end. If you are confortable with Qt, JavaFX, Xamarin, there is hardly anything to see with Flutter, plus they are based on programming languages that you actually want to have on your CV, instead of one that was dropped from Chrome and rescued at last minute by AdWords team. Plus, even Fuchsia is not so focused on Flutter anylonge…

> Plus, even Fuchsia is not so focused on Flutter anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust. I highly doubt that. See here https://fuchsia.googlesource.com/topaz/+/bd4464d6b8d586d74b6...

Yes, Flutter is still there. I didn't say it was removed, only that it is being downgraded to one among many options.

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

#369

Post by Nokinside »

kristoffer wrote: post #364
Nokinside wrote: post #360

Earlier quoted context omitted.

> No need for the tone. I think I'm allowed for the tone when you respond with the following: >You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications. The above is completely wrong. You develop and distribute your closed source software and link it with QT libraries like you would do normally. Nothing is needed from the customers. Your closed sou…

You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause). Do you see any possible security problems with the above? Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.

>You are forced to help customers replace the Qt libraries in your product.

Depends on what you mean by 'help'. You are forced to give the opportunity for them to do the work if they need it. If you have statically linked files, it can't be done by accident.

> Do you see any possible security problems with the above?

No I don't. When I provide completely closed binaries for my customers, they can hack with the binaries and create security problems if they want to.

Software security is not improved by obfuscation. If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.

Btw. I'm confused by your wording. I'm suspecting that you have some underlying assumptions you are not stating. Are you thinking that LGPL forces you to allow customers to modify the software in the hardware they are buying?

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

#370

Post by Kaotique »

Frameworks like this have come and gone in the last 10 years. I'm not convinced that using this will save you time in the long run. You need to invest a ton of time learning the ins and outs of these frameworks to get stuff done. There are always limitations compared to real native solutions. I think the time is wiser spend understanding the iOS and Android platforms itself.

There is also a big chance that Facebook, Google or whoever will drop their project at some point leaving you hanging and having to rewrite everything again to native or the next multiplatform framework.

Post reply on HN