Hacker News new | past | comments | ask | show | jobs | submit login
Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop (googleblog.com)
653 points by mikece 12 days ago | hide | past | web | favorite | 449 comments





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, creating an experience that is just close enough but not good enough. And no matter how many smart people and an insane amount of resources they put into it, it'll never be good enough.

There's a reason why flash died out, and it's not only apple. It was dropped for making interactive website long before apple killed it - it doesn't work well with the web.


> This is flash

This was exactly what I thought when reading about this. I'm pretty sure the one codebase for multiple plattforms just won't work. An app has it advantages so has a website. Mixing those up leads to something that just combines the disadvantages of both. And this my main critic on Flutter: It just doesn't feel good. Maybe it does on Android but it surely doesn't on iOS or on the Web. I would rather prefer something where I can share a core codebase between platforms and then implement a user facing layer with all the plattform specific features


> It just doesn't feel good.

This was my thought exactly. It's not that it feels different, but that it's not an improvement.


>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 was more marketed to designer types, and it was frequently slow and used for apps and annoying stuff.


> 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.


>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.

Only if they care, most don't. In this case, they also don't. It's still trivial to do it, even in Flutter.


Last I checked, web games pretty much died with Flash. Sure, it coincided with mobile games soaring, but I doubt web games would've become this scarce without Flash dying as well.

Scarce? There are plenty of them available.

Web games died? They are stronger than ever, and a huge multi-billion market...

> 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.


Perhaps you've missed the "controlled by a single company", made for designer types (by marketing to I don't just mean how it was promoted), slow, and used for ads and annoying stuff like flash screens and such.

Are you saying that web standards are not controlled by a single company? That is not how I interpret the behavior of the relevant standards bodies of the past decade.

More importantly: Flash was closed source.

It was also a massive vector for security vulnerabilities.

You're bemoaning that the lack of use of DOM to render the UI???? Seriously? That ship has sailed when Canvas was introduced in the mid-2000s and it was introduced for the EXACT reason to provide the same kind of capabilities that people had with Flash.

People wanted and want to build rich web-based APPLICATIONS - not just websites with columns of text. That's why Flash became huge, and that's why HTML now has Canvas, Video, WebGL, WebAssembly, WebRTC (all of which were available in Flash - sometimes years before they were available in HTML).

The specific example you showed, nyTimes puzzle game, you'd never build that on-top of DOM (you could, but why would you?). You'd use JS to draw your UI with the Canvas 2D APIs. So I don't know what you're talking about.

>There's a reason why flash died out, and it's not only apple. It was dropped for making interactive website long before apple killed it - it doesn't work well with the web

NO!!! That's not why Flash died out. Flash died out because you had a standards-based alternative. Steve Jobs probably accelerated the transition a little bit, but it was inevitable.


Flashed died out way before canvas. No one but design shops made their websites with it. It remained strong in games and ads and disappeared everywhere else. That is why apple could even survive not supporting it.

>Flashed died out way before canvas.

No. Canvas was introduced in 2004 but not really mainstreamed until a few years later. I would put the golden age of Flash as 2000-2008, with a slow decline after.

>It remained strong in games and ads and disappeared everywhere else.

You're just saying things, but you inadvertently hit on the point that I'm making, that is the decline of Flash coincided with HTML/JS being given capabilities to actually replace Flash. Had that never happened, you'd still have Flash because there would be things that people would want to do over the web, and no other way to do it.


There's almost certainly no middle ground between "use the DOM for everything" and "deploy any possible app on the web". As soon as we decided the web was more than just documents, this was inevitable. Smearing tech that's advancing this pretty obvious idea as "Flash" isn't super useful, and rings hollow when applied to Google tech but not Emscripten, WebAssembly, Canvas/WebGL, or other tech that is just transpiled to JavaScript and can only possibly use web APIs.

If this bothers you, your argument is with Web 2.0, not Google.


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.


Which is going to be hard. Xamarin these days is really nice to work with.

Perhaps, but for whatever reason React Native seems to still dwarf it. Maybe the companies that tend to churn out popular mobile apps just don’t invest in .NET?

React-Native has two significant pros that Flutter doesn't have.

Native UI. I heard multiple times now that Flutter drains the battery rather quickly because it doesn't use the highly optimized native UI elements.

JavaScript. There are more JavaScript developers out there than .NET ones. Also, the JS devs are much cheaper.

Another interesting pro is, you can use RN to develop basically everywhere. Expo (a RN framework) announced Web support, so you get Android, iOS, and Web out of the box. Microsoft announced UWP support and rewrote react-native-windows.


Well, it might be burned soil. Even in tech companies it's hard to convince the "decision-makers" to have another look at a technology that failed some years ago.

Also, you need some experienced people to look at new technology.


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).


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).


> But, looking at the iOS implementation, it seems that it severely affects performance.

How did you come to that conclusion? They use the same Webview classes that RN wraps.


Wow. I figured you were exaggerating, but this is dead on. Safari has a native two-fingered-swipe for going back a page, even that's broken here.

I can't believe we gotta do this Flash and Silverlight fight all over again. Google should know better.


> You can't do anything in it that fills like the web

Why "can't"? In this example they were making a game not a web, and they wanted it to feel like a game. The texts you see there are ultimately a plain old HTML p tag with selection and mouse interaction overridden, but I'd be surprised if you can't change those behaviours.


yes. And additionally it uses a new Dart language, requiring re-training JS programmers, unusual and less readable noodle-like code, slow single-core compilation and not as much 3rd-party libs and plugins as they are for JS and Cordova, React Native and NativeScript. I liked it at first, but I have doubts it will ever be wide-spread and highly-adopted. At first I hoped it could make Android app development better, getting rid of Java tooling nightmares but it is also bad in its own ways. So many years passed and Android dev experience haven't improved much. And Flutter is considered main Fuchsia UI language. :( I miss xcode and Cocoa...

