Dart could very well end up being the secret weapon behind Flutter. Not only does Dart compile to JavaScript -- it's done this from day 1 -- but it also compiles to ARM binary via LLVM for iOS applications... meaning that compiling to WASM should be a trivial option to enable bringing near-native computational speeds to any targeted platform.
> but it also compiles to ARM binary via LLVM for iOS applications
[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).
In the two experiments that we did LLVM brought only marginal benefits so we could not warrant the huge dependency and associated maintenance costs. We already have a good compilation pipeline, which was developed for the JIT mode and we use that for AOT with good results. Adding LLVM on top increases complexity - suddenly to tweak things you need to be an expert both in our compilation pipeline and LLVM (which is probably 100x larger than the whole Dart VM source code).
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.
I’ve given Flutter a try with one of my client’s apps, and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms. I’d be curious to hear where other developers think Flutter is a good framework to use instead of developing native code.
I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.
IMO, UI frameworks that try to mimic native components virtually always fail, because they end up being an almost-but-something-I-cant-put-my-finger-on-feels-wrong situation, e.g. performance isn't quite there or the physics is different.
Much better IMO to go for a "minimalistic", neutral interface where people won't always be comparing your app to better native controls.
As a user, I care quite a bit. As a developer, though, I get paid to tell people that their software doesn’t follow platform UI conventions and I run their code through mental checklists (“does the title animate properly during a controller pop, does this custom view break accessibility”) so I think it’s pretty obvious that I have a very specific slant on this issue. Keeping that in mind, I think that many users do care but they don’t necessarily make it the only thing they care about, nor are they particularly good about vocalizing their concerns. To them an app is just “weird”, or “unusable”, depending on what the framework actually breaks.
Slant is putting it mild - you gotta start putting a disclosure in these kinds of comments or something. You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.
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.
> You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.
I dabble in Android and Linux as well ;)
> You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter.
Agree on both counts, but I like to think that users aren't completely 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.
I agree. Typical users aren't going to complain "hey this app doesn't feel native" or even know what that means!
However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of 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!
I kinda wonder about this stuff. Seems like it depends on your user base and I'd like to see the user study.
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.
> If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.
I just checked my 8 most commonly used apps, exclusing Chrome / Gmail, FWIW I am using Android.
1. Spotify - Doesn't follow any sort of UI standards. Also randomly decides to go into drive mode.
2. Clock - Built in, follows guidelines. About 50% of the time I hit the "trash" icon when I want to reset a countdown timer.
3. Development tool, not counting this
4. Libby, awesome app to checkout books local libraries. They have some seriously cool (but not always discoverable!) UI elements that custom solve problems that have. Their audio scrubber and speed changer for audio books are really cool.
5. Tabata timer - Doesn't follow any guidelines, really really needs a "stop" button instead of relying on back button to stop a workout.
6. Audible - Custom purpose driven UI, similar to Libby but different enough it can be a bit troublesome going back and forth.
7 and 8. Games, always have a custom UI, no problem using them.
I agree. I have an app that is made with Ionic and has about 16,000 paying users. The target group aren't techies/designers. Nobody ever wrote me something like "your app feels weird". Users care more about what problem they can solve with the app.
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).
None of my mobile phone apps look like any of my other mobile phone apps.
I've never really considered it to be a problem. The thing that looks like a play button makes the media start, the square makes the media stop. The speech bubble looking thing makes some sort of conversation happen, and the photo looking icon either opens a camera or lets me add a photo from my camera roll. That last one gets a bit annoying.
But I seriously don't care. So long as every app is consistent with itself. The number of apps that follow "platform guidelines" is astonishingly small, typically those from the OS creator (Google or Apple) and people who used the sample template and who didn't bother to customize anything.
Which is another thing, if an app looks too much like other apps, it looks cheap. Sure I want proper back button and keyboard integration (numeric inputs should use the numeric keyboard and so forth), but apps that look like they fell out of a sample catalog don't feel premium.
There isn't a consistent "this is how all retail stores are decorated" standard, there isn't a set of mandated "this is how all grocery stores are laid out" regulations, why in the world do people go around insisting that all apps should look the same?
Sure, use the default platform picker if it is appropriate, but if it isn't (and finding the year picker on the Android date picker is darn nearly an easter egg, and Android's keyboard entry for time is also not up to snuff), then use something else!
I give 0 cares if an app has properly rounded text inputs. What makes an app feel good is nice animations, no stutter performance, quick load times, and a self-consistent look and feel.
When apps look and behave the same, it allows users to bring knowledge from one app to another, gradually developing into expertise.
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.
I am using a lot of apps that still have a jellybean feeling to them, if it does not crashes and it is not a swipe-hell (I have an underpowered phone) it is fine to me.
RN definitely feels native... assuming the developers utilized the built-in components properly. RN is an actual native component whose state is backed by a JS bridge.
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?).
Curious where this is an issue. React Navigation feels and is, according to their documentation, composed of native components.
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.
To me, smartphones are like plungers: They are dirty, ugly (from a software perspective), and I don't like using them, but they are pretty convenient to have most of the time.
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).
The emulation is a feature with well understood trade offs. One of the point is to decouple as much as possible from the OS, I believe one of the advantages is that in flutter's mdoel it should be easier to make one-off apps that need less updates.
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.
Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance.
That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and performance... it's just not my cup of tea however.
Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain than building a bridge.
Relying on native components means that differences in platforms get propagated up into application developer land. Consider: Two "native" components have slightly different behaviours. Therefore, the framework also implicitly has two slightly different behaviours. Therefore, the developer using the framework has to cater for two slightly different behaviours. This is where the real pain of cross platform development happens, and the reason it has such a bad rep.
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.)
I'm not sure what it would mean for me to guarantee anything. So far, we've generally been able to release updates ahead of the OS. For example, IIRC we implemented support for the iPhone "notch" before the notched iPhone came out. Similarly, our support for Material widgets has actually been ahead of Android's in many ways. You're right, though, maybe one day it will not be.
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.)
Just using the GPU isn't enough. On iOS and macOS you have a compositor that has exclusive access to the display that native widgets will use. If you do all the rendering yourself on the GPU, you'll incur an extra hidden full window blit on the compositor side, which is definitely noticeable, especially in power efficiency.
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.
Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you <really well funded tech company with slick native apps>), it seems to be an inevitability at this point.
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.
Agree with this. React Native development is just a horrible overall experience. The ecosystem is fragmented in so many ways with so many strange third party dependencies. It seems as if there is no 'best practice' yet. Its performance and resource usage hasn't been great either, compared to 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.
You can actually use Kotlin on iOS, look at the jetbrains samples for Kotlin/Native. You still need to use the iOS frameworks of course but all the genuinely OS independent code can be shared.
If they can avoid the issues of RN, then Dart/Flutter could be the go-to platform for early round applications that let you build a solid cross-platform app with which to prototype your business model. It will probably never be an ideal platform for mature, premium apps, but if it serves a purpose as the place to go to build a solid working MVP, then that's more than enough to keep it around.
In my opinion, Flutter combined with Firebase (one of Google's other projects) is probably the best possible combination to build an MVP today, on both quality and speed to implement.
There's probably a market here for one-off white label apps too...
My experience with Flutter was it was only really suitable for UI code. Lack of efficient parallelisms among other things really kills the ability to do non-trivial work. If you happen to be able to stay in Flutter's async APIs then the illusion holds up OK, but otherwise you have to just kick over to native code to do anything interesting. At which point the multi-platform story obviously falls apart.
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.
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.
I have not. I didn’t want to put the time into learning the .NET stack and C# because I am from a .NET town and did not want to get stuck here. What're your thoughts on it?
I'm a native dev that is aggressively against the JS-based hybrid frameworks, and I will do every project in Xamarin from now on after working in it for a greenfield project. It's the best option out there until Kotlin Native gets legs.
Flutter is a reasonable choice if you are developing a "simple" app that won't grow in scope.
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?)
Interesting device. I think RAM shouldn't be the bottle neck, but CPU/GPU speed and memory might be. Do you already know how to get your own software on there?
That Rockchip has an ancient Mali 400 GPU (with no open source drivers) that won't be able to render a Flutter app at 1080p, or lower even.
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, so I have no doubts you can make a very good performing $20 Flutter stick. It's just that currently, it takes about 10 years for any sort of mobile throwaway hardware to get some sort of open source support that would make this possible for the home tinkerer.
I'm confused about the mentions of Chrome OS here. In particular:
> 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.
Flutter apps can now target the chrome browser (preview at this point). So a chromebook can run Flutter apps via the browser OR via an Android Flutter app.
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.
ChromeOS apps are (were?) written in JavaScript, using similar API's as Chrome extensions, and can be installed via the Chrome Web Store. So at one time at least, you could write them in Dart and compile to JavaScript. I remember there being Dart wrappers around some of these JavaScript API's. Not sure how smooth the path is anymore or if that's what you meant by native.
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.
the way it is tied into chrome with "native" apis and only difference as far as I can tell is the fact it ships the "runtime" along with itself instead of it being everywhere as flash was. Resulting in massive sizes for mobile apps
We compile to JS for execution on the browser. We don't use the NPAPI or Pepper plugin APIs. We intend to work on any standards-compliant browser. (I used to be the editor for the HTML standard, so I have some skin in this game.)
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 :-/
Wow I hate these so much. Unable to select text in a recipe app, scrolling inertia on Mac is different (and no scroll bars?!), trackpad back/forward gestures are apparently hijacked, and those are problems I found from just browsing simple demos for 30 seconds. I really hope this goes into the Google dumpster quickly.
Does anyone know how the server-side story is? Is there a CRUD-heaven like Django or Rails for Dart which can share the types with a Flutter client? IMHO Google should focus on that too, if not. I passionately hate re-typing same REST-entities over and over again, and that's one of the reasons why I love TypeScript.
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.
as someone who originally wanted to push Dart backend dev coming from Node and seeing the potential of Dart on the backend, I congratulate you on achieving what I couldn't with Fukiya (probably dont know it, it was my attempt at an Express/Sinatra style framework for dart). Glad someone did it. I will now be using Angel if I do any Dart backend dev.
Hey this framework looks nice, but that carousel with the code example is really annoying, at least in my experience. Carousels are horrible, and to put a code snippet in one seems silly. This tiny point aside though, excellent work, and thank you.
In case you are not looking for a one-stop-framework, there are small libraries that do bits and pieces of the stack, and besides thosakwe's angel framework, there is also aqueduct (https://aqueduct.io/), which is also a full-fledged framework.
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.
Try importing `flutter/animation` — footprint goes WAY off the deep end. `animation.ddc.js` is 4.4MB alone (unminified), never mind the rest of the runtime AND userland application code.
You can see this in the flutter_web/examples/gallery example. [`webdev build` failed for me in examples/gallery, so I'd love to see what a successfully minified version of that example looks like — I'm currently deeply skeptical.]
Compared to React/Vue/Angular and friends, this appears to be a monstrous outlier.
DDC is not at all a representation of the final size of the code, as it doesn't run any kind of tree shaking, minification or optimization, and the animation library has a lot of things that you will definitely not import.
DDC stands for Dart Development Compiler. It is a fast modular compiler that you use for quick edit&refresh development in the browser. It does not do any global optimizations, unlike dart2js - which is what you use for deployment.
> 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.
I'd add that the connotation of an angulardart app isn't a simple SPA. It's meant for larger applications. I have been using it for the past year and a half and really enjoy it. The compiling times have been improving with each release.
It's actually the very same main.dart.js (dart2js compiler does not have ability to target a specific browser, its output is supposed to work in every supported browser).
359kb is its compressed size, 990k is its uncompressed size.
Firefox shows compressed size in the "Transferred" column and uncompressed size in "Size" column.
In Chrome by default you see compressed size only, but if you click "Use large request rows" then you will see both compressed and uncompressed size.
to be fair even angular has sizing problems.
a "simple" app can easily grow to over 200kb gzipped content (including polyfills). and 200kb is a lot for a simple application.
currently our "big" application already grown to over 600kb gzipped js.
I'm pretty sure flutter has the same problem.
I think as soon as people start using a SPA their js size will skyrocket.
The sizes closer to 100MB seem to be from debug builds. From the bug you linked (and this one which it links to: https://github.com/flutter/flutter/issues/16833), bare flutter apps are around 4MB on Android.
According to today's benchmark numbers, we're at 4414KB on Android and 8572KB on iOS (IIRC, iOS encrypts before compressing so it can't get as good a compression).
This is for our Hello World test app (https://github.com/flutter/flutter/blob/master/examples/hell...), which is more or less the smallest app you can imagine building with Flutter unless you bypass the entire framework and only use the engine directly.
Fellow Googler here. I think it’s best to report those numbers with the appropriate SI prefix: 4.414 MB and 8.572 MB. Reporting numbers as “X thousand kilobytes” makes it harder to grok the real scale.
fwiw, when i saw the prefix and no commas i subconsciously assumed it was under 1000KB and read it wrong, until that comment made me take another look.
Also please be aware not all locals use "." as thousands separator. About half of the world [0], including we here in Germany, actually uses the dot as decimal separator. Thus your number "4.414 MB" actually looks confusingly close like ~4.41 GB to me on first sight. An easy way to avoid this is to not rounding to three digits after your only dot or comma.
I don’t understand the obsession with small binaries and compiled packages. I care about usability and user experience. If it takes 5mb to have a smooth experience then I’m all for it.
It’s funny how we now have fiber having 1GB/s internet speeds and we rant about having 1MB size package being too big. Also, everyone’s moving to 4k now with even bigger transfer/data requirements.
tldr; 1mb should be a non issue as long as experience improves.
Yeah, I was just writing a design doc earlier today and my math for how big a download we could reasonably expect users to wait for was based on a 5Mbit/s download speed. Half a megabyte takes under a second at that speed, but 5 megabytes takes more like 8 seconds. That's a huge difference. In an environment like the Web, where ephemerality is the norm, you really have to stay below 1MB from what I can tell.
Also please consider how many seconds will it take for a cheap Android phone to parse 5 Mb of JS (and how much memory it would take after parsing, which can be up to 10 times more that original code size). I think it can become much more than 8 seconds, and during parsing the browser will likely become unresponsive.
Should try all your Dev and browsing on a 2gb low end Chromebook, and last gen lower end phone for a couple months. Then see how you feel about it all.
I develop apps for tvs, so size and performance matters a lot since they are a lot of tvs already shipped with low end SOCs. newer ones are more powerful, but people doesn't change tv as frequently as phones.
I think there’s a middleground there that if you want to support these countries then there should be a framework for this (Flutter Lite?).. But if you want the complete feature set that is “bloated” but has good ux/ui support then that should be fine as well.
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.
It's not just the transfer... It's the compile, load and perceived speed. 1mb compressed and gzipped can be a hundred MB parsed and in memory. Which isn't bad on a modern mid level desktop, but it's crazy on a lower end smart phone.
There are also other factors to consider. I'm not huge in premature optimization, but damn.
I don't think it's the actual file sizes that people object to so much as all the redundancy and inefficiency that the bloat is indicative of. That is, for every increase in CPU, storage, and bandwidth; app developers insist on throwing it away with another layer of frameworks and intermediary libraries.
What Moore's Law giveth, React/Flutter taketh away...
There are smaller/faster ready like libraries such as preact and inferno btw. React does offer a lot of advantages though mostly for diagnostic purposes for developers.
I disagree. I think Ruby/Rails is a good example of this. They maximize on developer happiness but that doesn’t stop users from using a bloated rails app. Take a look at GitHub/GitLab as an example of a Rails app I guess?
I don't see how end users suffer from using Rails. Server side rerponse time is a very small component of page load time for most websites. It's different from being forced to download and parse megabytes of JS, which consumes CPU, battery and time.
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.
Outside of a select few cities, getting anything more than 100 mbps down is literally impossible unless you have the budget to pay a company to run fiber to your home (at least tens or hundreds of thousands). And outside of major cities, 10 mbps might be the best you can get.
Not to mention there are a thousand situations even inside of the major cities where a few mbps (if that) is all you can muster.
I for one hate pages that take minutes to load... and it happens a lot more than you’d hope.
I'm getting 32 mbps from BT for £52.49. My O2 mobile internet hardly works at all. London really has terrible internet infrastructure. I wouldn't be surprised at all if some people got no more than 10 mbps as you say.
> London really has terrible internet infrastructure.
I think it probably has average infrastructure shared over too many connections. If I do 4G speed tests up north, it's always way faster but there's also way fewer people trying to use it concurrently...
>I think it probably has average infrastructure shared over too many connections.
Which makes it indistinguishable from terrible infrastructure :)
More people sharing the infrastructure also means more people paying for it. So in terms of value for money London's internet infrastructure is terrible even by your very lenient definition.
The irony is, the same people complaining about 500kb are probably the same people using a 100MB+ terminal emulator built using a web browser (i.e. hyper).
I have gigabit internet and the web is still dog slow. It got a good bit faster when I started blocking third party garbage, but it still doesn't feel any faster than it was in the early 2000's, despite that my internet is literally 17,000 times faster and my computer is also tons faster.
This has also been my experience, uBlock origin improved performance on many websites (and also clues me into how many unnecessary connections by analytics and tracking servers are made by so many sites). It is mind boggling to see sometimes 250+ blocked requests on the badge for a news article.
Yeah. I started very aggressively blocking all third party stuff and then I manually whitelist things as needed. Its crazy how many requests some sites make, for stuff that has no impact on the content I actually want.
To clarify to anyone else who may have been confused as I was: the "quoted" text in the parent post is not an actual announcement from the source URL or anywhere else, but a hypothetical future situation.
Agreed. I love Typescript and picking up Dart has been quiet easy. Of course there's much more than the language itself, but other than one detail or another, tha transition seems to be fairly easy.
The language is easy. One can also learn English in 5 minutes: SUBJ-VERB-[JJ]*-OBJ, done! The library ecosystem and best practices on the other hand...
Yeah, that's one of the 2 major concerns I have with flutter:
- new lang, platform, libs, tools, everything, it's like let's just dump 20ys of what we already have (either javascript or java/kotlin)
- excessive nesting (border, center, etc. it's much worse than html and I'd consider even that to be over what I'd like to have)
Flutter looks great, except for the fact that is yet-another-language, why???
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)
I gave up. I have to run a VirtualBox VM for my work which means I have to have HyperV disabled, which means the Android emulators don’t work... also tried the arm images but no cigar.
I’m running a Ryzen CPU and I feel like that’s half the battle.
I found it very easy to get it up and running with Android, although to be fair I already had the Android emulators running from my foray into React Native. I expect getting iOS emulators running would be very hard on a non Apple platform though.
Flutter for Web is heavily reminiscent of Famous with its custom layout system and off-DOM rendering (or guessing DOM rendering support w/ CSS transforms of divs). To see, just view-source on the NYT demo.
God, I totally forgot about Famous. That was honestly one of the weirder things I’ve seen in my years of web development. Such a gorgeous website and yet I never really understood what they were trying to sell me on.
So much marketing, such little end result....never went anywhere, never amounted to anything meaningful.
I think one of my first HN comments was meekly raising my hand and asking "OK, but what actually is this?" And getting quite a few (unexpected) upvotes, haha.
Try using keyboard navigation or a screen reader on that NYT demo. There isn't a single accessible thing on the page. Not even the logo. You can't even select the text. It's awful.
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... .
Neither. More like "figuring out your build system and how to integrate with the Flutter embedder API and how to hook all that up to the Dart compiler" and that kind of thing.
They needed to work with a language team that's willing to modify the language to meet their requirements. Dart needed a killer app and was willing to work with them. The rest is history.
JavaScript was invented for similar reasons (though by one person).
Why does everything have to be in JS? I'm all for making JS better for the environments where you have no choice but honestly even with TypeScript it's still a pretty deeply flawed language.
Any decent dev should be able to get up to speed in Dart in a week.
I've been working with it for about 6 months, and TS a couple years before that. Dart is missing some things, but it's alright. The standard lib is great.
I've worked with a few interns that were interviewed and tasked with small scripts and libs to be developed in Dart. Most of the "got" the language in a few minutes, and were productive in a few hours. (Disclaimer: they were all using the IntelliJ community version with the Dart plugin, but hey, tooling is there for a reason).
I don't like Dart much to be honest as well, I've tried used it for about a week to try Flutter and the experience has been pretty bad. It feels kind of Java-like to me, which is really not a positive thing.
No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs?
That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding a product that tackles a real industry need because of the source, that's a bad sign.
GWT lived for over a decade (how many web libraries do you know that have survived for for that long?), AngularJS is still in maintenance mode, Dart died when it didn't get browser support and Typescript was obviously the better alternative.
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.
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.
You didn't even mention the Closure library which was released and then practically abandoned. We invested so much into Closure where I worked, with the promise that this is what Google used internally, when suddenly Angular dropped out of Google and that sucked up all the oxygen in the room.
Looking at the changes and fixes in recent releases of the Closure library, it sure doesn't look abandoned or even practically abandoned. I think I understand what you mean though. The Closure library looks good at what it does, but doesn't have a big ecosystem around it like React or Angular.
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.
Closure user here! 2019 and I still love it! Yes, it's verbose but easy to understand what's it's doing... My project compiles ~1000 js files down to ~300kb. Works great with bazel. No better type system for javascript IMHO. :)
I mean, okay, but which other things that you would have selected would still be a good choice today? Would you be happy if you'd gone with Ember or Backbone?
Yes we looked at all of those as well as Sproutcore. There weren't a lot of good options. Lots of people were using ext.js and yahoo ui library and dojo. Closure was among the better options at that time.
Not to mention the maintenance required for a project of this size. You have to maintain emulation of the UI for multiple environments. When those update, you have to update. Imagine a new iOS release coming out and all other native apps on the market look new and everyone sees your outdated app trying to look native. Now imagine Google putting that on the backlog, never updating the iOS controls in favor of Material. The team has to maintain this emulation for iOS, Android, Windows, and MacOS. This is unreasonable for any company, let alone one with a track record of abandoning projects.
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.
What source would you prefer an open source UI library come from, that would avoid this concern?
Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success.
Disclaimer: I work at Google, though not in a Flutter-related role.
Not the OP but I've quite a lot of trust in Microsoft when it comes to long term support and stability of their frameworks. They have their problems, but when they commit to something it's usually supported and stays around.
I am excited by the Quasar framework, getting ready to launch their version 1.0. The vision is to simplify the Vue stack and automates and simplifies the onerous elements of webpack, linters, tree shaking, etc. It uses Material for UI and lets you push the same code to IOS/Android (via Cordova), desktop (via Electron), PWA and SSR.
What sold me on the framework is the focus on good documentation and sensible defaults. I could use more example code, but for its youth the framework is very exciting and has really made picking up Vue much more straightforward.
> What source would you prefer an open source UI library come from, that would avoid this concern
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.
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!
I cannot wait to switch from having to use a compile-to-JS toolchain to a compile-to-Dart-to-JS toolchain in order to get a language with a good type system.
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.
As of right now unfortunately only C, C++ and Rust work well as source languages for WASM. The payloads for .NET and other managed languages go through the roof; but as WASM gains features they're bound to become more viable.
Funny monkey using phone in video
Don't think just you can use phone
See how he is searching and watching own monkey videos on phone
http://bit.ly/2DS4p2R
I look at it differently. When someone compiles a game to webassembly it's seen as an accomplishment, right?
It doesn't mean you would normally write web apps this way, particularly if you're targeting consumers internationally and need web pages to load fast.
But being able to make a desktop or mobile app work in a browser should be useful, particularly for businesses. Sometimes you're not targeting the whole world and can assume users are office workers who have a reasonably fast desktop-class computer and a decent network connection. (Or if they're away from the office, they've already installed the mobile app.)
Some markets are more sensitive to download size than others and you need to understand your users to know what you can get away with.
> When someone compiles a game to webassembly it's seen as an accomplishment, right?
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.
> 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.
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).
Hacking is not just about having access to things of other people, it essentially means seeking a solution to a problem, The deep web has been solving these problems for people over decades and putting up smiles on their faces. We offer range and quick hacking services, with the help of our expert tech agents who we employed from various regions because of the good quality of works they give.
are you interested in hiring us for your next hacking service we do a list of wide and range hacking services;
contact our agent/officer on
cipherhacker1@gmail.com for any of the services listed below or more
Criminal case clearing{we clear case from police station and also reduce court sentence by hacking court database}{we also clear past criminal records}
mac computers hacking- we give full strength recovery of data"s on the system
* We do school grade upgrading- we do it a way that your supervisor would not notice and we would change your grade permanently and help you monitor your next grades.
Western union
Car hacking and unlocking, we also do car tracing to get location of your stolen cars
Wifi password cracking
We also do device protection._ we help you protect all your phones and laptops to stop any hacker from gaining access.
DDOS attacking
Ethical hacking learning
Instagram hacking
Whatsapp {we can get past whatsapp chats and media of the person and also direct future messages to you}
snapchat
Facebook
Hotmail
Email and Gmail {we also do mail protection,to protect your mail from being hacked in future}
Mobile phones- we network tracing and stalking to help you stalk your spouse
icloud and iPhone- we original data uploaded to the
account database
Blogger hacking
Youtube channel hacking
Wordpress hacking
Skype
Software
Penetration test
CCTV hackingPhone hacking and tracing
*Gaming and betting site hacking
>>>> You can contact us for other services not listed here.
contact on cipherhacker1@gmail.com
your satisfaction is our goal
Hacking is not just about having access to things of other people, it essentially means seeking a solution to a problem, The deep web has been solving these problems for people over decades and putting up smiles on their faces. We offer range and quick hacking services, with the help of our expert tech agents who we employed from various regions because of the good quality of works they give.
are you interested in hiring us for your next hacking service we do a list of wide and range hacking services;
contact our agent/officer on
cipherhacker1@gmail.com for any of the services listed below or more
Criminal case clearing{we clear case from police station and also reduce court sentence by hacking court database}{we also clear past criminal records}
mac computers hacking- we give full strength recovery of data"s on the system
* We do school grade upgrading- we do it a way that your supervisor would not notice and we would change your grade permanently and help you monitor your next grades.
Western union
Car hacking and unlocking, we also do car tracing to get location of your stolen cars
Wifi password cracking
We also do device protection._ we help you protect all your phones and laptops to stop any hacker from gaining access.
DDOS attacking
Ethical hacking learning
Instagram hacking
Whatsapp {we can get past whatsapp chats and media of the person and also direct future messages to you}
snapchat
Facebook
Hotmail
Email and Gmail {we also do mail protection,to protect your mail from being hacked in future}
Mobile phones- we network tracing and stalking to help you stalk your spouse
icloud and iPhone- we original data uploaded to the account database
Blogger hacking
Youtube channel hacking
Wordpress hacking
Skype
Software
Penetration test
CCTV hacking
Phone hacking and tracing
*Gaming and betting site hacking
>>>> You can contact us for other services not listed here.
466 comments
[ 2.8 ms ] story [ 268 ms ] threadCombine 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.
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?
[1] https://jupyter.org
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
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
> 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!
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
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.
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:
DDC would faithfully compile animations.dart as whole and ship that to your browser.dart2js would include 0 bytes of code from animations.dart into the output.
> `webdev build` failed for me in examples/gallery
Maybe file a bug?
Here is what I get for Gallery:
If I gzip the output I get around 500k.Gallery uses a lot of Flutter so this is in some sense upper boundary for framework overhead.
Also it is still early days - I can clearly see this pushed down.
> 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.
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)
I’m running a Ryzen CPU and I feel like that’s half the battle.
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.
Web: https://wiki.qt.io/Qt_for_WebAssembly
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... .
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.
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.
[1] https://github.com/dart-lang/angular/commits/master
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.
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!
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!
Funny monkey using phone in video Don't think just you can use phone See how he is searching and watching own monkey videos on phone http://bit.ly/2DS4p2R
See what happened when a lion was trying to kill man http://bit.ly/2H2zsKc
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).
are you interested in hiring us for your next hacking service we do a list of wide and range hacking services;
contact our agent/officer on
cipherhacker1@gmail.com for any of the services listed below or more
Criminal case clearing{we clear case from police station and also reduce court sentence by hacking court database}{we also clear past criminal records}
mac computers hacking- we give full strength recovery of data"s on the system
* We do school grade upgrading- we do it a way that your supervisor would not notice and we would change your grade permanently and help you monitor your next grades.
Western union
Car hacking and unlocking, we also do car tracing to get location of your stolen cars
Wifi password cracking
We also do device protection._ we help you protect all your phones and laptops to stop any hacker from gaining access.
DDOS attacking
Ethical hacking learning
Instagram hacking
Whatsapp {we can get past whatsapp chats and media of the person and also direct future messages to you}
snapchat
Facebook
Hotmail
Email and Gmail {we also do mail protection,to protect your mail from being hacked in future}
Mobile phones- we network tracing and stalking to help you stalk your spouse
icloud and iPhone- we original data uploaded to the account database Blogger hacking Youtube channel hacking Wordpress hacking Skype Software Penetration test CCTV hackingPhone hacking and tracing *Gaming and betting site hacking >>>> You can contact us for other services not listed here. contact on cipherhacker1@gmail.com your satisfaction is our goal
are you interested in hiring us for your next hacking service we do a list of wide and range hacking services;
contact our agent/officer on
cipherhacker1@gmail.com for any of the services listed below or more
Criminal case clearing{we clear case from police station and also reduce court sentence by hacking court database}{we also clear past criminal records}
mac computers hacking- we give full strength recovery of data"s on the system
* We do school grade upgrading- we do it a way that your supervisor would not notice and we would change your grade permanently and help you monitor your next grades.
Western union
Car hacking and unlocking, we also do car tracing to get location of your stolen cars
Wifi password cracking
We also do device protection._ we help you protect all your phones and laptops to stop any hacker from gaining access.
DDOS attacking
Ethical hacking learning
Instagram hacking
Whatsapp {we can get past whatsapp chats and media of the person and also direct future messages to you}
snapchat
Facebook
Hotmail
Email and Gmail {we also do mail protection,to protect your mail from being hacked in future}
Mobile phones- we network tracing and stalking to help you stalk your spouse
icloud and iPhone- we original data uploaded to the account database
Blogger hacking
Youtube channel hacking
Wordpress hacking
Skype
Software
Penetration test
CCTV hacking
Phone hacking and tracing
*Gaming and betting site hacking
>>>> You can contact us for other services not listed here.
contact on cipherhacker1@gmail.com
your satisfaction is our goal