3 ms·

This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%22&sort=byDate&type=all

This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%22&sort=byDate&type=all https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%... They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen. The best open ecosystem we have on the planet is being body snatched by the closed-as-can-be native app world. The post here is a more developer-centric view of open & I think that's so valuable. It feels like we really used to have a more share-early share-by-default spirit. I think that's one thing that kind of agitated so many folks about webdev, is how share-centric it was. We didn't have established experts, there were no well established patterns, everyone was collectively figuring it out. Finding libraries that might work for you or doodling around with an idea was lead by sensibilities fit & taste. Throw it against the wall & see what sticks. The web today has really become a far far far more hyperindustrialized system, with far more popular (not enforced) norms & conventions. The random lead devs at a company are no longer necessarily intrepid explorers navigating an open sea of possibility. Everything is more set. And we no longer have that spirit of it just being us in the room, of sharing by default. The expectation is there's very very smart far off people building libraries, and we're just working on our app. The mindset has shifted, the culture has shifted, in a way where open is no longer the collective exciting happening place that we are all a part of.

LinguaBrowse 4y ago
I think there's potential in those ideas, if only they are not to the detriment of the Web (which is already working just fine). As an alternative to iOS and Android development, I welcome ground-up solutions as long as they can get text editing right. However, I bring that up as I can't see anyone ever making a ground-up text view as reliable as a browser or native one (consider CJK, RTL, and vertical text, and IME input) without a dedicated team spending years of work and closely examining each platform's equivalent.
- nicoburns 4y ago
  The Rust ecosystem (with cosmic text and parley) is well on the way to achieving this
  - yw3410 4y ago
    Rust does well on the text-shaping and glyph rendering, but the rest of the ecosystem is still massively geared towards Windows and game development. I am rooting for Vello to succeed!
    - overthrow 4y ago
      What would you say is state of the art for Rust-native text rendering on the web? I'm aware of ab_glyph, used by e.g. https://www.egui.rs/ https://www.egui.rs/ but it looks noticeably non-native to my eyes. For one there seems to be no hinting. So text ends up blurry at 96dpi, and since a glyph stroke is thinner than a pixel the text always appears slightly faded, never able to reach fully black or white. I wish these libraries would just use native APIs on each platform to render text, then all these problems would already be solved by the OS/browser. Though I'm not sure if the web has good APIs for that. Maybe there's something better in Rust these days that I missed?
      - yw3410 4y ago
        My personal applications tend to use only monospaces fonts and stick to Latin characters so I can get away with glyph rendering and then a very simple layout algorithm so something like ab_glyph or freetype is enough and I don't need harfbuzz. I'm aware of swash and the other libraries in that stack, but it was going through a rewrite. The Linux support was incomplete, for example, it was dependent on a piped call to fc-list and parsing the output to get the system fonts. Also, if I were doing it via web, I'd be tempted to render to an offscreen canvas and call it a day.
