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.
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.
I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.
So no pizza demo for me.
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”
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
Furthermore users don't care about the technology used to build the application if it works, that's the unfortunate reality.
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.
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.
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.
It’s not about controversy. It’s just that in most apps, the UI is far more than 10% of the code base.
No, just non-represenative of most apps, who are closer to CRUD than "GPS Navigator".
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.
emscripten/WebAssembly is pretty viable.
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.
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.
...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 :/
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.
E.g. JS embedded in C code:
...called from C:
...and a C function:
...called from a JS function embedded in the C code:
How about debugging? Is it possible to step through a mix of C and JS stack frames?
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".
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.
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.
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.
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.
I'm not sure about the quality. I'm bullish on Flutter but the iOS reviews for the app are awful.
>Is it that hard to find developers who know more than one programming language?
Who said everybody has a team or this luxury?
Nobody needs native UI. It's time we get passed that!
Qt for WebAssembly is available under the GPL3 and the Qt commercial license, though.
Those were painful days...
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.
- 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 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.
Dart literally has reactivity build in, like RxJava or RxSwift. You have no idea what you're talking about.
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.
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
Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)
Ionic 4+ is a complete rewrite from the ground up to use web components.
I use it in a non-traditional way, I do vanilla js + lit-html + web components and it works great.
Performance is smooth, mobile first approach makes responsive apps straightforward.
I don't do any of the native things or command line app creation or any of that.
I've been generally pleased with it.
Sadly, a shrinking market day by day.
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 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.
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.
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.
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.
Just bite the bullet and go native upfront.
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.
Some examples from the top of my head:
- various performance issues (e.g.: memory leaks which haven't been fixed for years )
- 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)
 - https://github.com/ionic-team/ionic-framework/issues/19242
My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue . 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.
 - https://github.com/ionic-team/ionic-framework/issues/17902
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.
You cant blame them for being skeptical.
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.
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 ?
This is a mantra on HN. But is it true? I don’t think it is if you’re trying to build a big product mainstream people will use.
People want native apps. No one needs the apps to work in 25 years. The web is just part of the picture, an important part, but still just a part.
I'll take a well done web page anytime over a native app.
That is an oxymoron.
Blanket statements don’t work.
Secure Shell 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.
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.
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.
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.
Web is still great for Discovery though.
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.
Which platform did Clubhouse build out first? Why?
Advertising accounts for 99.9% of Facebook revenue, with mobile advertising accounting for 94% 
Not sure for the other ones.
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.
Anyway, I do still wonder: if FAANG had to pick between native and web apps, which do you think would they pick?
A: web, for sure. That's how they make their money.
A: I wonder how much money they would lose if they shut down their website? Would they sell their stuff on A instead?
N: Who cares, it's only there to make the acronym nicer.
Facebook could have shut down their Website and it wouldn't even have a 10% revenue impact.
Today, 10 years later, I say Web.
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.
Only because OS vendors made them believe that.
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"?
Wanting / Loving something to succeed is one thing. Whether it will actually work or succeed is an entirely different matter.
For what it's worth, people had the exact same mantra about internal combustions engines for decades any time someone brought up electric cars.
You're absolutely right that entrenched systems are hard to change and attempts to change them mostly fail... until one succeeds.
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.
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.
But... think of this as new Adobe Flash. Or a new MS Silverlight. Some people use it, mostly for privately hosted local apps. Most people won't.
PS. And then Google will probably kill it anyway
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.
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.
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.
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.
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.
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.
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.
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.
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...
(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.
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.
The Medium post 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.
Good for games.
But a demo site asking to register an account to see the demos? I gave up. It almost like they are not interested to show their demos.
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.
I can't experience this problem, for my browser only displays for this site a beautiful, immaculate, plain white page :)
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.
Works fine on Firefox and Chrome.
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.
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.
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.
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.
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.
COBOL is still being updated, it even supports OOP now, yet it shows its age and its joints creak a little, just like
And hey, it might even become hipster trendy eventually.
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.
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.
They're still updating GWT, so I'm not sure what you me by that.
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.
Someone in our team had a small Android TV app working in 2-3 days with WebSockets, web views, some animations, etc.
What kind of an argument is this?
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.
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.
The Dart implementation seems much slower than the NodeJs implementation and it doesn’t bring anything new to the table? It added null safety today.
Anyone that knows if it has any feature beyond for example what Ocaml has?
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.
Saying "any decent language" assumes we know without measurement the very thing that we need to measure.
Showing "very similar performance characteristics" is a valid outcome.
So how different are the "busy" measurements?
To understand actual performance first understand what approaches were used.
How programs are written does matter.
What if we can all see implementations that are not wildly different?
But the argument here started as "Hey look language A is faster than language B" , while pointing out completely different implementations, which is, absurd.
danielscrubs referenced measurements which showed similar performance for Dart and NodeJS programs, but did not mention that similar performance.
nbody dart 8.44s nodejs 8.37s
regexredux dart 4.89s nodejs 4.79s
Those don't seem much slower.
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.
I suspect you could learn it very quickly.
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.
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.
But. They. Won't.
Can you think of a "minor Google property" that is open source?
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.
Flutter is not better or easier than SwiftUI. Especially in accessibility or native performance.
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.
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.
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.
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.
- Memory management without GC
- Unboxed data structures
- Shared-memory multi-threading
- Precompiled snapshots (does not need to be recompiled on page reload)
JS has atomics and shared memory arrays which also basically bypass garbage collection 
JS had working simd.js implementations in both Firefox and Chrome until they were pulled in favor of WASM
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).
I'm not surprised. You probably happen to agree with the majority of HN on these topics so the upvotes outweigh the downvotes.