4 ms·

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 i

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.

oscargrouch 6y ago
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.
- saagarjha 6y ago
  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.
themacguffinman 6y ago
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.
- danShumway 6y ago
  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.
  - themacguffinman 6y ago
    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.
oftenwrong 6y ago
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.

oscargrouch 6y ago

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.

saagarjha 6y ago
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.

themacguffinman 6y ago

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.

danShumway 6y ago
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.
- themacguffinman 6y ago
  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.

oftenwrong 6y ago

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.