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
You're bemoaning that the lack of use of DOM to render the UI???? Seriously? That ship has sailed when Canvas was introduced in the mid-2000s and it was introduced for the EXACT reason to provide the same kind of capabilities that people had with Flash.
People wanted and want to build rich web-based APPLICATIONS - not just websites with columns of text. That's why Flash became huge, and that's why HTML now has Canvas, Video, WebGL, WebAssembly, WebRTC (all of which were available in Flash - sometimes years before they were available in HTML).
The specific example you showed, nyTimes puzzle game, you'd never build that on-top of DOM (you could, but why would you?). You'd use JS to draw your UI with the Canvas 2D APIs. So I don't know what you're talking about.
>There's a reason why flash died out, and it's not only apple. It was dropped for making interactive website long before apple killed it - it doesn't work well with the web
NO!!! That's not why Flash died out. Flash died out because you had a standards-based alternative. Steve Jobs probably accelerated the transition a little bit, but it was inevitable.
Flashed died out way before canvas. No one but design shops made their websites with it. It remained strong in games and ads and disappeared everywhere else. That is why apple could even survive not supporting it.
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.
>This is flash. You can't do anything in it that fills like the web - no copy paste
Whereas you would have that in a Canvas or OpenGL equivalent web game?
>right clicking causes things to happen.
That's already the case for tons of websites, there's support for that in web standards.
>There's a reason why flash died out, and it's not only apple.
Yes. It was controlled by a single company, IDEs were paid for, it was more marketed to designer types, and it was frequently slow and used for apps and annoying stuff.
> Whereas you would have that in a Canvas or OpenGL equivalent web game?
Yes, you would, at least for some parts. Web games often combine the canvas showing the "game world" with DOM showing some UI elements - on which all the usual affordances work.
> That's already the case for tons of websites, there's support for that in web standards.
Fortunately most sites don't bother. The defaults matter.
>Yes, you would, at least for some parts. Web games often combine the canvas showing the "game world" with DOM showing some UI elements - on which all the usual affordances work.
Only if they care, most don't. In this case, they also don't. It's still trivial to do it, even in Flutter.
Last I checked, web games pretty much died with Flash. Sure, it coincided with mobile games soaring, but I doubt web games would've become this scarce without Flash dying as well.
> It was controlled by a single company, IDEs were paid for, it was more marketed to designer types, and it was frequently slow and used for apps and annoying stuff.
So aside from the IDE cost and marketing, there's no difference.
Perhaps you've missed the "controlled by a single company", made for designer types (by marketing to I don't just mean how it was promoted), slow, and used for ads and annoying stuff like flash screens and such.
Are you saying that web standards are not controlled by a single company? That is not how I interpret the behavior of the relevant standards bodies of the past decade.
There's almost certainly no middle ground between "use the DOM for everything" and "deploy any possible app on the web". As soon as we decided the web was more than just documents, this was inevitable. Smearing tech that's advancing this pretty obvious idea as "Flash" isn't super useful, and rings hollow when applied to Google tech but not Emscripten, WebAssembly, Canvas/WebGL, or other tech that is just transpiled to JavaScript and can only possibly use web APIs.
If this bothers you, your argument is with Web 2.0, not Google.
It seems like hedging your bets by supporting a large number of competing SDKs is the new normal. Microsoft does exactly the same thing. Apple appears to be alone in committing to something specific.
The problem with this sort of hedging is that it only works for platform providers but not for developers.
Perhaps, but for whatever reason React Native seems to still dwarf it. Maybe the companies that tend to churn out popular mobile apps just don’t invest in .NET?
React-Native has two significant pros that Flutter doesn't have.
Native UI. I heard multiple times now that Flutter drains the battery rather quickly because it doesn't use the highly optimized native UI elements.
JavaScript. There are more JavaScript developers out there than .NET ones. Also, the JS devs are much cheaper.
Another interesting pro is, you can use RN to develop basically everywhere. Expo (a RN framework) announced Web support, so you get Android, iOS, and Web out of the box. Microsoft announced UWP support and rewrote react-native-windows.
Well, it might be burned soil. Even in tech companies it's hard to convince the "decision-makers" to have another look at a technology that failed some years ago.
Also, you need some experienced people to look at new technology.
The biggest advantage of React Native is that it makes use of native UI. You won’t be able to embed a browser, or a performant video player into a Flutter app (on iOS, at least).
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).
> You can't do anything in it that fills like the web
Why "can't"? In this example they were making a game not a web, and they wanted it to feel like a game. The texts you see there are ultimately a plain old HTML p tag with selection and mouse interaction overridden, but I'd be surprised if you can't change those behaviours.
yes. And additionally it uses a new Dart language, requiring re-training JS programmers, unusual and less readable noodle-like code, slow single-core compilation and not as much 3rd-party libs and plugins as they are for JS and Cordova, React Native and NativeScript. I liked it at first, but I have doubts it will ever be wide-spread and highly-adopted. At first I hoped it could make Android app development better, getting rid of Java tooling nightmares but it is also bad in its own ways. So many years passed and Android dev experience haven't improved much. And Flutter is considered main Fuchsia UI language. :( I miss xcode and Cocoa...
Flash was fast. Much faster than JavaScript+DOM at the time. In fact, it was only within the last few years that browser JavaScript and rendering engines became more performant.
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)
Which bit was fast? My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble. Eventually the machine died of fan failure and I had to spend an entire afternoon doing brain surgery on it. I wasn't surprised when Jobs subsequently banned it from the iPhone!
The performance. The comparison macspoofing made was with JavaScript+DOM, not with native applications. I wrote games in Flash and played around with JavaScript+Canvas back when HTML5 was still fresh and Flash was still king.
The difference in performance was huge and Flash was faster for years. You'd hear people saying that JavaScript+Canvas was a valid replacement, sure, but those people had absolutely zero idea what they were talking about (especially when they said such stuff when there wasn't even a cross platform working sound API).
Things changed over the last years, sure. But do not rewrite history, JavaScript+Canvas sucked for a long time compared to Flash (and in some areas, like distribution, still sucks - a single compressed SWF file with all your resources is still nicer for distributing games than a bunch of HTML and whatever else files).
FWIW i always maintained that Java was miles ahead any of the above when it came to games (especially about performance), but Sun killed applets brutally with its awful startup times and bloated VMs. Then Oracle came along and just abandoned the whole thing.
All good points. But I'm still struggling with the idea of using the word "fast" to describe a technology that brought a 2GHz GPU-accelerated machine to its knees with Scrabble. Perhaps "sucked less than JavaScript"?
Both you and the person you responded to (Crinus) are right. I’ll share some context.
On Windows, Flash was fast but on OS X (as it was called then), Flash performance was atrocious. In fact, this was one of the major reasons why Steve Jobs felt compelled to pen his famous “Flash” article [0], because after getting Apple’s engineers to work directly with Adobe’s engineers, they couldn’t quite get Flash to be performant on the Apple desktop. Jobs added that the single biggest culprit of stability issues reported by customers on Macs was: Flash [0]. I remember this part vividly because my MacBook had never crashed on me until I had Flash in use during a browsing session. The other time this happened was from another Adobe product: Adobe AIR, which I believe uses the Flash engine internally.
Apple worked directly with Adobe because investing the engineering resources needed to make Flash performant and stable didn’t make economic sense for them, but even after this, they couldn’t get it to be stable as desired. Job’s thinking was if you cannot do this on desktops, how on earth will you manage on a resource-constrained device like the iPhone?
FWIW i did almost all of my Flash development on OS X. It is kind of amusing to read that it was even faster on Windows (although TBH i do not remember any significant performance difference in the games i did between Windows, Linux and OS X - then again all i did was blit bitmaps and largely avoided the vector stuff).
I was not comparing Flash to the JavaScript of the era, just pointing out that, as an end user, Flash didn't seem "fast" to me (on Linux, Android and OSX). Performance on a desktop-class CPU is also only one metric. Flash was clearly inefficient, it didn't use multicore, GPUs or hardware decoders. Was your Quake2 demo above using even OpenGL? Java applets could do that since well before 2008. The original Quake2 could do that in 1997.
> Care to guess why it was a flash-based game and not an HTML5 based game?
Anything would have been better, even bare HTML tables with no animations. The user experience of Facebook Flash Scrabble was awful (at least on OSX).
>I was not comparing Flash to the JavaScript of the era
But that's the entire point!!! People didn't use Flash because they felt like it. People used Flash because there were things you could do with Flash that you could not do with HTML/JS. Remember there was a time that Flash was the best way to do video.
>Flash didn't seem "fast" to me (on Linux, Android and OSX).
Let's leave subjectivity out of it. If you ran a standard benchmarks and compare to JavaScript of the day, Flash would beat it. That's what I meant by fast.
>Flash was clearly inefficient, it didn't use multicore
Neither does JavaScript (without WebWorkers). Neither does Node.js. Then again, Flash did get Worker support around 2012. And though your code was executed in a single thread, the actual rendering was delegated to the runtime, which was multi-threaded or backed by GPU.
>GPUs or hardware decoders
It sure did. Stage3D (think WebGL equivalent) was introduced in 2011. Video decoding delegated to hardware decoders since forever. Alchemy/FlaCC (WebAssembly equivalent) was released around 2009/2010. In many ways Flash was the vanguard of where HTML5 ended up going.
>The user experience of Facebook Flash Scrabble was awful (at least on OSX).
To be fair, Flash never ran well on OSX. It wasn't bad, but it wasn't as good as on Windows.
>Java applets could do that since well before 2008.
Java applets were an alternative to Flash, but Flash was lighter and had much broader support. It was better for video, better for vector graphics and 2D animations. But yes, Java applets were used to gain functionality that wasn't available in the web just like Flash.
and unusable on firefox (on my up-to-date pixel c) with it being a bit better on chrome... ipad pro though, actually not too bad in safari (though it makes me wonder about how much of a hit in battery it would cause)
>Google today announced the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers who want to use a reactive programming model similar to React Native and Vue.js.
This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ? Remember I'm talking about developing nations like India - where startups like ours invest in training college graduates . These guys can't afford 10$ courses on udacity and Coursera.
But even if it was not India, having this parallel signalling for Android based startups is very confusing. Atleast Apple was very clear about Swift .
Where will Android be in 2 years : Dart or Kotlin ?
Internal politic wars at Google, with management having popcorns to see who wins at the end.
If you are confortable with Qt, JavaFX, Xamarin, there is hardly anything to see with Flutter, plus they are based on programming languages that you actually want to have on your CV, instead of one that was dropped from Chrome and rescued at last minute by AdWords team.
Plus, even Fuchsia is not so focused on Flutter anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust.
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.
Weren't Symbian and MeeGo both sabotaged by Stephen Elop who came in briefly from Microsoft to assume the role of CEO of Nokia, decided to burn everything they had to instead buy Microsoft's solution, and then returned to Microsoft when the job was done?
> Plus, even Fuchsia is not so focused on Flutter anylonger. Android userspace is being ported to Fuchsia, and now they have a UI Framework agnostic layer, Scenic, with examples in C++ and Rust.
I don't think scenic is written in Rust. A big chunk of the source code in the topaz layer (the view layer) is still written in dart. With that said, many were actually surprised when it was revealed that ermine (the new fuchsia shell) was written in dart/Flutter [1] since earlier code for it was in Rust [2]. Guess that didn't pan out.
Your last sentence is a bit hard to comprehend but not paying for Qt and shipping a commercial embedded product is pretty difficult due to the anti-tivoization clauses of GPL3.
I agree with parent poster that flutter is very interesting for Embedded GUI development.
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.
You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause).
Do you see any possible security problems with the above?
Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.
>You are forced to help customers replace the Qt libraries in your product.
Depends on what you mean by 'help'. You are forced to give the opportunity for them to do the work if they need it. If you have statically linked files, it can't be done by accident.
> Do you see any possible security problems with the above?
No I don't. When I provide completely closed binaries for my customers, they can hack with the binaries and create security problems if they want to.
Software security is not improved by obfuscation. If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.
Btw. I'm confused by your wording. I'm suspecting that you have some underlying assumptions you are not stating. Are you thinking that LGPL forces you to allow customers to modify the software in the hardware they are buying?
I think I'm clearly stating my assumptions. GPL3 and LGPL3 requires you to enable the user to replace the GPL/LGPL3 code on your device with the users own version of said code. It does not matter if you link statically.
Now, it would be possible let the user do this and not let it be a problem for your product (in terms of security, reverse engineering, ip theft, etc) but it is more and harder work.
I have used both older version of Qt (LGPL2) without licensing and newer (LGPL3) with licensing in commercial products. The former was not a problem. But using LGPL3 Qt without licensing in a commercial embedded product is a headache (if you are concerned about the problems it might bring), according to me.
> 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.
> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
Also, anti-tivoizaton clauses does not apply to devices sold to business.
Good point, forgot about the latter part, that probably would help in some cases. Gotta ask some licensing experts about that one.
From what I see, only a tiny part of the potential market for embedded Qt and things like that can get away with "no updates possible", but still, applies for some.
JavaFX is fully open source, it doesn't need licensing. It also supports hardware acceleration, embedded usage on Linux, animation framework etc. Also, fits well with kotlin.
Flutter is very similar to Qt: signals and slots are similar to streams and sinks, and the BLoC pattern is similar to the state machine paradigm in Qt. I've been loving Flutter and Dart, developing with it seems almost too easy.
I’m sure those are all great cross-platform solutions, and Qt in particular has been around forever and predates smartphones, but you never hear about high-profile app examples that use them. Unlike React Native, which has lost more high-profile companies that previously tried them than I’ve ever heard of any firm using Xamarin.
I wonder why is that. Doubtlessly you can make great apps with say NativeScript, or in Pascal with Delphi or Lazarus, but no one chooses those frameworks for some reason.
> but you never hear about high-profile app examples that use them.
part of the reason for that is that a bunch of companies are paying TQTC for their tech stack not being known. But if you are looking for high-profile stuff using Qt, how about :
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...
Can you explain what you mean about React Native? If I understand, you're saying more companies have tried and then abandoned React Native than Xamarin? Can you provide evidence of this please?
Sure. The major apps that were previously using React Native are AirBnB and Udacity, who are fairly prominent as far as startups go. As far as companies currently using the framework, they are respectably impressive:
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 multi platform development, Kotlin multi platform
Kotlin mpp is still in beta but it works pretty amazing. I have 1 app in production that shares models/API/database. The UI on Android and iOS is native and platform specific. I highly recommend it.
Not naysaying you but i learnt kotlin and flutter this past year(from january). flutter has an AMAZING experience for the things that are "done", kotlin multi platform only does one thing well - kotlin.
it's basically like xamarin with C# swapped out with kotlin(and that sucks as much as kotlin mp does right now even after 3 years of ms acquisition time).
The development experience with flutter is great, that's right. But I don't like the end result. It feels very close to a native app but still not 100%. And I think it will always be a step behind.
One benefit of kotlin mpp compared to xmarine is, that kotlin mpp is not limited to iOS/Android. You can have a shared code base between web frontend/Backend/iOS/android and even macos/windows/linux and all native. One language to rule them all.
Flutter is on its way there, too. Already native on iOS, Android, and Fuchsia, with the web build in technical preview and desktop OSes under development.
I use C# almost on a daily base in Unity3D and have a little experience in Xamarine but I have no idea how a android/iOS/desktop/web project would be build up. Would be interesting to compare it with kotlin mpp.
If i understood it correctly,
React Native basically gives you a JS runtime environment that handles communication with native APIs of the system and is shipped with your app.
Flutter (and Dart) will transpile into native code and compile natively for your platform.
So on React Native you will have that abstraction layer add runtime latency and package size of your app, while Flutter (Dart) really outputs native code.
When React Native's fabric rearchitecture is available you will see much better performance. The thing that hurts performance today is that damn bridge communication between javascript and native that will be severely improved in fabric.
Package size for Flutter apps is a lot larger than RN, even the RN Android build that ships it’s own JS runtime. There are complaints everywhere of simple apps reaching 100MB size.
As for runtime latency, I’ve recently worked on a RN app that outperformed its native sibling. Looking forward to the Fabric release.
Unless you're importing a ridiculous amount of packages and assets, you'd never hit 100MB with simple apps, that's just people looking at debug mode and thinking that it's the final app size.
Simple apps can easily be under 8MB once compiled.
Not really true, you are likely comparing a debug build. An Android Flutter apk sits around 4MB for smallest app. Most of my apk sizes are around 8MB-10MB w/ Flutter
I haven't written any myself, going from reports online that builds are a lot larger than expected. That minimum size is for an app without any components or other modules. The RN app I mentioned was ~6MB with a fully blown app, state management, heavy data layer, hundreds of components, animation, i18n, a handful of native modules, encryption, and so on.
In short, Flutter doesn't really have any advantage in size over RN.
React Native has a JavaScript layer that hurts performance and it is not truly native as they say. Just do a reach on flutter vs react native and you'll see better explanations and comparisons.
I’m not sure this really matters for a lot of things anymore. Sorting a few hundred text items in a list, for example, is going to be so fast on modern smartphones that it will not make much of a difference whether it’s done in JavaScript or native.
Maybe a poor example, but I suspect the only times it really makes a difference is significantly computationally expensive tasks
so? most apps are by nature going to be computationally expensive if they want to compete/successfully use all phone features. i made a simple(according to them) corporate data sync app recently and the company wanted a laundry list of features - background sync, smooth scrolling of extremely large datasets, photographic analysis of images taken at tolls(extracting license plate information/classifying vehicles automatically for tracking).
All of this had to be made in a performant way so as to run on phones with 1 gig of ram as the company was giving phones to everyone specifically for just this purpose(and general communication ofc).However it also needed to work on iphones/windows phones(old ones the execs purchased en masse)
Xamarin was the only choice att as react just doesn't work stably on windows phones but i'm excited to see the future
Your app sounds like it used some advanced features, but I don’t think most apps are going to be computationally expensive in the way that local-AI, image processing, or crypto activities might be. I am not sure what qualifies as extremely large datasets, but I’d be surprised if keeping a few dozen objects in order is significantly lower in JS than Swift. Yes, it may be an order of magnitude slower - or ten orders - but that seems negligible if the total time for processing is still nanoseconds.
Guess it always comes down to the task at hand.
Preference for Dart over JS (lots of reasons, involving language, package manager, compiled performance)
Predictable UI behaviour across devices, OS versions, platforms. As long as you handle presence/absence of device features, and build your UI to scale properly, it behaves as you would expect, everywhere. The value of this cannot be overstated enough.
Future opportunity for code sharing with non mobile platforms. Even without Flutter-web, I could still compile the business logic part of my code to JS and use it with another UI (similar things can be done with React).
I don't think anyone has a definite answer, not even Google itself. Google placed several bets on different technologies and community will ultimately decide which of them is the winning one. Personally I think native Android (Kotlin) and iOS (Swift) development is here to stay. I have tried many cross-platform frameworks and on any non-trivial mobile app, all of them cause more problem than they solve.
I tried flutter. The available plugins cannot compete with the cordova or react native plugin system. For most apps a PWA or cordova-based web app is enough... Many apps are data-intensive and don't require fancy animations... My clients are more than happy with what the web has to offer.
I can only disagree. Flutter is primarily a UI framework. The "functionality" of a mobile application requires access to core features of the mobile platform (e.g. accessing sensors, bluetooth, nfc, contacts, camera, ...). The platform feature access is made available via plugins also when working with flutter. This is the same for RN, Cordova, Xamarin etc. There is no SDK in flutter, Android is the SDK. Flutter has no direct access to Android SDK APIs...
They're changing their stance on that gradually, just recently they started tracking their options for natively implementing multithreading in the background using dart(the current advice is to use platform specific plugins which isn't robust for services that run without a visible app). You're also wrong about xamarin- you do have direct access to android sdks(if you know enough C# to correctly translate the API usage into Xamarin android - which is a bit of a headache admittedly)
i really like the flutter dev community btw, very agile and open to newer ideas for plugins. havent seen this in react(fb controls all and devs usually just talk about js patterns all the time) or xamarin(community is nonexistent at this point, even questions barely get answered unless you post an interesting one on the gitter monitored by core xamarin devs)
That's mostly my opinion as well... Your better off with a mostly portable web based codebase, or dedicated or hybrid apps. Say what you will of Facebook, their ux approach with react send the most pragmatic.
You can't avoid learning Kotlin & Java, that's the native language for Android platform. Even if you use Flutter, leaky abstraction mean you will probably have to dig down to the native layer as your apps get more complicated.
That’s right. I’m a professional plugin developer. I’ve got my hands in both worlds, making dart APIs into the Obj-c/Java bridge where I’m implementing native APIs.
And several universes as well...I do plugins for React Native and Cordova, as well: same thing but JavaScript APIs into the Obj-c/Java bridge.
>This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart ?
Oh come on. Pick one. That's what you do for every other platform. Hell, even for web development, you'll have to make framework and transpilation decisions. This is no different.
>These guys can't afford 10$ courses on udacity and Coursera.
Yeah, too bad there are no free ways to learn programming languages on the internet.
But there is something arrogant about stating that programmers in developing nations somehow aren't capable of reasoning about tool choices for Android development.
Yeah, get out of business if you can't afford to send your offshored $5/hour indian developers to a 1-time $10 course to learn a new paradigm... Not sure I'm for flutter, react native, or some other (shopping around now for a good cross platform solution, quasar + cordova might be enough for my needs as I prefer vue), but these people need not be in business if they have no money to run their business properly. They'll just get shitty code that someonee else will eventually have to rewrite.
edit : I am not a Googler, but that's what I gathered from talking with them
Here is what is happening :
A couple of years ago, when the dart team failed at getting their runtime embedded into the browsers, they started searching for a problem to solve. They thought they had hit jackpot with multiplatform development. So they started working on Flutter. This is all entirely independent from the Android team at Google.
The Android Team at Google continuously improves their own framework, hence the jetpack set of libraries. One of the new libraries they have been working on and that is now public in pre-alpha stage is JetPack Compose. They have hired one of the engineers behind React and had them work inside of the Android Team on a "React like UI framework for Android".
The official direction of the platform is what the Android Team is doing.
Flutter is interesting, with all the advantages and caveats shared with other multiplatform tools like ReactNative.
As far as the bit about Flutter goes: Flutter was started by engineers from the Chrome team, and myself (who worked in the open source team as editor of the HTML standard). We had no relationship with the Dart team at all until some times into the project, when we were looking around for a language to replace JavaScript in our project (codenamed Sky at the time). We considered a large number of languages but ended up picking Dart because it was the best fit (see the Flutter FAQ for more details). We then had to learn Dart and made friends with the Dart team, with whom we now work very closely.
Languages I recall us considering include: Java, Kotlin, Swift, C++, Dart, Lisp, Lua, ObjectPascal, Python, C#, Go, Rust, TypeScript, JavaScript itself, Perl.
I wish I had our notes from back then, but I looked for them recently and couldn't find them. Our best theory is we did it on paper or on a whiteboard. :-(
How cross platform can this be? What's the fallback plan if you need some API that's unavailable? Simply having a lightweight native wrapper around the webview allows a lot of oomph.
Invest in Kotlin. It's been created by Jetbrain and they are showing clear support for it. I can't say the same about Dart. Google won't support Dart, GWT, Angular, Polymer ... eternally. Yes different purpose, tech and ambitions but too much overlapping. In case of a "more wood behind a fewer arrows" situation, you'll have to pray that the Google gods didn't choose to sunset the stack you bet on.
I don't mean to be cynical, but the answer may be 'whichever language wins'.
Maybe Google wants to support Dart because its built in-house, while simultaneously supporting Kotlin because it is so well loved by developers. Just a guess.
No. Mobile Dev is not anything close to web dev : developers don't have control of run time devices.
Google is now mandating 64 bit APK for its apps (after years and years of trying) - that's a end device support issue. React native has had 64 bit problems for years.
Viewmodel is a lifecycle aware component. Android Q will come with foldable-aware SDK. Will that be
supported both on Dart & AndroidX/Kotlin ?
Someone has to explain to Google management that an ecosystem that has gazillion different devices , that are not in developer control is a far different beast than web dev .
Microsoft understands this better than anyone else. Look at their bug-compatibility spanning 30 years.
We cannot afford a fight-to-the-finish when my customers are on a gazillion different devices with different hardware. NBU markets like India operate at a very different level of complexity than the two-device markets of North America.
As a developer you cannot expect that the technology you learned at university will be used forever ( or actually at all) in your professional life. Schools are supposed to teach you enough of the fundamentals to be able to adapt and learn the tech du jour on your own.
The sooner your students learn that lesson the better.
this is not an issue with two languages targeting the same SDK. you are mistaken on these aspects - I'm not sure if you are an android dev, so please forgive me if I'm pedantic.
Kotlin vs Java is the situation you described. They both target the same underlying SDK. For example Pyspark vs Spark-scala. You can program in either, but you are still using the same paradigms - RDD, Graphframes, Dataframes.
Flutter and AndroidX are not even the same paradigm - the lifecycle management is completely different. Android development forces you to think in terms of Activities and Fragments since they are a lifecycle model. Flutter changes it entirely.
I'm pretty sure I can learn it fast, but the issue im asking is about investment. If you are running a company with 100 android devs, where will you invest your training and future architecture research.
Or do you believe that the code of an app that's being used by a couple of million users for financial transactions can be ported to a new framework in a jiffy ? Just the testing and validation impact is huge.
The issue is that we are just coming out of a Java -> Kotlin transition that required significant investment on our part. Because of Google making their stand very clear that Kotlin was the future. So now, this is very confusing.
Sorry, i read your original post a bit too fast. Indeed, for corporations that’s a big question ( i thought you were teaching students, not hiring them)
And you think that anybody can answer that from Google? There are different factions in every company, they are fighting over things constantly. This is why Google has many similar products.
There's been activity porting the Android Java components to Fuschia.
I have no inside information (not a Googler) but that leads me to believe that if Fuschia becomes the next mobile OS from Google it will support both.
So same goes for Android I would assume. Why does an OS need to have a single stack? You can write desktop apps in a zillion different languages and Frameworks after all.
s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.
> You can write desktop apps in a zillion different languages and Frameworks after all.
You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.
> s/Fuschia/Fuchsia/ And also it hints that you don't know what are you writing about.
Is this necessary? Also, you definitely shouldn't be throwing stones while living in a glass house. s/mobiles/mobile
> You can but the portability would be an issue. Each major OS has their own set of API/ABI, vastly different from each other, and Fuchsia isn't an exemption. You can write with QT for desktops but it wouldn't work on mobiles, you can write for Electron/CEH but lose performance and still have to do a lot of trickery, and so on.
ABI only matters if you're linking code or directly running bytecode on another platform. If you're targeting another platform, you're almost certainly going to recompile libraries/your application to target the new platform, so you won't run into ABI issues. Especially because most desktop platforms (read: x86) have bytecode incompatible with mobile platforms (read: ARM).
Also, Qt and Electron are abstraction layers over OS interfaces. As long as the OS supports the required primitives you could presumably rewrite Qt and Electron to target the new platform. Although it might take a fair bit of work, people have done so.
Aside: Would love to see electron and Cordova bridge the gap together for mobile targets. If they can establish a few common interop libraries, you could come very close to the same code for both.
I'm really uncertain about a huge JavaScript runtime on mobile -- seems like an energy waste/slow code. Dart's AOT story the Cupertino wrappers for iOS in Flutter really excite me.
Disclaimer: I work for Google; all opinions are my own.
The runtimes is already there. Not to mention there's still room for improvement.
I'm not against other options being available. But there's a certain amount of pragmatism to being able to use the same skills, developers and code to approach development that targets several disparate platforms in a very open way.
My favorite language is JavaScript for all the flexibility. My second and third are Rust and C#. Just getting my feet wet with rust and have done C# from the beginning. They all have very different reasons to exist and most applications can be written with any of them.
In the end of the people paying for the development cannot fund a given approach, there's a certain pragmatism that must and should take priority.
With JS I can use functional, classical, and procedural approaches and mix them as needed. There are foot guns. They are there in every language.
As to overhead and battery, I can see the point. If rather have an app with more overhead, than no app at all. I use Windows, Linux and Mac and tend to favor apps that work everywhere. If like to see that extended to phones.
Me not knowing how to spell the name of a plant/colour/operating system has something to do with my recollection of recent tech journalism?
I appreciate the correction of my spelling (honestly) but this is a bit of a stretch.
Your API/ABI point is also completely off topic. My comment points out that on the _same_ OS you can use different technologies, like Electron or Qt. I'm trying to point out that having both Kotlin and Dart/Flutter as options isn't bad or unprecedented like the parent comment seems to allude to.
And what do you think those plugins implementing the native sensors or CLLocationManager / FusedLocationProviderClient is written with? Obj-c/Swift and Java/Kotlin.
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.
> 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.
Try importing `flutter/animation` — footprint goes WAY off the deep end. `animation.ddc.js` is 4.4MB alone (unminified), never mind the rest of the runtime AND userland application code.
You can see this in the flutter_web/examples/gallery example. [`webdev build` failed for me in examples/gallery, so I'd love to see what a successfully minified version of that example looks like — I'm currently deeply skeptical.]
Compared to React/Vue/Angular and friends, this appears to be a monstrous outlier.
DDC stands for Dart Development Compiler. It is a fast modular compiler that you use for quick edit&refresh development in the browser. It does not do any global optimizations, unlike dart2js - which is what you use for deployment.
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.
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.
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.
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.
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.
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.
It's not just the transfer... It's the compile, load and perceived speed. 1mb compressed and gzipped can be a hundred MB parsed and in memory. Which isn't bad on a modern mid level desktop, but it's crazy on a lower end smart phone.
There are also other factors to consider. I'm not huge in premature optimization, but damn.
I think there’s a middleground there that if you want to support these countries then there should be a framework for this (Flutter Lite?).. But if you want the complete feature set that is “bloated” but has good ux/ui support then that should be fine as well.
Our current plan is to support the complete feature set while still supporting places with connectivity around 5Mbit/s. We are still in very early stages (we only just put out the tech preview today!) but we have some confidence that this is possible. Personally I'm more worried about the performance of layout animations (e.g. resizing paragraphs) than about download size, but again, it's early days still.
I don't think it's the actual file sizes that people object to so much as all the redundancy and inefficiency that the bloat is indicative of. That is, for every increase in CPU, storage, and bandwidth; app developers insist on throwing it away with another layer of frameworks and intermediary libraries.
What Moore's Law giveth, React/Flutter taketh away...
There are smaller/faster ready like libraries such as preact and inferno btw. React does offer a lot of advantages though mostly for diagnostic purposes for developers.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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 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.
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.
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.
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.
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.
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.
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).
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?)
I simply love Flutter for Android and iOS development and have been using it since alpha. I haven't tried the web application part; I'm pretty sure I never will. Here's my opinion. I've created several apps with Flutter and every time I enjoy it. The UI is easy to make beautiful and the resulting code easy to read. It feels like all what the current Android SDK is missing. The current Android SDK is old and quite frankly painfull to work with. You just can't create beautiful apps with ease; it's always a hassle. It's also messy and not easy to read the resulting code. The way the whole way the framework is structured entails ugly code in my opinion. This all becomes evident when you use different apps on Google Play. You get the sense that every app reinvented their UI; there is no real UI continuity. Google became a freeloader after JetBrains created Kotlin and marketed it will. The thing is Kotlin made just a little better; in terms of boilerplate stuff; the framework I still hate compared to Flutter.
What I really like about flutter is the framework and “it’s all a widget” idea. You can basically do crazy things in UI with ease and on the other hand just use the standard UI components with a great result.
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.
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.
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.
It feels wrong architecturally for Google to be pushing this right now:
1) Dart was intended as a Java like language and is inferior to Kotlin, a language they just endorsed on Android yesterday. Dart feels like a step back, not forward. The message is confusing from Google on this front. They have a huge Kotlin developer community already. Why push Dart at all?
2) World + dog is moving towards compiling Kotlin and many other languages to web assembly as well as native. Cross compiling Dart to javascript was maybe a valid choice a few years ago but not in 2019. See e.g. Rust roadmap for this year, .Net 5.0 agenda for MS, Kotlin Native, etc.
3) LLVM seems to be the toolchain of choice for this type of stuff to happen. Go and Kotlin + WASM would be very valid choices for Google to prioritize on this platform.
4) In a browser you need to be driving the DOM to look and feel like a proper web application. If you abandon that notion, you might as well grab something like QT or some other UI toolkit and use that.
My recommendation would be for Google to untangle flutter from Dart and just retire that and focus on WASM and native based runtimes only. That's going to take time and in my view it's inevitable that whatever they are pushing right now is ultimately going to be deprecated in favor of something like that.
Dart was originally meant to be a superior alternative to JavaScript. They originally wanted native Dart support in the browser (dartium) just like there is native JavaScript support.
Kotlin was/is meant to be a superior alternative to Java.
Java != JavaScript
Flutter I'd say is more like a successor to Flash. Dart is now relegated primarily to being Flutter's ActionScript.
If you just look at the languages, Kotlin has a lot of nice features that Dart doesn't currently have. Non-nullable types, extension methods, and data classes are on the top of my mind.
If you look at Kotlin and Dart as implementations, then there are differences under the hood. Kotlin is deeply married to the JVM. That has a lot of obvious pros: you can seamlessly interop with your existing Java code, reuse the existing JVM ecosystem, and incrementally migrate your code to Kotlin a file at a time. There are trade-offs to this, though. Kotlin fundamentally doesn't own its runtime. It gets the JVM for free, but anything the JVM lacks, it has little easy way to acquire.
Dart is both its own language, and its own ecosystem and runtime. This means the adoption cost is higher, and our growth has been slower. We had to build more from scratch. But the return on investment is that we have a runtime that is deeply tuned for Dart and the needs of our users. For example:
* Our garbage collector is tuned for the frequently-allocated but short-lived objects that get constructed every frame by a reactive framework.
* When you deploy your app, we compile your Dart code ahead of time, all the way to machine code, statically link in the runtime, and give you a standalone native executable. Our deployment model is closer to C/C++ than to Java or C#.
* Our runtime object representation faithfully understands the full language. For example, there's no type erasure, and generics are represented at runtime. You can ask a list if it's a List<int> or List<Object> at runtime and it will tell you true.
* We can expose interesting debugging, profiling, and other diagnostic hooks from the runtime to tools. For example, the Flutter Inspector [0] will show you the bounding boxes of every widget on screen from the running app on your device. Touching one navigates your IDE to the corresponding source code. We can do that because we have the ability to plumb things all the way through the IDE, parser, compiler, runtime, and debugger, because it's all a custom stack.
* Likewise, the near-instant hot reload stuff we do works because the language design, Flutter framework design, IDE integration, compiler, and runtime all work in concert to enable that. Even non-obvious things like the fact that static fields are lazily initialized in Dart make this stuff easier.
Of course, the Kotlin+JVM advantages are real too. It's a question of which trade-offs are right for you today, and tomorrow. One thing I'm particularly excited about right now with Dart is that we're in a much better places to evolve the language quickly now that we've moved to 2.0, a full static type system, and a shared front end.
Right now, we're implementing non-nullable types. Ours will be fully sound, unlike in Kotlin and TypeScript, because they have to handle values flowing in through interop. We're also implementing extension methods. I'm hoping we can do something a la data classes not too long after. If we pull that off, I hope users will feel that we're at parity at the language level and then it becomes more a question of which tools are the best ones for your need.
Actually Kotlin has a native compiler and (and a js compiler) and I'm not advertising the JVM variant here. The native compiler is also able to target WASM. WASM of course still lacks a garbage collector, which is currently holding back Kotlin (and other languages) there. I believe Google is involved in fixing that. On native they bundle their own garbage collector. I imagine MS is bundling one with Blazor in WASM. As soon as WASM matures (GC, threads, and a few other things) that becomes an obvious path for Flutter as well. Now would be a good time to start working on that. E.g. MS is doing very similar things with C# and Blazor as you are doing with flutter. Except they are doing this with WASM and llvm (check their .net 5.0 announcements a few days ago). I think this is the future proof path for Flutter as well and I question the need for Dart or a separate runtime. IMHO a LLVM based toolchain like on IOS needs to be the default on Android/ChromeOS as well. Something like Flutter paired with Kotlin or Swift could work really well.
I've actually heard of flutter projects doing the business logic in Kotlin and cross compiling that as a library to IOS and Android. The main reason the team cited is that they thought Dart was simply to limited for what they needed; from their point of view it was a necessary evil. It's great that you are trying to fix that. IMHO Typescript and Kotlin are worlds apart (I use both). Typescript is much more limited and way more quirky to deal with.
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.
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?
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).
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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).
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.
>> 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 :-/
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?
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...
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.
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)
Because some people asked when to use Flutter instead of something like React-Native.
Complex UI.
If you got a system with complex UI, like Photoshop, Maya or Logic, you want it to look the same on all platforms. Sure, it won't adhere 100% to the platforms idiosyncracies, but re-designing it forever platform isn't an option. It's too expensive and people already poured time into learning the UI and just want it to work the same when they changed platforms.
I 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.
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.
It is interesting that they have a special, third-party mirror for China: [1]
Also, I don't like Dart after I used a site built with it by Google. As far as I remember, it was a Doubleclick for publishers or something ad-related. It was very slow, even in Chromium, all animations were laggy, and in Developer Tools I saw that it loaded megabytes of JS, compiled from Dart code. For example, a "What's new" widget was implemented as a separate app and loaded several megabytes of code including its own copy of a standard library. I would recommend against using Dart for Web sites.
The lack of accessibility sucks, but there's a part of me wondering why we don't have accessibility tools that don't rely on us tagging images and giving us the ability to navigate the layout of a page.
Wouldn't tools that do text and image recognition based on screen selection, arrow keys that move to the center of the nearest shape, etc. be a lot more useful? Like a Google lens for desktop.
Text selection is 100% reliable, but being able to get the text and layout from any arbitrary image and be able to navigate that would help those who struggle with vision a lot more, even if it's only 85% reliable.
Once you're at the level of OCRing text from screen, it becomes a general-AI-complete problem. See e.g. how bad OCR still is for books, and there you can still make good assumptions about the shape and meaning of text (sentences, paragraphs, chapters). With arbitrary UIs, you have to recognize what each block of pixels means, and that's the GAI-complete problem at which even humans fail (that's why the UI/UX/HCI fields exist).
Frameworks like this have come and gone in the last 10 years. I'm not convinced that using this will save you time in the long run. You need to invest a ton of time learning the ins and outs of these frameworks to get stuff done. There are always limitations compared to real native solutions. I think the time is wiser spend understanding the iOS and Android platforms itself.
There is also a big chance that Facebook, Google or whoever will drop their project at some point leaving you hanging and having to rewrite everything again to native or the next multiplatform framework.
This is great news for those investing in Flutter. But from the looks of it, it seems like a Front end framework (AKA client-side rendering).
Is there a plan to implement a web framework that can render Server Side Pages. Since it's developed in Dart. Like how next.js took react and implemented an isomorphic rendering. I don't think any reason not doing it. That's a win-win.
I would really give it a shot if they can do that.
These frameworks are starting to get too complex that is why the sizes are huge.
I liked that pika concept of not using webpack anymore. I think the future of the mother of frameworks is to o stop compiling in webpack!
It seems like nothing has changed. The repository wiki still says "The current Linux shell is a GLFW placeholder, to allow early experimentation... Expect the APIs for the final shell to be radically different from the current implementation."
How does Dart compare to Kotlin? I was planning on learning Kotlin, hoping to use it for server side development as well. But somehow now I have a feeling that developing mobile flutter apps might be more pleasant (pure feelings not based on any real data).
Does Dart offer good performance, asynchronous IO and all those things?
Sure, by the end Flash was a pain in everyone's backside. But Flash was critical in the transformation from a text-only internet to one where we could watch videos, or play games, or chat to other people in real time. So much of our modern web standards were born from an attempt to make it possible to do the things that Flash taught us should be possible.
If Flutter can be half as transformative as Flash was, then bring it on!
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.