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.
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.
[1] https://flutter.dev/docs/development/tools/web-renderers
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...
Chris Sells PM, Flutter
(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[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.
[1] https://medium.com/flutter/flutter-web-support-hits-the-stab...
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.