Live data from Hacker News

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

developers.googleblog.com

171–180 of 467 posts

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

#171
post #96

Earlier quoted context omitted.

> It’s funny now that there’s fiber having 1GB/s internet speeds, we rant about 1MB size package. Half the people in the world probably struggle to have access to a 10 Mb/s connection. Even I go to places with connections that are tenuous at best.

(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…

All of this takes memory. Also i do a lot more than use some crappy flutter calculator.

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

#172

Earlier quoted context omitted.

Do users care? It doesn't feel exactly native on Android, but is still fast and looks great (it might indeed be better than native). Afaik the main alternatives, RN and Web (for fully reusable UI) are both heavy and don't feel that native either, yet are popular with developers.

As a user, I care quite a bit. As a developer, though, I get paid to tell people that their software doesn’t follow platform UI conventions and I run their code through mental checklists (“does the title animate properly during a controller pop, does this custom view break accessibility”) so I think it’s pretty obvious that I have a very specific slant on this issue. Keeping that in mind, I think that many users do c…

None of my mobile phone apps look like any of my other mobile phone apps.

I've never really considered it to be a problem. The thing that looks like a play button makes the media start, the square makes the media stop. The speech bubble looking thing makes some sort of conversation happen, and the photo looking icon either opens a camera or lets me add a photo from my camera roll. That last one gets a bit annoying.

But I seriously don't care. So long as every app is consistent with itself. The number of apps that follow "platform guidelines" is astonishingly small, typically those from the OS creator (Google or Apple) and people who used the sample template and who didn't bother to customize anything.

Which is another thing, if an app looks too much like other apps, it looks cheap. Sure I want proper back button and keyboard integration (numeric inputs should use the numeric keyboard and so forth), but apps that look like they fell out of a sample catalog don't feel premium.

There isn't a consistent "this is how all retail stores are decorated" standard, there isn't a set of mandated "this is how all grocery stores are laid out" regulations, why in the world do people go around insisting that all apps should look the same?

Sure, use the default platform picker if it is appropriate, but if it isn't (and finding the year picker on the Android date picker is darn nearly an easter egg, and Android's keyboard entry for time is also not up to snuff), then use something else!

I give 0 cares if an app has properly rounded text inputs. What makes an app feel good is nice animations, no stutter performance, quick load times, and a self-consistent look and feel.

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

#173

Earlier quoted context omitted.

Faster speeds for some do not equate to faster speeds for all. This applies doubly so when bandwidth is metered and may cost the end user more money. Abstraction for the engineer should not come at the expense of the person on the other end of the wire.

I disagree. I think Ruby/Rails is a good example of this. They maximize on developer happiness but that doesn’t stop users from using a bloated rails app. Take a look at GitHub/GitLab as an example of a Rails app I guess?

I haven’t used rails in about a decade. Is the bloat of a typical rails app on the user’s machine?

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

#174
post #144

Earlier quoted context omitted.

What source would you prefer an open source UI library come from, that would avoid this concern? Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success. Disclaimer: I work at Google, though not in a Flutter-related role.

Not the OP but I've quite a lot of trust in Microsoft when it comes to long term support and stability of their frameworks. They have their problems, but when they commit to something it's usually supported and stays around.

More-less agree, but, khah-Silverlight :)

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

#175
post #97

Earlier quoted context omitted.

> You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. I dabble in Android and Linux as well ;) > You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. Agree on both counts, but I like to think that users aren't completely cl…

I agree. Typical users aren't going to complain "hey this app doesn't feel native" or even know what that means! However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of ho…

> If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.

I just checked my 8 most commonly used apps, exclusing Chrome / Gmail, FWIW I am using Android.

1. Spotify - Doesn't follow any sort of UI standards. Also randomly decides to go into drive mode.

2. Clock - Built in, follows guidelines. About 50% of the time I hit the "trash" icon when I want to reset a countdown timer.

3. Development tool, not counting this

4. Libby, awesome app to checkout books local libraries. They have some seriously cool (but not always discoverable!) UI elements that custom solve problems that have. Their audio scrubber and speed changer for audio books are really cool.

5. Tabata timer - Doesn't follow any guidelines, really really needs a "stop" button instead of relying on back button to stop a workout.

6. Audible - Custom purpose driven UI, similar to Libby but different enough it can be a bit troublesome going back and forth.

7 and 8. Games, always have a custom UI, no problem using them.

tl;dr normal doesn't exist.

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

#176

Does anyone know how the server-side story is? Is there a CRUD-heaven like Django or Rails for Dart which can share the types with a Flutter client? IMHO Google should focus on that too, if not. I passionately hate re-typing same REST-entities over and over again, and that's one of the reasons why I love TypeScript.

Self-plug, but I just released Angel v2.0 this past month: https://angel-dart.dev (and https://docs.angel-dart.dev ) It's got a great story for code-sharing, an ORM, GraphQL support, along with dozens of supplementary packages for things like static files, WebSockets, etc.

Awesome!!! Looking for something like this. Will definitely check this out.

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

#177
post #117

Earlier quoted context omitted.

Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance. That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and perfo…

Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.

Just using the GPU isn't enough. On iOS and macOS you have a compositor that has exclusive access to the display that native widgets will use. If you do all the rendering yourself on the GPU, you'll incur an extra hidden full window blit on the compositor side, which is definitely noticeable, especially in power efficiency.

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

#178
post #127

I love the idea of Flutter for mobile and desktop but I'm very skeptical about the web implementation. They will need to reimplement tons of stuff that are already included in the browsers and ship all that code with the application.

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 and can assume users are office workers who have a reasonably fast desktop-class computer and a decent network connection. (Or if they're away from the office, they've already installed the mobile app.)

Some markets are more sensitive to download size than others and you need to understand your users to know what you can get away with.

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

#179
post #96

Earlier quoted context omitted.

> It’s funny now that there’s fiber having 1GB/s internet speeds, we rant about 1MB size package. Half the people in the world probably struggle to have access to a 10 Mb/s connection. Even I go to places with connections that are tenuous at best.

(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…

India. Next billion users.

Size matters a lot.

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

#180
post #144

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…

What source would you prefer an open source UI library come from, that would avoid this concern? Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success. Disclaimer: I work at Google, though not in a Flutter-related role.

I am excited by the Quasar framework, getting ready to launch their version 1.0. The vision is to simplify the Vue stack and automates and simplifies the onerous elements of webpack, linters, tree shaking, etc. It uses Material for UI and lets you push the same code to IOS/Android (via Cordova), desktop (via Electron), PWA and SSR.

What sold me on the framework is the focus on good documentation and sensible defaults. I could use more example code, but for its youth the framework is very exciting and has really made picking up Vue much more straightforward.

Post reply on HN