CharlesW 4y ago
> They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen. This is effectively what Flutter does on other deployment targets as well, building a framework and high-level primitives on top of the host's low-level primitives, and in the process abandoning everything good about native frameworks and primitives for the sake of a Google-controlled runtime. It's why Flutter apps feel so janky and awkward, and the same will be true of the web runtime.
- rektide 4y ago
  It's going to run fine everywhere. It's going to work. As a native app strategy I think it's fine. It's immaterial, if it works. But on the web, it is damage. It breaks all user agency, wrecks all extensions, breaks accessibility extensions, prevents scraping. It's a closed world, and the web doesn't deserve this native app mistreatment.
  - CharlesW 4y ago
    > But on the web, it is damage. I couldn't agree more. > As a native app strategy I think it's fine. It's fine in the sense that it doesn't damage open ecosystems in the same way that circumventing the web experience does. It matters if you care about the customer experience. Companies like McDonald's would likely see a significant bump in use and user satisfaction if they replaced their Flutter app with native apps.
    - rektide 4y ago
      Ok, that's reasonable. Thank you for your upfront starting agreement. I obviously have some real emotional attachment to the issue of whether users have agency or not, and this has been a really hard time for me, and hearing some recognition of the jeopardy as relevant is really touching, thanks. I had kind of assumed Flutter was performing fine/native-ish, it just didn't look native native. Different people will feel differently about the importance of native purity. I personally (with apologies) have seen native as a bit of a negative in general (with concerning privacy, dark patterns, & no observability/extensibility), and that's made me care a lot less about React-Native & Flutter & the like there. But if Flutter's really running bad too: that's embarrassing and not good, straight up!! However, two things. The first is a repeat: it won't always be bad. This team is going to make this fast. There aren't real encumbrances to that happening & it will, is what my reading of the tea leaves says. Mostly gut feel, yes, but the plan seems solid. On the web, they're only just getting WebGPU booting, and still using older Dart VMs rather than actually compiling to wasm, so the web in particular is just barely getting started, but I'd expect the mobile situation has gobs of tuning potential too, and the team seems capable & smart & like they have the mandate to bring it. Their new Impeller optimizations to underlying Skia are just landing & already should help a lot, for ex. The other point I'd just raise is the Electron/Slack problem. People all assume Electron is unbelievably awful & slow & terrible, because they used Slack a couple of times & saw it responds slowly. When an app is bad, people tend to blame the framework. Electron is not without sin, but there are examples like vscode where it is quite snappy & fast & universes more featureful & expansive-in-purpose than Slack. No matter what your development target, it's possible to make slow & bad apps. I have no real insider knowledge of the Flutter app situation today, the lay of the land, but I'd caution too much against using current bad apps as an indicator of what to expect, caution against letting current experience too deeply/permenantly shape our belief/disposition (lest these form convictions which lead us astray from the truth everyone else experiences). More than UI, issues like Client-server data models & algorithmic complexity are woefully under-considered everywhere. Few businesses have a chain of command that speaks the tech language well enough to keep the ship from bottoming out or from not just rubbing along the seabed as it travels. It would be unshocking in the least to me to find a bunch of the big name Flutter apps are at Slack levels of quality internally. Then again, maybe it is partially or all Flutter's fault! Maybe I'm wrong and it stays terrible forever! But the Highest Form of Disagreement is to assume these problems are surmountable, and I don't see anything really strongly technically impeding success (if having native widgets isn't somehow a requirement).
EnergyAmy 4y ago
The worst part of flutter's web stuff is that the quality is absolute janky garbage. They're trying to undermine an open ecosystem, and they don't even offer anything useful in return. It's like making a deal with the devil except instead of getting the thing you bargained for, you just get stuck with a pitchfork and also you lose your soul.

LinguaBrowse 4y ago

I think there's potential in those ideas, if only they are not to the detriment of the Web (which is already working just fine). As an alternative to iOS and Android development, I welcome ground-up solutions as long as they can get text editing right. However, I bring that up as I can't see anyone ever making a ground-up text view as reliable as a browser or native one (consider CJK, RTL, and vertical text, and IME input) without a dedicated team spending years of work and closely examining each platform's equivalent.

nicoburns 4y ago
The Rust ecosystem (with cosmic text and parley) is well on the way to achieving this
- yw3410 4y ago
  Rust does well on the text-shaping and glyph rendering, but the rest of the ecosystem is still massively geared towards Windows and game development. I am rooting for Vello to succeed!
  - overthrow 4y ago
    What would you say is state of the art for Rust-native text rendering on the web? I'm aware of ab_glyph, used by e.g. https://www.egui.rs/ https://www.egui.rs/ but it looks noticeably non-native to my eyes. For one there seems to be no hinting. So text ends up blurry at 96dpi, and since a glyph stroke is thinner than a pixel the text always appears slightly faded, never able to reach fully black or white. I wish these libraries would just use native APIs on each platform to render text, then all these problems would already be solved by the OS/browser. Though I'm not sure if the web has good APIs for that. Maybe there's something better in Rust these days that I missed?
    - yw3410 4y ago
      My personal applications tend to use only monospaces fonts and stick to Latin characters so I can get away with glyph rendering and then a very simple layout algorithm so something like ab_glyph or freetype is enough and I don't need harfbuzz. I'm aware of swash and the other libraries in that stack, but it was going through a rewrite. The Linux support was incomplete, for example, it was dependent on a piped call to fc-list and parsing the output to get the system fonts. Also, if I were doing it via web, I'd be tempted to render to an offscreen canvas and call it a day.

