5 ms·

flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads

• wruza 2y ago
  This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately. When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
  • 1oooqooq 2y ago
    you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
    • wruza 2y ago
      Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing. Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.
      • saagarjha 2y ago
        In fact the input field is one of the few native UI surfaces in the Telegram app.
      • 1oooqooq 2y ago
        it's not a native widget. you can type styles on whatsapp which is not possible on native input. whatsapp is the poster child of this technique btw.
        • wruza 2y ago
          Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within <p>. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know. So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
    • throwaway19972 2y ago
      Do you have an example of a texting app that doesn't use native input? This just straight up doesn't seem accurate.
      • deleted 2y ago
        [deleted]
  • divan 2y ago
    I disagree with this so much for two reasons: 1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far. 2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinion, of course. And yet, as a developer, I care about using the right tool for the right task, and no amount of browser engine optimization can change the fact that XML-based markup language is not the right tool for modern performant cross-platforms UIs.
    • wruza 2y ago
      Native doesn’t mean web. I meant just an input as it works everywhere on a platform, input core. Partially agree on the web sentiment, it just lacks a proper model, both positioning and styling, for what we call apps.
• chrismorgan 2y ago
  If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean impossible, design limitations of the web platform that in some cases fundamentally cannot be relaxed and in others are very unlikely ever to be. With this direction, scrolling will never be good, text rendering will never be perfect, input and manipulation will never be acceptable, links will never work properly.
  • satvikpendem 2y ago
    Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.
    • chrismorgan 2y ago
      > Flutter Web is for web apps, not web sites When you want to draw this distinction: most web apps will still suffer heavily for many users if they use Flutter. To begin with, few web apps don’t use text, scrolling, or form fields. Games are almost the only thing that may not suffer, or only barely suffer. But beyond that: well, that’s what they say its purpose is, but at least two of the three times I’ve encountered Flutter in the wild on the web, it was inappropriate, and frustrating; regular DOM should certainly have been used. (The third, I’ve forgotten what it was. It was probably similarly inappropriate.) Skia is not the bottleneck. The web platform is. Scrolling is limited on two counts: ① what browsers expose in events is insufficient to match the native implementation (which varies by platform) in scrolling amounts, overscroll behaviour, and related things; and ② the browser is a compositor, and your code will never get access to that layer, because it’s way too deep in performance-, security- and implementation-detail–land, so you’ll always be stuck at least sometimes at least one frame behind “native”, and janky.