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 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.
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.
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.
So aside from the IDE cost and marketing, there's no difference.
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.
If this bothers you, your argument is with Web 2.0, not Google.
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.
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.
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.
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.
I can't believe we gotta do this Flash and Silverlight fight all over again. Google should know better.
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.
I'm actually scared of this fact. Flutter could very well be how Google finally kills the open web, if it succeeds.
A never-ending parade of actively-exploited security bugs?
<link rel="preload" href="/games/prototype/kenken/main.dart.js" as="script">
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)
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 , 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 . 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.
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).
Here's some metrics for a FlasCC compiled AS3 compared to C++:
>Flash was clearly inefficient, it didn't use multicore
>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.
>Android development will become increasingly Kotlin-first,” Google writes in today’s announcement
>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 ?
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.
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?
I highly doubt that. See here https://fuchsia.googlesource.com/topaz/+/bd4464d6b8d586d74b6...
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.
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?
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.
Who do you think does the porting and OEM certification work?
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.
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)
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 haven’t heard of anyone similar using Xamarin, not even Microsoft-related ventures. Maybe because they’re mostly not in the U.S.?
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.
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.
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.
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).
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)
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.
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 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. :-(
I thought that flutter was started outside of Google.
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.
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.
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.
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.
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.
Qt works on mobile, too.
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. 
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.
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.
> 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.
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:
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
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.
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!
I'm not sure this is a good enough reason to never compress anything.
Almost gave me a heart attack.
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.
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.
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.
There are also other factors to consider. I'm not huge in premature optimization, but damn.
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.
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.)
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.
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.
So much marketing, such little end result....never went anywhere, never amounted to anything meaningful.