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

321–330 of 467 posts

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

#321

Post by stonogo »

coldtea wrote: post #305
Illniyar wrote: post #259

This is the example flutter app for the web - https://www.nytimes.com/games/prototype/kenken#/ This is flash. You can't do anything in it that fills like the web - no copy paste, right clicking causes things to happen. I don't expect games like this to have links and proper bookmarkable urls, but I doubt it'll work as expected if it did. This is the epitome of the problem with flutter - it re-implements the UI, creat…

> This is flash. You can't do anything in it that fills like the web - no copy paste Whereas you would have that in a Canvas or OpenGL equivalent web game? > right clicking causes things to happen. That's already the case for tons of websites, there's support for that in web standards. > There's a reason why flash died out, and it's not only apple. Yes. It was controlled by a single company, IDEs were paid for, it wa…

> It was controlled by a single company, IDEs were paid for, it was more marketed to designer types, and it was frequently slow and used for apps and annoying stuff.

So aside from the IDE cost and marketing, there's no difference.

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

#322

Post by ricardobeat »

toan3rd wrote: post #281
rattray wrote: post #263

Earlier quoted context omitted.

Why not React / React Native?

If i understood it correctly, React Native basically gives you a JS runtime environment that handles communication with native APIs of the system and is shipped with your app. Flutter (and Dart) will transpile into native code and compile natively for your platform. So on React Native you will have that abstraction layer add runtime latency and package size of your app, while Flutter (Dart) really outputs native code…

Package size for Flutter apps is a lot larger than RN, even the RN Android build that ships it’s own JS runtime. There are complaints everywhere of simple apps reaching 100MB size.

As for runtime latency, I’ve recently worked on a RN app that outperformed its native sibling. Looking forward to the Fabric release.

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

#323

Post by bsaul »

sandGorgon wrote: post #293
bsaul wrote: post #268

Earlier quoted context omitted.

As a developer you cannot expect that the technology you learned at university will be used forever ( or actually at all) in your professional life. Schools are supposed to teach you enough of the fundamentals to be able to adapt and learn the tech du jour on your own. The sooner your students learn that lesson the better.

this is not an issue with two languages targeting the same SDK. you are mistaken on these aspects - I'm not sure if you are an android dev, so please forgive me if I'm pedantic. Kotlin vs Java is the situation you described. They both target the same underlying SDK. For example Pyspark vs Spark-scala. You can program in either, but you are still using the same paradigms - RDD, Graphframes, Dataframes. Flutter and And…

Sorry, i read your original post a bit too fast. Indeed, for corporations that’s a big question ( i thought you were teaching students, not hiring them)

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

#324

Post by TeMPOraL »

coldtea wrote: post #305
Illniyar wrote: post #259

This is the example flutter app for the web - https://www.nytimes.com/games/prototype/kenken#/ This is flash. You can't do anything in it that fills like the web - no copy paste, right clicking causes things to happen. I don't expect games like this to have links and proper bookmarkable urls, but I doubt it'll work as expected if it did. This is the epitome of the problem with flutter - it re-implements the UI, creat…

> This is flash. You can't do anything in it that fills like the web - no copy paste Whereas you would have that in a Canvas or OpenGL equivalent web game? > right clicking causes things to happen. That's already the case for tons of websites, there's support for that in web standards. > There's a reason why flash died out, and it's not only apple. Yes. It was controlled by a single company, IDEs were paid for, it wa…

> Whereas you would have that in a Canvas or OpenGL equivalent web game?

Yes, you would, at least for some parts. Web games often combine the canvas showing the "game world" with DOM showing some UI elements - on which all the usual affordances work.

> That's already the case for tons of websites, there's support for that in web standards.

Fortunately most sites don't bother. The defaults matter.

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

#325

Post by fauigerzigerk »

ricardobeat wrote: post #319
Apocryphon wrote: post #287

Earlier quoted context omitted.

I’m not convinced that Flutter needs to beat native to survive- it just needs to be better than React Native, Xamarin, and PWAs.

Beating RNW and PWAs will be hard. It’s a bit worrying to have Google pushing both PWAs and Flutter, there is always the chance of collateral damage from infighting.

It seems like hedging your bets by supporting a large number of competing SDKs is the new normal. Microsoft does exactly the same thing. Apple appears to be alone in committing to something specific.

The problem with this sort of hedging is that it only works for platform providers but not for developers.

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

#326

Post by TeMPOraL »

tracker1 wrote: post #274
pcr0 wrote: post #150

Earlier quoted context omitted.

I don't see how end users suffer from using Rails. Server side rerponse time is a very small component of page load time for most websites. It's different from being forced to download and parse megabytes of JS, which consumes CPU, battery and time.

There's more CPU time across 1000 users' browsers than on the server. That doesn't mean you shouldn't try to minimize your load at both ends.

The difference is who pays for the load.

And now that developers make the visitors pay for the load (through their electricity bill, and also through their mental state), they don't give a shit about how much the users will have to pay - and thus how much electricity will be unnecessarily wasted on a global scale.

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

#327

Post by pjmlp »

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…

There are plenty of high-profile Qt apps running on four wheels, and I bet with more users than all Flutter apps combined.

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

#328

Post by joking »

tracker1 wrote: post #271
Hixie wrote: post #96

Earlier quoted context omitted.

(I'm the Flutter TL.) Yeah, I was just writing a design doc earlier today and my math for how big a download we could reasonably expect users to wait for was based on a 5Mbit/s download speed. Half a megabyte takes under a second at that speed, but 5 megabytes takes more like 8 seconds. That's a huge difference. In an environment like the Web, where ephemerality is the norm, you really have to stay below 1MB from wha…

Should try all your Dev and browsing on a 2gb low end Chromebook, and last gen lower end phone for a couple months. Then see how you feel about it all.

I develop apps for tvs, so size and performance matters a lot since they are a lot of tvs already shipped with low end SOCs. newer ones are more powerful, but people doesn't change tv as frequently as phones.

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

#329

Post by ktpsns »

strange_quark wrote: post #194
stefan_ wrote: post #91

Earlier quoted context omitted.

The web samples: https://flutter.github.io/samples/ Because they make this impossible to find. I literally pieced this link together from the fricking browser screenshot.

Wow I hate these so much. Unable to select text in a recipe app, scrolling inertia on Mac is different (and no scroll bars?!), trackpad back/forward gestures are apparently hijacked, and those are problems I found from just browsing simple demos for 30 seconds. I really hope this goes into the Google dumpster quickly.

I hardly can say how much I second you. This feels like a bad full screen interactive video simulation of a mobile phone screen in the browser.

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

#330

Post by TeMPOraL »

CapsAdmin wrote: post #277

The lack of accessibility sucks, but there's a part of me wondering why we don't have accessibility tools that don't rely on us tagging images and giving us the ability to navigate the layout of a page. Wouldn't tools that do text and image recognition based on screen selection, arrow keys that move to the center of the nearest shape, etc. be a lot more useful? Like a Google lens for desktop. Text selection is 100% r…

Once you're at the level of OCRing text from screen, it becomes a general-AI-complete problem. See e.g. how bad OCR still is for books, and there you can still make good assumptions about the shape and meaning of text (sentences, paragraphs, chapters). With arbitrary UIs, you have to recognize what each block of pixels means, and that's the GAI-complete problem at which even humans fail (that's why the UI/UX/HCI fields exist).
Post reply on HN