We're all complaining about how js is a bad language, tooling is a mess, and how the web is fundamentally built for documents and makes it hard to create app-like experiences. Now, Google comes and creates a whole new UI toolkit from scratch, couples it with a very beautiful SDK and component framework and offers a far better programming language than js could ever be but we're still nagging. I was also pretty disappointed with the demo at flutterfolio.com that is supposed to show how great Flutter 2.0 for the web is. It's not that good but it's gonna get there eventually, given the hype around wasm and <canvas> technologies. Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS. I believe Flutter is an extremely ambitious project and I appreciate that Google is really trying to give an answer to the problem of cross-platform UI development.
Are you a native mobile developer? I am (was I'm moving to ML/AI/Data engineering) and I don't think flutter is in any way easier or nicer than the native toolchains for mobile. Both Swift and Kotlin are better languages than Dart IMO, the IDE and tooling is far superior for both also. Flutter is faster but once to deploy a substandard quality of app for sure but matching the quality of a native app? That takes just as long in Flutter as building a native app in each tool chain. I've built apps in React Native, Flutter, Ionic, and Swift/Kotlin. I'd reach of Swift/Kotlin for developer experience, performance, and quality of app EVERY time.
I am a native app developer. I have only built one small app with Flutter. Here's where I disagree:
- I've used Xcode since version 2 and like it, but in my opinion it's a worse developer experience than Flutter. Refactoring and code navigation were much better in both Android Studio and VS Code.
- Flutter's hot reloading is fantastic. Meanwhile, SwiftUI previews seem to be built on the same technology as IBDesignable, that is, they're just barely stable enough for a short WWDC demo.
- I am very sensitive to non-native controls on macOS, but UIKit doesn't even have a standard button class, the first thing that everyone has to reinvent (Apple included). I wouldn't pick Flutter for business apps with loads of text editing, but it feels perfect for social game-ish apps, like QuizUp or Duolingo.
- In my experience (German freelancing market), the typical native app developer does not care about the user experience anymore. Ever since RxJava and Swift have hit the scene, the focus has moved from impressing the user, to one-upping your coworkers with exotic language features and avant-garde architecture patterns.
Dart is a dumb language like Go, and I think that's exactly what's needed to bring UX back into the spotlight.
I'm a native app developer too (iOS and Android) and I've got some experience with Flutter.
I agree with most of your comment, but the only thing I'd add is that from what I've seen if your concern is the quality of apps then Flutter definitely is not where you'll go to find that. If anything, Flutter developers seem to care even less about the end-user experience and instead simply focus on their own productivity. The end results are often horrible with a ton of jank, UI weirdness, etc.
> but UIKit doesn't even have a standard button class
Doesn't anyone else use UIButton? Granted, the native iOS app I developed was intended primarily for blind people, so I didn't really make it visually polished.
Yes, the visual polish is what I mean. It's not rocket science to style UIButton, but the lack of a good default style means that mediocre native apps often have weird/inconsistent highlighted button states, and so on.
And because it's built in, unlike the bolted-on Rx framework family, it doesn't bother me much. I found the language to be much more focused and pragmatic than Swift, but as I said that was just my experience after a single project.
I am, and I agree, native toolchains can be better but that is expected, they have a lot more resources dedicated to their development. I also am responsible for an app built using flutter, it's been on production for almost two years with a very good rating in the app stores and over a hundred thousand users, isn't that what matters? that the technology enables you to solve problems? Flutter did that for us, keep happily working on Xcode if that works for you, for our startup this announcement is great news.
If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.
I've been in that situation 3 times, I choose React Native and Flutter each once. I was forced to use Ionic. I would NEVER use Ionic again, terrible experience and very difficult to get decent quality/performance. I like Flutter's technology much more. I like that it is natively compiled. I dislike that it has it's own UI toolkit. React Native with TypeScript is a highly productive environment but I LOATHED the developer experience and any code that had performance goals was way harder to be successful with, not impossible but the threading model that RN imposes (it doesn't really thread at all) was hard to make the UI snappy and crisp as it should be. I've played with Xamarin also since I was a .net dev for 10+ years (I'm old in the industry 25 years now) and the developer experience was actually pretty good but the compile times and the UI performance were not. Though that was not a production level app and I might have been able to make it work.
tldr; If I HAD to do cross platform I'd use the following logic to choice one:
If I have a team of react JS/TS devs: React Native
else if I have a .net team: Xaramin
else: Flutter
Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)
Sorry to hear you had a bad experience with Ionic. The stack has improved considerably in recent years and actually Capacitor, our replacement for Cordova, was just rated the highest satisfaction mobile tool on the latest State of JS survey. Cordova was definitely a sore spot for Us but we’ve since moved beyond that and you can use any web stack to build apps with Capacitor (seeing a lot of React + Next.js apps of late)
This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).
However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).
I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.
I look forward to being able to share publicly (once I decide which license to use).
If if a CRUD frontend for data, just go with mobile Web.
If doing games, Unity.
If I require some native access, Xamarin.
Finally, using C++ in a MVVM approach with native Views for anything else.
Those answers are for personal projects, at work we just do mobile Web, and with Chrome and Chrome Edge teams pushing the agenda of Web APIs =~ ChromeOS, we get to do most of the stuff we care about.
If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.
What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base?
We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.
We made this choice at Rdio back in like 2012. Our mobile apps were written almost entirely in C#, shipping on iOS, Android, and even Windows Phone 7/8. About 70% of the code was identical on all platforms, even the super-hairy audio bits. Contrary to the prevailing notions at the time, our app had native levels of quality and performance. We could roll out a new feature an all platforms in only a little more time that it would have taken to do it for one.
That agility didn't come for free, however - we gained speed, but also traded routine bugs for exotic ones. In addition to simple null-pointer errors and the like, we got to spend two weeks digging into the Mono runtime to find a locking bug that drained users' batteries. We had our own sqlite wrapper because the built-in ones on Android and iOS had too many incompatibilities. We had our own red-black tree, for some godawful reason. We had a standing weekly call with our Xamarin reps to discuss toolchain bugs.
Ultimately, the pain ended up outweighing the savings of sharing code. At the time Rdio went bankrupt, we had substantially rewritten the apps in Java and Obj-C. RIP.
I was with a team that went the React Native route. At first it was fine until we had to go slightly off the rails.. and I was rebuilding .so files based off random gists and updating linkage assemblies.
React Native works until it doesn't and then you are getting into very detailed platform specific territory.
A lot of the cross platform promises were untrue - we quickly learned the importance of QAing both builds and frequently had platform specific patches.
I have had the exact same experience. I’m not a big fan of React or React Native, but I can see that it does increase code reuse; but...
As you say, platform-specific glitches will always crop up so you’ll always need a bit of native work. If you’ve thinned out native development team this can make things hard. Instead of a team of 5 or 10 native developers working on bread-and-butter UI stuff, you only have enough work for 1 or 2, but it’s all grungy stuff like talking to low-level frameworks and working around platform bugs (or React Native bugs, of which there are plenty). That’s not a recipe for clean and maintainable code.
A related issue is that React and React Native aren’t 100% compatible. You can’t just move existing React code directly over as you might elect. It is possible to write code that works on both, but it isn’t trivial.
QA definitely needs to be done separately on each platform.
I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves.
Some examples from the top of my head:
- various performance issues (e.g.: memory leaks which haven't been fixed for years [1])
- their push/pop router navigation seems like a really bad idea
- worse developer experience than using Angular directly (e.g.: last time I checked this, the save/compile/reload cycle of an Ionic project was an order of magnitude slower than the same project without Ionic)
This heavily depends on the framework you choose to use, and modern Ionic uses the stock tooling your framework does, so build times should be on par with any other project of that framework type. Earlier versions of Ionic had custom tooling and much slower build times.
This was happening in an Ionic 4 project which was already using the stock tooling of the framework (Angular CLI). But I remember it being worse in Ionic 3 with its custom tooling, so overall things do seem to be improving with time.
My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue [1]. Just importing the IonicModule in a new Angular project (without actually using any Ionic component) made the dev server build times jump from around 200 ms to a couple of seconds. And the situation only seemed to get worse as more Ionic features were being added to the app.
Just to make it clear, I understand that this is an open-source project and I don't expect anyone to fix my issues. And I'm also very grateful to you and the Ionic team for giving us Capacitor which is such a big improvement from Cordova.
So I don't like being all negative in here. But I did encounter a fair share of issues with Ionic and I'm only sharing my experience here as just another data-point in case it helps someone make a well-informed decision.
And I have to say, the overwhelmingly positive reaction to Ionic in general did make me question my own abilities several times. Maybe I just don't "get it". I still haven't ruled that out as a possibility.
Thanks for the info. I do think the choice of Angular here is significant. Angular builds have historically been very heavy. Later versions have sped things up and Ionic apps have gained from that. I haven’t seen slow builds in React, for example.
-the push/pop router navigation is insane, it by default keeps all views in memory all the time for react it will reload every view with any state change by default.
I have seen this a lot. Most of those people are Web Developers. They want their Web technology to move towards cross platform native apps. And are frustrated with people bashing or stopping this progress.
On the other hand you have Native Apps developers, while equally being excited about Cross Platform UI and toolset have been burned more than enough. And this didn't even start with Smartphone. It goes back to earlier PC history with Java or even further. None of them were good enough.
At the same time Native Apps developers dont understand why Web Dev or those who has Web Dev background now working on cross platform toolchain constantly push and produce the same thing years after years.
As a native Android developer (who is also doing Flutter atm) I look at compose as a seismic shift in the Android space. Flutter wont be able to compete
History has shown us over and over again, always bet on the web. Sure you might not like JS as a language, you might find CSS confusing and full of warts, etc. but it's here and will be here 20, 50, and 100 years from now. We're not going to just sit up and throw away 25+ years of progress and history on the web overnight. Tech like java applets, flash, silverlight, etc. come and go like fads. Who knows if Google will even care about flutter in 5 years, let alone 25 years. A page that Tim Berners-Lee wrote 25+ years ago renders just fine in a browser today.
I guess I would like to think we are betting on the web. :) All of the Flutter founders came from Web backgrounds. After years of attempting to make the Mobile web awesome, we forked Chrome and built a new thing. Now we're bringing it back to the Web.
The web is a big tent. I think there is a lot of room for innovation here. We're attempting with Flutter to push on some of the newer aspects of the Web. There are still some pieces missing from the Web to make things like Flutter really shine (e.g. a multi-line text measurement API could help get rid of a ton of code in Flutter Web). As you saw in the keyonte today, we're working with Chrome to continue to improve life for developers.
I don't think Flutter will ever be the right solution for all of the Web. Certainly not today. For example, we don't even support SEO or great indexability yet (although it's long been planned for and will be coming soon).
I just want to believe we can do better. We, developers, can all push development (including the web) to be better. Hopefully Flutter will do it's part.
Read somewhere flutter canvas rendering was only a first « quick n dirty » way of rendering something on the web, but a true DOM renderer was the end goal.
Can you give more info on that ?
Another question i’ve always had about flutter : last time i explained how this tech looked promising, a friend asked me about performance. I said « they said it’s really good and smooth ». But then we tried the iOS demo app (something very basic about vegetables) from the app store, and the scrolling performance was a total disaster (on an iphone x).
Do you have an explanation for the discrepancy between the official ad one can read on google blogs, and the real-world experience of app developped with flutter ?
People want native apps for some domains. On my phone, I typically want the opposite. Every company has to have its own app, and it’s annoying. I do want Flux, because that functionality can’t be done without an app. I don’t want a terminal in my browser because that would be ridiculous.
> I don’t want a terminal in my browser because that would be ridiculous.
Secure Shell[1] is actually my go-to terminal for daily use, and supports some features that are important to me (e.g. OSC 52 codes) that GNOME Terminal doesn’t.
I would argue that people want a certain quality experience. They don't care about whether the developer used Swift or Javascript or OCaml to deliver it.
The Web does usually deliver a certain baseline experience, and most platforms actually deliver a browser which mostly matches platform experience.
For native apps, there is a wide variety of things which you may or may not be able to do based on what the developers implemented and whatever their chosen toolkit supports - including toolkits which reimplement their own drawing, widget and event systems and does not support accessibility or even consistent copy/paste.
For web apps, you do have to somewhat actively have to break this stuff as a developer.
The same engine of HTML + JS has powered entire businesses and industries from $0 to billions and billions of dollars over 25 years. Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web. I would say there's zero danger of the web going away when folks like that (and many, many more... Google, Facebook, etc.) depend on the web for every microsecond of their existence.
>Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web.
Except 70% of e-commerce, 90%+ of Social Media are now on Mobile Apps, where they were all previously 100% Web.
The problem with Tech industry is that too much thinking is about centralised, decentralised, Technology with backend front end. etc. When its users or customers dont give a fuss at all.
That's because the current mobile platforms were engineered from the ground up specifically to kill the web in favour of walled garden app stores.
We'll have to see how long this approach will stand up for, both legally and technically. With real open source phones and antitrust developments we might see a revival of mobile web eventually.
Even in the extreme unlikely case of opening up Apps without App Store. People will still be using apps. Even if they are Web Apps or Apps with WebView. It will still be Apps. Simply because accessing a button is easier than typing in a link.
How is a home screen app icon different from a tab in your browser, if it leads to what is essentially a web app? I count such apps as a success wrt "betting on the web".
Sadly, the capabilities of PWAs are very much second class on every mobile platform right now. But I don't think it will stay that way forever.
Clubhouse is targeting the middle-class silicon valley market right now (quite literally, those are the only people who got invites early on), who of course are infatuated with apps and have the money for fancy phones, tablets, etc. It's smart marketing for them to go where their customers are right now.
The web is for everyone--I can go to an internet cafe in a slum and browse and buy from the same Amazon.com as I can from inside a $15M mansion. It's a quantum leap in access to the world using the web.
Not sure what personal income has to do with anything. Hand held touch devices have revolutionized Internet access. The deeper down the income scale you go, the less likely you are to encounter a personal computer while you’ll still likely encounter a smart phone. Amazon will work on the web or as an app on that phone, but with the app the user experience will be better. That may be because Google and Apple have intentionally prioritized native APIs while hindering PWAs, but that’s still the case.
Anyway, I do still wonder: if FAANG had to pick between native and web apps, which do you think would they pick?
Microsoft would try to make everyone happy by creating 200 different GUI tool-kits that do similar things on different platforms but with each one having slightly different syntax but giving you the capability of using different languages. If they targeted languages they don't own, they would extend the languages with Microsoft specific keywords!
They can collect more metrics and have more control when it's a native app. My web browser is still my most used app on my phone.
But I think betting on the web actually meant to bet on native for each respective platform. Bet on native for the web is betting on HTML/CSS/JavaScript. And then have a Java/Kotlin version for Android. And have a Swift/Objective C version for iOS
I think the learning is, write once run everywhere is what has been tried and failed time and time again for user applications. Java failed many times, Silverlight, Flash, etc.
The reason is always the same, user experience is limited when you go that route, and it eventually loses out to competitors who offer the better user experience on the user's platform of choice.
Or maybe because native apps are a better experience, nearly every time. True multi-threading, native code performance, latest UI implementation, more and better hardware access/performance, etc.... I can keep going but the point is that the web really is the lowest common denominator. That isn't bad but it also isn't how you build the best experience.
If OS vendors wanted web-apps to succeed, they could have done a lot more than they have done so far. E.g. better integration, or improved web standards to optimize for certain cases.
No matter how "better you integrate", there's one big core issue: the DOM. You simply cannot make the DOM behave as smoothly an as reliably as a native app. And no, no amount of "improved web standards" can help with that.
The DOM is just a kind of retained mode graphics, which can be fast depending on implementation. Also the DOM in most browsers is already sufficiently fast for many applications. It will never be as fast as native, but if you think that it needs to be then you are missing the point.
> The DOM is just a kind of retained mode graphics, which can be fast depending on implementation.
It's not, and can't be. There's literally no implementation of DOM that can be fast. There's literally no conceivable implementation of the current Web that can do, for example, fast animation on a list of elements without horrible hacks (like cloning elements, taking them out of the layout, hiding the original elements and then animating the new elements).
> It will never be as fast as native, but if you think that it needs to be then you are missing the point.
And what point would that be in the context of "If OS vendors wanted web-apps to succeed, they could have done a lot more"?
I generally agree with you, but I don’t think it’s unequivocally true. Facebook bet on the web/HTML5 for their iOS app, and Zuckerberg later referred to it as the company’s biggest mistake.
I just visited flutterfolio.com. The very first thing I tried to do is enter a username and Tab to the password field. But Tab just catapulted my input focus to the browser address bar. I mean, come on.
The accessibility is a bigger concern, but flutterfolio.com also
A) lags on my work machine when tabbing through fields
B) doesn't handle HDPI screens well (the entire interface looks blurry)
C) keeps fields visually indicated as selected even when I click outside of the browser (if I start typing, is it going to go into the field or not?)
D) has a separate touch mode? Touch doesn't just work?
Looked up another of their sample apps:
A) doesn't respect my OS scroll direction
B) lags on scroll
C) mousing over any of the buttons has a 0.5 second delay before my cursor turns into a hand icon.
And all of these sample apps take about a second to fully load for me, despite the fact that most of them aren't doing anything complicated.
The "we can rebuild the browser in Canvas" idea is alive and well in GUI toolkits, but I have never seen an implementation that didn't have these kinds of basic problems. How many UI toolkits do we need to see that can't figure out how to do scrolling before we acknowledge that having one team try to independently reimplement decades of work on the web might just be a bad idea?
I really appreciate the feedback. We clearly have more work to do on the Web side of Flutter. Unlike the Mobile side which has shipped 100,000s of apps, the Web side may be up to like 1000. :) So many more issues to address as we work closely with more users to get their apps into production.
If you'd like to track progress on any of these, I'd encourage you (or anyone else reading) to please file issues at flutter.dev/support. We read (and try to address) each and every one which comes in via Github.
The CanvasKit renderer[1] is highly concerning to the general health of the web. It's nice that it's easy for developers, but it remove all the power of the web.
To an end user, their accessibiliy tools, & user extensions, the page might as well be VNC'ed in to some system. Everything is opaque. There's no HTML elements.
I can not state strongly enough how immoral & unethical this path is. Bending the web to the developers will & breaking all the contracts of what a web page is a grevious act, is enormously harmful. This is one of the worst possible things that could happen to the web. Please for god sake don't do this to us. Don't injure the web like this.
This will be raised again and again and again until the ends of time as an incredible black mark on the name of Flutter.
Edit: constructive feedback welcome. Whether it's me or others, folks pointing out this peril often find themselves hit by downvotes as I do now. This seems like an existential challenge for the web, to keep humans able to be in the loop when browsing the internet. We would all love if you would defend or explain or have something to offer in your critiques about this crisis.
I appreciate that building something that works even this well targeting Canvas must have been a metric ton of work, and I'm impressed. But that's kind of the issue -- it cannot possibly be more work to maintain a separate rendering/compilation pipeline for browsers than it is to rebuild the entirety of Chrome's DOM engine in WebGL for CanvasKit.
I just don't see how Flutter is going to keep pace with "native" web apps when the team is constantly playing catch up every time a new medium, input method, or browser feature comes up.
Handling scroll is hard enough, is this going to handle WebVR? Can I control this web app with a voice assistant?
Sorry if this is something of a dismissive answer, but I'm not sure what the right way is to file an issue that boils down to, "it seems like you picked literally the hardest possible way to build a web GUI toolkit, and I'm very impressed that you have anything that's usable at all, but I also don't understand why you did this."
I don't know, I don't want to be overly negative here, but I don't have any confidence at all about the overall strategy that Flutter is pursuing. In order to get accessibility to work, you're basically going to end up building a DOM representation of these apps anyway. It's just now you have to build a DOM representation and you have to completely reimplement the rendering stack and capture all of my events? How are you going to make something like that performant across every browser?
I want to echo a few other comments I've seen here that this result isn't really surprising to me. I guessed before I clicked on the demos that they probably wouldn't handle scroll events well, because I know how you're building Flutter for the web, and I have never seen any GUI frameworks targeting pure Canvas on the web that don't have basic errors like this. If Flutter ever managed to be the exception, that would be very surprising to me. I don't know what Flutter's internal process looks like, I'm not going to tell you you're building something wrong. I only know what the end result looks like, and I know that end result is not going to radically improve any time soon.
It's not my place to tell any team what to do, and nobody is obligated to care what I think, but... I don't know, the demos online do not leave me feeling confident about Flutter's future. I don't think the experience as it exists today is the result of a bunch of isolated issues/bugs that can be fixed one at a time.
Its nice to have absolute control of the rendering going over canvas if you are a flutter platform developer and i think even playing the catch-up game they should get there eventually.
But i don't think this is the real issue here.. Flutter is more of a Flash and GWT lineage, and that's fine if that's what you are looking for.
But i bet on the Web every time, its the most popular UI (and now much more) platform ever. So while some will go through the Flutter and React way of doing things, most will just stick with the web.
The web is the most sophisticated platform ever built. It gives you a lot of power and freedom, so i don't understand why some prefer to get stuck into a cubicle when you have so much space?
Its nice to have frameworks to make things easy and developers more productive, but the ones that do this without alienating the developer from the bigger, broad and sophisticated framework are just better.
Just let them be the new Flash, now at least open and over the web, and look for other approaches if you want to maintain real control and freedom, instead of delegating to the platform developers.
The price of infinite freedom in UI toolkits is that you get nothing for free. This has consistently been untenable: you quickly get stuck in the weeds reimplementing basic behaviors.
Supporting new and unique APIs/inputs/etc like WebVR is a pretty classic cross-platform problem and it's usually addressed by allowing native hooks. Flutter has MethodChannels which let you call native methods in the underlying "platform host". It also supports "PlatformViews" which let you embed native widgets.
It doesn't really need to have instant parity with "native" web apps at everything. Maybe Flutter is a poor fit if you have extensive native requirements. That's okay.
It's not just about building special experiences. I want to be able to browse normal websites in VR -- VR and uncommon user agents introduce a new set of user inputs that Flutter will need to handle if it doesn't want its websites to just break if someone loads them up in a headset.
Currently as a web dev, if I want my website to be usable by a voice assistant, I don't have to do anything. If I want my website to be usable in VR, I don't have to think about it -- that's Chrome's problem, not mine, I just expose the exact same controls I've always used. If someone is building a user agent that interacts with my site in a novel way, as long as I've built my site well everything just kind of works, because of how the web is architectured.
But if you're rebuilding all of the controls from scratch, suddenly you can't think that way anymore. You have to think about the controls and gestures that every medium exposes, or else you have a website that just randomly breaks depending on what OS/platform a user accesses it from.
> and it's usually addressed by allowing native hooks
Not on the web though. I mean, for obvious reasons on the web we can't just expose native OS methods for websites to call. Flutter doesn't have a choice on that front, Google, Mozilla, and Apple realistically aren't going to break browser sandboxing just so the devs have an easier time.
It's true of course that as a cross-platform toolkit independently built on top of another platform, Flutter will have to consider new controls, gestures, and changes in many platforms. You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. There's been far more handwringing over the web's deficiencies as compared to native OS platforms; why reinvent the wheel with some crappy dynamic language called JS, why rebuild everything with a custom style language and layout engine? Yet Electron and web apps continue to dominate because the trade-offs can still be worth it.
The web is not really adopting hordes of new input modes like WebXR every year, there'll be plenty of time for Flutter to consider new stuff like that before it approaches relevancy in mainstream product development. Accessibility features like voice assistant support don't necessarily come free either. Rich web applications usually don't produce simple/accessible DOM structures even if you're developing with web-native tooling. Flutter or not, accessibility practically always requires some level of manual annotation in web apps, which is Flutter's primary use case.
> Not on the web though. I mean, for obvious reasons on the web we can't just expose native OS methods for websites to call.
I meant native-to-the-web. Flutter's MethodChannels & plugin system works on the web too. If there are browser APIs that you need to use, you can setup hooks to call them from within Flutter.
> You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable.
The difference is that the web efforts aren't being headed by one team in one company, they're a giant effort with a huge amount of funding, shared resources, and attention from multiple companies and communities.
Flutter doesn't have that benefit. It's not that nobody could build a cross-platform replacement for the web, it's that the web was hard to build, and it's very unlikely the Flutter devs are going to be able to repeat that effort on their own.
> Yet Electron and web apps continue to dominate
Largely because Electron piggybacks on existing work by embedding the entire Chromium engine, they're not building an entirely new render engine from scratch. And Electron still struggles trying to keep pace with native systems, even though it's largely just hooking into them instead of rewriting them.
> Accessibility features like voice assistant support don't necessarily come free either. Rich web applications usually don't produce simple/accessible DOM structures even if you're developing with web-native tooling.
The web gives you a lot for free though. It's sort of like comparing OpenGL and Qt. Sure, both require me to be thoughtful as a developer, but one requires me to be a lot more thoughtful.
----
The bigger problem here isn't whether application devs need to think about accessibility, it's for the Flutter dev team. It's that the web doesn't expose the kind of accessibility APIs that a pure Canvas UI needs to recreate all of the accessibility and screenreader support that's built into browsers. Qt on the web has run into the same problem. What you end up doing (because it's the only interface you have to work with) is either trying to on-the-fly maintain part of the DOM and working really hard to figure out which parts need to be maintained, or just flat-out adding a second, hidden DOM tree that screenreaders can interact with. The only way that Flutter can tell a screenreader that a piece of text exists is by making a node and putting it into the DOM.
This is, from what I can see, what Flutter does in its forms. It has a DOM representation of all of the input elements (but interestingly enough not the links or other text, so they're not screenreader accessible at all), and then completely separately, it re-implements the entire browser rendering stack. And the performance is... well, you can see the performance.
Flutter's strategy for handling events to those elements appears to be (for lack of a better term) inverted. It's "Render first, worry about the DOM second", which is not the way that I would try to build something like this. I don't want to read too much into it, maybe I'm misunderstanding their architecture, but the tab errors that people are seeing look to me like they exist because Flutter is trying to poorly reimplement how browsers tab, rather than using an underlying DOM model that could for free signal to them what the currently selected element is. Similarly a lot of the input selection and mouse lag is because it looks like they're doing collision detection in WASM and performing a DOM mutation every time they need to change the mouse cursor into a different shape. Which, yeah, of course that's not performant.
Ideally, a framework like this would target the DOM directly in the first place and use that to drive input, accessibility, and styling wherever possible, adding canvases back in only when necessary to override specific parts of rendering. That's the path that frameworks like Blazer and OpenSilver are trying to go down, which is just a lot more realistic of a goal for an individual team to accomplish.
I'm trying to thread a fine line here, because I haven't read Flutter's source code, so I don't know for certain how they're doing everything or why. I don't want to confidently say they're doing something wrong if I don't have the full picture. But I can see the outcome, which is currently pretty bad, and I can see little bits and pieces of the architecture they're using to get that outcome, which all seem very counterintuitive, overly-complicated, and buggy. I'm happy to be proven wrong in the future, but in the present there's a nearly half-second delay to change my mouse cursor when I hover over an input and none of the links in-app are screenreader accessible, so that's not exactly inspiring optimism. Sure, Flutter could theoretically overcome everything and keep pace with the web, but is that what's currently happening? They're announcing v2 and the web version is basically unusable.
I can't say that matches my generally nice experience with the demos on desktop, although mobile scrolling was pretty bad.
As you mention yourself, Flutter Web already implements some things using the DOM and is clearly capable of doing so, it's just a matter of degree. I can believe that Flutter would benefit a lot from using the DOM more, but that could change any time by some Flutter contributor saying "hm the custom tab ordering impl doesn't work too well, let's render a DOM tree for tabs" or something similar for ARIA attributes, text inputs, etc. It's hardly a fatal or intractable issue with the architecture.
Many of these complaints are real issues that Flutter should tackle but they feel pretty overblown. There's a general tenor that jumps from "there are still many issues" to "what's even the point of Flutter Web if it can't get everything right". Flutter Web has to start somewhere and good desktop browser support (which is hardly unusable) is good enough for many real use cases. I don't think anyone is selling it as a mature second iteration which seems like a misunderstanding of the v2 semantic version which applies to the core framework, not Flutter Web that just left beta. If there's any org I trust to do the difficult work of cross-platform support, it's Google which already provides the lion's share of funding, standards design and implementation development to the web. IIRC Flutter's dev team also has Chrome engineers on it. I expect it to attract the attention of more orgs as it matures and hopefully becomes more popular, the core framework has already received open source contributions from Microsoft and Canonical.
> they're not building an entirely new render engine from scratch
The web platform builds an entirely new render engine from scratch. Native OS platforms give you a lot for free too and you see the exact same complaints about the web's independent behavior proven irrelevant again and again as the web/Electron continue to demonstrate incredible value despite reinventing many wheels.
Well, no, I'm claiming that it is a matter of approach, not just degree. There are two ways you can go about syncing the DOM to your rendering. Tabbing is a good example of that:
A) you can build a DOM tree, listen to a focusin event, and then when an input/link element gets focus, you can update your Canvas to match the state of the DOM. This means that you listen to one event and (with some exceptions) your rendering engine mostly just has to worry about rendering. Or
B) you can build a Canvas, reimplement tabbing, mouse selection, touch events, and everything else... and then when your new implementation decides that focus is changing, you can update the DOM to match your Canvas. In short, you can choose to have the Canvas drive the DOM, rather than having the DOM drive the Canvas.
What I'm arguing is that approach B, which Flutter seems to be using, is fundamentally much, much harder, buggier, and less performant than approach A -- and my evidence for that is that GUI frameworks surrounding Rust, Silverlight, and C# that are following similar approaches to A are almost all much more mature than Flutter is, despite having fewer corporate resources devoted to them. I'm arguing that path B is an high-level architectural decision that is not going to yield performant, high-quality results.
> The web platform builds an entirely new render engine from scratch.
Right, but again, the web platform at this point has spent over 20 years doing that, and for the majority of that time it would not have been realistic to build a project like Electron. A lot of this seems to come down to, "is the Flutter team big enough to handle this". I don't think they are, but maybe I'm wrong.
I mean, we can debate this endlessly, or next year Flutter v3 can start releasing demos that can handle smooth scrolling and don't lag in Firefox. My prediction is that Flutter is not going to turn into a performant, good quality target for the web any time within the next couple of years. But again, maybe I'm wrong, and luckily it will be very easy to verify if I am. I'll check back in January 2022 and see if anything has changed.
It's disappointing the Flutter team members haven't addressed this justifiable concern about their big-picture strategy. I would really like to hear what they have to say on this.
On mobile, you can hook to low level native input events.
On a web browser, <input> is all you have and because of the abstraction you cannot build it from the scratch using lower events. Think iPhone text selection.
Flutter on web may cater a specific category of graphical intensive apps, but not all apps because <canvas>. It will fall to the same uncanny valley where Java applets where back in 00s.
Multiple countries around the world have legal standards around accessibility. Then you have the ethical, DE&I, and business reasons to enable disabled users equal access to the web platform and apps through screen readers and other assistive technologies, i.e., accessibility.
It’s certainly not a uniquely American concern.
I assume that you just haven't run into this specific term before, but if that's not the case then comments like these are why the web community overall should oppose web technologies that leave accessibility decisions solely up to end developers or that don't make accessible options the default.
The web works as well as it does because (in general) it's accessible by default. There are lots of open problems on the web regarding accessibility, but we should be moving towards being more accessible by default, not less -- because if we want a universally accessible app platform, developers and corporations can not be trusted to make these decisions on their own, and laws will only affect specific industries and countries.
That's part of why Flutter devs talking about dev decisions that can increase accessibility ring kind of hollow to me. Accessibility has to be something that's pushed at a technological and cultural level if we want the web to be a platform that leads the way forward on these issues.
Currently I'm counting four or maybe five different HN users in this thread indicating this affiliation. I appreciate this open look into the organization. We're probably getting a more honest idea about what really goes into the sausage. Still, your PM might be less happy about this thread...
I happen to be on a 1.5 Mbps connection at the moment, and "about a second" sounds wonderful. The demo apps I opened took closer to 30-60 seconds to load.
Strange how I don't see many of your issues on my side.
(parent issue) Tab tabs through text fields only.
A) No lag on my laptop
B) Zooming to 400% reveals pure vectors for text as well as control decorations, even the fingerprint icon. Only the logo becomes pixelated but that one could of course simply be an SVG instead and not Flutter's problem.
C) Yes, this is a common issue with web apps. One often needs to look at web browser focus. I'm unsure if an event is even sent to the page as the page itself loses focus.
D) I think it does and this is just a tech demo for adaptive interfaces if you want them.
Could be the browser/platform you're using? I'm not sure. I've seen some reports here that the demos work better in Chrome, but that's not exactly a point in Flutter's favor; this is supposed to be a cross-platform toolkit after all. Regardless, odd.
A) I'm on Firefox on a Mac Book Pro. My feeling is that should be able to handle a login form, but I mildly suspect that Flutter's dev team is not testing on Firefox at all.
B) Here's what I see when zoomed to 400%. No vectors anywhere, not even for text: https://i.imgur.com/7QFC40v.png Nothing that I see on the page is being handled as an SVG. Very strange to me that you're seeing vector graphics, as that would imply that the form isn't being rendered onto a Canvas for you?
C) This shouldn't be a problem with web apps that use :focus/:active CSS selectors. I understand if a from-scratch webapp doesn't handle focus loss, but I would expect any GUI toolkit to be able to.
D) On the web touch already for the most part just works. There's nothing on this login page that should require a separate interface. I think it's a problem if Flutter only provides adaptive interfaces "if you want them"; in a good GUI framework you should be getting the stuff that the web already handles for free regardless of whether or not you "opt in" to having your site work on an iPad.
I think you're missing the point of touch mode: mouse and touch actually work fine in both modes. The touch mode is just there to demonstrate how Flutter adapts the layout depending on the target modality: see how the controls get larger when you select touch mode.
The Medium post[1] about Web support explains some adaptations they made for Desktop browser, including:
We also increased the default content density, because mouse pointers support a tighter density than touch devices.
I expect that in a "real" app the default mode is adapted automatically based on the device type.
B.2) I bet that it doesn’t respect a wheel multiplier either. It is 3 down keys by default, but I set it to 6 (7 at summer). Even VSCode annoyingly does not, but at least it has its own setting for that, which still only affects text buffers and not everything else.
I know I do almost nothing on HN but complain about accessibility, but it's really important to me because, well, that's how I uze my tech. And so far, sadly, Flutter hasn't impressed either with its previous versions. Edit boxes in particular were a major pain point, and things like you're describing were also less than optimal. I never knew where the focus was and what it was doing. With broken markup there was at least ways around it. But I'm scared of things that render on the canvas. Most browsers actually get this right and have support for these things that don't require ugly hacks if you use the DOM. And there is no real way to interface with assistive tech from JavaScript except through it. So you have to somehow still actually represent your apps UI in the Dom in some way.
To be fair there were some flash sites I’ve still never seen anything that equals. I think the way flash marketed to more designers and content creators was both what made it awesome and maybe its downfall.
It is the same. But at least runtime, WebAssembly and canvas are open source and natively integrated to the browser. Less security holes, but the same UI integration problems.
Yup, that happened to me. Then I clicked again and tab worked correctly.
It will be hard to overlook little details like this -- and there will be a million tiny details like this -- when decades of browser development have led us to expect a DOM experience that Just Works for UX like that.
If your situation is like mine, you have to wait for some
fifteen seconds or so. And then greeted with a login input.
Also, my CPUs were at around 50 % the whole time.
I'm sorry, but if that's the “future of web UIs”, I'd rather
stay with the “troglodytes”, who write simple HTML forms
with a bit of vanilla scripting here and there.
> couples it with a very beautiful SDK and component framework
I would not call the flutter SDK and component framework "beautiful" nor would I ever add the adjective "very". I have actually found it to be very verbose compared to alternatives I've used in the past. In some ways I suggest it is over engineered.
> offers a far better programming language than js could ever be
Dart is a bit of an odd duck language to me. I think of interesting ideas like the cascade notation (using .. to do sequences of operations on the same object).
Perhaps it is due to having worked a lot in Typescript and having my brain molded to code that fits that shape but Dart feels clunky in comparison. I can't put my finger on why, but defining and instantiating classes feels so heavy compared to the functional type code most Typescript seems to become. In Dart, I just feel like I'm creating massively indented component definitions with tons of properties and nested classes. Maybe I'm just finally accepting OOP and deep type hierarchies are things I want to leave to my past. I feel I can do 99% of what those things did with Algebraic types and functional composition. Nowadays I prefer that style and going back to heavy OOP feels bad.
With the dominance of classes, massive type hierarchies and quirky syntax - I'd just prefer to be working with a more react-ish framework in a language like Typescript. My feeling is Dart is a step in the wrong direction.
How many times has Google done this? And then gotten bored of their own work?
JavaScript, with all its many many warts, is widely supported, incredibly popular, and not going anywhere.
I'm not about to waste my limited weekend time learning Flutter 2, knowing it's going to be in the trash bin by 2023. I'd rather suffer through some more JS warts and get better at avoiding them.
> How many times has Google done this? And then gotten bored of their own work?
Google's history on this sort of thing isn't good but this will be much more stable than their other offerings. Dart is the primary language of the ads (i.e. money making) side of Google and Flutter is their best shot at making the language relevant elsewhere. I'm still not in a hurry to learn it but I'd be very surprised if it's in the trash bin within 5 years.
Extremely same feeling here. Ditching IE11 support is a total game-change for the web. ES module imports just work and you don't have to go down a complex bundler rabbit-hole. Template literals make constructing HTML inside JS components a breeze. And if you do reach for a bundler the modern ones like snowpack and vite make the experience incredible with instant hot module reload on change--the feedback loop for development is like nothing I've ever experienced.
The problem with JS is not the tooling per se but the constant "upgrades" for the tools that exist. Sure, this week's hot new thing is Vite, but by this time next year it will be out of date with some other thing we're all supposed to use. In projects from the last 10 years, I see Gulp, Grunt, Webpack, Browserify, and now Vite - all doing mostly the same thing in different ways, with different config files.
You don't have to use any tools, plain old HTML, CSS and javascript still work just like they did 25 years ago.
Tools come and go, they serve a purpose like writing code in a more futuristic style and compiling it down to a broader browser support base. There will always be a treadmill like that in any language. Look at how C++ has evolved from its 90's roots to more modern C++11, 14, and 17 styles--each change also required more work for the tooling, compilers, build systems, etc. to learn. It's just in the C++ world there are far less people working on tools than in the web world.
I’ve used quite a few. What are the popular scripting languages to compare with? Python, Ruby, PHP are probably the only real competitors (disregarding others like VB or Perl).
Functional programming is very difficult in those languages due to weird closures, bad lambdas, weird block/proc/lambda rules, etc. async from the ground up means that concurrency story is much better and allows lots of threading (with libuv or whatever low level library handling the difficult parts).
JS used to have less ergonomic syntax, but has benefited from adding it last, so it usually chooses the best version.
Stability of JS is much better. When the implementation is the spec, there are bound to be lots of little breakages. Asa result, there’s not much room for alternative implementations.
Tooling is far better than any other scripting language. Debugging and introspection tools are second to none in the category. All these other languages have broken compatibility so that old software won’t run on new versions. Webpack gets hate, but what other scripting language bundles its output? Babel gets hate, but if Python had something similar, the v2/3 switch would have been no big deal and all the “I can’t use that because REHL doesn’t support that version yet wouldn’t be an issue either. Likewise, minifiers reduce download size, improve performance by removing and simplifying parts of the code and improve parse time, but other scripting languages don’t bother.
Type support via typescript is miles ahead of the competition.
Finally, performance is one or even two orders of magnitude better compared to other scripting languages (luaJIT being a notable exception). In fact, modern JS JITs can come very close to the performance of Java or even C in many cases.
JavaScript isn’t the end all, be all of programming, but it’sa very solid choice with good reasons to like it.
Have you tried Elixir or any Scheme? If the scope is dynamic languages, both put JavaScript to shame with much more power, useful tools and far fewer non-sensical footguns.
If the scope is programming languages in general, since it was stated that JS isn't a "bad language" after all, then you can include a long, long list of type-safe languages that are much better for dealing with both its role in the browser and in the backend. Elm, Reason, F#, OCaml, Scala, Kotlin, Swift, Rust, Haskell, to name a few.
I necessarily confined myself to popular languages because of all the advantages that brings. If I could choose any language and magically have an awesome ecosystem, I'd definitely choose StandardML with my second choice being Scheme.
Most of the languages you mention are as fast or faster than JS. Most of them are also much more niche. Tooling for most of them is lacking. Others drag around a huge ball and chain in the form of the JVM or .NET (even the light versions are generally much bigger than v8).
Reason/ReScript seems mostly abandoned by Facebook at this point. Elm is very deliberately a one-man show (I don't like that bus factor). Ocaml compatibility and tooling seem easy then drop off a cliff in practice. Haskell is way too worried about math and the illusion of purity (and finding people willing to deal with it is very hard). Swift is Apple-only and doesn't actually bring much to the table (honestly, it seems like a rip-off of Dart with tuples and ref counting instead of a GC). Rust is much lower level and writing something in rust will take far longer than in JS.
Exactly - too often we see developers spending vast amounts of time on stuff that's "better" but by what metric? Often, it's better only by standards that matter to the developers, not the business paying the bills. In my experience, Flutter makes it very fast to ship a decent solution.
> Now, Google comes and creates a whole new UI toolkit from scratch
Worth remembering that this is not the first or even second attempt at this from Google. So I think people are fair when they are not just jumping along all happily as people have been burned before.
Syntax, semantics, code organization and best practices, libraries, frameworks, debugging and debuggers, IDE support (preferably multiple IDEs for multiple platforms), LSP support, linters, profilers, disassemblers, dependency license checkers, dependency vulnerability scanners, package managers, package repository with support for private repos and proxying/mirroring, should I go on and on and on?
Your toy app takes 2 days to create and then you (or worse, someone else) have to support the crummy Visual Basic/PHP/Javascript/Mongo/ColdFusion/insert easy to use crappy tech here, forever.
Not wanting to learn all those things for multiple languages is valid. But "it would take a while" doesn't tell you anything about whether a language is crappy.
The odds are pretty close to 50:50 that the language you already know is the crappier one.
My main point is that developers chase shiny things and "easy to use" is one of the shiniest things out there.
Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.
> Past a certain point, being usable in 2 clicks is a negative signal for overall tech quality. Most of the really solid techs need some extra configuration. The classic example of crappy tech is the DB tech that listens on 0.0.0.0 after installation, with no user + pass or admin/admin.
Yeah, but the post up there said 2-3 days. That's plenty of time to handle those important details that make a project non-instant.
To give context, the implementations for the same problem are completely different, e.g. javascript versions uses worker thrreads on 4 cores for most of the examples. To compare actual performance first similar approaches should be used.
Spectral norm is an interesting example because on single thread and without using SIMD, C, C++, Java, Javascript, Swift and Dart shows very similar performance characteristics (5-6 seconds). The loops are tight, there is not much to do for a decent compiler. it almost pure simple 64 bit floating point arithmetic.
Then you add multi-threading, and see a decent improvement, e.g. from 5 seconds to 1.5 seconds on 4 cores (almost all implementations show a similar gain)
And some languages with support for Vector operations further improves this to 0.7s
So this benchmark seems to be not very useful for comparing performance of any decent language. It could however be used for comparing improvements of using different techniques to solve the problem, or to showcase what new features brings to the table.
Of course it matters, What I am saying is that; here is a program written in language A, which uses all the tricks in the book to solve this particular problem, here is a another one written in language B, it uses a completely different technique / algorithm and isn't optimized to death. How is it valid to make a decision about performance if implementations and restrictions are wildly different?
So to me the site offers very little of value and
I can not take any comparison from there seriously.
And as I explained on a different comment, performance of many different language / compilers for this particular benchmark are almost same "If" they use the same technique ( C, C++, Java, Swift, Javascript and Dart.)
But the argument here started as "Hey look language A is faster than language B" , while pointing out completely different implementations, which is, absurd.
I think in the framework of choosing boring things, you are spot on. However, all innovation tends to be ten steps forward and eight steps back, so the way that I look at it is simple. For a given effort, are those two steps forward worth the total long term cost? Maybe, maybe not. Usually not, but... people are going to do silly things.
I look at flutter as a quick way to bootstrap a simple CRUD app, but... for what? How does it improve on the web? Not 100% sure, but I do like the down chain investments that flutter supports like Skia.
I'm a huge fan of canvas, but I recognize its limits for building apps. It's great for many things like games, and it is a 2D escape hatch. I'll admit that I get suckered into the lure of building a 2D canvas empire that is cross platform because it would be nice.
The fact is that even considering all those points, Flutter+Dart is still much easier to learn than Swift+iOS and Kotlin+Android (even separately). And I'm not even considering Desktop.
Sure, but you also get really powerful ecosystems with those languages. Which can't be said about Dart + Flutter, where most of those packages are amateur quality.
It's never about the language, most any language is easy to pick up. However picking up a whole new ecosystem with its associated dev tools, build tools, packaging, and different libraries is where the time consuming portion of new languages come in.
Exactly. When I scanned Dart's language spec, it looked just like any other C derived language. In terms of complexity, Flutter/Dart is no different than Android/Java. When I started writing Android apps, learning Java was the absolute easiest part of that process.
Yeah but it’s usefulness is really limited and just feels shoehorned into the project. Why couldn’t it have been Kotlin or TS? Something that mobile developers or web developers could jump into and keep a bunch of their existing tooling.
Flutter does not offer enough to justify tolerating such a terrible programming language*
Going from Kotlin, Swift or TypeScript (let alone more powerful languages) to Dart is like going back to the dark ages without something as basic as algebraic data types.
> It's not that good but it's gonna get there eventually, given the hype around wasm and <canvas> technologies
Is it though? Canvas is basically invisible for anything that doesn't have functioning eyeballs (which include not only screen readers, but also mundane things like your browser's ctrl+f functionality, google's crawler and siri). You know how people complain about some SPAs' back buttons and scrolling being terrible? I feel like this "next gen" tech is just gonna be more of the same excellent-in-some-aspect-but-completely-subpar-in-others stuff.
Can’t speak for others, but I still want a proper set of primitives and not yet another rightest-way-to-do-it sdk whose examples stutter on top hardware and will be great tomorrow. Time to go sleep I guess, will check it in 8 hours. All I want is untangling of the mess a css boxing model is, not just some buttons on canvas. I wrote gtk-flavoured widget drawing libs for few times in Lua+cairo ten years ago and these ran smoothly on a hardware than couldn’t even boot an OS today, except some rare stop the world gc issues Lua had back then. It was no big deal, and strange (not really) that Google Itself couldn’t beat that score.
The only thing I really dislike about it is the fact that in the end, it’s still just a layer on top of JavaScript, so you lose all types at runtime and stuff like object literals and classes are still not “complete” in my eyes. Otherwise it’s pretty good. I’d also like beter arrow syntax, something where you can properly write shorthand like in Scala for example.
Because Google is focused on language and tooling development, but forgot to create a killer app example with publicly available source code. Show us a minor Google property re-done in Flutter with code examples and people would flock to it.
> forgot to create a killer app example with publicly available source code. Show us a minor Google property re-done in Flutter with code examples and people would flock to it.
Can you think of a "minor Google property" that is open source?
Its a hard resource-intensive problem to dogfood your own OSS at a company as large and diverse as Google. But hard problems haven't stopped Google in the past.
What you're trying to create is the same spark in your users as PHP and React did to the web. The "oh wow I could do...." that while technically possible before the product existed, is completely re-framed by relatively minor improvements to the DX. You want to inspire an entire generation that may have passed on mobile and cross platform app development due to the verbosity and pitfalls of the iOS and Android ecosystems.
I think a killer app example is the ticket to do this. It may not be the only way, you could blow a huge marketing budget, you could convince another large tech company to do it, but doing it yourself is probably the quickest (or only way) to get it done.
> Now, Google comes and creates a whole new UI toolkit from scratch, couples it with a very beautiful SDK and component framework and offers a far better programming language than js could ever be but we're still nagging
All of these things, more or less, already exist in great variety in the JS ecosystem (angular, react, vue, redux, webpack, etc.). Many people have also already adopted other languages such as TypeScript, which is easier to learn for someone coming from JS, and superior to Dart imo.
We're nagging because the apps suck and stick out like a sore thumb. Maybe Flutter will be the one to get there and be the holy grail of cross platform UI development, but the developer community has been burned by this promise so many times, we're going to have to see the final product before getting excited.
Just because a project is ambitious doesn't mean we should all jump on board, particularly when similar projects have crashed and burned, and there's really nothing stand-out about Flutter that separates it from prior efforts.
I don't understand why more resources aren't being put into Qt and making that easier to use or building a more "web-developer-friendly" abstraction layer on top.
I don't know if they've changed their approach over the past year, but the last time I looked at Qt demos for the web, I was solidly unimpressed.
At the time, they were making almost all of the same mistakes that Flutter is, and the devs I talked to seemed to be of the opinion that those problems wouldn't be fixed until browsers started adding brand new capabilities specifically for them.
Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...
Halfway through playing with their pizza app, the page just froze and stopped responding to any clicks at all. Maybe those demos are outdated?
Blazor and Rust are showing a lot of promise here, but from what I know about Qt I'm much less optimistic, because Qt is used to handling everything about rendering itself -- and as Flutter is showing that's just not a good approach to building web GUI frameworks. But (again, purely from what I've seen) trying to layer on a system where Qt is actually interacting with the DOM seems like it would require a somewhat difficult shift in its architecture. Maybe I'm misunderstanding the problem though.
> Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...
I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.
At least you got the pizza demo to work at all. All I got was a large Qt logo with the message: Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))
For the moment the only useful usecase of qt for webassembly I found is: https://qmlonline.kde.org/ It's really useful to share some bits of QML but otherwise I wouldn't recommend using Qt for the web as much as I wouldn't recommend to use Flutter for the web.
I don't even fully understand why "cross-platform UI development" is such a holy grail. Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? Is it that hard to find developers who know more than one programming language? With a lot of these frameworks and higher level abstractions, if you go off the toy-app happy path, you end up fighting the framework and tools more than you're writing your app anyway.
> Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
I mean... yes? There is a ton of incidental complexity (i.e. unrelated to the business domain) involved in creating nice user experiences. If dev salaries weren’t so high then sure, more companies would probably spend the money to repeat the same work across several platforms, but right now? No way.
That said, I still think I agree that you give up more than you gain by going cross platform, at least for now, but I totally get how companies look at how much it’s costs to hire and says “you know what? I’ll take a cross-platform compromise”
Not to mention the LARGE realm of internal tools where you need something functional as conveniently as possible and aren't trying to drive a consumer-product-level market-differentiated experience.
It also takes time to ensure the feature is developed for all platforms. Due to low usage you may not bother developing for that platform. Thus feature in one platform lag other.
I worked for a company where we did iOS release after very 3 android release coz android was 80% users and iOS 20%. Mind you this was a cross platform Iconic/Cordova app. Now think if we did native. iOS users would have to wait even longer
Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.
Not only that, but corporations are not everything. What about one and two person shops? It would really be nice to be able to develop a product without first having to invent the universe.
Counterexample: banks started with shitty cross-platform UI type apps, but those received low customer satisfaction figures so most of them have now switched over to native apps. A similar thing happened with Facebook.
Users are not knowledgable enough to know what technology was used to build a product, but many have repeatedly complained about non-native UIs.
Heck, Lotus Notes went from being a market leader to an also-ran and user complaints about UX to corporate IT departments definitely played a role in convincing those departments in switching away.
More recently, this also happened with many mobile apps made with cross platform/HTML5 toolkits. They got low review scores and low user engagement across many firms, prompting a switch to native.
It’s not just a “small UI layer” — there’s an entire stack that goes with it. Want to build iOS apps? Can’t do it on Windows or Linux; you have to buy a Mac, run macOS, learn that whole stack, install Xcode, figure that whole thing out, learn how the App Store works, including all of its rules and regulations. But that’s not all—you also have to figure a CI pipeline for that whole thing too.
Rinse and repeat for every platform.
That’s what makes the web beautiful: you write the app once and it mostly runs everywhere. You have to figure out the infrastructure I described above once and you’re done.
Or at least that’s how it use to be before the major platform players realized how lucrative it is to charge developers App Store fees.
> Is it that expensive to separate your business logic from UI and write the small UI layer
Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic.
Ideally, I want to write it once that I want a row of buttons what colors they have and what function should be called when the user clicks on it.
I did what you describe and extracted all the logic in a small component I manage and the result was very banal, extremely straight forward code with was essentially "business logic". The 90% rest was building the UI based on it.
Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing the app N separate times. Major engineering savings AND each platform's build had its own UI idioms that users of those platforms were accustomed to. Guess I never realized this was a controversial approach to take!
And write your shared business logic in what language? If it's a C library perhaps you could do this on iOS and Android, but how is that going to run in a browser?
I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial.
That's why a lot of shops are writing the same logic N times in N languages and frameworks. It can actually be easier than having to target something these wildly different platforms share.
If your business logic is in C - well you are in luck! Use emscripten to compile this to WASM and you can use it in the browser. This approach is very much viable. Large scale commercial web-applications like Figma are written in C++.
Well, if “viable” means “doable but really fiddly”.
C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier).
C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself.
So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option. What other language are you going to use?
It’s kind of ridiculous, but that’s the way it is. Programming languages are all the same in principle, but in practice they don’t interoperate well and they can’t easily be used everywhere.
> and you have to do all the JNI marshaling yourself.
After 10 years of Android, while I understand the goal is to force developers not to write unsafe native code, Android team could have already provide better tooling.
However they have always behaved as the NDK was something they had to offer, not something they actually wanted us to use.
> but in practice they don’t interoperate well and they can’t easily be used everywhere.
...and yet, it's still much better than replicating the same code in different languages just to support different platforms.
The idea that a platform dictates the language to be used for creating applications on that platform has always been ridiculous, just because it was the status quo on the web for a bit over a decade doesn't mean it's a good idea that should be copied :/
I at least agree with this! It’s a big shame that the major mobile OS platforms bless only one or two languages for targeting their devices, and are at best neutral, at worst hostile to developing in other languages.
I'm not commenting on any other platforms, but I maintain a few C/WebAssembly libraries and they work exactly as expected without being unreasonably large. C-in-JS has been viable for a number of years now.
I realise it works, I just don’t think it’s really useful for what was asked for, a way to write common cross-platform business logic for a platform-specific UI.
Unless there are some great new tools I’m not aware of, C on WebAssembly seems about the same as C on Android. You can compile stuff just fine, and run it, but actually connecting it up to any substantial UI written in JS/Java is going to be incredibly tedious.
For a computation library with well-defined inputs and outputs, and that “just works” and doesn’t need any debugging in situ, it makes a lot of sense. But I think business logic by definition is going to need a much richer interaction with the UI, and that’s what makes it hard.
The interaction between C and Javascript offered by Emscripten is a lot better than JNI on Android. I wish the Android NDK would steal a few ideas from Emscripten, but all the Android teams at Google don't seem to be able to look outside the nice comfy bubble they've created for themselves.
With Emscripten, you can embed Javascript source code directly into the C code and then call the embedded JS function from the C side as well as C functions from inside Javascript.
In my case I usually debug the platform-agnostic code compiled natively in IDEs like Visual Studio or Xcode, and for the HTML5 specific code (which is just a few hundred lines) traditional "printf-debugging".
Fair enough, and I strongly agree with the general point about the need for a solid cross-platform framework either way.
I don't see why you couldn't write your entire business logic, state management, etc. in C or Rust and treat it effectively like a client-side server, but I've never used wasm in that way so I can't speak from experience there. Either way, I can certainly see how that would require some extra effort, and of course it would only really be useful for applications that don't offload most of their work to a server.
Generally speaking the "connecting it up" between c/wasm + js or C + java/kotlin on android can be completely automated with codegen. It's really not tedious at all.
you release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers.
You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working.
You implement the feature over on Macs as well copying the Win strategy. But a recent Mac OS update causes a bunch of permission popups that mess with another thing. Now you're messing around with that, and your internal users are pissed (cuz they're all on Macbooks).
There is no Linux version, luckily.
I mean... OK, yeah, you still have to deal with platform differences even when using Electron. But you are in the same boat with like.... Slack, Discord, etc etc. You get _all_ that shared knowledge, a unified code base. And in theory you throw any of your engineers at the problem and they can try very hard googling "Electron [issue] windows".
I also bemoan the fact that _even Slack_, with its billions of dollars, didn't feel the need to have a native application. But I do get it, especially when there's a lot of pressure to ship.
While I realise you’re just providing an example, Windows has supported deep linking in one form or another since Windows 3.1 (DDE, specifically topics), but also HTTP-style application URLs (eg app://command?options=opts) ever since ActiveDesktop and WebView.
Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.
Google Pay also reports that their engineers are far more efficient, with a huge reduction in technical debt and unified release processes such as security reviews and experimentation across both iOS and Android.
That's very interesting in light of the facts that
1) This announcement seems to claim that Flutter 2 apps can be deployed as web apps as well as mobile apps, yet
2) This very morning I received an email from Google stating that pay.google.com is going away and the service can only be used via the mobile app going forward.
>Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
Yes.
>Is it that hard to find developers who know more than one programming language?
Working on an app that's running on... 6 different OSs/UI toolkits on last count, yeah, that "small UI layer" is costly. And yes, finding devs that know more than one language/one UI toolkit is hard. (Heck, for some UI toolkits, finding developers is hard period)
Isn't the licensing for Qt a very curious and weird quagmire? Maybe it's better these days but I remember about 10 years ago there was a weird divide and unanswered questions about if you could really take a bet on using Qt and not be violating GPL.
No. 10 years ago it was 100% fine. About 25 years ago there was a licensing issue, and the Gnome project talks about it as their reason to exist to this day (which amounts to spreading FUD at this point, IMO).
QT isn't neccesarily a crowd pleaser, and in 2020 it's starting to look a little long in the tooth. Don't get me wrong though, I love QT on the desktop, and it powers some of my favorite software out there. Ultimately though, I don't think QT's fate is on the web.
Pure nonsense, phonegap has been renamed Cordova and is widely used. The Electron of smartphones is Ionic which is a sexy and performant superset of Cordova.
PhoneGap (Cordova + Ionic marketshare) has a bigger marketshare than flutter and react native!
Source: https://www.appbrain.com/stats/libraries/tag/app-framework/a...
Ionic is a gift and it will only get more widespread, the myth that chromium is slow is increasingly dying. Also, did you notice the irony/hypocrisy that flutter is using the rendering engine made by chrome developers for Chrome developers ?
Ionic has released Capacitor as the successor for Cordova. And it's still compatible with Cordova plugins so all the work from Cordova days is not wasted. Ionic is definitely a gift.
Time is on webview apps' side. IMO cordova/phonegap got too big too early and the industry still has a revulsion that may not be justified anymore. I don't think they will ever come to dominate, but I do think hybrids will eventually go back to using webviews.
If groundbreaking UX is your core competency you need native. Hybrids get you neither the best feel nor the best dev leverage. Hybrids are selling the exact same dream phonegap has. But they let developers distance themselves from the bad rep and claim they're doing something different. Alternatively, at the other end, they get developers to build essentially native apps while pretending to save a lot of time.
Yup, really they had the right idea in that it was native components that were hoisted by JavaScript binding... it really lost steam because it became easier to just build native Swift (and later kotlin android). It was a solid play at the problem in it’s time. Note: I worked at Appcelerator in the “gogo” years and it was great, and they/we almost made it happen in a real way.
> Not to mention that Flutter is already better and easier to use than the existing native tools for both Android and iOS.
No, it's not. It's easier to start with, which is infinitely different from "easier to use". Once you get of beginners phase you see that native toolkits are equipped with battle tested solutions unlike Flutter.
With SwiftUI and Compose there's literally no upsides to Flutter except portability and even that Compose has potential to snatch.
So now every website will require enabled WebAssembly to run god knows what code and I will have to install an anti-virus for my browser? No thanks. JS might be a bad language, but it's even worse in how it's abused with frameworks, tracking, etc for no good reason.
edit: funny how I can discuss extremely controversial political topics here and never have any of my comments killed, but having a negative opinion about wasm and JS frameworks is just a step too far lol.
There are a few things that WASM can do that JS can't (at least not now):
- Memory management without GC
- Unboxed data structures
- SIMD
- Shared-memory multi-threading
- Precompiled snapshots (does not need to be recompiled on page reload)
BigInt landed in ES2020 and has been supported in something like the last 10-20 versions of Chrome and Firefox, so no huge worries about using it (the "current" browser without support is IE11).
The `123|0` type hint is also recognized and implemented by most browsers too. It forces a 31-bit integer on most platforms (and can offer a significant performance boosts if you're running a tight algorithm).
> edit: funny how I can discuss extremely controversial political topics here and never have any of my comments killed, but having a negative opinion about wasm and JS frameworks is just a step too far lol.
I'm not surprised. You probably happen to agree with the majority of HN on these topics so the upvotes outweigh the downvotes.
Flutters model really fundamentally isn’t there “right one”. It truly is the successor to Flash, but with Google behind it.
But if you want to make apps that feel actually native on their platforms, React has it handily beat. It’s a better fundamental model, that even with a slower language and runtime feels better in the end by far.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality. By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.
from pay.google.com
> Starting April 5, you won't be able to use pay.google.com to send and receive money from other people. To send and receive money, use the new Google Pay app.
The new Google Pay app on iOS is incredibly sluggish -- animations stutter, switching pages has hesitations. I'm not sure what they mean by "quality" in this case.
We were also not satisfied with the performance of the initial GPay release. We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app. Hopefully the next release of GPay will be out soon and others will be able to see the progress we're continuing to make with the team.
> We've been working with the GPay team the last couple months and have made significant improvements within both Flutter and the GPay app
So seriously, how can you reassure any indie dev not getting VIP support to optimize their app for laggyness, that they can easily produce a decently performant app?
Many of the lessons we learn with GPay directly fed into improvements in the framework, improvements in our tooling to make this kind of debugging much easier, and better documentation to try to scale the knowledge to the whole community. Some of these have already shipped (see e.g. new features in our DevTools) and much more will continue to deploy over the coming months.
Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress.
And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply no alternate universe where a third-party team gets the level of access the way you described the Google Pay team did.
Of course, it helps that the stakeholders are in the same company, but my point is, shouldn't there be a Flutter Foundation where every developer can feel at home on equal footing with other Googlers? Flutter is so promising, and yet, at the same time, I don't want to end up being slave to its complexities with no way out as a third-party small development shop.
Despite that, I'm 99% porting my cross-platform app to Flutter after strong reviews from other developers I know.
I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)
We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.
We are using Flutter at our company and it's far from a black box if you get stuck.
For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.
For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.
At least with iOS you know it will take three years for something to come out of beta but then it's pretty solid. It's just Xcode that never gets fixed.
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
And then, the reality:
> We were also not satisfied with the performance of the initial GPay release.
Ah, the classic false advertisement.
Let me re-write the ad for you:
> Thanks to several-months-long involvement of Flutter's development we could finally fix some of the issues plaguing our app that we re-wrote in Flutter. We're still not close to the release, and we only hope it will be better.
Flutter used to be such a great experience, but something happened ~6 months ago that totally derailed it.
It brings my late 2016 MBP to a crawl if I am building on iOS simulator.
After reading online about it being related to Metal, and needing to switch flutter channels, trying that, and still seeing no success... I just gave up on Flutter (for now).
Hi, I audited the performance of the GPay app. Almost all of the performance issues in GPay are related to its use of vector graphics libraries which make Skia spawn many new shaders that have to get compiled. The suggestion was given to move to raster graphics but since GPay ships in many locations that are sensitive to app size, like India, they made the tradeoff to keep raster graphics.
That said there are some longer term initiatives to address this problem on Flutter's side and Skia's side since the problem can show up outside of vector graphics, it's just more unlikely.
It was buggy as well. I was locked out of receiving and sending payments for about a month. After some updates, had to relink my bank account and the app created a new UPI ID by appending a -1 ie. myname-1@okhdfc! It's like creating a new email ID to resolve the issue.
It's not clear what you're arguing for or against. Google Pay is a product with multiple features and one of them is being phased out. What's that to do with the benefits they're claiming from the rewrite of the mobile app?
Yes, exactly, it doesn't follow. You've just re-written your app using a framework that allows you to run one codebase in multiple places, including the web, and instead of doing that, you decide that you no longer want to support the web at all.
The web version isn't shut down, but losing crucial functionality. If Flutter let's you run the same code across multiple platforms, then what reasoning is there for one platform getting less functionality after switching to a framework that, if anything, should increase cross platform feature match.
I'm currently 5 months into developing a mobile app for a startup with flutter and my experience so far is very underwhelming.
Flutter as a framework is not the worst but far from best, it's very OO while trying to use reacts vdom model which just wants to be functional.
The biggest limitation of the platform is Dart - it's a horrible language that should have died once TS and ES6 became mature enough. And I've used dart back when it was supposed to be a JS killer shipped with browsers, used dartium to build a MVP for an app using Angular Dart durgin the betas.
Back then Dart was miles ahead in terms of tooling and JS the language didn't even have async/await - so I was singing it's praises. But the language stagnated and it's fundamentals with a nominal type system and a closed object model make the language so inflexible and full of boilerplate it's incredible. It's very much like Java (the language, without the powerful ecosystem) and people prefer Kotlin for frontend for a reason. C# is similar but they figured out that they need to build a lot of things in to the language to reduce the boilerplate so they are adding stuff like Records and pattern matching.
If you look at state management patterns in flutter there's probably 5-10 competing approaches all lacking in their own way and all severely hampered by how unexpressive dart is. Or how you deal with serialisation/immutability/etc.
That corresponds exactly to my experience when I tried it a few years ago. Very disappointing to learn nothing changed on that front. The "just works" aspect of Flutter is what attracted me to it initially, and it took me a few weeks before realizing React-Native, as much of a clusterf*ck as it was, was still a more pleasant development experience.
Would have been be nice if they provided a way to use Kotlin Native as a language for Flutter instead. Not a JVM Kotlin of course, because it's too slow for the native mobile apps. Or, even better, Rust. That would be very impressive.
Could any Android dev veterans chime in and comment on JetPack? This is the first time I'm hearing about it and I'm not sure I like it. It looks like a weird blend of HTML, CSS and JavaScript event handlers and I'm starting to wonder: Why not use web technologies from the get-go then and make use of the lessons learnt there?
This reminds me, I'm getting the impression that with every new UI framework that gets released, we're just recycling ideas learnt on the web and re-living its paradigm shifts:
1. First, in the early days of the web, we defined UIs declaratively but mixed structure and looks (`<h1><font face="Comic Sans MS">Hello, world!</font></h1>`).
2. Then we separated content structure (HTML) and styles (CSS) (or even XML and XSLT)
3. Later on we added dynamics and discovered event handlers (JS)
4. Then we realized we could use JS for everything (content, styles, dynamics) and imperatively create & manipulate UIs by manipulating the DOM (document.createElement, jQuery, d3).
5. Finally it dawned on us: That's not a good idea, either, because 1) we're mixing business logic and styling and 2) the DOM is global state. So we switched back to the now classic separation of using HTML for content, CSS for styles and JS for dynamics. But this time we try to keep individual components (their state, their DOM and their business logic) neatly encapsulated (React, Angular, Web Components).
> Could any Android dev veterans chime in and comment on JetPack?
Small nit but Jetpack is the name of the entire suite of libraries that Google offers for Android. The thing formally known as "support lib", a name that stopped making sense when it had random useful stuff not just compat stuff.
You're talking about Compose here (or Jetpack Compose).
The step 6 is to integrate graalVM into web browsers in order to allow seamless interoperability between any language (e.g Kotlin) and any other language, especially javascript and the web apis.
Unfortunately because of harmful politics from mozilla pushing the NIH webassembly, it's not going to happen before a proponent come (maybe Microsoft someday)
I'm doing something that while not the same thing, it let you control the web infrastructure with native languages. The first SDK is in Swift.
But im sure that with enough work a Rust Sdk could be created as most of the core functionality is exposed as a C interface.
The product i'm finishing is more of a answer to the question of if there's something between the browsers and
mobile application platforms that could also work in a
more distributed fashion.
So what about working on integrating graalVM into chromium so that e.g Kotlin can interoperrate with javascript and the web apis?
That would be the best solution and support for swift could be added as graalvm supports llvm.
If you can create a binary that links with a C api, its possible.
The access to DOM apis are going over the C, so its just a matter of wrapping all up in the target language.
Im using the Chrome multi-process architecture, but instead of a renderer process what gets called is a application executable that binds to Webkit and acts as the renderer process do to Chrome now.
So this gives the application much more control over the client rendering, hooking over every event WebKit triggers, something that is not even possible with Javascript now. So its much more powerful.
You also have a "service" process which runs as a service, that is actually the one that receive every request and can launch the application process or do something else.
The requests are over GRPC, so the service process serve not only the UI requests for routes but also the RPC method calls to the API it defined according to what the app does. The API for both are in Swift, but the core runtime and system is on C++ and in a multi-process architecture, so any native app that can compile into a standalone binary and interface with a C api can also use the facilities.
The applications and resource distributions are over torrent so anyone can serve the application without any intermediaries or shipping on servers.
If a app want to talk to the cloud, its just a matter of doing so when processing the routes or the RPC method calls, but it can work offline or eventually online/offline given its design.
I've heard Kotlin can produce standalone binaries, so that means its possible (and no WebASM shenanigans with direct access to Webkit and with the real native boost)
Unfortunately i cannot ship with another SDK right now because i'm doing too much already, but i intend to create interfaces for other languages once things are more stable, and people understand better what is it's place in the game.
But is more a application and window manager as Chrome is more-less and less as Electron or Flutter, where it wraps a standalone app.
With this design together with the RPC api's exposed by each application, you end forming a local network of apps, where they can work with each-other. And with the Api's working as a social contract, you can replace the application to serve the same things without losing everything (effectively real data ownership)
But my goal is that you can just call "./pacman" and the thing pops, even being managed by a core process as in chrome. The user dont need to deal or know anything about it.
You really don't know what you're talking about, do you?
Kotlin jvm is significantly faster than kotlin native. Also both kotlin native and Kotlin jvm are multiple time faster than dart.
Indeed Kotlin is a better language than dart.
Rust is obviously a missfit for frontend programming, nobody wants to loose productivity on low level issues such as memory management.
As what exactly ? Look at libraries like built_value and built_collection. That level of boilerplate and code generation is only seen in Java land, even there there's better stuff because the metaprogramming is better with stronger reflection capabilities.
Dart is a worst of all worlds
- languagee designed by VM engineers in a Java shop
The idea sounds very appealing, especially to an indie developer: being able to ship your app on multiple platforms from a single codebase is kind of the holy grail. Unfortunately, the result is....
I tested this Flutter example[1], on a 16" MBP with and i7, and it is janky as it can get, it feels like I'm using a 15 year old computer. From the code it looks like the whole thing is... rendered on canvas? I'll pass.
Wow, this is some of the worst scrolling I’ve experienced on the web in a long time. Incredibly weird and not smooth at all on both a newer iPhone and Mac. Can’t copy text either.
I just tried it on an iPad Pro with Safari. Clicking the tiles does not work, scrolling does not work with the touchpad, and overall it feels very janky. They probably didn‘t care to optimize / make it usable with Safari.
Trying it on Windows 10 with Firefox. Scrolling is incredibly slow, in every possible way. The scroll wheel barely moves the content, so I have to spin the wheel ten or more times to get any reasonable distance down the page, and the animation is janky and stuttery.
I remember getting accurate values from the scroll wheel being the worst in Firefox and basically impossible. You could only get the scroll direction, but not the correct extent (bascially everything just looked like one detent). So you either get incredibly fast scrolling, or incrediby slow scrolling, depending on how you work with the value and whether you still do the oft-needed division by 120. This can also make some touch pads that generate mouse wheel events very unusable for zooming or scrolling.
The scaling there works with very different speeds in Firefox and Chrome because both disagree on what value the delta should have. Scrolling up once yields -100 in Edgeium for me and -3 in Firefox.
Still relatively early days for Flutter Web, so I would not be shocked if it's not buttery everywhere. However, we would certainly love to learn more. fluter.dev/support has links as to how to file an issue if you're interested.
https://flutterplasma.dev/ is one demo to try. We expect to be updating flutter.dev/web and flutter.dev/showcase to update more over time.
The plasma demo you linked runs at a stuttery 40fps on Firefox (ubuntu 20.10) on a quad core Ryzen 5 laptop. The fans immediately spin to max speed. I'm not impressed...
Here's a hard question, why is this surprising to you? What are you missing in development--is this a gap in testing? Are you hamstrung without support internally to bake this as long as it needs? Rather than double-down on extolling the virtues here, it's time to double-down on fixing the team and the product.
Sorry but the plasmadev demo doesn't pass muster compared to 60fps animations we were able to do years ago with html+js. Something about the renderer approach is causing hiccups in the animation.
"Buttery smooth animations and scrolling" will be a great selling point for flutter ..if it actually works.
As usual for Google products, this works fine in Chrome on a decently powerful desktop.
Not up to the speed of well-written Javascript, but definitely viable.
In contrast, this is completely unusable on other browsers or on lower powered devices.
On Firefox desktop, initial loading brings a "This page seems to be stuck" prompt. Once it finally loads, clicking the play button just does nothing.
Please note that for 80+% of websites/apps, Firefox is faster or on par with Chrome for me. Google products and some other exceptions are the only ones that are consistently slow on Firefox. Whether that's intentional or just a lack of testing, I can't say.
Similarly unusable on Safari.
On lower powered devices this just freezes Chrome for me.
As I mentioned in other comments, I like Flutter, but Flutter Web is not anywhere close to being viable for production use.
Why are you guys here on HN still using Chrome? There is literally not a single reason I can think of to be supporting this behemoth that is killing the open web. Firefox is excellent actually and Firebug IMO is far superior to Chrome's offering. I understand non-techies using it like they used Explorer, but come on guys.
Yes, we consider accessibility a must-have feature. On the web, we have a second DOM tree called the SemanticsNode tree, which is generated in parallel to the RenderObject DOM tree. The SemanticsNode tree translates the flags, actions, labels, and other semantic properties into ARIA attributes. We've been testing Windows Narrator, VoiceOver, TalkBack, and ChromeVox screen readers to navigate a Flutter web app.
So why is FlutterPlasma.dev completely unusable with a screen reader even after pressing the "turn on accessibility" button? I understand that the actual demo presentation might not be accessible, but the intro screen should be fully readable, and it's not.
Edit: You may want to add the NVDA open-source screen reader for Windows to your list. And when you test with a screen reader, make sure you use it the way an actual user would when browsing the web, e.g. using NVDA's browse mode with the arrow keys to move through the page.
On my iPhone 12 mini the demo took 13 seconds to show me something besides a blank screen. On my desktop it was around 3 seconds and cpu usage went through the roof.
FWIW the plasma demo runs at something like 50fps in Chrome on my 3yr old Samsung Galaxy S9, and only a bit worse in Firefox (perhaps 40fps) - so they are not buttery smooth experiences, but neither are they terrible.
Oooff, the edges in that demo look terrible - particularly the grey boxes in perspective. The demo boasts that it isn't a video, but the interpolation looks as bad as one.
I hate to be critical - I'm sure a lot of work has gone into this - but there's still lots of room for improvement too.
flutterplasma.dev just shows a blank screen for me on iOS safari. Every few refreshes I can can get the content to show for a split second before it goes back to white...
No, I won't help you. The OP post is about how great flutter is and you're in the comments telling everyone it will actually be useable soon and asking us to test it for you on common browsers.
Another data point is the new flutter Google Pay app vs the old version. On my iPhone 11 Pro, the former is incredibly laggy. The latter is as smooth as you’d expect given the hardware.
Is that a counterpoint? To me that tells me performance is going to vary between users computers, possibly due to something other than resources. That means the experience I'd be delivering won't be consistent and I probably won't be able to fix it, or even replicate it, reliably. Something that's janky everywhere can be profiled, debugged and possibly fixed. Something that has an unknown problem that only affects some users is far more problematic.
That isn't a counterpoint to say the language might be worth considering. That's an additional data point to give me reasons to not use it yet.
Just tested https://gallery.flutter.dev/#/crane in Chrome and Safari on Mac and if I go to another tab and then back to the fly tab it just shows a gray screen. Does not inspire confidence.
> and it is janky as it can get, it feels like I'm using a 15 year old computer.
Ironically computers 15-20 years ago with native software ran much, much much faster and snappier. KDE3, XFCE, even Windows 98SE and XP were much faster. They were crippled by disk I/O, true, but once the software loaded, the feedback was inmediate.
Just as a bit of counterpoint, I'm still running the same hardware right now as I was 12 to 15 years ago with KDE3, nowadays KDE5 is so much faster than KDE3 ever was. Yes I need to upgrade badly, yes I was planning to just a few months ago, but prices seem a bit crazy now, so I'm still continuing with my ancient but somehow still operational hardware.
I'm seriously considering looking at something like https://heaps.io/ for cross platform utilities rather than flutter etc. i suppose accessability is likely to still be an issue, as well as ciustom (not native) widgets -but at least the resource usage and interaction is likely to work?
note that heap+haxe is pretty much "the same" as flutter/dart - a language, a compiler and a runtime + a rendering engine..
Interestingly I've tried it on Brave on a M1, and it is very smooth. I also tried their Plasma demo and it was very smooth (https://flutterplasma.dev/) but that might say more about the M1 than Flutter.
If it's running on canvas, normally you would see "unpkg.com/canvaskit-wasm" - and even then it may not be the latest (supposedly more optimized) version. For example, my simple Super Tic Tac Toe app - uses it - https://malkia.github.io/tictactoe/#/ - but the gallery was compiled to use HTML, instead of canvas - which would be slower (IMHO). I think there is even mixed mode - where it can choose one or another ("fat" binary on the web ;)).
It is very janky, and worse, totally unaccessible, rendering it useless (or frustrating at best) for huge numbers of the population. And why? It's just yet another shiny web framework. We've known how to build websites for decades now.
Agreed... How can they be proud to release such an extreme regression in usability and accessibility? It is entirely 100% inaccessible for anyone not using a visual user agent. And this somehow isn't considered a non-starter?
I think a lot of people will compare React (Native) and Flutter in this thread, and as someone who has had a positive experience with Flutter, I will say that by far the biggest benefits were that (a) there's one way to set up a project, dependencies, compile, and run, and (b) it mostly just works across iOS/Android/macOS (and I guess Windows, which I didn't test).
(a) is so, so big. It is a big part of the reason that Rust, a genuinely difficult language, feels inviting. The Flutter community is small, but the core tooling (all from Google of course) is at least consistent. It's obviously how to include packages, it's obvious how to develop, how to run. No need for figuring out Babel or includes or Webpack, or whatever people use these days.
(b) is really nice because it allows you to get started. Yes, it's true that the experience on one platform (web) doesn't seem that good, it's the "new Flash" etc. But for someone wanting to develop high quality desktop apps, this is it, folks. It works. It's not hobbled or just a tech demo, the scaffolding is there. Will you have to write custom components? Maybe. But as a programmer I don't want to think about packaging and compilation and inconsistencies; I want incompatible code to be sandboxed and clear (i.e. filesystem access or sound). The runtime should be the same.
Exactly - I didn't have loads of time to spend writing separate code for Android and iOS, so Flutter helped me ship faster (see my profile).
It was also encouraging to know that if I ever wanted to branch out and deploy my app to the desktop on Windows, MacOS or Linux, that I would have that choice very soon.
And I'm a long-time pure web guy who prefers mobile-responsive web apps most of the time! But if you're going to deploy native and don't have the budget for writing code for every platform, Flutter to me is a lot easier than the other toolkits out there.
I want to love Flutter. But once looking at it, it's a no go. It's the new flash. Really, you cannot copy the text anymore. React native is my goto solution now.
Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions...
I can see it being useful for games and similar where there isn't really any UI but even then I would want dialogs and similar to use regular text that I can copy.
I am definitely not looking forward to flutter on the web. I foresee a lot of websites that I will need to avoid.
But do you really need that as a requirement across the boars for all apps? How many times have you wanted to save an image or copy text from a UI element in a native app? (eg. a save icon and “Save” on a button) How many times have you been frustrated in a web app that when you search using the browser you are getting results from UI elements or “app chrome” instead of the actual content that the web app is displaying? Isn’t it enough to have some fields with content a user actually would want to copy/search, which would be set based on the component type you are using and can be overridden per element if needed?
The only thing I do get is that you’d want open in new tab and copyable links. However, that’s hard from a developer perspective as you have to make sure you create links that store all data needed to rebuild the same UI in the same “conceptual” context but a different underlying data context (logged in user may be different, data may have changed so some saved context has become stale). You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar or a link by another user 2 days before, that may have been the result of that second user clicking through 10 levels deep in your app with all sorts of filters and options based on the state of data at that exact time two days before the first user clicks the link. Obviously you can’t show them the data from two days ago, but what if the data is still there but the path to get there is different? Does it conceptually still make sense to show the data and perhaps some breadcrumbs showing the new path? Or should you just say sorry that data isn’t here anymore? That depends entirely on what the data is and what you’re users are trying to do, so you can’t build one-size-fits-all technical solutions for this (if that were even possible). How are you ever going to reliably rebuild the UI and context that the first user intended to share by copying the link without spending huge amounts of time? That requires actual business logic and functional design.
For a lot of apps, it may make more sense to just have a share button in some places where you actually and intentionally support this (and where it will be actually used by a substantial number of users). Less time spent on developing things that are hugely complex and very little used (on average per state for ALL your different UI states that you have links to somewhere in the app, even if it’s a typical line-of-business master-detail form with some filters for the master list and a details segment with a dialog box or expanded element showing additional details of a certain property).
> But do you really need that as a requirement across the boars for all apps?
No, there are a few exceptions, but mostly yes. And I'm sure more than just the exceptions will use Flutter which is why I'm not looking forward to it.
> How many times have you wanted to save an image or copy text from a UI element in a native app?
Often. I mean not necessarily from a UI element but a lot of the time I want to get an image from a native app and can't.
> How many times have you been frustrated in a web app that when you search using the browser you are getting results from UI elements or “app chrome” instead of the actual content that the web app is displaying?
Almost never. There are rarely many extra results. In fact I already am bothered far more often when websites hijack Ctrl-F (I do not understand why browsers allow this) and fail to search the entire page. With flutter this will become the norm and I am not looking forward to it.
> Isn’t it enough to have some fields with content a user actually would want to copy/search
No, it isn't. I regularly copy things that people didn't expect. If it is just to send someone instructions how to use the app. In fact Android has automatic copy based on OCR from the app switcher and I use that a couple of times a day. There is already too much uncopyable text around. For example all messaging apps on android appear to only support copying the full message. This is what happens when you let people mess with standard UX patterns, they break them!
> You’ll likely end up spending an awful lot of time to cater for all the unexpected things that may happen when someone just clicks a link copied from the address bar
Good! I love apps with great links. It makes them so much easier to use. I don't need to go through their custom navigation to get to my favourite pages. I can use the browser navigation that I already know and love. Also I can share links to my friends! Maybe I can help people use the app better!
You just described a bunch of problems that I already have! Especially on mobile devices. This is why I hope that Flutter on web doesn't take off. We will be making all of those annoyances more common! You seem to think that you can predict all of my use cases and provide the share button manually right when I need it. However product developers on a time crunch often miss or skip use cases so it is much better to have supported by default (like text find/copy that can be disabled) than hope that a developer will think, and find time, to implement them. And if URLs encourage people to make it possible to save and share the state of their app then I think that is a good thing!
I would expect you to have come from a react background then? When evaluating technologies 1.5 years ago for the company I work at, I took a good look at comparing both react native, as well as flutter, and we decided on flutter.
Now, out of the many considerations we had, in this process, "cannot copy the text" is... well, I have no idea what you are talking about. Are you referring to not being able to do this in a EditableText widget, and if so, have to tried a `TextField` with `enableInteractiveSelection: true`?
I mean, there should be hugely more important development concerns when evaluating these things, than... a brief rejection based on something as trivial as that. Then again, I won't presume to know your situation or the criteria you had. But it does strike me as a bit... shallow reasoning.
I can say, that for our case, the dependency hell that you more easily get with React Native was what put me off completely.
Looks like a very developer/product-owner-sided opinion, not being able to select text and other "trivial" things are what makes software tolerable and actually usable, as listed by sibling post by kevincox, I'll quote:
> Yup. I would also like to open links in new tabs, view images, copy links, search on page, use browser extensions...
Throwing away all platform conventions is a very heavy-handed and user-unfriendly way of bringing about portability.
Another triviality, for example is the behaviour of scroll chaining as compared to my browser: In Flutter, as soon as the inner scrollable hits its boundary, the outer scrollable takes over, while the expected behaviour for me would be for the outer scroll to not move until I reposition the mouse.
It's exactly the same as Microsoft's Windows 8 fiasco, by unifying the experience across platforms every one of them felt broken and contrived, and this effect is even more notable if your application deals with a more diverse user-platform ecosystem. Your app will be the odd one out that works strangely compared to everything else in every system.
I do appreciate your point of view on this, and I hope I did not come across as dismissive of your choice. If it was a thorough evaluation of the capabilities, and it did not seem able to provide the user interactions you needed, I'm sure that is then a reasonable enough basis. My knee-jerk reaction however, was to think this might have been made without properly evaluating the capabilities of the platform. If I head over to https://gallery.flutter.dev/#/crane, I am annoyed by how "app-like" it feels. I'm in a browser, I should be able to select tings. Clicking and dragging isn't supposed to scroll, it's supposed to select. It feels all wrong. But then again, this was mostly when coming at it from a "this is a website" approach. If the use case is to develop an app, then the conventions used have not felt weird to me.
Fair enough, and sorry if I seemed a bit combative too.
However, I believe "this is a website" or "this is an app" is a perspective the user will take, despite what our intentions as creators were, and so, the safest bet would always be assume what is the norm for the platform, since the user would never be "disappointed" by that even if they expected an app-like feel. On the Web, (at least some, in my anecdata most) people expect to see Websites, even if highly interactive ones.
I have not tested Flutter in a mobile application so I wouldn't be able to tell if it feels par to the course with other mobile applications, so it might be viable if you only need "Android<>iOS" portability.
I'm glad we can be nice, stalking and all :D. I think those are very valid points, and I think Flutter has a much more natural place as a framework for mobile apps, or desktop software. The gallery showcase feels like a half-assed attempt at creating web-site like pages, that as you pointed out, all feel wrong. So using flutter to develop something like that, I think I'd have agreed with you. However, from just the app side, I do feel flutter developers have made the UX very much in line with that of apps. I rarely know if an app is made using flutter, or pure android (as for iOS, I have no clue. The cupertino stuff looks like iOS to me, but I also have no clue).
I'm also not entirely convince that native apps with flutter is a good thing, especially considering that I'll be just another attempt at providing an opinionated UX stack that is completely different from that of the native experience.
So, maybe we agreed more than we thought. I also believe that a native experience, one that matches the otherwise existing UI interactions should be king. Throwing App UX paradigms into website or desktop app bound to feel terrible. Maybe it can be made more enjoyable to use with better configurations more in line with the respective platforms.
Breaking common user affordances (e.g. the back button, bookmarks, text selection, copy and paste) is indeed a big concern in the apps we make at my workplace and I would hope that's the case anywhere that values a positive user experience.
Flutter team member here. In Flutter, the developer consciously decides which text should be selectable (and thus copy/paste'able), so while it's true that text is not inherently selectable in a Flutter app, text that the app developer decided to make selectable will be.
This sounds awful. Like some sort of bullshit DRM in a way.
Now I'm thinking of all the ways I could get screwed here.
* Not being able to copy transactions from my bank account
* Not being able to easily send text to a read-later service (not sure if this necessarily depends on selectable text, but who knows, maybe selectable means the text isn't visible to these services now)
* Not being able to easily copy something that needs entering into another page
This reminds of sites that try really hard to NOT allow password managers, or even allowing pasting of text into form fields.
I use the select text -> web search feature in Chrome all the time to quickly look up definitions of words. Breaking this will be really annoying to anyone reading webpages in a 2nd language than their own.
It takes work to make it non-selectable. In Flutter, it defaults to non-selectable.
Most of the time a dev isn't thinking "I'd better make this selectable," because they simply aren't going to think of all the reasons someone might select text. They'll think of the obvious-to-them cases, and leave all the other text as unselectable.
OK, but the Flutter gallery has zero selectable text, as far as I can see. Seems like a great case of where developer decided "doesn't need selection, let's let the user drag to scroll with their mouse instead".
Why even make it a 50/50 choice? I hate apps without selectable text and they're everywhere. Translating something becomes a nightmare and that hurts useability.
It's like if you made spoiler 50/50. Do you want to see this without clicking?
I think we really overlook the thought that had gone into making js, and other open tech.
Exactly. And I didn't even realize how often I subconsciously select text while I read until I saw the relevant xkcd. [1]
I truly think my random clicking on paragraphs that I'm approaching isn't just ADHD but a way of helping my eyes stay on track. It's very disconcerting when the text doesn't select. (As, clearly, all these comments noticed as well -- why were we all trying to select the text? To check if it's Flash-ish, of course, but also we just like things to grab onto while we read.)
Try putting their demo website in Google Translate or even try to select the text on an email in their demo webmail app to copy paste it in google translate ....
I'm not happy about "user-select" not having an easy override. But at least it can be overridden by a user CSS file or a browser extension, which isn't so bad. This is much worse.
Yes but on the web you can use a user-agent that doesn't care about what the site says should be selectable, or at least an extension that overrides the CSS in question.
Not only is this making it easy for app developers to do the wrong thing ("I will just put some text here and make it unselectable, that is going to be great UX") but even worse, it is the default?
There are going to be some unintended consequences here, I suspect.
This reminds me of those websites that use javascript to preventing pasting into password fields "because security", thus breaking everyone's password managers, and making everyone less secure in the process ("if I have to type in that password every time, I'd better choose something simple I can remember...").
So, what about accessibility? If the text is not accessible, how are screen readers going to work?Vision impaired people are just going to have to ... do what, exactly? Will they have to apply OCR to access the content of a Flutter app?
This really reminds me of what was so sucky about Flash. I guess we'll get lots of little walled gardens that make basic interaction via text deliberately difficult. This feels like the opposite of the open web.
As a user I don't want the developer to need to anticipate which text ought to be selectable as they will inevitably fail to consider some use cases it ought to be the default.
In the context of the web, this seems like it should be a non-starter. Why should the developer be able to tell the user what can and cannot be selected?
They already can, CSS has a property called "user-select" that can be set to "none". It's pretty common to disable user selection on label text that isn't expected to be copied.
This is annoying, but is at least trivial to get around with browser debugging tools. The web developer is not the person whose expectations matter. Selecting label text is almost essential for being to explain to someone else how to do things, or communicate about the interface with the site developer.
Depends on the label, it's not essential for plenty of things. I don't, for example, need to copy "Cancel" in my browser before I am capable of talking about the cancel button in the UI. You're right, user expectations are what matter, and users do not expect most buttons and controls to be text-selectable. It was never an expectation in native apps while users find it frustrating when control labels unexpectedly seep into blocks of text they are dragging to select.
Most users don't open devtools to workaround this (Safari doesn't even enable devtools by default). While it's annoying when developers get it wrong (put "user-select: none" on things that should be selectable), this changes very little for the vast majority of web users.
Sure but presumably many developers who are deciding whether to adopt Flutter aren't only targeting a population of you and other people in this thread. The fact remains that this is not a significant issue for most users and rational developers will weigh it as such against potential benefits that Flutter provides.
I guess but... I don't think that changes anything about the complaints that people have about this. What you're saying is a fact, but I don't think it's a relevant fact.
I'm looking over this thread, nobody has said that they're in a majority. We're just saying that Flutter's default behavior is bad for us, and that it encourages developers to make bad choices about text, and that it's pretty demonstrable that the average Flutter app has less selectable text than the average web app in general.
The fact that many companies will not care about this when weighing the technology is exactly why we're complaining. Because we don't want the web to suddenly become unusable for us just because we're in a minority of users.
It still doesn't make me feel any better or make me any less likely to complain to hear that my problems don't affect everyone else. It's not addressing the criticism, or explaining why I shouldn't be upset about Flutter's decision, or explaining why the current situation on the web is equivalent. It's just a polite way of saying, "yes this will affect you, but we don't care because we don't think you can do anything about it."
And yeah, it's probably true that this issue in specific is not going to cause Flutter to fail (there are plenty of other problems with Flutter on the web that will do that), but does that fact change anything about whether or not widespread Flutter adoption would make my web experience worse?
I think you overlook that, at least to me, it's an accessibility thing and as such, is not just the population of people here in this thread but is an issue for anyone who is disabled and takes advantage of those features of the web, and now will not be able to in Flutter apps.
I know Flutter is working on accessibility, but they have already made choices that are counter to the default expectations web users have. And are having to work to fix the accessibility issues they introduced by not adhering to web standards and/or best practices to begin with.
I am aware, and I would argue against any spec that told me to implement that also for the same reasons I don't think its a good idea for Flutter. Not that I haven't had to do it for reasons, but I'd make the case against it when I can.
Don't want to restart the entire thread that already existed, but I rarely check comments and just saw this.
Why can't the default be always selectable? Let the developer choose which ones they don't want to be selectable. Also, what is the use case for non selectable behavior?
Come on. Isn't this only happening because the initial text widget did not have text selection, the one with text selection came later and now we are in this bad situation? Just enable text selection for both/all text widgets when targeting the web. You could couple that with a major version increase...
This feedback you get here will only get worse with time, and it will block adoption.
I think the selection some improvement improvements needed reach a native-feel. For example, interactions like triple-click to select a line.
However I think the decision to make text selection opt-in makes sense from the context of an application that targets web.
For example, if you open up your mail app or Slack, you will find that a lot of text on the screen isn't selectable. For example, you can't select the text of the tabs on your browser.
If all text was selectable by default for an app, it may cause unexpected results rather than having the develop opt-in to deciding what is selectable. We have many widgets in our app that we wouldn't want selectable for UX reasons.
In practice, it hasn't been much effort for us to make things selectable. Just need to replace a Text widget with a SelectableText widget.
I get that user-select was already a thing in CSS, but why is so much of the text in the demos at https://gallery.flutter.dev/ not-selectable? It's a real bad look.
Is the goal to get full parity with native text selection? I went to the plasma demo and tried to double/triple click on text and it didn't match what text selection is supposed to do, at least on macOS. Which makes it a bit jarring. Right now it seems to be a bit "uncanny valley".
(Disclaimer: I work for Google but not related to Flutter.)
If `Text` and `SelectableText` exist, I would call that an opt-in. The default is "Text" (not selectable) and a modifier can be applied to opt into using "SelectableText". It would be different if they were called "UnselectableText" and "SelectableText".
Seems like every dev using Flutter for more than a few days would know that both `Text` and `SelectableText` exist and pick the one that's relevant to whatever kind of text they're adding. At that point, it's the dev's fault for making a conscious decision to make text selectable or not (if they choose wrong); not really the language's.
You (and your team) would be surprised at how performant and well designed dart is https://dart.dev/samples.
Not to mention the ability to use flutter and target multiple platforms.
Would adblockers work on these kind of webapps? Adblocker typically look for specific piece of js files and DOM nodes to block ads, but Flutter web doesn't really work like that, no?
Isn't this a feature? Having text easy to copy and paste is a copyright problem for many sites. Same with being able to save full-resolution images. It's pretty common to see a copy/paste in forum comments to get around a paywall.
IMO either this or some other webassembly view is the future, simply because it's great DRM. Sure, you can circumvent it, but most people cannot.
I do think it's the norm, and very much dislike this trend.
I should make my position more clear: I hate this stuff with a passion. But, big business wants better content protection, and big money always gets what it wants - very few exceptions there. I wish we could do something as technologists who want to keep these features of the web; but against trillion dollar companies I know who I'd bet for...
Pretty sure I'm the only person on this thread who loves flutter. We use flutter web and Firebase for our hobbyist project, and the results have been simply amazing.
Dart makes Typescript look like a joke. The build system alone makes flutter better than React Native !
I'm confident in being able to build any CRUD app in dart
Edit, in fact how many of you have actually built a project in flutter .I can't believe anyone would want to go back to react native after trying it
All of the complaints about flutter I see here are based on people using apps built with flutter, and not about the development experience. "Have you actually build a project in flutter?" is a total non-sequitor response to complaints about how even the official demo is miserable to use.
Would you not buy a screwdriver because some people with that screwdriver don't build chairs correctly ?
Like with Unity, the power of cross-platform development leads many to just assume apps work across platforms automatically. This is absolutely not the case, you need to properly QA any code you write and code it to accommodate each platform's quirks.
I would not buy a screwdriver if a salesperson walked up to me, said "look how great this screwdriver is" and then the chair they were holding as an example immediately fell apart in their hands. There's a difference between a dev community building apps that perform badly and the actual platform advocates showing off apps that can't perform.
Exactly! I always think of the official demos as "this is as good as it gets". Look at how Unreal Engine advertises. Beautiful! Will your game look like that? Probably not, but it potentially could!
All the Flutter demos I've seen today are saying "Do you want your app to, at best, take a long time or even fail to load, feel like scrolling through molasses, break when you click a button, and spin text around at 25 fps like a 2005 Flash animation? Well, have we got a framework for you!"
Can you share any example of Flutter Web that isn't a extremely basic Todo app, doesn't completely break regular browser UX and works without being slow as molasses?
I haven't seen one.
I like Flutter, but I don't think the Flutter Web design is very viable for production apps. It renders everything in canvas. Dart is already sluggish on native, and cross compiled to JS it's usually unusable.
I think Flutter will be a good choice for mobile and Desktop soon-ish, but for web ... maybe in a few years. Maybe.
https://rive.app/ is built with Flutter. I use it a lot works very well for me. It's a good example imo of the kind of website that Flutter is a good fit for.
You're not the only person. After using two decades of improvements to JavaScript, Dart comes out swinging and wins without a contest. I don't want to spend all my time playing with build systems and and Flutter just works, plus even though JS is better these days, Dart in IntelliJ (Android Studio version) is so straightforward you can be productive from day one without having ever written Dart before.
We built our mobile app in Flutter, and it was pretty amazing. I would absolutely never suggest we create a web version of that mobile app and would strongly fight against it if someone else suggested it.
I strongly disagree re: Dart vs. TS, but then, I was a JS dev before I worked with Dart/Flutter, so probably a bit biased. But I think that is a very subjective statement, not objective.
Yea I have used Flutter for hybrid apps and love the dev experience. The apps have come out great, and are smoother than my native Android work.
I am really hopeful for it and am going to keep using on it for hybrid apps.
I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.
What is your main use case for type unions? I don't know typescript, but I haven't felt the dart language was not feature complete for all my uses. Is this something you cannot solve with a combination of abstract classes, and or/extension? https://dart.dev/guides/language/extension-methods
(Small excerpt from a game we're developing at $dayjob)
You can switch on that and the compiler will know what variant you're talking about, and it will apply exhaustiveness checks (ensures your code will handle all possible states)
Haha. That's alright. That looks super neat though, I must admit. The only equivalent that comes to mind would be using an abstract class. I still might fail to fully understand what that code example does, but, would this be somewhat similar?
abstract class AppState {}
class AppLoading extends AppState {
final int progress;
}
class AppSelectingLevel extends AppState {}
class AppPlaying extends AppState {
final Level level;
}
...
Certainly not as neat, but also, not that far off either. Then where you use this app state, you could switch over its `runtimeType`, and in each clause, the IDE will understand which implementation you are dealing with, and actually give you context sensitive help related to that particular state.
If you instead only cared about one case, you would be able to do:
if (appState is AppPlaying) {
doSomething(appState.level);
}
Would this be somewhat analogous to the functionality you get with unions in typescript?
The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.
Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)
I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.
> Have you considered not going full-on structural-typing but still providing some sort of union?
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
No time frame, sorry. We generally don't make promises about future dates because schedules tend to be flexible and picking dates just sets people up for disappointment.
Indeed, that is basically what you get from unions, except the exhaustiveness check.
Unless I'm mistaken, if one were to later implement a new class that extends AppState, all existing code would compile, but possibly fail or misbehave at runtime, unless you meticulously checked every place that tries to determine something based on those derived types.
In TypeScript, adding a new case for an union and not handling it everywhere is a compilation error on every incomplete usage site.
I have to say, the default diagnostic isn't brilliant, but some tooling will give a better error and actually point out the missing arms, instead of complaining about the return type.
I suppose. In practice, I haven't experienced this to be a problem. Since you already check which implementation you are dealing with, any code that relied on any state, should still work without any issue. This is the same as with typescript unions. Any code that somehow needs to handle a new state hm... I suppose getting a compile time error is nice to immediately see all places where it is used... but, I mean, so would a "find all uses" search. It's also not all that different from the linting warning error you'd get from iterating over runtime types without handling all cases.
All in all, sufficiently analogous to not consider unions a missing feature of the dart language? Seems nice to have, but, maybe not very necessary. Especially if the only difference is whether it is considered an error by the syntax, or a warning by the linter.
The proper analog to union types in Dart (as in Java) is enums and / or church-encoding [I think that's the term] generalized algebraic data types (GADTs). E. g. something like this: https://gist.github.com/jbgi/208a1733f15cdcf78eb5
Scala 2 also had `sealed` classes that could be used in places where you needed enums parameterized by runtime values and that's been generalized in Scala 3 IIRC.
I'm certainly confused now whether or not we are talking about the same thing. Without delving to much on the use of the word "union", how would you solve the use case presented in the typescript examples using enums?
Yes, union types are really nice for data like that.
But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types).
In a language that is built more strongly on objects and static types, it's less common to see APIs that "return one of these, or one of these, or on Sunday one of these things". So there is relatively less use for union types.
In other words, because people express unions at runtime less frequently in Dart (and other languages like Java and C#), there's less value in supporting them statically. Still some, definitely, but I don't think it's as critical of an omission as you might expect coming from TS/JS.
People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goes wonderfully well with them, allowing for exhaustiveness checks and all that.
The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.
I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature.
The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?
> The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check.
The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great.
Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style.
Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.
- Scala has the whole OOP stuff
- F# as well
- SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works.
- OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully.
- Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that.
So I'd say it might not be as ergonomic, but the capability is still 100% there.
You could create an abstract class for the base response, then implement this abstract class for the two cases one where it has a list member, and one where it contains the object. Then, using the return value with something like `if (response is listLike) { }` the IDE already knows that you are scoped to having only the list like properties, and you'd get the full help of the language. Something like that, I suppose.
You are not the only one -- I've been developing in Flutter for the past couple of months and overall I'm very satisfied how easy it is to develop in it compared to native Android and iOS. Being native Android dev, I truly believe that there is a future in Flutter. Till now I was rejecting all the other cross-platform frameworks.
Big part of it is thanks to the community which is providing all the handy packages to add some native stuff easier (such as permission, localization etc.)
I agree with other comments that Flutter Web is not ready yet I've tried to build web version for wish list sharing based on Flutter and I was struggling, so in the end I've switched to Tailwind + Vue. Some issues I had was that website didn't behave like website. For example I couldn't select text with my mouse. It felt and behaved more like a mobile app through the browser.
For mobile though it works (almost) perfectly, my example of the mobile iOS and android app build with Flutter: https://wishpy.com/
Although it loads a bit long at the beginning and I still need to figure out how to show images and icons without an uncomfortable glitch at the screen start.
I've been writing a desktop app using Flutter and couldn't be happier honestly. The widget pattern makes sense, the bloc library does what it's supposed to do, and just building an app is mostly on you. My blossoming love of Dart has also been a nice but welcome surprise. It has a couple weird spots and irritations, but so does literally everything else... It works well for the problem space its used in and has the necessary language features to get the job done without blowing off your feet.
Writing a desktop app _on_ and for Linux, that works on MacOS, and Windows ... and a web browser is beyond awesome. It'll probably work well on Android and iOS, with little effort, but I haven't even bothered to try yet. Before I add a dependency I will check out the code and run the demos (if there are some). I haven't had one fail or render strangely yet on a Linux desktop and nearly all of the existing packages were originally created/intended for a mobile device.
With web support, I personally have zero reason to ever write a line of JavaScript again. Why would I want to roll all my own basic widgets? I don't. Writing the logic for a performant and interactive list view, in JS and HTML, is woefully boring to me. I want a list view I can give data to and have a meaningful display of my data. I do not want to browse twenty different packages to find a list view that is the right mix of code I don't hate and features I actually want. I want that done because it's a solved problem, and takes time to solve right.
I couldn't be more excited for this release and future ones because Flutter is providing me a solution that fucking works.
I’m still having a hard time believing any « flutter is so great for me » testimonies, because my personnal experience with app having only the most basic list screen has always between a disaster. There’s such a big discrepancy between those testimonies and my experience that i’m starting to become suspicious about their authenticities
What was the actual problem with your list? The default list worked really well for me, even when not correctly building the child. What platform were you using it on or building for? I'm not asking to be a prick or prove you wrong, my experience is just limited to my own and haven't had any of the issues you describe.
I can say, because I've read quite a lot of code Dart and Flutter code over the past few months, that my experience does seem to be a newer one. I'm sure up until recently (past year or two) it was probably pretty awful at times because of constant flux and a myriad strangely broken shit.
Right now though, it's fucking great. Let me tell you a story even:
Hokay, so, there is this fucking "null-safety migration" going on and I'm thinking to myself, "oh shit, this is going to be fuckin' awful. Every package has to be updated or it doesn't work. This is gonna end up like Scala 2.11... Heat death of the universe or my obscure flutter dependency updates, which could happen first?"
Turns out, almost zero time, the Dart/Flutter team built a tool to automate it... the tool has a built-in "migration UI" with it to make the process super obvious and easy.
It was so easy, and generally correct, I proceeded to make PRs to add null-safety support to my dependencies because I realized I could do them ALL, myself, with a couple of hours of work.
</end>
What that says to me, is that Google's tooling is pretty fucking mature and that my quality of life is likely to only get better. I have never had an experience even remotely close with anything except Swift and that only works on and for Apple's specific platforms. I'd be worried of Google abandoning it if it wasn't for Flutter and Dart being what Fuchsia uses for its UI.
Flutter is not for everything, but it is really worth a look.
We (AU MVNO/Telco) recently converted iOS and Android apps (200,000 MAUs) to Flutter and it has been game changing. We had experimented with react native and found it just didn't deliver. Flutter is different. On mobile platforms the experience is super responsive and smooth and for your typical consumer app indistinguishable from the native experience. The tooling and developer experience are incredible. The benefits and experience where so clear that the whole team was onboard - including the most die-hard career platform specialists. Our velocity and ability to deliver is measurably better.
We're looking at the web target as maybe "good enough". I don't think it could be a replacement for a well-crafted web app, but could be used to provide a fast alternative to the primary native experience, and for rapidly prototyping and experimenting. In the current state, Flutter Web could never replace our highly optimised ecommerce funnel - some things you just need to sweat the details. But it's definitely better than some of the CX in the corners of our legacy applications. Shipping fast is valuable - so build for native, get a good enough web for "free" and then spend time and attention on the web if it is warranted.
From what I've seen and has been confirmed quite a few times now Flutter definitely does not deliver on producing mobile apps that are "super responsive and...indistinguishable from the native experience"
You can even find the director of engineering for Flutter confirming that's not the case on a thread on Reddit along with numerous devs reporting being burned by Flutter and swearing off using it ever again: https://www.reddit.com/r/FlutterDev/comments/llmkd4/ios_jank...
What can I say? As with all things, YMMV.
We're happy with it, we launched with zero customer impact, and have had no issues. Perceived performance has increased.
Performance in some areas was an issue. Overall benefits productivity and ongoing maintenance weren't enough to be really worth it. There is nuance to it all, because some of it lies in team structure and knowledge as well.
As a hobbyist Flutter user, I would like to be excited for this release.
However, this announcement page does not do a very good job at highlighting changes and new features from Flutter 1. The only concrete feature mentioned is the web platform being stable. Everything else is old news or plugging random companies.
I have to agree with you. Maybe especially as someone coming from using flutter exclusively for app development. Someone joked about this at work "wait, so flutter 1 did not enable developers to create beautiful, fast and portable apps for any platform?"
I had a vague idea that flutter 1 had a desktop/server like backing so that it could be used to develop desktop apps. Maybe this was incorrect, and only possible now with flutter 2? I'm still confused. This app: https://rive.app/ was made using flutter 1, no? It runs in the browser, so maybe this is the key difference with flutter 2, that... it allows native apps?
Reading all the comments it sounds like Flutter is exactly what I feared would come out of things like WebAssembly - a trojan horse to bypass web standards and turn the browser into a shell for shipping applications that put all the power back in the hands of application vendors and take away the power that open standards give to users (portability, accessibility, customisability, interoperability etc etc).
Of course, it will be achieved by delivering amazing developer experience and engineering in parity in all kinds of ways so this doesn't look obvious. But in the end, that is what it will be.
(I was previous editor of the HTML standard for ~10 years, now I'm the Flutter TL)
I mean... you're not wrong. But let's be honest, we never managed to really deliver on the web's promise here. It was <table> and <font> in the 90s, it's WebGL+Wasm now, but the reality is we've never succeeded at true portability (ever tried going to a non-trivial site in lynx? or a web app on your phone?) or accessibility (just ask anyone who uses a screen reader how accessible the web truly is) or customisability (have you _tried_ creating a user style sheet?) or interoperability (I spent a literal decade just trying to clean up the mess around HTML parsing and that was the success story!).
I just typed this comment using a plugin that gives me vi bindings
inside the editor, on a page where I have increased the font size to 110%
because I personally find it nicer that way.
All done without the permission of ycombinator and yet working perfectly
with their web page. And this is not just because ycombinator has very
basic HTML ... this works with at least 90% of web sites I go to.
It may not have achieved its loftiest aims, but I think the open web is an
absolutely amazing achievement and success if you compare to what we would
have had without it.
HackerNews uses tables for layout, inline styles, and still forces browsers into quirks mode. Yeah, it can handle slightly bumping up the font size. I can also bump up my font size on Windows, macOS, and Android, and that works for 90% of apps there too.
I agree that the open web is an amazing achievement. I don't think Wasm and WebGL take away from that at all. It's just the next logical step to make the web possible for an even greater set of applications.
Exactly. This is something which will most likely be lost by adoption of canvas webapps :( It will solely be on the webapp developer to implement/allow any kind of scaling. And generally such creators don't care. Webapps today are already pretty hostile - for example their embedded video players are often terrible but it is difficult or even impossible to play in an external dedicated players because of various chunk/blob/mediaSourceExtension/DRM stufof.
One question that's been in the back of everyone's mind with Flutter is "will Google toy with Flutter and then drop it? Or will they stick with it and make it the real deal?"
I take this post as partial evidence that they're making this the real deal. It's already surprisingly good, and there's reason to believe that it will get a whole lot better.
Considering that Flutter is most likely to be the defacto framework to develop for Fuchsia, I'd expect Flutter to stick around if they release at least 3 different consumer devices running Fuchsia OS until 2024.
There have been posts like this in the lifetime of various killed Google products - it would be nice if they would openly admit how many years of funding they've committed
Flutter for Web feels like such a wild step backwards in terms of functionality that I'm not sure the benefits it brings are worth it. I just tried a few samples, and basic interactions like selecting text, saving images, and opening links in new tabs don't work. This is the result of rendering everything to a <canvas> element. I'm much more interested in a React Native style approach, which seems to provide a consistent set of components that work the same on mobile, desktop, and web.
Yeah, I haven’t been following Flutter, but I’m surprised their approach to the web is just shipping their entire custom layout/drawing code in WebAssembly and drawing everything with canvas. I would have expected them to actually port their native UI components (buttons, links, text, etc.) to their corresponding native components on the web, and maybe ship a custom layout engine if CSS layouts aren’t flexible enough.
We actually have two distinct approaches: the CanvasKit/WebAssembly approach you mention for high-intensity graphics, and an HTML-based renderer for other apps. This article has more details: https://medium.com/flutter/flutter-web-support-hits-the-stab...
You're right -- we do render the controls, so that existing Flutter code (that might itself include custom styling or matrix transforms) just runs without change or surprise, but we integrate with the underlying browser support for things like text autofill and accessibility.
We actually did try that as our first approach, but it really didn't give you the flexibility that Flutter developers expect.
As the erstwhile editor of the HTML standard for ~10 years and the now TL of Flutter I must admit that it's weird to be creating a web framework that completely ignores all the HTML stuff I worked on before. :-)
That said, Flutter is different from Flash in some important ways. Flash used the NPAPI to "break out" of the web and was basically "native" code you could escape to, whereas Flutter really is using web APIs, like Wasm, ARIA, WebGL, JS, WebComponents, and so on, to create true web apps that just happen to not use much of the control set that HTML exposes.
I suspect that even outside of Flutter, the web in general is going to move towards this kind of framework in the coming years. It just gives you so much more control. It's basically how every other platform works -- pick your language, compile to machine code, don't need to be limited to what HTML and CSS (etc) enable.
Not really. They were not portable. NPAPI was not a web standard in any meaningful sense (hint: the first N stood for Netscape).
> That's why there has never been a UI toolkit as successful as the web.
The web's success in terms of active users and in terms of deployed content is astounding, certainly. I think I'm relatively well placed to understand why, and I don't think it's because the web restricted developers to one scripting language or one set of controls. I think it is very much _despite_ that.
Really not fair to compare against flash in this way when wasm wasn’t available and npapi was the only option. That is additionally an implementation detail, Adobe could (theoretically) revive and port flash to wasm today without breaking the majority of applications.
So this is already a pretty toasty section of comments so let me put this to you. If you've already answered this elsewhere, please let me know.
I would be surprised if someone heavily involved in the Web's development process for a long time didn't have some really sore spots about it.
That aside:
--
What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
Fairly loaded questions I guess, but realistic ones too, not just philosophical.
> Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I got into web design/programming in the 90s, and the answer is basically no. Sure you could poke around a bit, but I never found it to be a revelation. I still had to buy books, read blogs, and do a ton of trial and error. Also, it was a never-ending game of trying to testing to see what each new browser release added or broke.
> What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages.
I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we sailed past the point where view source stopped being useful years ago. Everything now is minified, and sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
> How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
> Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
I have not. A lot of people do like extensions though.
Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
> Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using HTML/CSS/JS, even if not perfect.
Perhaps if Flutter became mainstream enough that there's theoretically nothing stopping this from eventually happening for it as well. That's an interesting thought.
--
I suppose that leaves my last question, and it leans away from what might be a practical view from your position: Do you think flutter pushing for major market share while also trying to replace the core part of the web (HTML/CSS/JS -> Canvas renderer/wasm) is a good thing for the web's health and future?
(That's a good bit more philosophical, but I hope in #CURRENTYEAR we're starting to see value asking long-term questions like that, especially from inside of the giant companies. I'll stick to one of those kinds of questions)
--
> I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
That is interesting, thanks for sharing that.
> I have not. A lot of people do like extensions though.
Also interesting, fair enough.
> Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
Perhaps a good new question is what kind of tooling is available or planned for users to interact with Flutter applications? Such as what Devtools provide, or an expansion to them directly.
As a developer, the Devtools are absolutely critical to my workflow and ability to learn from and often fix issues I have with other sites.
(It could be pointed out that native applications don't tend to have that functionality, so it shouldn't be expected.. but in this context we're talking about effectively removing it from the Web, which does)
I mean, I try to use Devtools on other sites, but I haven't really had any real success with that for years. I don't know how many of the rest of the web's ~4 billion users try to use DevTools but I can't imagine it's anything close to a majority. Or even a large minority.
FWIW Flutter isn't trying to replace the web. We're trying to offer a way of writing web apps that aren't really possible today. For example, something like the Flutter Folio demo, which works on multiple platforms including web, was written in a few weeks. I cannot fathom how I would do that without Flutter.
It's painting stuff in a canvas and not using the standard web controls.
It's the web in the sense that almost every UI toolkit also offers a canvas (for example Tk does this) and you can reimplement every control using it. That doesn't make your new toolkit in a toolkit Tk.
But why would an app that writes to a WebGL canvas be any harder to maintain than an app that uses HTML controls? If anything, it'd be likely to be easier to maintain -- we (the web standards community) are much more likely to change how a particular element is supposed to work than to change WebGL in an incompatible way.
But the framework? That will have to be updated when each OS the framework runs on changes.
The HTML controls are used by a ton of stuff, so they're quite likely to be updated. Your framework? I have to really, really trust you that you'll update them.
Look at how Motif or GTK or AWT or Swing or Tk widgets look on modern OSes. There's an entire graveyard of cross platform UI libraries out there.
Annoyingly yes. If flutter web behaved like a true web(whether that be through building html elements or through canvas), it would have been a breath of fresh air and for once not a cluttered codebase of 8000 npm modules, html templates and a ditch full of css and no idea of figuring out which is which and which comes from where. I can kind of see a market for it in a sense that I don't want to install a separate app to track my shipment from a specific courier and have a web which is easily accessible on my phone but those are very narrow niches and honestly I can't think of a business that would invest into something like that for nothing more than accessibility. Aside from that I strongly stand by the statement that flutter is the best option for cross-platform mobile apps by a very long shot.
> This is the result of rendering everything to a <canvas> element.
If the accessibility story isn't rock-solid, frankly this is a non-starter for a lot of applications. Web apps suck in a lot of ways but regular HTML has pretty great accessibility properties.
I guess it's just the two ways of approaching a problem. Make native look like web or make web look like native. Both are kinda bad.
The labyrinthine rats nest of absolute hot garbage to beat a document rendering engine into a windowing toolkit with widgets is horrible. It's a testament to front-end devs that with enough effort you really can squeeze water from a stone.
And then imagine being so comfortable navigating that maze that you want your windowing toolkits to behave more like document rendering engines pretending to be windowing toolkits.
And you're like "why not just have a windowing toolkit for the web and sites can choose their rendering engine basically so all the SPAs get all the nice features of stack-based GUIs and document people get documents. Surely that would be less work!" And I think you're right but I doubt anyone would agree on a single toolkit so now you can just bundle your own compiled to wasm and rendered to canvas. Woooo.
Which mostly died from JVM startup time (Think 30 + seconds). There was other issues as well (security and UI issues mostly) but if you knew what you were doing, Java applets were not bad for the time IF the JVM as already loaded.
Accessibility is actually a really big deal here on Flutter (Ian Hickson and I both worked on Accessibility in browsers for years). AX is something I feel we've done pretty well with on iOS and Android. Web is still pretty early days, but many AX features should work already. We have more AX work to do on web yet. We've not yet taken any Flutter Web apps through Google's accessibility testing processes similar to how we've done on the mobile side, but I expect we will soon.
Things changed a lot, I observed the same symptoms as late as late 2020, I can't reproduce these issues now
In general Flutter for Web is _amazing_ if you want to deploy an app.
after seeing this thread, pretty clear to me its almost a perfect nerdsnipe - makes perfect sense if you're already building a Flutter codebase, sounds bonkers if you build web apps.
Check out Flutter Folio [1], built in partnership with Google. Right-click is actually disabled, so you can't even open the "Create account" link in a new tab, nor can I right click an input to autofill with my password manager. You can't inspect any image rendered to the canvas element. Furthermore, you also can't blur the form input (although that's probably application specific rather than Flutter's fault).
The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.
We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.
> You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer
This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms.
Instead of a cross-platform development environment doing that for you.
I have to be honest, not trolling at all, genuinely curious to me: I have the same opinion for the completely opposite reason! _without_ "Skia everywhere", Flutter for Web was annoying, because then there was this autogenerated CSS/JS and it might be _close_ to other Flutter platforms, but it often couldn't be 100% of what it was
I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_
Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.
Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides
> Perhaps it's fixable via education and platform-specific guidelines.
I think this is right, but I also think it should be clear to everyone (i.e. in the first tutorial) that not using a Link widget will make this work wrong for all sorts of accessibility and UX reasons. And the Link widget should work across platforms and implement the equivalent of page history correctly.
Maybe it's worth writing down somewhere what the equivalent of each tag from HTML is; what is the canonical way to create an h2, input, textarea, button, a, img, etc.
dstaley just said that those issues happen now. " I just tried a few samples, and ..."
I just tried the demos over at https://flutter.github.io/samples/#?platform=web and I concur, Flutter is utterly horrible for everything the web stands for. So not amazing and seems to actively make everything worse.
We certainly don't think Flutter should replace HTML or other frameworks. We hope Flutter will work well for many use-cases, but the web is huge. There's room for multiple approaches. If it's not working for your use-case it's totally fine with us if you use something else. We welcome constructive feedback on what's not working so we know where to focus our efforts.
Thanks! A great first step would be to have a "web-native" renderer for your web version. Meaning that it'll use DOM elements that the browser to handle the rendering of. Would fix many of the current issues with your implementation.
I have a large Flutter codebase and flutter web is still alpha quality in my opinion, there's way too much jank to make it work properly on a web platform.
The example spinner ( hhttps://flutter.dev/#dartpad-landing-page ) also looks pretty choppy on my Macbook Pro 16. I haven't tried on lower-specced devices, but it doesn't inspire a lot of confidence.
Yeah, that's running in development mode, since it's a scratchpad for live coding. Try something like https://flutterplasma.dev for an example of Flutter's web support when compiled in release mode.
Thanks for the link. To confirm the point of copying text being broken: try doing that at https://flutterplasma.dev/ -- it kind of works, but not really, no.
Ah fuck me. This is awful. You have to be precisely on the text to select it. I frequently offset my mouse a little to the left of the element to ensure I select the whole text. Even a little bit off to the left and nothing.
I love the idea, but this sounds like it's going to be unpleasant for me. Hopefully they figure out these UX things.
Yeah, tiny differences that would nag the hell out of me. For example double clicking for selecting word is implemented, but triple clicking to select whole line is not implemented ;(
I don't think that shows off Flutter's web support. There are no interactive widgets or user interfaces (Flutter's primary purpose?), and the animations are less impressive than demos in DOS from ~30 years ago, e.g. https://en.wikipedia.org/wiki/Second_Reality
As timsneath mentioned above, Dartpad is the dev environment. That means we ship the full Dart and Flutter SDK ahead of time as you can type/change anything in the code box. We also ship debug metadata to give better errors.
In production mode, we do a much more expensive compile to remove the parts of Dart, Flutter, and packages you don't use and to optimize/minify the rest.
It is working in Safari for me, but we've definitely appreciate bug reports if it's breaking for you (https://github.com/dart-lang/dart-pad in this case).
There's no difference between CanvasKit and HTML as far as interactions are concerned. The differences are in pixels and performance. If there are issues with interactions, we'd like to hear about them. Please file issues on Github.
Yep, I’ve been really impressed with react native on the web so far. Our current code base deploys across Android, iOS, web and windows with minimal effort.
>Moving forward, Flutter is the default choice for future desktop and mobile apps created by Canonical.
This is terrible news. I thought Canonical learned from it's last decade of painful failures to converge desktop and mobile. They have different needs and it doesn't work. What this means is another dark age for the Ubuntu desktop environment.
Last time I tested a Flutter-built app on an iPhone X (perhaps a year ago) there was still obvious jank in transitions/animations.
I assume most of the showcases mentioned here (WeChat, Grab, Yandex Go, Nubank, Sonos, Fastic, Betterment and realtor.com) are Flutter-based on Android only?
Is there a well-built Flutter-based iOS app without jank now?
According to AppAnnie, most of these are using Flutter on iOS too: WeChat, Alibaba, Grab, Nubank, Sonos all show up on their list of Flutter-powered apps on the Apple appstore. We don't capture analytics on apps, so our sources here are external sites like AppAnnie (or occasionally, direct connections with the development team).
I tried the Sonos app since it looked very similar on both platforms. It's a lot smoother than my experience from a year ago. (Hard to really tell in the limited set of screens before hardware pairing.)
Edit: If the signup screen in the Grab iOS app is written in Flutter I'm very impressed. I want to believe.
Edit 2: Nubank: I only evaluated the sign-in screen(s), but it has enough animations at what seems like a very solid 60 fps on my iPhone X to convince me that Flutter on iOS is actually a real thing now. Very nice.
Edit 3: Maybe I jumped the gun here. Quote from that post: "We’re also facing hard prioritization decisions, especially in flows and screens that work very well in their current state (native Objective-C, Swift, Java, Kotlin, or React Native) for which there are no near-future update plans."
Interesting you mention it. I've actually been working on a fairly fully featured app in flutter, and was shocked at how well it performed on iOS. Coming from the React Native world its miles ahead in terms of perf, at least in our case.
Shameless plug, the app is https://droppod.gg, an app to find time to play video games with your friends!
I like the idea so I just installed it. In the sign up screen I can swipe back and get to a second sign up screen, then swipe back again and I go to a loading screen forever.
I don't know if that's flutter or you, but it doesn't fill me with confidence.
I tried it - there's some jank here and there, but the general experience is smooth. Image loading while scrolling through your game feed seems to cause skipped frames, but that's not necessarily the toolkit's fault.
I replied above as well. My team has also not been satisfied with the performance of the GPay app on all devices. We've been working with the GPay team since release and made many improvements in both Flutter and the GPay app. I expect there will be an updated GPay app soon, with still more performance improvements in the pipeline.
Maybe publish a Flutter showcase app on both appstores? With Apple's store you'll probably have to jump through some hoops to provide some useful functionality, but it should be doable.
The app works fine although as of today it's still tagged Beta in the Google Play store, which may give some people pause.
NFC on the other hand is so unreliable as to moot the use of Google Pay, which is unfortunate. I really prefer tap-to-pay over anything else, but not at the expense of making people in line behind me wait as I try various workarounds like toggling NFC. I realize there's nothing you can do about it - my grumbling is more a warning to folks who (like me) may have used it previously on the Pixel 2 and loved it. It's problematic in the Pixel 4. :shrug:
0 - Remove any skins / bumpers / cases from the device.
1 - Lock and unlock the device.
2 - Toggle NFC mode.
3 - Reboot the phone.
I've seen some speculation that on the Pixel 4 it could also be due to some flexing in the case. During a two week period where I couldn't find my wallet I spent a lot of time trying to make it work because of Chase's allowing tap-to-authenticate on their ATMs. Out of 100+ tries using those work arounds and several different ATMs (in case that was the issue) it worked once.
I ordered a tile for my wallet since I can no longer rely on my Pixel 4 as a replacement credit card.
Congrats to the Flutter and Dart teams! This is a huge accomplishment.
However, I worry about accessibility story for Flutter applications. Am I naïve? Should screen-reader support be a concern for the kind of complex visual applications that Flutter is built for?
Screen reader should always be a concern! But we built accessibility as a core feature of Flutter from the start. You can read about our support for screen readers here: https://flutter.dev/docs/development/accessibility-and-local... including a session where a developer who is blind shows how to make an app accessible.
Flutter 2 also supports accessibility for web apps, and you can use Windows Narrator, VoiceOver, TalkBack, or ChromeVox screen readers to navigate a Flutter web app.
The real news is buried a little towards the bottom:
> Today we’re announcing the beta release of Google Mobile Ads for Flutter, a new SDK that works with AdMob and AdManager to offer a variety of ad formats, including banner, interstitial, native, and rewarded video ads. We’ve been piloting this SDK with several key customers, such as Sua Música, the largest music platform for independent artists in Latin America, and we’re now ready to open the Google Mobile Ads for Flutter SDK for broader adoption.
Does this mean all desktop integrations have now migrated from alpha and are available on stable releases?
The post isn't 100% clear on this.
I tried out Flutter a while ago, and it's really promising as the only really viable alternative to the JS/browser stack for cross platform GUIs.
Dart is not terribly inspiring and lacks the appeal of other new languages like Kotlin or Swift, but it's fine; as in: boring/easy to pick up and good enough for frontend, although somewhat sluggish.
ps: I personally don't see the design of Flutter Web as viable for production apps, so if you need Browser support, a JS stack will remain the only solution, at least for a few years.
I'm a developer who uses Flutter and the thing I love the most about Flutter is the Dart language.
It's such an easy language to pick up, and if you know TypeScript/Java/JavaScript, it feels immediately "home", you just know how to do things.
Regarding Swift and Kotlin, yes, they have more features, but that makes those languages also harder to learn and more difficult to master. I think Go demonstrated that more simplicity is also important and more features does not automatically mean you'll be more productive (that's not to say that Swift or Kotlin is bad, I just want to express that Dart feels great).
Extensions, null-safety are already here, and data classes are being worked on, so I think the Dart teams listens to the feedback from the community and prioritizes well.
Seems like you've been around long enough to have read In Search of Stupidity. Lots of great stories in there, including one about a super famous tech person who once said the browser is too slow and will not ever be a viable place for apps. :)
A bit later that famous dude literally wrote: "whoever can make HTML sing will win the API wars". About 5 years before people understood what he meant.
Doubt it. More likely this is Google half-assing something else. I doubt Flutter 2 is worth it, since they were just beginning expanding the Flutter team 2 weeks back
It seems to me that "Flutter (2) for Web" is still mostly "rendering widgets/elements to a canvas", and therefore lacking native HTML/CSS, etc, making it pointless in many ways. Am I missing something or did they change this?
You can choose to render to Canvas or to HTML (DOM). Both seem to work equally well, although the canvas one may have a performance advantage on faster devices.
Reading through this thread makes me think the canvas approach has a performance advantage on faster devices (the demos load instantly and feel snappy to me on a Razer Blade Stealth from 2-3 years ago) but probably also has a performance _disadvantage_ on slower devices (people complaining things taking 10-20 seconds to load), etc.
Is that a reasonable assumption?
If so, I wonder if there's anything that could be done to help match the right rendering strategy to devices that handle it better (e.g. DOM on slower devices). Seems easy enough on Android/iOS where you know the device specs (mostly) and can target them, but the web is a huge beast of variance.
I have one Flutter web app in production, and for predictability's sake it is set to only use the web renderer (DOM), not canvas. O have not noticed any issues so far and it's fairly fast on even slow Androids.
I created apps in cordova, react native and now flutter and I have to say flutter beats both by a lot. It's just been such a nice experience. I'm absolutely in love. My most successful app in flutter is https://stockevents.app if you want to try.
I just tried your app, and like the droppod.gg app and every other flutter app I've tried, there are obvious broken UI things. In the watchlist tab, with one item in the list, I am able to scroll and make the one item hide behind the navbar, and it's happy to stay like that.
These things are big obvious things that make me uninstall an app even if I want/need to use it. Again, I don't know if it's you or flutter that made this thing behave like that. But it makes me think flutter apps are all just one big mess.
Haha.. Thanks for your feedback and I totally understand. In this case tho it's my own fault and not flutters. I wanted that fancy AppBar and created that mess myself. I was actually planning on fixing all the broken AppBars in my next release.
I'm a big fan of your app! It has become the main way I consume and watch stock data.
There are some minor issues however. The "Watchlist" header has an issue where it renders under the back button both on Android and iOS. Also the Watchlist view can have some jank while scrolling unlike other sections of the app. Finally it'd be great if the app responded to the system level dark mode setting instead of having it's own toggle.
Overall though, great stuff so keep up the good work :D
The app looks nice but scrolling feels incredibly weird on my iPhone XS Max. Did you write some custom scrolling logic or is that just how scroll views are in flutter?
There’s a bit of chop in the scrolling and it feels completely linear, instead of elastic like native iOS apps feel (and websites).
I'm a long-time fan of pure web apps, but in my experience, it's more streamlined to develop and ship mobile apps with Flutter than with Cordova and some of the other tools that package web apps for mobile.
Exactly, and for all the skeptical folks on here, I do not feel Flutter will the the ultimate solution, just another step forward like Cordoba was for abstracting some things and making development faster and easier and paying the bills by shipping more stuff sooner.
I've been using flutter for a while and it has been great. The developer experience is awesome, and the community has released and maintained some very useful libraries. Dart is a bit strange but they've made some good improvements.
Flutter web last I checked was a bit strange, especially how text selection didn't really work. That was a showstopper for me so I didn't continue, but I'd definitely be interested in trying it again.
I think Dart's new way of declaring variables as null safe by default is very interesting. If you want a variable to be able to hold a null, you have to explicitly say so. It seems a less heavy-handed version of how Golang handles nil, and much better than the standard way of declaring variables in most any other language.
Maybe this is some common language thing I haven't seen before, but it seems an "obvious in retrospect" sort of idea.
Interesting. Typescript seems to need a --strictNullChecks flag, but yeah Kotlin does have this already. (Sadly, Kotlin is filled with so many bad ideas, it's hard to notice a good one.)
Flutter is winning the race in cross platform development. I have been using Flutter for past few days, and I really like the package on whole, tools and community. Having used Xamarin and Qt in the past, Flutter is a lot easier to learn.
I'm curious, when you refer to Qt, do you mean the QWidget application approach or QML? QML is much more like Flutter (but is indeed somewhat arcane to learn how to work with).
I recently discovered Flutter and I love it for making mobile apps. The multiplatform by default with good API and stability is a winning combination. Lots of modern language features from Dart and built in support for two way binding makes GUI programming much easier. I much prefer it to React Native.
What is the API story like now? When I first looked before version 1 was stamped you had to search for 3rd party plugins for features like accessing the camera and such.
We've spend the last 25 years hacking a document renderer and scripting language aimed at 5 line form validation logic into the be-all and end-all of modern application development. Browsers sit at 10s of millions of lines of code, with thousands of people working on them. We depend on a standardization committee to have things like the common controls you could find in a Smalltalk-80 UI, and these are still insufficient for many purposes such that developers end up cramming together a million diffs to create the controls they want, in the style they want.
The writing was on the wall once we had a canvas element, aka a drawing context, and webassembly, aka a vm target you can compile to. We can keep building up giant garbage heap of complexity and saying that's what we meant to do ( https://youtu.be/oKg1hTOQXoY?t=814 ), or we can take step back and ask if we can provide simpler lower level tools on top of that.
With that said, I feel somewhat ambivalent about all of this. Of course the web is an open standard and has provided an incredible explosion of knowledge and utility for everyone. Any sweeping changes to that should elicit feelings of caution I think. Things like accessibility are important, although I think that enough people recognize this that we don't need to worry about it being left behind with this approach and I would also say the ocean of divs approach isn't exactly great for accessibility either.
Will this take off and be the first of a new kind of application development? Maybe, or maybe we'll all look back on it in 10 years and wonder what the hype was. For my part I do feel like some sort of change is going to happen, the current approach of piling more crap on top of the current html app dev paradigm feels unscalable, while the strengths of how it allows for app distribution feel like something that we can never get away from. Will Flutter retain those strengths and leave behind the weaknesses? I hope so, and it make me excited for the future of web development in a way I haven't previously.
> To start with, Canonical is partnering with us to bring Flutter to desktop, with engineers contributing code to support development and deployment on Linux. During today’s event, the Ubuntu team showed an early demo of their new installer app that was rewritten with Flutter. For Canonical, it is critical that they can deliver rock-solid yet beautiful experiences on a huge variety of hardware configurations. Moving forward, Flutter is the default choice for future desktop and mobile apps created by Canonical.
Am I missing something or on web does it render the entire UI in a <canvas/>? I'm looking on the gallery[1] and that's what it looks like. They say they "added" accessibility, though. Does that mean that every bit of functionality you get for free in HTML needed to be re-implemented in canvas? Can you really trust that that abstraction is going to be air-tight?
This is DOA..... fine for some generic/basic app, but I wouldn't touch it with a ten foot pole if you are building a serious app.
This is another attempt from javascript/web front end developers trying to unseat native apps.... with the naive promise that is truly build once, run everywhere...
It hasn't worked since 1995.... as these frameworks get decent, native apps push the envelope and user expectations just increase over time, and apps created by these framework just look outdated or as toys.
Flutter for mobile apps, cross-platform across Android and iOS is pretty amazing. I do not like what they are doing with Flutter Web, but that doesn't change that it is a pretty amazing framework for cross-platform mobile development.
Also, it isn't FE web devs driving Flutter. I know a lot of mobile cetric devs who really love it.
We have used Ionic to build once deploy on mobile and web for years. It works really well for us now. (I am not sure it would work for all usecase but my guess is 99% of non-game apps would be fine).
> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
I don't know how they can claim this. The new Google Pay on Android was noticeably laggier the moment it was released. It continues to be so, and I still hate using it. Now I know the cause.
I don't auto-update any Google app anymore. The amount of bloat keeps piling up with each new update. Google's Product Managers, as great as they are, need to seriously slowdown a bit.
The initial GPay Flutter release definitely had some performance rough spots. We've learned a lot from working with that team since release and have made resulting changes in both Flutter and the app code.
GPay hasn't released since December last I checked, but I expect the next release should perform better on both iOS and Android and we will be continuing to work with them closely over the coming months.
What are you talking about Flutter runs butter smooth on most smartphones at 60fps, far better than what react-native and other half assed solutions on the market.
go ahead and take time to downvote my comments. do you boo
I just wanted to commend you guys on Flutter. I've put off Android/React Native for almost a decade because of how clunky it was and I feel like Flutter finally gets the pieces right.
It is refreshing to be able to start development quickly without worrying about tooling (react-native), CI, etc.
Also I feel like Dart is perfect. It's a joy to use, I feel like this is the future. It's not es6 and it's not Java either.
I had wondered what had happened to this app to make it so slow. It takes around 10 seconds to get past the loading screen and show me anything useful on an S9.
Those seconds are excruciating when I'm at a checkout trying to actually use the app, with a large line behind me and a checkout person staring at me.
As long as the old Google Pay app still does NFC payments, I'll keep using it.
I was also pretty salty that the new Google Pay app was marked as "early release" so you couldn't leave a review on the Google Play Store. That's fixed now though.
All the highly optimistic claims from the blog post and HN comments would be a bit believable if someone could just show us a web demo that doesn't suck hard. Or show us something accessible at the very least.
This is definitely interesting; I'm so tempted to try this.
But the question that comes to mind with this kind of the technology from Google: is there any mandatory Google services that I'd have to use? Just as an example: Do I have to use Google's ad platform or I can use any other service?
For Canonical, it is critical that they can deliver rock-solid yet beautiful experiences on a huge variety of hardware configurations. Moving forward, Flutter is the default choice for future desktop and mobile apps created by Canonical.
Very interessting that i`m on the opposite side of many comments.
For the startup we just founded i was able to crank out a mobile app in less then 3 months without prior mobile or dart experience. Its fast and just works from day one. Certainly something i can recommend for every Fullstack Dev out there who wants to add mobile to his portfolio as 95% of all apps can easily be done in flutter.
The widget aproach for mobile is fantastic cant say it will work the same on the web but certainly on the desktop.
One thing flutter needs is time, that certain champions will be chosen by the comunity (state managment etc.) - see react
But is has a vibing ecosystem that especially empoweres people outside the western world to create beautifully widgets.
When a company releases a new technology for building desktop applications, the primary thing I look for is a really solid fleshed out implementation of a CRUD application:
- sign in to some back end
- create and edit data using forms
- browse data in some sort of datatable/datagrid
- use ajax to GET and POST data
But such a demo is pretty much never there - I certainly can't see it in this case. But surely the vast majority of ordinary desktop applications people need to build are just this ... CRUD with auth, ajax and data browsing.
It would be dramatically easier to give a new technology for desktop applications a try if such a demo was provided.
My problem with Flutter is that it requires the developers to track and maintain parity with native widgets on both platforms; this is a massive undertaking and one that is prone to bugs and subtle mistakes. This is especially a problem for something backed by Google. This downside is not a problem for e.g. React Native which utilizes the platform's native widgets.
> Flutter allows you to handcraft beautiful experiences where your brand and design comes to the forefront.
This isn't strictly related, but can we instead make good, useful experiences that are consistent with the platform instead? I'm sick of companies making their app some lowest common denominator abomination to push their "brand"…
I think that's just coincidental naming, the Flutter mobile framework was founded by Eric Seidel, the Flutter AR company was founded by Navneet Dalal and Mehul Nariyawala.
Interesting. I wondered why flutterapp.com (the AR/VR app) redirected to flutter.dev (the UI framework)... It led me to believe it was the same team. Apparently not. Thanks.
Yeah, flutter.io is the same. Given Google acquired the Flutter (AR) team, I assume it was just easy for them to reuse the domains when they launched Flutter (framework).
This article didn't say why Flutter "1" (that was just named "Flutter") couldn't just, you know... keep evolving. Is this just marketing or is Flutter 2 a new product that breaks compatibility semver style? It's confusing because almost everything they say, they said about Flutter "1" as well.
This looks like a great thing for people who are building web apps and need that app presence and want to keep a unified code base.
That said React Native is plenty good here even if the language ecosystem it's in is a bit of a mess. And I think there's a bit of work to do here with regards to the web before I'd adopt Flutter 2 for my business.
I tried a few different examples both on my desktop and my iPhone via safari and design wise the demos look really good, but the experience left a bit to be desired in terms of choppiness, user cues where pressing buttons left me wondering if anything happened until I saw red highlights around a text box and certain things not working, text highlighting is a big one for me and something I use all the time on my phone.
I'd definitely try Flutter out for a personal application but for my business if I was not going to develop a native app I think I'd still go with React Native for now.
Toyota is going the Tesla way, with touch infotainment systems. Seems like most car manufacturers are headed in this direction. My gut says this is probably going to lead to an increase in accidents, but I don't know of any dataset that shows it. Let's hope this change works out.
Honest question, what's Google's angle with flutter? It's one thing to be develop a toolkit for platforms they have a vested interest in, it's an entirely different thing to create such a toolkit for all platforms, including their competition.
I think there's value in having a certain amount of ownership and control of a developer ecosystem. It's open-source, but Google will probably remain associated with Flutter and have the dominant influence on its future.
I'm not totally sure what you mean by "a toolkit for platforms they have a vested interest in". Google has a vested interest in basically all the platforms out there. They might create Android, but they certainly make a lot of apps for iOS. I'm guessing they'd like to simplify things using Flutter. Mac and Windows might not see a huge number of native Google apps, but that could change over time - especially if they have a way of making a web version and a desktop version out of the same codebase. Imagine a native macOS Gmail client using Flutter. The same code that could compile to JS for the web could compile down to native for macOS.
Having something be open source and widely adopted makes a language and ecosystem stronger. The Go authors noted that they open-sourced Go because it would become stronger as more people used it.
And I wouldn't underestimate the soft power that comes from being in charge of one of these things. VSCode, .NET Core, and TypeScript are all free, but it's given Microsoft a huge amount of soft power in the ecosystem and a lot of credibility and mind-share.
With a cross-platform UI kit, you can definitely end up with a lot of power. Maybe the experience on Android feels better and more native because your engineers are putting their effort into the Android UI and its patterns more. That's not to say that they'd purposefully make the iOS experience bad or anything, but maybe the iOS-style widgets don't get quite as much polish and maybe developers get encouraged or defaulted into shipping Android-style Material Design apps to iOS. Again, I'm not saying this is malicious, I'm just saying that Google might spend more time on the pieces that are important to them. Google's web docs for Flutter could easily include sections for "and this is how you hook it up to Google Cloud".
I think it's also important to recognize that while Android has more marketshare globally, Apple is generally more popular in the US and generally more popular with upper-income folks. Apps like Clubhouse often launch as iOS-only. 11 months after launch and the Hottest New Thing™ is still iOS-only. If Google can convince developers to use Flutter for the Next Big Thing™, it guarantees that it will be available for Android.
I think there's a lot of value for Google. Your teams can build better apps in less time cross-platform. You potentially become a leader in the way that Facebook has with React, Microsoft has with VSCode/.NET Core/TypeScript, etc. You guarantee first-class support for your devices. You guarantee that the new things you want supported will get supported since you can prioritize your engineers on it - and potentially even get supported in the way you want. And potentially some nice tie-ins to Google Cloud and Firebase via first-class support, documentation, etc.
The answer to these types of questions usually boil down to: Google wants to improve the web experience for everyone. They are the biggest benefactor of the web today, so it makes sense they have the most to gain the more pleasant the web experience is.
Also I think they are looking to get revenue with their own Cloud services that integrate seamlessly with Flutter. For example Firebase is the #1 backend most Flutter Devs use.
My experiences with Flutter have been generally impressive and pleasant, but I feel like it's a great GUI framework for an imaginary mobile ecosystem. You can quickly put together a beautiful UI, but as soon as you want to interact with the filesystem, or run a foreground service that won't immediately be nuked by Android, it's completely unclear how to accomplish this, if it's even possible.
There are lots of libraries for abstracting over the differences between iOS and Android for a lot of these things, but it turns out the least common denominator between the two doesn't leave you with much exciting functionality.
Flutter is a Google project so everything is always a bit better on the Android side. Lots of libraries that only exist for Android because most devs come from the Android side, lots of features and widgets that lag on iOS.
I looked at their demos and was less then impressed. Would've probably make more sense to get some mature multiplatform GUI capable tool like Delphi add WASM as their compile target and be done with it.
I'm impressed with this update. The ability to use existing C-libraries should open up a lot of high-performance functionality you'd have to write yourself.
I haven't really looked, apart from glancing, into flutter yet. Now with desktops and mobile, premise seems interesting. How and does it compare to Qt?
My perspective is that Flutter is positioned dead on against Qt's QML. I develop mobile and desktop QML applications and this seems to be trying to be very competitive with it.
Qt also has a WebAssembly build for QML apps on the web but in my experience it has suffered from some of the same issues reported here about the Flutter WebAssembly runtime.
Edit: One key difference is Flutter seems to do everything with procedural code. QML is based on a declarative DSL plus Javascript.
I'm not sure, but I think that you have to use Dart language to use Flutter.
Incidentally, I was pretty sure that Dart was dead. Turns out it's alive. I'm not sure what it is currently, now that it's statically typed, null safe and all. What are Dart's killer features?
It's not clear to me that killer features are really a thing for most languages. Sure Haskell has laziness/purity and Rust has ownership.
But what is C++'s "killer feature"? C interop? It used to be OOP but it's not that any more and yet C++ is still massively successful. What is Java's killer feature? GC? C#'s?
I think most languages don't have killer features, they have killer platforms and frameworks. For C, it was Unix. For Java, it was servers and the broad set of libraries. For C# it was WinForms and now Unity. For JS, obviously, the web.
Flutterfolio.com falls flat on its face on an iPad with kbm. I had to toggle to “precision mode” in the upper-leftcorner to even make an account. Why did I have to press a toggle to register click events? I know ClickEvents and TouchEvents have slight differences on the web, but this is a demo web app that shouldn’t need to consider those nuances to register an account.
I tried Flutter but I just couldn't stand the Dart language. Building interfaces is a PITA too. Crazy nesting is unavoidable even if you split things up into separate methods/components. React Native is much better in this regard.
While Flutter works for mobile I cannot see Flutter for web succeeding. The latter will end up in the Google graveyard for sure.
It’s strange to keep citing https://flutterplasma.dev/ as a sample app. Don’t get me wrong, it’s a nifty and well-written little demo, but it doesn’t demonstrate anything you’d actually need in an app. As a sample for a game engine it would make sense.
I assume it's intended to show web rendering performance, not demonstrate its viability as an app framework.
As a Flutter developer, I don't think Flutter will ever be a great choice for a lot of text-heavy things that people generally consider "web apps" (just going through my tabs now - GitHub, StackOverflow, reddit, Gmail, Wikipedia).
But it will really shine for "traditional" desktop-type applications, but delivered via web (think Rive, Figma, Filmora, etc). I think that's why they're focusing on rendering performance.
That being said, Figma have done an amazing job with WebAssembly (and I guess they rolled their own UI framework?), so it's not like Flutter is the be-all and end-all.
I've never developed with Flutter, but one of the nicest, fastest app I've ever used, Natrium, is built using it. Which to me makes me very interested in developing with Flutter.
Do they render everything themselves to pixels? If so, then does that mean any native integration with, say, a screen reader won’t work? Copy paste using native UI? Any future native offerings that work on top of the view hierarchy and components (really important for accessibility, to start)?
Eh, it's a little murky. I was playing with dart a little. It can in fact create a single binary, but it looks like it's just putting the interpreter with the code.
I say that because if you strip or pack the binary, instead of working it shows the output of running dart with no arguments.
It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.
`dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code.
The approach is not pretty but was chosen as an implementation shortcut.
That's why `strip` does not actually do good things to the binary.
There is no reason to run `strip` on such binaries - because they don't contain anything strippable.
We are planning to fix it some time in the future, we really only expected moderate usage of `dart2native` and only on Linux. Turns out that there is demand for using it all over the place, which includes Mac and Windows and requires things like signing support... And to make executable signable we need to make them real Mach-O / PE executables and not weird concatenations of bytes.
IIRC Flutter compiles your Dart source code to a native platform binary and uses Skia to render the UI. I assume the Flutter Desktop API provides abstractions for creating windows.
Needing more integration support from e-commerce perspective. There are some right ideas like the feel for flash but also some wrong ideas here. Maybe requires here a fresh look at what is needed which can solve developer and business needs.
Hope they bundle a native webview with flutter with a consistent api across platforms. The web will always be a unique case, but that would be epic for other platforms. I'm not coding so much these days but I still want it. :)
Ah yes, the reason for Google's gluttonous usage of space on iOS, where most of their apps are over 200MB in size and most of the remaining ones are at least 150MB.
Yes, but to ship my app to both stores, I would have had 2 codebases if I had done what you're suggesting. It depends on whether your goals have a budget for spending that extra time. Not everyone is shipping an app that has such performance requirements.
don't bother with google technologies. they all eventually become a mess of versions and incompatibilities. googlers create new shiny versions to get promoted instead of incrementally improving existing tech.
Even Microsoft realize that Xamarin is not a tool for serious mobile or desktop development. Sure, you can get apps that work but they are 2.5x larger than if you had written them in Java or Kotlin and offer no more features than if you had done a hybrid mobile app with Ionic instead. Everyone thought Microsoft acquired Xamarin for the mobile dev tooling? No: it was the only way they could get the brain trust and the core Mono team at Xamarin to come work for them.
Stadia has not been cancelled, they just shuttered the internal development studios. The service itself is still alive and getting new games frequently.
If you'd have any clue of the games industry, you wouldn't be saying this.
AAA publishers are pushing heavily for this since it makes piracy and hacking obsolete and they always get what they want - there's no way that this is not the future of "popular" gaming.
I don’t think Flutter offers enough value over Electron to justify learning Dart and leaving behind the vibrant tooling and package ecosystem that JavaScript has.
I long for the day when software development steps out of its infancy and we have one programming language that targets all platforms and frameworks.
Kotlin is pretty great - so you're in this situation where you can either learn Flutter or JavaScript - at least with JavaScript you can also target the web (I'm aware that Flutter 2 also can target the web, but it's not the same thing).
edit: I must clarify - I'm not saying software development must necessarily have only one language, but rather that there exists a single language that can target all environments natively. C was close, but then the web and mobile happened. Java was also close, but no dice. We're getting there, I think.
I don't understand - Math is a great example because the notation is bounded across all disciplines of math. Can you imagine if Physics used different "math" and "notation" compared to Chemistry or Computer Science? You don't have to learn a different math to understand different disciplines in the same way you have to learn different programming languages to understand different programs.
Notation is highly variable in math. Take a look at penrose notation [1] as example of just how different they can be. Most mathematics books will have a definition section in the front stating their notation choices because things are so fragmented. Good luck trying to read something like Russell's PM without a notation guide open alongside it.