One of the major factors that finally killed flash was the security liability. Presumably Flutter won't have that problem.

I'm actually scared of this fact. Flutter could very well be how Google finally kills the open web, if it succeeds.


> There's a reason why flash died out

A never-ending parade of actively-exploited security bugs?


This is plain javascript.

  <link rel="preload" href="/games/prototype/kenken/main.dart.js" as="script">

dart transpiles to js. that's how it's delivered on the web. Nothing surprising there.

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.

Not sure why you are downvoted, you are right.

The initial loading time was there, but then execution was pretty fast.

With the amazingly optimized JS engines we have now, it's easy to forget how slow things were just 10-15 years ago. (I think Chrome really kicked of the competition there)


Saying anything remotely positive about Flash is an auto-downvote on HN, even if factually accurate.

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!

> Which bit was fast?

The performance. The comparison macspoofing made was with JavaScript+DOM, not with native applications. I wrote games in Flash and played around with JavaScript+Canvas back when HTML5 was still fresh and Flash was still king.

The difference in performance was huge and Flash was faster for years. You'd hear people saying that JavaScript+Canvas was a valid replacement, sure, but those people had absolutely zero idea what they were talking about (especially when they said such stuff when there wasn't even a cross platform working sound API).

Things changed over the last years, sure. But do not rewrite history, JavaScript+Canvas sucked for a long time compared to Flash (and in some areas, like distribution, still sucks - a single compressed SWF file with all your resources is still nicer for distributing games than a bunch of HTML and whatever else files).

FWIW i always maintained that Java was miles ahead any of the above when it came to games (especially about performance), but Sun killed applets brutally with its awful startup times and bloated VMs. Then Oracle came along and just abandoned the whole thing.


All good points. But I'm still struggling with the idea of using the word "fast" to describe a technology that brought a 2GHz GPU-accelerated machine to its knees with Scrabble. Perhaps "sucked less than JavaScript"?

Both you and the person you responded to (Crinus) are right. I’ll share some context.

On Windows, Flash was fast but on OS X (as it was called then), Flash performance was atrocious. In fact, this was one of the major reasons why Steve Jobs felt compelled to pen his famous “Flash” article [0], because after getting Apple’s engineers to work directly with Adobe’s engineers, they couldn’t quite get Flash to be performant on the Apple desktop. Jobs added that the single biggest culprit of stability issues reported by customers on Macs was: Flash [0]. I remember this part vividly because my MacBook had never crashed on me until I had Flash in use during a browsing session. The other time this happened was from another Adobe product: Adobe AIR, which I believe uses the Flash engine internally.

Apple worked directly with Adobe because investing the engineering resources needed to make Flash performant and stable didn’t make economic sense for them, but even after this, they couldn’t get it to be stable as desired. Job’s thinking was if you cannot do this on desktops, how on earth will you manage on a resource-constrained device like the iPhone?

[0] https://www.apple.com/hotnews/thoughts-on-flash/


FWIW i did almost all of my Flash development on OS X. It is kind of amusing to read that it was even faster on Windows (although TBH i do not remember any significant performance difference in the games i did between Windows, Linux and OS X - then again all i did was blit bitmaps and largely avoided the vector stuff).

>Which bit was fast?

Code execution and 2D rendering. What else could I mean?

But there's more. You know how people are excited to see native applications running in the browser? Flash did it in 2008[1].

You think you could run Quake2 with 2008-era JS engines?

