Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop
developers.googleblog.com
developers.googleblog.com
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.
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.
Also, you need some experienced people to look at new technology.
It’s a bit worrying to have Google pushing both PWAs and Flutter, there is always the chance of collateral damage from infighting.
The problem with this sort of hedging is that it only works for platform providers but not for developers.
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).
How did you come to that conclusion? They use the same Webview classes that RN wraps.
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.
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)
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.
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?
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?
> 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).
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.
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.
So aside from the IDE cost and marketing, there's no difference.
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.
Only if they care, most don't. In this case, they also don't. It's still trivial to do it, even in Flutter.
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
This was my thought exactly. It's not that it feels different, but that it's not an improvement.
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.
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.
<link rel="preload" href="/games/prototype/kenken/main.dart.js" as="script">I can't believe we gotta do this Flash and Silverlight fight all over again. Google should know better.
If this bothers you, your argument is with Web 2.0, not Google.
A never-ending parade of actively-exploited security bugs?
I'm actually scared of this fact. Flutter could very well be how Google finally kills the open web, if it succeeds.
>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 ?
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.
> 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.
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.
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
Disclaimer: I work for Google; all opinions are my own.
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.
Qt works on mobile, too.
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.
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.
The sooner your students learn that lesson the better.
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.
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.
I know what you mean. But have you tried flutter? Try it and you might change your opinion just like me.
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 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)
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 thought that flutter was started outside of Google.
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.
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. :-(
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.
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.
Who do you think does the porting and OEM certification work?
I agree with parent poster that flutter is very interesting for Embedded GUI development.
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)
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.
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.
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.
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?
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.
> 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.
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...
How do you do that, while said software depends on LGPL3 licensed Qt?
> 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.
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.
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.
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...
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...
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 ;)
I highly doubt that. See here https://fuchsia.googlesource.com/topaz/+/bd4464d6b8d586d74b6...
[1] https://fuchsia.googlesource.com/topaz/+/refs/heads/master/s...
[2] https://fuchsia-review.googlesource.com/c/topaz/+/184430
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.
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?
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.
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.
React Native is the other way around - real native widgets backed by interpreted/jitted JavaScript code.
To get native code plus native UI widgets plus some cross platform reuse you'd have to go with something like Xamarin.
As for runtime latency, I’ve recently worked on a RN app that outperformed its native sibling. Looking forward to the Fabric release.
In short, Flutter doesn't really have any advantage in size over RN.
Maybe a poor example, but I suspect the only times it really makes a difference is significantly computationally expensive tasks
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
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).
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.
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).
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.
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.
Android will be Kotlin
Flutter will be Dart.
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...
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.
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.
If you write something like:
import 'package:flutter_web/animations.dart';
void main() => print('Hello, World!');
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
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.
> 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 :).
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.
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.
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.
Disclosure: DevTools technical writer
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.
Doesn't seem bad to me.
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.
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!
[0] https://en.wikipedia.org/wiki/Decimal_separator#Arabic_numer...
I'm not sure this is a good enough reason to never compress anything.
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.
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.
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.
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.
Size matters a lot.
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.
There are also other factors to consider. I'm not huge in premature optimization, but damn.
What Moore's Law giveth, React/Flutter taketh away...
Abstraction for the engineer should not come at the expense of the person on the other end of the wire.
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.
Waiting for a page to load is a terrible user experience.
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.
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...
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.
(New place has 1Gbps fibre - average is about 300-350Mbps during peak times, 800Mbps+ in quiet times.)
Almost gave me a heart attack.
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.
So much marketing, such little end result....never went anywhere, never amounted to anything meaningful.
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.
Except it is still a very early stage product and feature set of one tenth of what QT or GTK would have provided.
I think if you want a fully themed app that looks the same across all environments, you should go with Flutter.
If you want an app that looks the same as other native apps on the target environment, you should go with React 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.
Much better IMO to go for a "minimalistic", neutral interface where people won't always be comparing your app to better native controls.
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.
I say this as someone who prefers native controls, has written/launched apps in ObjC/Swift/etc. There's increasingly little reason to bother with the stack.
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 clueless. There are certain things that they do feel acutely: animation physics that differ from the system's (particularly for things like scrolling), lag, choppiness, lack of proper accessibility support…
> There's increasingly little reason to bother with the stack.
I disagree with this (this isn't just an iOS thing, by the way: I would say the same for every other platform I've interacted with). It is almost certain to be the case that the team that wrote the platform libraries is smarter, better, and cared more than you did about the UI (there are some very notable exceptions, but I think it's very obvious when this is the case). Going with the native stack means lock-in and sometimes more work, but in exchange you get a significant amount of functionality "for free" (sometimes without even realizing that this functionality existed) and automatically share a common design language with the rest of the system, which is a usability plus for users almost all of the time.
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 how apps work in general to navigate your app.
Most people I know, including myself, have found it initially a little more difficult to navigate around apps from the platform other than the one we are used to using daily.
Apps that insist on creating the same UI on both platforms can be a mixed bag, IMO. Sometimes executed well, sometimes poorly. Because of this, I usually prefer apps that separately comply with each platform.
I am however interested in playing around with Flutter soon!
Helping older relatives who find touchscreens to be disconcerting (due to mistaken touches that they don't instinctively recover from by hitting the back button), I think native look and feel doesn't go nearly far enough to make things easy to use, for some audiences anyway.
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.
And lesson #1 in why to always follow some/any kind of UI standard.. Luckily their algorithms/service are decent.
One of my competitors has a native app, but they require an internet connection, and saving a data point has substantial lag. Parts of the UI (a graph) require a few seconds to be fully loaded, whereas my stupid Ionic app renders much bigger graphs much faster, has no "saving" lag, works offline etc.
My point is: you can screw up a native app easily as well, especially if you don't keep in mind what's blocking and what is not. Sure, at the end of the day, you can squeeze more performance and a better feeling out of a fully native app than anything Cordova-based, but this 5-10% optimization is something that non-techies really don't care about (unless maybe your app has no other USP).
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.
The Mac has a profound depth of power-user acceleration: keyboard navigation, keyboard shortcuts, modifier keys, drag and drop, context menus, type-select, arrow keys, etc. Learning this stuff isn't wasted because it applies to every app (or at least that's the vision).
Controls look consistent, which signals to the user that their knowledge applies here.
Mobile obviously needs different UI paradigms, and yet it doesn't really have much of anything. There's still no good convention for basic operations like Undo. And part of the reason is that every app has to be a snowflake.
This is an example of following an established convention, much like the conventions of the platform.
> But I seriously don't care. So long as every app is consistent with itself.
What if every app invented its own symbols for play and stop?
That'd suck.
But I don't care about the shadows, or lack of, on buttons.
Nor do I care about the exact animation that happens when transitioning between screens.
There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native.
From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).
Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.
I only want them to get the job done and then get out of my sight, so I don't care about the UI being pretty. I would say "elegance is reserved for desktop PCs", but those are ugly too (x86 is horrible, all OSs suck).
Funny thing is, that it is emulated on Android as well.
(Accessibility not so much unfortunately, but that is a work in progress.)
If you can tell that we're not using OEM widgets, we consider that a bug. Please file it and explain what the difference is. We're definitely not perfect, but fidelity is a high priority for us this year.
https://github.com/flutter/flutter/issues/new?template=BUG.m...
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 performance... it's just not my cup of tea however.
Here's a (random) post talking of performance of Native vs Flutter vs RN: https://thoughtbot.com/blog/examining-performance-difference...
>I feel confident in saying that a native Android app will perform better than either a React Native app or a Flutter app
By bypassing the target environment's native controls, they're paying more heavily in render code, but they're getting rid of all of that propagation of pain to higher up the development stack. As a developer, that's a cost I'm willing to pay.
(* For reference, I have used Flutter, Xamarin, React Native and Java at various points in time, and Flutter has very rapidly become my preference. It has a consistency that I appreciate. But of course, ymmv.)
In practice, we've found many apps these days don't even try to use the OEM UI style. Instead, they make "branded apps" with very customized widgets. Flutter really shines at this; it's very easy to make custom widgets. (Indeed, all our widgets, including the ones that look like OEM widgets, are just "custom widgets"... it's because it's so easy to make high-quality custom widgets that we're able to make OEM-like widgets so quickly.)
I agree simply for the reason that native simulation is a moving target and not something that can ever be truly complete. If you push your app into production and never release another update then your app will atrophy over time as updates to native UI widgets outpace your application's UI; not so with native or RN. You're also betting on the fact that maintainers will make updates to the rendering engine in a timely and comprehensive fashion in perpetuity.
In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just spent the last 6 months as a contractor running around fixing companies' RN apps for Android that had obscure build issues and dependency problems, along with all the weird UI stuff that just doesn't work the same as it does on iOS and it's not been fun.
After playing with Flutter for a bit it looks great. I just hope it isn't susceptible to the same issues I faced with React Native.
After messing with it for a couple of months, I would much, much rather duplicate my work with native Swift and Java/Kotlin codebases than one huge spaghetti code javascript codebase that I don't understand.
There's probably a market here for one-off white label apps too...
I would expand that to mobile AND desktop. It annoys me that multi-platform development typically means only iOS and Android.
It's really not unlike the web platform. If you're in the semi-narrowly supported "good" path it's great, but if you hit the limits of things you're pretty much immediately out of options.
And also really bad interop with some really critical components like WebView.
Does it have a Websocket client?
Just that once you do that you're no longer a portable cross-platform app, and there's limits to what you can do with that pipe in terms of data marshaling and the overhead from that.
Have you tried Xamarin?
It's worth learning the language because you can use it in so many places. It's not a case of "learn a new language for platform xxx."
By simple I mean that you don't need anything special from the device, no access to the sensors, no deep integration with the OS.
I think that enterprise apps would be an obvious target (because otherwise, for most of these small apps, the first question to answer is why not just have a website?)
For everything else, go native.
Short version: Flutter is growing nicely
As an example I've created an alternative to Nissan's Connect EV app. It's basically a way to control and monitor your electric vehicle from Nissan. The official app is I’m very disappointed by; it’s slow and full of wrong decisions. My alternative is called "My Leaf" and its available on Google Play and the App Store; https://play.google.com/store/apps/details?id=dk.kjeldsen.ca... https://itunes.apple.com/us/app/my-leaf-for-nissan-ev/id1436...
It's completely open source.
I'm hopeful Dart will get better given what I've seen and what a member of the Dart team mentioned in a thread a few weeks ago, but right now it's still nothing that gets close to the ancient ML. Would be nice if they learnt a few things from Facebook or Microsoft.
None of the JS nonsense required!
and docs: https://flutter.dev/docs
Because they make this impossible to find. I literally pieced this link together from the fricking browser screenshot.
edit : i’ve tested on latest ios safari on iphone SE.
not ready for demo. indeed it was good idea to hide links
Combine this with the fact that Flutter has announced that they intend for desktop support, and I think the future is pretty bright...
[disclaimer: I am TL for Dart Native Compilers]
We currently don't use LLVM for compiling Dart to native and we actually never used it in production - though we previously built couple of prototypes to evaluate potential benefits of using LLVM.
We use our own AOT compilation toolchain which has roots in our JIT compiler for Dart.
> meaning that compiling to WASM should be a trivial option
It's not really trivial because you still need to figure out some things - most importantly GC. On ARM you can scan the stack - on WASM you can't. They are working on GC support from WASM, but I don't think it is ready yet. And some things are just unfortunate (e.g. i31ref type which mimics V8's SMI - Dart SMI's are 63-bit on 64-bit platforms).
A lot of optimizations which benefit Dart code size and performance require high level optimizations anyway, so having LLVM does not help you in any way.
That said there are obvious benefits for having LLVM as a backend - so we are planning to explore it yet again in the near future.
Kotlin compiles to about three times as many different targets already.
1) Dart was intended as a Java like language and is inferior to Kotlin, a language they just endorsed on Android yesterday. Dart feels like a step back, not forward. The message is confusing from Google on this front. They have a huge Kotlin developer community already. Why push Dart at all?
2) World + dog is moving towards compiling Kotlin and many other languages to web assembly as well as native. Cross compiling Dart to javascript was maybe a valid choice a few years ago but not in 2019. See e.g. Rust roadmap for this year, .Net 5.0 agenda for MS, Kotlin Native, etc.
3) LLVM seems to be the toolchain of choice for this type of stuff to happen. Go and Kotlin + WASM would be very valid choices for Google to prioritize on this platform.
4) In a browser you need to be driving the DOM to look and feel like a proper web application. If you abandon that notion, you might as well grab something like QT or some other UI toolkit and use that.
My recommendation would be for Google to untangle flutter from Dart and just retire that and focus on WASM and native based runtimes only. That's going to take time and in my view it's inevitable that whatever they are pushing right now is ultimately going to be deprecated in favor of something like that.
Kotlin was/is meant to be a superior alternative to Java.
Java != JavaScript
Flutter I'd say is more like a successor to Flash. Dart is now relegated primarily to being Flutter's ActionScript.
If you look at Kotlin and Dart as implementations, then there are differences under the hood. Kotlin is deeply married to the JVM. That has a lot of obvious pros: you can seamlessly interop with your existing Java code, reuse the existing JVM ecosystem, and incrementally migrate your code to Kotlin a file at a time. There are trade-offs to this, though. Kotlin fundamentally doesn't own its runtime. It gets the JVM for free, but anything the JVM lacks, it has little easy way to acquire.
Dart is both its own language, and its own ecosystem and runtime. This means the adoption cost is higher, and our growth has been slower. We had to build more from scratch. But the return on investment is that we have a runtime that is deeply tuned for Dart and the needs of our users. For example:
* Our garbage collector is tuned for the frequently-allocated but short-lived objects that get constructed every frame by a reactive framework.
* When you deploy your app, we compile your Dart code ahead of time, all the way to machine code, statically link in the runtime, and give you a standalone native executable. Our deployment model is closer to C/C++ than to Java or C#.
* Our runtime object representation faithfully understands the full language. For example, there's no type erasure, and generics are represented at runtime. You can ask a list if it's a List<int> or List<Object> at runtime and it will tell you true.
* We can expose interesting debugging, profiling, and other diagnostic hooks from the runtime to tools. For example, the Flutter Inspector [0] will show you the bounding boxes of every widget on screen from the running app on your device. Touching one navigates your IDE to the corresponding source code. We can do that because we have the ability to plumb things all the way through the IDE, parser, compiler, runtime, and debugger, because it's all a custom stack.
* Likewise, the near-instant hot reload stuff we do works because the language design, Flutter framework design, IDE integration, compiler, and runtime all work in concert to enable that. Even non-obvious things like the fact that static fields are lazily initialized in Dart make this stuff easier.
Of course, the Kotlin+JVM advantages are real too. It's a question of which trade-offs are right for you today, and tomorrow. One thing I'm particularly excited about right now with Dart is that we're in a much better places to evolve the language quickly now that we've moved to 2.0, a full static type system, and a shared front end.
Right now, we're implementing non-nullable types. Ours will be fully sound, unlike in Kotlin and TypeScript, because they have to handle values flowing in through interop. We're also implementing extension methods. I'm hoping we can do something a la data classes not too long after. If we pull that off, I hope users will feel that we're at parity at the language level and then it becomes more a question of which tools are the best ones for your need.
I've actually heard of flutter projects doing the business logic in Kotlin and cross compiling that as a library to IOS and Android. The main reason the team cited is that they thought Dart was simply to limited for what they needed; from their point of view it was a necessary evil. It's great that you are trying to fix that. IMHO Typescript and Kotlin are worlds apart (I use both). Typescript is much more limited and way more quirky to deal with.
I've been playing around with devices like this https://www.ebay.com.au/itm/WiFi-Display-Dongle-1080P-Wirele... and it would be fun to run Flutter engine on them.
edit - would also be fun on the 4GB RAM rk3399 http://rockchip.wikidot.com/rk3399 tv box:
https://www.ebay.com.au/itm/X99-TV-BOX-4K-UHD-RK3399-4GB-32G...
open source LInux support is here: https://github.com/rockchip-linux
http://rockchip.wikidot.com/rk3036
You use buildroot to get your own software on it.
CPU: Dual-core ARM Cortex-A7
128KByte unified L2 Cache
GPU ARM Mali400
High performance OpenGL ES1.1 and 2.0, OpenVG1.1 etc Embedded 1 shader core with shared hierarchical tiler Memory
Video
Real-time video decoder of MPEG-1, MPEG-2, MPEG-4,H.263, H.264, VP8, MVC
The engine library alone is also already ~70 MiB. Running the Flutter Demo on my RPi3 (in aarch64, so the numbers are somewhat inflated) it's at 250 MiB of memory (with about 60 MiB of that for the system) and an additional 60 MiB of graphics memory. This is on a 1366x768, where the RPi graphics just about manage 60 fps (when warmed up).
>>We have $80 retail smartphones that blow this chip out of the water
I'm interested in things that plug in to HDMI.
This for example is $150 https://www.ebay.com.au/itm/X99-TV-BOX-4K-UHD-RK3399-4GB-32G... and uses the newer rk3399 chip http://rockchip.wikidot.com/rk3399
Why o why is this thing not written with/for TypeScript?
JavaScript was invented for similar reasons (though by one person).
Any decent dev should be able to get up to speed in Dart in a week.
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.
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 a product that tackles a real industry need because of the source, that's a bad sign.
At the end of day though, I look at if Google itself is using it extensively, because that's when a library will have the best support/longevity.
There was some Dart web framework churn before they settled on AngularDart.
It hasn't seen a release in a while because the developers contributing to it have been working on making it work with Google's recently open sourced J2CL compiler. From what I've read, builds of though are available but no official release yet.
I use React and Angular these days, but even back in 2010-2011 GWT felt pretty "done". At least for the things I needed to use it for.
Starting a new project with it now probably wouldn't be a career-enhancing move, but it was a pretty decent way to build really complex web apps at a time when the JS ecosystem was a lot less mature than it is now.
I remember looking at the Closure library back in 2010 and decided against using it, but from what I can see it still looks pretty decent. It doesn't look as nice to use as Angular or React, but it's been around a lot longer than either of them and probably has to remain backward-compatible with some pretty old code.
For the record I believe Flutter is here to stay, but I don't believe for a second they'll keep the "native look" around for anything other than Material design. It's a marketing gimmick to get their foot in the door and then transition everyone over to their own design.
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.
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.
Note: "this concern" is not "the library may go away or be unsupported". That's true of any open or closed source library.
The concern specifically is "this may get hyped to the point where it feels reasonable to depend on, then go unsupported". And that's never a surety, but frankly Google makes it MORE likely than, say, some random internet package that it will build enough of a groundswell to be seem safe, then suffer a sudden Nest-API-like strangulation. (Convenient for my argument that that announcement came out between my original post above and this one, but it's convenience that is directly my point).
Some rando package is unlikely to be broadly adopted unless it's actually good stuff...and the good stuff tends to get well supported, even if that means the occasional fork. Google has name cachet that can build support quickly, but the track record doesn't support that.
There's never a guarantee...but there are performers that are above average risk, and that's where I put Google when it comes to APIs and libraries.
They will need to reimplement tons of stuff that are already included in the browsers and ship all that code with the application.
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.
Yes, but browsers do not have game engine APIs. They do however have a layout engine, text editing and rendering, accessibility features, and a very long etc. Basically anything you need to make an app with text, images, buttons, etc.
Don't me wrong, I'm sure Flutter for the web is a technical marvel.
> Some markets are more sensitive to download size than others and you need to understand your users to know what you can get away with.
So you are arguing that Flutter for the web is a nice bonus you get but not really intended to be a general use case web dev framework.
If this is the case, it seems the Flutter team is missing a huge opportunity by not being a truly universal UI toolkit which it could be if it used the DOM instead of reimplementing everything.
Maybe. Just don't make any assumptions about their physical abilities, i.e. make sure business apps are accessible unless the task at hand inherently assumes a particular ability (i.e. is inherently visual).
> You can also publish Flutter apps for Chrome OS to the Play Store
Do they mean, you can publish an Android app and then run it with Chrome OS's support for that? How else are you supposed to run Flutter apps on Chrome OS? The only other way I see is "web" unless I'm missing something.
We support targeting the Web (that's the tech preview we released today), and we support targeting Android, both of which ChromeOS support. We also support development on ChromeOS.
The modern way would be to write a single page app using standard web API's, if those are enough to accomplish what you want, since it's portable to other browsers that way.
What size would you consider acceptable for a mobile Web app?
>> Flutter apps can now target the chrome browser (preview at this point)
> We support targeting the Web (that's the tech preview we released today),
Sorry for asking that way, I see my first question wasn't too well received by some other people here - and I can kind of see why - but I hope with the added context it makes it more clear why I asked.
I reread the article now in the morning and I see FF and Safari mentioned. I'm just so tired of everything that for some reason doesn't work in my main browser :-/
Good luck then!
You can honestly pick it up in a weekend, there's nothing particularly new or groundbreaking.
BTW: I'm working on subset of react-native for desktop (not yet ready) https://github.com/cztomsik/stain/tree/master/src
Why o why is this not written in a way to support TypeScript?
otherwise I might put some time into it, the Dart decision is unwise to me. Life is too short to get good of so many languages(esp the eco-systems behind each)
Complex UI.
If you got a system with complex UI, like Photoshop, Maya or Logic, you want it to look the same on all platforms. Sure, it won't adhere 100% to the platforms idiosyncracies, but re-designing it forever platform isn't an option. It's too expensive and people already poured time into learning the UI and just want it to work the same when they changed platforms.
I’m running a Ryzen CPU and I feel like that’s half the battle.
As a target platform or as a development platform?
We don't support targeting Linux out of the box today, but we support Linux as a first-class development platform (it's what I use). That said, we do work on Linux, and if you're willing to do a bit of work, you can use it to write Linux apps. If you want to target X11, you'll need something like https://github.com/google/flutter-desktop-embedding whereas if you want to target the hardware directly, you can do something like https://medium.com/flutter-io/flutter-on-raspberry-pi-mostly... .
Also, I don't like Dart after I used a site built with it by Google. As far as I remember, it was a Doubleclick for publishers or something ad-related. It was very slow, even in Chromium, all animations were laggy, and in Developer Tools I saw that it loaded megabytes of JS, compiled from Dart code. For example, a "What's new" widget was implemented as a separate app and loaded several megabytes of code including its own copy of a standard library. I would recommend against using Dart for Web sites.
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% reliable, but being able to get the text and layout from any arbitrary image and be able to navigate that would help those who struggle with vision a lot more, even if it's only 85% reliable.
There is also a big chance that Facebook, Google or whoever will drop their project at some point leaving you hanging and having to rewrite everything again to native or the next multiplatform framework.
Is there a plan to implement a web framework that can render Server Side Pages. Since it's developed in Dart. Like how next.js took react and implemented an isomorphic rendering. I don't think any reason not doing it. That's a win-win.
I would really give it a shot if they can do that.
Anyone from Flutter dev got a comment??
Does Dart offer good performance, asynchronous IO and all those things?
Sure, by the end Flash was a pain in everyone's backside. But Flash was critical in the transformation from a text-only internet to one where we could watch videos, or play games, or chat to other people in real time. So much of our modern web standards were born from an attempt to make it possible to do the things that Flash taught us should be possible.
If Flutter can be half as transformative as Flash was, then bring it on!
An euphemism for "we failed to provide a good UI designer experience".