CharlesW 4y ago

> They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen. This is effectively what Flutter does on other deployment targets as well, building a framework and high-level primitives on top of the host's low-level primitives, and in the process abandoning everything good about native frameworks and primitives for the sake of a Google-controlled runtime. It's why Flutter apps feel so janky and awkward, and the same will be true of the web runtime.

rektide 4y ago
It's going to run fine everywhere. It's going to work. As a native app strategy I think it's fine. It's immaterial, if it works. But on the web, it is damage. It breaks all user agency, wrecks all extensions, breaks accessibility extensions, prevents scraping. It's a closed world, and the web doesn't deserve this native app mistreatment.
- CharlesW 4y ago
  > But on the web, it is damage. I couldn't agree more. > As a native app strategy I think it's fine. It's fine in the sense that it doesn't damage open ecosystems in the same way that circumventing the web experience does. It matters if you care about the customer experience. Companies like McDonald's would likely see a significant bump in use and user satisfaction if they replaced their Flutter app with native apps.
  - rektide 4y ago
    Ok, that's reasonable. Thank you for your upfront starting agreement. I obviously have some real emotional attachment to the issue of whether users have agency or not, and this has been a really hard time for me, and hearing some recognition of the jeopardy as relevant is really touching, thanks. I had kind of assumed Flutter was performing fine/native-ish, it just didn't look native native. Different people will feel differently about the importance of native purity. I personally (with apologies) have seen native as a bit of a negative in general (with concerning privacy, dark patterns, & no observability/extensibility), and that's made me care a lot less about React-Native & Flutter & the like there. But if Flutter's really running bad too: that's embarrassing and not good, straight up!! However, two things. The first is a repeat: it won't always be bad. This team is going to make this fast. There aren't real encumbrances to that happening & it will, is what my reading of the tea leaves says. Mostly gut feel, yes, but the plan seems solid. On the web, they're only just getting WebGPU booting, and still using older Dart VMs rather than actually compiling to wasm, so the web in particular is just barely getting started, but I'd expect the mobile situation has gobs of tuning potential too, and the team seems capable & smart & like they have the mandate to bring it. Their new Impeller optimizations to underlying Skia are just landing & already should help a lot, for ex. The other point I'd just raise is the Electron/Slack problem. People all assume Electron is unbelievably awful & slow & terrible, because they used Slack a couple of times & saw it responds slowly. When an app is bad, people tend to blame the framework. Electron is not without sin, but there are examples like vscode where it is quite snappy & fast & universes more featureful & expansive-in-purpose than Slack. No matter what your development target, it's possible to make slow & bad apps. I have no real insider knowledge of the Flutter app situation today, the lay of the land, but I'd caution too much against using current bad apps as an indicator of what to expect, caution against letting current experience too deeply/permenantly shape our belief/disposition (lest these form convictions which lead us astray from the truth everyone else experiences). More than UI, issues like Client-server data models & algorithmic complexity are woefully under-considered everywhere. Few businesses have a chain of command that speaks the tech language well enough to keep the ship from bottoming out or from not just rubbing along the seabed as it travels. It would be unshocking in the least to me to find a bunch of the big name Flutter apps are at Slack levels of quality internally. Then again, maybe it is partially or all Flutter's fault! Maybe I'm wrong and it stays terrible forever! But the Highest Form of Disagreement is to assume these problems are surmountable, and I don't see anything really strongly technically impeding success (if having native widgets isn't somehow a requirement).

EnergyAmy 4y ago

The worst part of flutter's web stuff is that the quality is absolute janky garbage. They're trying to undermine an open ecosystem, and they don't even offer anything useful in return. It's like making a deal with the devil except instead of getting the thing you bargained for, you just get stuck with a pitchfork and also you lose your soul.