You think you could run all those 2D games in 2002-era JS engines (even if had access to a Canvas element - which you didn't)?

>My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble.

Care to guess why it was a flash-based game and not an HTML5 based game?

[1] https://www.youtube.com/watch?v=vH4p8wzqtuA


I was not comparing Flash to the JavaScript of the era, just pointing out that, as an end user, Flash didn't seem "fast" to me (on Linux, Android and OSX). Performance on a desktop-class CPU is also only one metric. Flash was clearly inefficient, it didn't use multicore, GPUs or hardware decoders. Was your Quake2 demo above using even OpenGL? Java applets could do that since well before 2008. The original Quake2 could do that in 1997.

> Care to guess why it was a flash-based game and not an HTML5 based game?

Anything would have been better, even bare HTML tables with no animations. The user experience of Facebook Flash Scrabble was awful (at least on OSX).


>I was not comparing Flash to the JavaScript of the era

But that's the entire point!!! People didn't use Flash because they felt like it. People used Flash because there were things you could do with Flash that you could not do with HTML/JS. Remember there was a time that Flash was the best way to do video.

>Flash didn't seem "fast" to me (on Linux, Android and OSX).

Let's leave subjectivity out of it. If you ran a standard benchmarks and compare to JavaScript of the day, Flash would beat it. That's what I meant by fast.

Here's some metrics for a FlasCC compiled AS3 compared to C++: https://docs.google.com/spreadsheets/d/1PjMDwh4ZbJMMoo-G8vdK...

>Flash was clearly inefficient, it didn't use multicore

Neither does JavaScript (without WebWorkers). Neither does Node.js. Then again, Flash did get Worker support around 2012. And though your code was executed in a single thread, the actual rendering was delegated to the runtime, which was multi-threaded or backed by GPU.

>GPUs or hardware decoders

It sure did. Stage3D (think WebGL equivalent) was introduced in 2011. Video decoding delegated to hardware decoders since forever. Alchemy/FlaCC (WebAssembly equivalent) was released around 2009/2010. In many ways Flash was the vanguard of where HTML5 ended up going.

>The user experience of Facebook Flash Scrabble was awful (at least on OSX).

To be fair, Flash never ran well on OSX. It wasn't bad, but it wasn't as good as on Windows.

>Java applets could do that since well before 2008.

Java applets were an alternative to Flash, but Flash was lighter and had much broader support. It was better for video, better for vector graphics and 2D animations. But yes, Java applets were used to gain functionality that wasn't available in the web just like Flash.


and unusable on firefox (on my up-to-date pixel c) with it being a bit better on chrome... ipad pro though, actually not too bad in safari (though it makes me wonder about how much of a hit in battery it would cause)

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 a reactive programming model similar to React Native and Vue.js.

This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ? Remember I'm talking about developing nations like India - where startups like ours invest in training college graduates . These guys can't afford 10$ courses on udacity and Coursera.

But even if it was not India, having this parallel signalling for Android based startups is very confusing. Atleast Apple was very clear about Swift .

Where will Android be in 2 years : Dart or Kotlin ?


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 anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust.


> Internal politic wars at Google

If you allow internal politics in technical decisions, the old is drowning the new child that is tasked with killing the old every time.

This is what really killed Nokia's platform domination in mobile phones. Google should take a note.

Nokia had dominating smartphone platform (Symbian) and market dominance in mobile phones. It was becoming old, messy and outdated but still doing fine at the moment. Instead of choosing and committing they allowed innovation but allowed the most critical decision for the company to be the question of internal politics. Linux/Qt based new system was sabotaged from inside buy people whose careers were based on the old Symbian. Of course the VP who overseeing overseeing billions in revenue is looked differently than VP that is tinkering with the new platform with bunch of young Linux hackers.

Netflix is perfect example of how to execute technological transition correctly. They made the decision to move from DVD rental to steaming when disc rental was still making money and there was time. They committed to it. People working in the money making disc rental side were shut down completely from the discussions where the company future was planned and made.

Google has so much market dominance that it can make these attempts and never commit, but it also guarantees that they will never succeed. Developers outside the company know that everything is just 'another try out' and it's not worth of getting into it.


>People working in the money making disc rental side were shut down completely from the discussions where the company future was planned and made.

This is brilliant. I continued to be surprised at how well Netflix executed everything so well. Are there any counter example they didn't do so well?


Weren't Symbian and MeeGo both sabotaged by Stephen Elop who came in briefly from Microsoft to assume the role of CEO of Nokia, decided to burn everything they had to instead buy Microsoft's solution, and then returned to Microsoft when the job was done?

> 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.

I don't think scenic is written in Rust. A big chunk of the source code in the topaz layer (the view layer) is still written in dart. With that said, many were actually surprised when it was revealed that ermine (the new fuchsia shell) was written in dart/Flutter [1] since earlier code for it was in Rust [2]. Guess that didn't pan out.

[1] https://fuchsia.googlesource.com/topaz/+/refs/heads/master/s...

[2] https://fuchsia-review.googlesource.com/c/topaz/+/184430


Who said anything about Scenic being written in Rust?

For embedded devices the only good toolkit is Qt and the licensing costs are pretty high. Flutter for embedded is interesting in this regard.

Gluon, PTC and Aicas also license JavaFX.

Qt licensing costs are quite standard to market prices of similar products.

Also if one doesn't want to pay for Qt, it is free to do themselves the same they want to do with upstream developers.


Your last sentence is a bit hard to comprehend but not paying for Qt and shipping a commercial embedded product is pretty difficult due to the anti-tivoization clauses of GPL3.

I agree with parent poster that flutter is very interesting for Embedded GUI development.


Qt has LGPL3 license Not GPL3.

It's really easy to ship commercial Qt app with LGPL3 (except few modules that are GPL3) You just provide sources or linkable object files.

Qt intentionally avoids explaining how to do this because they are selling commercial licenses. If you are in software business and can't figure this out, maybe you should consult someone.

(disclosure: I own commercial Qt license and stock in the company)


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 source software can be statically linked to LGPL binaries (to fix another common misconception).

What is needed from you is a way for the customers to get things separately. It can be written offer, link to files in the website (used to be directory in DVD). You can be almost 100% certain that your customers will never use or notice this option. It's just there to comply with the license.


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?


I think I'm clearly stating my assumptions. GPL3 and LGPL3 requires you to enable the user to replace the GPL/LGPL3 code on your device with the users own version of said code. It does not matter if you link statically.

Now, it would be possible let the user do this and not let it be a problem for your product (in terms of security, reverse engineering, ip theft, etc) but it is more and harder work.

I have used both older version of Qt (LGPL2) without licensing and newer (LGPL3) with licensing in commercial products. The former was not a problem. But using LGPL3 Qt without licensing in a commercial embedded product is a headache (if you are concerned about the problems it might bring), according to me.

Hence, I wish Flutter all the best.


Notice the exception:

> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

- If you ship embedded product where the code is not supposed to be easily upgraded, you don't have to provide means to do that. Anti-Tivoization applies to cases like TiVo where they added DRM to prevent users from upgrading but allowing you to upgrade.

- Also, anti-Tivziation clauses don't apply software distributed to business. Medical devices or safety critical software etc. Any devices sold to business.


I am yet to see a embedded system using Qt that is not upgradeable.

And lots of embedded systems are sold to consumers.

In what way was I "completely wrong"? It seems to me you were the one who was wrong and now are grasping at straws...


> If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.

How do you do that, while said software depends on LGPL3 licensed Qt?


from GPL v3

> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

Also, anti-tivoizaton clauses does not apply to devices sold to business.


Good point, forgot about the latter part, that probably would help in some cases. Gotta ask some licensing experts about that one.

From what I see, only a tiny part of the potential market for embedded Qt and things like that can get away with "no updates possible", but still, applies for some.


JavaFX is fully open source, it doesn't need licensing. It also supports hardware acceleration, embedded usage on Linux, animation framework etc. Also, fits well with kotlin.

Please link me to an image for RPi or BBB that has working HW accelerated JavaFX. I'm not being sarcastic, I'd actually like to know.

Good luck getting JavaFX working out of the box in the embedded hardware supported by those vendors with the code at the open source repository.

Who do you think does the porting and OEM certification work?


Flutter is very similar to Qt: signals and slots are similar to streams and sinks, and the BLoC pattern is similar to the state machine paradigm in Qt. I've been loving Flutter and Dart, developing with it seems almost too easy.

With the big difference that JavaScript and C++ are CV worthy languages, while Dart is fighting for its survival.

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 Pascal with Delphi or Lazarus, but no one chooses those frameworks for some reason.


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

part of the reason for that is that a bunch of companies are paying TQTC for their tech stack not being known. But if you are looking for high-profile stuff using Qt, how about :

- the Tesla UI (https://twitter.com/qtproject/status/998902009922285568?lang...)

- and a lot of the modern in-vehicule infotainment stack actually

- LG screens (https://www.qt.io/lg-electronics-built-with-qt)

- Allegorithmic Substance stuff (https://blog.kitware.com/from-one-software-to-many-at-allego...)

- The Blizzard launcher (https://www.quora.com/What-front-end-and-back-end-technologi...)

- Amazon Lumberyard (and its grandfather CryEngine) : https://github.com/aws/lumberyard

- Microsoft Onedrive

- AMD Radeon panel (https://www.qt.io/amd-built-with-qt)

etc etc..

but generally speaking, it is not in the DNA of Qt-using companies to post nice articles on reddit / HN which has the pernicious effect of reducing its place in the dev mind marketshare and making it harder to hire...


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

Sure, but are they running on smartphones?

> 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 ;)


Can you explain what you mean about React Native? If I understand, you're saying more companies have tried and then abandoned React Native than Xamarin? Can you provide evidence of this please?

Sure. The major apps that were previously using React Native are AirBnB and Udacity, who are fairly prominent as far as startups go. As far as companies currently using the framework, they are respectably impressive:

https://facebook.github.io/react-native/showcase.html

I haven’t heard of anyone similar using Xamarin, not even Microsoft-related ventures. Maybe because they’re mostly not in the U.S.?

https://www.altexsoft.com/blog/mobile/13-apps-made-with-xama...


Lack of ecosystem. You'll find yourself having to write ports/bindings/however these are called on your own.

That's somewhat disingenuous. When Apple added bluebox to Rhapsody were they not so focused on AppKit any longer?

Holy hell, this makes me want to never work for google.

If you want to do android development, Kotlin.

If you want to do multi platform development, flutter.

I think flutter will be an amazing tool for smaller teams, especially in non-tech-primary organisations. I work in the public sector of Denmark, we do in-house development, our main focus is the public services we provide though. So there is just no way we can do mobile, desktop and web without something like Flutter, or severely increased funding. The latter won’t happen, but flutter might.


I have to correct you.

If you want to do android development, Kotlin

If you want to do multi platform development, Kotlin multi platform

Kotlin mpp is still in beta but it works pretty amazing. I have 1 app in production that shares models/API/database. The UI on Android and iOS is native and platform specific. I highly recommend it.


Not naysaying you but i learnt kotlin and flutter this past year(from january). flutter has an AMAZING experience for the things that are "done", kotlin multi platform only does one thing well - kotlin.

it's basically like xamarin with C# swapped out with kotlin(and that sucks as much as kotlin mp does right now even after 3 years of ms acquisition time).


The development experience with flutter is great, that's right. But I don't like the end result. It feels very close to a native app but still not 100%. And I think it will always be a step behind.

One benefit of kotlin mpp compared to xmarine is, that kotlin mpp is not limited to iOS/Android. You can have a shared code base between web frontend/Backend/iOS/android and even macos/windows/linux and all native. One language to rule them all.


Flutter is on its way there, too. Already native on iOS, Android, and Fuchsia, with the web build in technical preview and desktop OSes under development.

You should check all platforms where you can run C#. It runs everywhere.

I didn't think that through, you are actually right. With project Blazor I guess also in the browser.

I use C# almost on a daily base in Unity3D and have a little experience in Xamarine but I have no idea how a android/iOS/desktop/web project would be build up. Would be interesting to compare it with kotlin mpp.

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.


Flutter gives you native code but not native UI. It reimplements and draws everything itself (mimicking the native look), like Swing or Qt.

React Native is the other way around - real native widgets backed by interpreted/jitted JavaScript code.


When React Native's fabric rearchitecture is available you will see much better performance. The thing that hurts performance today is that damn bridge communication between javascript and native that will be severely improved in fabric.

As I understand it, Flutter/Dart is compiled to native code but not using any of the native UI widgets.

To get native code plus native UI widgets plus some cross platform reuse you'd have to go with something like Xamarin.


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.


Unless you're importing a ridiculous amount of packages and assets, you'd never hit 100MB with simple apps, that's just people looking at debug mode and thinking that it's the final app size. Simple apps can easily be under 8MB once compiled.

Not really true, you are likely comparing a debug build. An Android Flutter apk sits around 4MB for smallest app. Most of my apk sizes are around 8MB-10MB w/ Flutter

I haven't written any myself, going from reports online that builds are a lot larger than expected. That minimum size is for an app without any components or other modules. The RN app I mentioned was ~6MB with a fully blown app, state management, heavy data layer, hundreds of components, animation, i18n, a handful of native modules, encryption, and so on.

In short, Flutter doesn't really have any advantage in size over RN.


React Native has a JavaScript layer that hurts performance and it is not truly native as they say. Just do a reach on flutter vs react native and you'll see better explanations and comparisons.

I’m not sure this really matters for a lot of things anymore. Sorting a few hundred text items in a list, for example, is going to be so fast on modern smartphones that it will not make much of a difference whether it’s done in JavaScript or native.

Maybe a poor example, but I suspect the only times it really makes a difference is significantly computationally expensive tasks


so? most apps are by nature going to be computationally expensive if they want to compete/successfully use all phone features. i made a simple(according to them) corporate data sync app recently and the company wanted a laundry list of features - background sync, smooth scrolling of extremely large datasets, photographic analysis of images taken at tolls(extracting license plate information/classifying vehicles automatically for tracking).

All of this had to be made in a performant way so as to run on phones with 1 gig of ram as the company was giving phones to everyone specifically for just this purpose(and general communication ofc).However it also needed to work on iphones/windows phones(old ones the execs purchased en masse)

Xamarin was the only choice att as react just doesn't work stably on windows phones but i'm excited to see the future


Your app sounds like it used some advanced features, but I don’t think most apps are going to be computationally expensive in the way that local-AI, image processing, or crypto activities might be. I am not sure what qualifies as extremely large datasets, but I’d be surprised if keeping a few dozen objects in order is significantly lower in JS than Swift. Yes, it may be an order of magnitude slower - or ten orders - but that seems negligible if the total time for processing is still nanoseconds. Guess it always comes down to the task at hand.

When I made the decision in December:

Preference for Dart over JS (lots of reasons, involving language, package manager, compiled performance)

Predictable UI behaviour across devices, OS versions, platforms. As long as you handle presence/absence of device features, and build your UI to scale properly, it behaves as you would expect, everywhere. The value of this cannot be overstated enough.

Future opportunity for code sharing with non mobile platforms. Even without Flutter-web, I could still compile the business logic part of my code to JS and use it with another UI (similar things can be done with React).


I don't think anyone has a definite answer, not even Google itself. Google placed several bets on different technologies and community will ultimately decide which of them is the winning one. Personally I think native Android (Kotlin) and iOS (Swift) development is here to stay. I have tried many cross-platform frameworks and on any non-trivial mobile app, all of them cause more problem than they solve.

> all of them cause more problem than they solve

I know what you mean. But have you tried flutter? Try it and you might change your opinion just like me.


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...

They're changing their stance on that gradually, just recently they started tracking their options for natively implementing multithreading in the background using dart(the current advice is to use platform specific plugins which isn't robust for services that run without a visible app). You're also wrong about xamarin- you do have direct access to android sdks(if you know enough C# to correctly translate the API usage into Xamarin android - which is a bit of a headache admittedly)

i really like the flutter dev community btw, very agile and open to newer ideas for plugins. havent seen this in react(fb controls all and devs usually just talk about js patterns all the time) or xamarin(community is nonexistent at this point, even questions barely get answered unless you post an interesting one on the gitter monitored by core xamarin devs)


That's mostly my opinion as well... Your better off with a mostly portable web based codebase, or dedicated or hybrid apps. Say what you will of Facebook, their ux approach with react send the most pragmatic.

You can't avoid learning Kotlin & Java, that's the native language for Android platform. Even if you use Flutter, leaky abstraction mean you will probably have to dig down to the native layer as your apps get more complicated.

That’s right. I’m a professional plugin developer. I’ve got my hands in both worlds, making dart APIs into the Obj-c/Java bridge where I’m implementing native APIs.

And several universes as well...I do plugins for React Native and Cordova, as well: same thing but JavaScript APIs into the Obj-c/Java bridge.


>This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ?

Oh come on. Pick one. That's what you do for every other platform. Hell, even for web development, you'll have to make framework and transpilation decisions. This is no different.

>These guys can't afford 10$ courses on udacity and Coursera.

Yeah, too bad there are no free ways to learn programming languages on the internet.

But there is something arrogant about stating that programmers in developing nations somehow aren't capable of reasoning about tool choices for Android development.


Yeah, get out of business if you can't afford to send your offshored $5/hour indian developers to a 1-time $10 course to learn a new paradigm... Not sure I'm for flutter, react native, or some other (shopping around now for a good cross platform solution, quasar + cordova might be enough for my needs as I prefer vue), but these people need not be in business if they have no money to run their business properly. They'll just get shitty code that someonee else will eventually have to rewrite.

There's a chance that in the future, Android will just be a legacy environment within Fuchsia. Fuchsia's main UI framework will be Flutter.

or maybe something in Rust (Scenic).

Probably inevitable

edit : I am not a Googler, but that's what I gathered from talking with them

Here is what is happening :

A couple of years ago, when the dart team failed at getting their runtime embedded into the browsers, they started searching for a problem to solve. They thought they had hit jackpot with multiplatform development. So they started working on Flutter. This is all entirely independent from the Android team at Google.

The Android Team at Google continuously improves their own framework, hence the jetpack set of libraries. One of the new libraries they have been working on and that is now public in pre-alpha stage is JetPack Compose. They have hired one of the engineers behind React and had them work inside of the Android Team on a "React like UI framework for Android".

The official direction of the platform is what the Android Team is doing.

Flutter is interesting, with all the advantages and caveats shared with other multiplatform tools like ReactNative.


(I'm the Flutter TL.)

As far as the bit about Flutter goes: Flutter was started by engineers from the Chrome team, and myself (who worked in the open source team as editor of the HTML standard). We had no relationship with the Dart team at all until some times into the project, when we were looking around for a language to replace JavaScript in our project (codenamed Sky at the time). We considered a large number of languages but ended up picking Dart because it was the best fit (see the Flutter FAQ for more details). We then had to learn Dart and made friends with the Dart team, with whom we now work very closely.


What other Javascript replacements did you consider?

Languages I recall us considering include: Java, Kotlin, Swift, C++, Dart, Lisp, Lua, ObjectPascal, Python, C#, Go, Rust, TypeScript, JavaScript itself, Perl.

I wish I had our notes from back then, but I looked for them recently and couldn't find them. Our best theory is we did it on paper or on a whiteboard. :-(


What is a TL?

Team Lead, I'd assume.

Team Lead

Team lead

>A couple of years ago, when the dart team failed at getting their runtime embedded into the browsers, they started searching for a problem to solve.

I thought that flutter was started outside of Google.


Not to mention all the weight put behind Progressive Web Apps, including being in the Google play store, and has most of the features as native android... https://developers.google.com/web/progressive-web-apps/

How cross platform can this be? What's the fallback plan if you need some API that's unavailable? Simply having a lightweight native wrapper around the webview allows a lot of oomph.

Invest in Kotlin. Kotlin is useful for Android NOW. Whenever Dart starts becoming more mainstream, you'll know and have enough time to react to it.

Invest in Kotlin. It's been created by Jetbrain and they are showing clear support for it. I can't say the same about Dart. Google won't support Dart, GWT, Angular, Polymer ... eternally. Yes different purpose, tech and ambitions but too much overlapping. In case of a "more wood behind a fewer arrows" situation, you'll have to pray that the Google gods didn't choose to sunset the stack you bet on.

I don't mean to be cynical, but the answer may be 'whichever language wins'.

Maybe Google wants to support Dart because its built in-house, while simultaneously supporting Kotlin because it is so well loved by developers. Just a guess.


No. Mobile Dev is not anything close to web dev : developers don't have control of run time devices.

Google is now mandating 64 bit APK for its apps (after years and years of trying) - that's a end device support issue. React native has had 64 bit problems for years.

Viewmodel is a lifecycle aware component. Android Q will come with foldable-aware SDK. Will that be supported both on Dart & AndroidX/Kotlin ?

Someone has to explain to Google management that an ecosystem that has gazillion different devices , that are not in developer control is a far different beast than web dev .

Microsoft understands this better than anyone else. Look at their bug-compatibility spanning 30 years.

We cannot afford a fight-to-the-finish when my customers are on a gazillion different devices with different hardware. NBU markets like India operate at a very different level of complexity than the two-device markets of North America.


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 AndroidX are not even the same paradigm - the lifecycle management is completely different. Android development forces you to think in terms of Activities and Fragments since they are a lifecycle model. Flutter changes it entirely.

I'm pretty sure I can learn it fast, but the issue im asking is about investment. If you are running a company with 100 android devs, where will you invest your training and future architecture research. Or do you believe that the code of an app that's being used by a couple of million users for financial transactions can be ported to a new framework in a jiffy ? Just the testing and validation impact is huge.

The issue is that we are just coming out of a Java -> Kotlin transition that required significant investment on our part. Because of Google making their stand very clear that Kotlin was the future. So now, this is very confusing.


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)

And you think that anybody can answer that from Google? There are different factions in every company, they are fighting over things constantly. This is why Google has many similar products.

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.


> 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


Aside: Would love to see electron and Cordova bridge the gap together for mobile targets. If they can establish a few common interop libraries, you could come very close to the same code for both.

I'm really uncertain about a huge JavaScript runtime on mobile -- seems like an energy waste/slow code. Dart's AOT story the Cupertino wrappers for iOS in Flutter really excite me.

Disclaimer: I work for Google; all opinions are my own.


The runtimes is already there. Not to mention there's still room for improvement.

I'm not against other options being available. But there's a certain amount of pragmatism to being able to use the same skills, developers and code to approach development that targets several disparate platforms in a very open way.

My favorite language is JavaScript for all the flexibility. My second and third are Rust and C#. Just getting my feet wet with rust and have done C# from the beginning. They all have very different reasons to exist and most applications can be written with any of them.

In the end of the people paying for the development cannot fund a given approach, there's a certain pragmatism that must and should take priority.

With JS I can use functional, classical, and procedural approaches and mix them as needed. There are foot guns. They are there in every language.

As to overhead and battery, I can see the point. If rather have an app with more overhead, than no app at all. I use Windows, Linux and Mac and tend to favor apps that work everywhere. If like to see that extended to phones.


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.


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

Qt works on mobile, too.


I asked this exact question at the Android Dev summit this last year, and was laughed at

https://youtu.be/FV3iN4PIB5U?t=902


Hey. Clicked the link. Watched the video. It appears, that you were not laughed at.

By Googlers? No, but by the audience around me, yes

Flutter != Android

Android will be Kotlin

Flutter will be Dart.


I'd say Flutter/Dart.

And what do you think those plugins implementing the native sensors or CLLocationManager / FusedLocationProviderClient is written with? Obj-c/Swift and Java/Kotlin.

Dart

Has Flutter solved its footprint-bloat problem?

The internet is littered with reports of 10-100MB+ .ipa and .apk binaries coming out of simple Flutter apps for iOS + Android. Google states they can't imagine the footprint ever dropping as low as 1MB. [1]

On Web, 1MB of base runtime is a complete showstopper. Embedded applications may suffer similarly.

Does today's announcement mean Google has figured out how to fix this for Web, or are just ignoring it? Or worse — are they planning to 'boil the frog' with a sneaky transition into a world of a New Flash Player?

> 1MB of Flutter runtime got you down? Don't worry, Flutter Player now ships with Chrome.

This is possibly a very dark direction for the Web, of which Google is a powerful steward.

[1] https://github.com/flutter/flutter/issues/12456#issuecomment...


I tested it, and the "Hello, World" example results in a 560k js package.

Uglified and minified takes it down to around 480k.

Gzip takes that to 140k and Brotli compression to 100k.

That's a lot to bootstrap an app with, but it's not unreasonable, considering what most frameworks these days will start you with.


it's not just what goes over the wire. that's 560k of JS that has to be parsed and compiled, which is a shitload.

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 :).


I’ve worked professionally on pre-parsing and 30% is not a great result.

And it doesn’t help the time spent on compiling, so it’s saved not a lot of not a lot. Doesn’t really solve the problem.


True, but (unfortunately) it's hardly an outlier in today's ecosystem.

Try importing `flutter/animation` — footprint goes WAY off the deep end. `animation.ddc.js` is 4.4MB alone (unminified), never mind the rest of the runtime AND userland application code.

You can see this in the flutter_web/examples/gallery example. [`webdev build` failed for me in examples/gallery, so I'd love to see what a successfully minified version of that example looks like — I'm currently deeply skeptical.]

Compared to React/Vue/Angular and friends, this appears to be a monstrous outlier.


DDC stands for Dart Development Compiler. It is a fast modular compiler that you use for quick edit&refresh development in the browser. It does not do any global optimizations, unlike dart2js - which is what you use for deployment.

If you write something like:

    import 'package:flutter_web/animations.dart';

    void main() => print('Hello, World!');
DDC would faithfully compile animations.dart as whole and ship that to your browser.

dart2js would include 0 bytes of code from animations.dart into the output.

> `webdev build` failed for me in examples/gallery

Maybe file a bug?

Here is what I get for Gallery:

    ╭─~/s/f/f/e/gallery ⟨master ⟩ ⟨9s449ms⟩
    ╰─» flutter packages pub global run webdev build
    ...
    Compiled 18,344,245 characters Dart to 1,914,077 characters JavaScript in 27.9 seconds
If I gzip the output I get around 500k.

Gallery uses a lot of Flutter so this is in some sense upper boundary for framework overhead.

Also it is still early days - I can clearly see this pushed down.


DDC is not at all a representation of the final size of the code, as it doesn't run any kind of tree shaking, minification or optimization, and the animation library has a lot of things that you will definitely not import.

And here I am freaking about an uncompressed js payload of 300k for an entire app... 4+MB just feels crazy.

Yes, but it’s more or less in line with current single page apps. In fact, quite possibly a bit smaller.

not sure how many "Hello, World" SPAs would add up to that.

The point is, real world apps have a bit more complexity than "hello, world", and the runtime cost doesn't matter as much as the app grows in size.

I'd add that the connotation of an angulardart app isn't a simple SPA. It's meant for larger applications. I have been using it for the past year and a half and really enjoy it. The compiling times have been improving with each release.

I think the "fix" is not to accept the state of play but to challenge it.

Sounds the platform needs some tree shaking.

The sizes closer to 100MB seem to be from debug builds. From the bug you linked (and this one which it links to: https://github.com/flutter/flutter/issues/16833), bare flutter apps are around 4MB on Android.

Doesn't seem bad to me.


(I'm the Flutter TL.)

According to today's benchmark numbers, we're at 4414KB on Android and 8572KB on iOS (IIRC, iOS encrypts before compressing so it can't get as good a compression).

This is for our Hello World test app (https://github.com/flutter/flutter/blob/master/examples/hell...), which is more or less the smallest app you can imagine building with Flutter unless you bypass the entire framework and only use the engine directly.


Fellow Googler here. I think it’s best to report those numbers with the appropriate SI prefix: 4.414 MB and 8.572 MB. Reporting numbers as “X thousand kilobytes” makes it harder to grok the real scale.

Pardon me making a joke at your expense cornstalks, but...

Is this what a culture that AB tests 34 shades of blue looks like?

I think we can handle the conversion here in the HN comment section!


fwiw, when i saw the prefix and no commas i subconsciously assumed it was under 1000KB and read it wrong, until that comment made me take another look.

Ha, at first I thought "cornstalks" was a new slang reference for Googlers and was just over my head.

Well if it wasn’t, it certainly is now. Thanks for that typeformer.

Also please be aware not all locals use "." as thousands separator. About half of the world [0], including we here in Germany, actually uses the dot as decimal separator. Thus your number "4.414 MB" actually looks confusingly close like ~4.41 GB to me on first sight. An easy way to avoid this is to not rounding to three digits after your only dot or comma.

[0] https://en.wikipedia.org/wiki/Decimal_separator#Arabic_numer...


Sorry, I just copied and pasted the number as it appears on our benchmark page. :-)

Hmm, encrypting before compressing seems like a pretty strange decision. How does that happen?

I believe the literature says that compress before encrypt is less secure, because compression behaves predictably. See CRIME attacks.

But, why compress at all then? It won't do anything.

I'm not sure this is a good enough reason to never compress anything.


Maybe they encrypt with rot13. Compression should work on such a "ciphertext"...

To clarify to anyone else who may have been confused as I was: the "quoted" text in the parent post is not an actual announcement from the source URL or anywhere else, but a hypothetical future situation.

Almost gave me a heart attack.


> This is possibly a very dark direction for the Web

Yes, that imagined dark direction for the web is indeed very dark.

Call it too big to ship reasonably, but Chrome didn't ship an Angular player or Polymer player, so I don't see what suggests they'd start now.


Didn't they ship a Dart VM?


'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 rows" then you will see both compressed and uncompressed size.


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


That's a very large payload difference indeed!

See other comments, they're actually the same file. The heading names in developer tools are just slightly different.

to be fair even angular has sizing problems. a "simple" app can easily grow to over 200kb gzipped content (including polyfills). and 200kb is a lot for a simple application.

currently our "big" application already grown to over 600kb gzipped js. I'm pretty sure flutter has the same problem. I think as soon as people start using a SPA their js size will skyrocket.


I don’t understand the obsession with small binaries and compiled packages. I care about usability and user experience. If it takes 5mb to have a smooth experience then I’m all for it.

It’s funny how we now have fiber having 1GB/s internet speeds and we rant about having 1MB size package being too big. Also, everyone’s moving to 4k now with even bigger transfer/data requirements.

tldr; 1mb should be a non issue as long as experience improves.


> 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 what I can tell.


Also please consider how many seconds will it take for a cheap Android phone to parse 5 Mb of JS (and how much memory it would take after parsing, which can be up to 10 times more that original code size). I think it can become much more than 8 seconds, and during parsing the browser will likely become unresponsive.

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.

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

India. Next billion users.

Size matters a lot.


It's not just the transfer... It's the compile, load and perceived speed. 1mb compressed and gzipped can be a hundred MB parsed and in memory. Which isn't bad on a modern mid level desktop, but it's crazy on a lower end smart phone.

There are also other factors to consider. I'm not huge in premature optimization, but damn.


I think there’s a middleground there that if you want to support these countries then there should be a framework for this (Flutter Lite?).. But if you want the complete feature set that is “bloated” but has good ux/ui support then that should be fine as well.

"these countries"? I've seen schools in the US with 15 mb/s My mothers, Xfinity, has a low tier, 25mb/s.

A lot of Australia is still stuck on ADSL with speeds of 5 - 20Mb if your lucky

(I'm the Flutter TL)

Our current plan is to support the complete feature set while still supporting places with connectivity around 5Mbit/s. We are still in very early stages (we only just put out the tech preview today!) but we have some confidence that this is possible. Personally I'm more worried about the performance of layout animations (e.g. resizing paragraphs) than about download size, but again, it's early days still.


I don't think it's the actual file sizes that people object to so much as all the redundancy and inefficiency that the bloat is indicative of. That is, for every increase in CPU, storage, and bandwidth; app developers insist on throwing it away with another layer of frameworks and intermediary libraries.

What Moore's Law giveth, React/Flutter taketh away...


There are smaller/faster ready like libraries such as preact and inferno btw. React does offer a lot of advantages though mostly for diagnostic purposes for developers.

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 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.


No offense, but you sound like Verizon charging Netflix for what users are pulling down.

Not to mention your data plan

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

Not everyone is so fortunate to have 1GB/s internet.

Waiting for a page to load is a terrible user experience.


Outside of a select few cities, getting anything more than 100 mbps down is literally impossible unless you have the budget to pay a company to run fiber to your home (at least tens or hundreds of thousands). And outside of major cities, 10 mbps might be the best you can get.

Not to mention there are a thousand situations even inside of the major cities where a few mbps (if that) is all you can muster.

I for one hate pages that take minutes to load... and it happens a lot more than you’d hope.


...in the US? Here in Europe I’m paying 30 euro/month for 200 megabit down (just 20 up, though), and I live in a 50k people town.

Even in London I think some places only get 10Mbps

I'm getting 32 mbps from BT for £52.49. My O2 mobile internet hardly works at all. London really has terrible internet infrastructure. I wouldn't be surprised at all if some people got no more than 10 mbps as you say.

> London really has terrible internet infrastructure.

I think it probably has average infrastructure shared over too many connections. If I do 4G speed tests up north, it's always way faster but there's also way fewer people trying to use it concurrently...


>I think it probably has average infrastructure shared over too many connections.

Which makes it indistinguishable from terrible infrastructure :)

More people sharing the infrastructure also means more people paying for it. So in terms of value for money London's internet infrastructure is terrible even by your very lenient definition.


My old place was getting 12-16Mbps over ADSL despite being only 400yds from the exchange. Fibre improved that slightly to 20-25Mbps.

(New place has 1Gbps fibre - average is about 300-350Mbps during peak times, 800Mbps+ in quiet times.)


I have gigabit internet and the web is still dog slow. It got a good bit faster when I started blocking third party garbage, but it still doesn't feel any faster than it was in the early 2000's, despite that my internet is literally 17,000 times faster and my computer is also tons faster.

This has also been my experience, uBlock origin improved performance on many websites (and also clues me into how many unnecessary connections by analytics and tracking servers are made by so many sites). It is mind boggling to see sometimes 250+ blocked requests on the badge for a news article.

Yeah. I started very aggressively blocking all third party stuff and then I manually whitelist things as needed. Its crazy how many requests some sites make, for stuff that has no impact on the content I actually want.

Test on a phone, anything over 1MB will lock up the script parser for a few seconds.

The irony is, the same people complaining about 500kb are probably the same people using a 100MB+ terminal emulator built using a web browser (i.e. hyper).

You don't download the entire app every time you change directories like you do navigating between sites in a browser.

If you're sending JavaScript down the line with every request, you're doing it wrong and should give up your career.

When you go to a new website, it doesn't download anything?

NEW website. As in, ONCE and FIRST TIME.

Flutter for Web is heavily reminiscent of Famous with its custom layout system and off-DOM rendering (or guessing DOM rendering support w/ CSS transforms of divs). To see, just view-source on the NYT demo.

Quite divergent from the web platform in my opinion. The fact that they have to re-implement copy and paste (and, accessibility features!) further adds to that: https://medium.com/flutter-io/bringing-flutter-to-the-web-90...

Quite bizarre compared to the Chrome team "Use the Platform" messaging.


Try using keyboard navigation or a screen reader on that NYT demo. There isn't a single accessible thing on the page. Not even the logo. You can't even select the text. It's awful.

Odd. Accessibility should work fine. If you can reproduce this, can you file a bug with details of your setup? https://github.com/flutter/flutter/issues/new?template=BUG.m...

Web development with DOM, CSS, etc. is a morass of complexity.

I'm really excited about a fresh approach to UI development. If they can pull it off, it is going to be very compelling.

It is going to take an enormous amount of investment. Something like this could only be done by a "FAANG" size company.


Well, not new. They take features of regular toolkits like gtk and qt, claiming them as new, paradigm shifting, bigger than sliced bread things.

Except it is still a very early stage product and feature set of one tenth of what QT or GTK would have provided.


Unlike GTK and QT, Flutter targets mobile and web.


Huh, good to know.

God, I totally forgot about Famous. That was honestly one of the weirder things I’ve seen in my years of web development. Such a gorgeous website and yet I never really understood what they were trying to sell me on.

So much marketing, such little end result....never went anywhere, never amounted to anything meaningful.


Apparently they're still a company, and still a lot of marketing with little end result: https://famous.co/

I think one of my first HN comments was meekly raising my hand and asking "OK, but what actually is this?" And getting quite a few (unexpected) upvotes, haha.

I am pretty sure these web apps can't be indexed by google at the moment and am not sure how they are going to solve that.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: