6 ms·

You might want to build your WebApp in Canvas instead of HTML

42 points by wolframhempel 2mo ago

efficax 1mo ago
Not a word in here about accessibility, of course. If you’re blind you’re blind to the canvas as well without a lot of work, it’s much more straightforward to make the DOM accessible
- martinbooth 1mo ago
  It says: > For most web apps, the DOM remains the better choice. It gives you accessibility, responsive layouts, text selection, input handling, and countless other features for free
  - evan_ 1mo ago
    Ah, so literally a word. I was thinking you could probably get a fair bit of accessibility by using <div>s for your text rendering- or by maintaining a separate, hidden outline of DOM elements mirroring what’s on screen.
    - anticrymactic 1mo ago
      > maintaining a separate, hidden outline of DOM elements mirroring what’s on screen. Is there any analysis on the efficacy of this approach? This is always my first thought in these discussions. Performance of WASM with native text IO. Being fully "hidden" one could just use semantic elements, skipping most layout div's, maybe in turn reaping untold accessibility benefits? Being such a simple idea I cannot believe that it wasn't tried and abandoned before.
- josephg 1mo ago
  Yep. Accessibility isn't just a nice to have. Its a legal requirement for a lot of websites under the ADA (Americans with Disabilities Act).
dinkelberg 1mo ago
The dev tools in the browser become much more useless when you draw everything in a canvas. It's gonna be sad when everyone starts using frameworks that draw on canvases. Arguably more sad than when Webassembly came. One could probably write new dev tools for those frameworks though. I also imagine this will be a big setback for web accessibility.
- bryanrasmussen 1mo ago
  yes, and a big setback for the companies that do this when all the accessibility lawsuits hit them.
  - bryanrasmussen 1mo ago
    evidently people do not like to be reminded that if they do inaccessible things they will be sued for it various jurisdictions, and I have been downvoted for not bringing good news.
everdrive 1mo ago
I block all canvas requests. When I can no longer do so, I will just try to use the web less.
- aboardRat4 1mo ago
  Until you have to submit your tax declaration.
zarzavat 1mo ago
Canvas is a last resort if you absolutely cannot build the thing any other way. When you use canvas you're giving up on not just accessibility but also optimizations that the browser does for you transparently when you use the native render tree. There's no guarantee that your app will be faster in canvas, it could easily be slower. Do you really think you can beat the browser's C++ by writing code in a language that doesn't even have a native integer type? Perhaps you can, but your base assumption should be that you can't.
- sghiassy 1mo ago
  Can WASM write to Canvas though?
  - SPascareli13 1mo ago
    You need some JS in the middle but yes, you write your image to a buffer and share it with JS, then in the JS you put it in the canvas.
  - josephg 1mo ago
    WASM can call javascript, and javascript can call canvas. You can use JS bridges to let WASM do more or less anything.
- muglug 1mo ago
  You’re not “giving up” on accessibility. You’re just not getting it “for free” — though it was never free to begin with. When you’re dealing with things like spreadsheet viewers, disengaging from the DOM for sighted users can actually make accessibility simpler.
  - josephg 1mo ago
    > disengaging from the DOM for sighted users can actually make accessibility simpler. Do you have any examples? In my experience, a lot of software written like this just doesn't work with screen readers at all.
bramadityaw 1mo ago
If you've decided to make your next webapp's interface in Canvas, you are jeopardizing what makes the web flourish in the first place: openness. I personally agree with DHH that View Source is one of the browser's most liberating feature. Others in this thread have also pointed issues in accessibility. It's a shame that this is what the web is trending towards with more and more enterprise interest in the internet.
groomlake 1mo ago
I’m always curious how Google, Microsoft and Co. build their web apps - given that they need to work well on any computer, from a top-shelf speed machine to a potato with wires. In my experience, Microsoft webapps (which now includes many of their desktop apps) are rather sluggish. Even the Copilot Chat website. How hard could it be to make a chatbox and a session transcript not be sluggish?
- amiga-workbench 1mo ago
  YouTube too. And I'm not even talking about the video player. Displaying a 4x4 grid of thumbnails seems to be some kind of herculean task.
  - mister_mort 1mo ago
    I think some of the Youtube thumbnail stuff is lazy-loaded, so depending on the speed of your browser and connection it can just hang there doing nothing for a while.
    - amiga-workbench 1mo ago
      5800X3D and a 1gig symmetric line. I really don't know how much more system resource it wants.
- slopinthebag 1mo ago
  All of their webapps are garbage.
- nilslindemann 1mo ago
  The text entry of the Google AI is a catastrophe. Not scalable, sometimes text lines are half hidden, the cursor disappears on empty lines, it eats line breaks after sending the text. I reported it via mail, Google never answered.
- esperent 1mo ago
  Microsoft web apps are sluggish on my i7 with 64gb of RAM. But it's not performance issues, I think. It's networking, they have some crazy interconnected backend spread across about 20 systems and everything you do is going to need to wait for all of those to talk with each other. Switching HTML to canvas isn't gonna fix it.
lisperforlife 1mo ago
I call this the bluebox problem. Back when I worked for SAP there used to be this control called the bluebox control that embedded a browser (shdocvw) into a C++/MFC app. Almost every single annoying UI bug came from that control. I see the same now in the other direction. Every 5 years we come up with the bright idea to use browser as a distribution engine for a UI surface that is rendered by a box. This has historically never worked. I just wanted to recount applets, activex controls, flash, flex (also flash), silverlight, flutter ... and now this. The issue is developer tooling, screen readers, browser extensions and all the other small things that are difficult to account for.
- phoghed 1mo ago
  I’m pretty sure Google Sheets transitioned to this type of thing and it has been successful
johnasmith 1mo ago
Compose Multiplatform is an interesting framework that can render to a web canvas, including full accessibility support.
proc0 1mo ago
And of course, if you're going to go with Canvas, might as well go all the way and write the app in a cross-platform way in one of the many languages that supports Web Assembly and then compile to Web (which then gets embedded into Canvas). That way you could target more hardware and give users more options. There is some overhead but in my opinion browsers should be a backup UI for when you're away from a work station.
xnx 1mo ago
Canvas will be increasingly popular in the arms race against ad blockers.
- tarcon 1mo ago
  Had to remember how ads looked like when Flash was popular. We had fullscreen ads that interacted with the content! Interactive Flash Banner Ads Animation from the 2000s https://www.youtube.com/watch?v=w0Lu8BsjvK0 https://www.youtube.com/watch?v=w0Lu8BsjvK0
bob1029 1mo ago
> So don’t choose Canvas simply because it sounds fast. Choose it when your interface no longer behaves like a document and starts behaving more like a scene. Unity can literally deploy scenes to web canvases with its webgl target. If you are going to use canvas, why not use the most extreme form of it with the most complete tooling available? You can put the universal render pipeline in anyone's browser in 5 minutes. These deployed web assets are surprisingly small if we are responsible with art. Accessibility is even an option because we are leveraging a gigantic corporate engineering team and actually have time to try and solve this rather than reinventing basic layout and rendering concerns. https://github.com/mikrima/UnityAccessibilityPlugin https://github.com/mikrima/UnityAccessibilityPlugin
josephg 1mo ago
Please don't do this. Native controls have dozens to hundreds of subtle UI interactions. Consider a text input element. On macos there are text shortcuts - cmd+A to select all. cmd+left / right to go to the next or previous word. Page up / page down. Home / end. Spell check. A right click menu with about 10 more options, including OS based text services. Tapping on a text input element on ios or android will pull up the native on-screen keyboard, configured in system settings. Every major OS version, the UI changes in small and subtle ways. You simply can't reimplement this functionality in the web browser. Browser APIs don't let you intercept a lot of the keyboard shortcuts you need. You don't have access to macos text services, or the native iOS keyboard UI. Some people try to reimplement this stuff in the browser, but it always feels horrible to use. Nearly native, but laggy. Nothing looks quite right. You can't select text on the page properly. Fonts render slightly wrong. I have muscle memory for keyboard shortcuts that don't work. I hate it.
- satvikpendem 1mo ago
  Read the post. The author talks explicitly about when canvas is useful (unsurprisingly, for canvas shaped apps) versus when to use native DOM elements.
- sunnybeetroot 1mo ago
  Please read TFA > for most web apps, you’re much better off with good old DOM elements. Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers…
  - josephg 1mo ago
    I did read the article. It is not a balanced piece. The title is “You might want to build your webapp in canvas instead”. Almost the entire article - basically everything except for that paragraph - is talking about canvas rendering. About when and why it might be better. There is nowhere near enough discussion of the downsides. If you read this article you could walk away thinking Google docs is implemented entirely on top of the canvas API. This couldn’t be further from the truth. There are a lot of comments in this thread excited by the idea of turning my web browser into a dumb frame buffer for someone’s home grown, laggy, half baked UI framework that cannot function on par with the DOM for hard technical reasons. I don't want to run software like that.
chrismorgan 1mo ago
> The document in Google Docs is a Canvas. This is only mostly true, and no justification at that. I’ll just quote myself from a couple of years ago <https://news.ycombinator.com/item?id=42253177 https://news.ycombinator.com/item?id=42253177>: > Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&type=comment https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications. I haven’t ever examined Google Sheets closely, but it looks to use a similar approach, but worse in scrolling (it’s very obnoxious compared with native on my device—lags fiercely, and breaks inertia). Excel I can’t comment on. Docs should definitely have stayed HTML. Sheets and Excel should probably be HTML, or possibly SVG. For Hivekit’s scheduling interface as shown, I’d say most of the area should be HTML, but that I wouldn’t object to canvas or SVG for the centre area. Now, for their reasons. • Speed: at the level of complexity they’re talking about, this is flat nonsense. Yes, the browser does more than necessary, but a lot of effort has gone into making it perform far better than it has any right to, and DOM performance is not your bottleneck. (I mean by this that, if it looks like it is, it would be if you did the same thing with canvas too.) And as soon as it comes to things like scrolling, you cannot perform or behave as well as the browser, because the browser is a compositor and you can’t work at that level. Even in the rest, unless the entire thing is owned by a single small team skilled at saying “no” and at implementing everything from scratch rather than leaning on others’ libraries, your code is very unlikely to do better than the browser. • Control: it undermines its own point completely by talking of scrolling. You must use real DOM for the scrolling, or else it will be horrible to use on a reasonably large fraction of devices. Note how the likes of Google Docs and Sheets use real DOM and render slices with the adding and removing and such that it criticises. • Consistency: you only get this if you do all the text rendering yourself from first principles, which Google Docs and Sheets don’t do because it performs terribly. So no, this one falls flat too. (I’ll continue more later, got to go again.)
aboardRat4 1mo ago
There is no such a thing as a "WebApp". There are "web pages", which are just plain text html downloaded over http (or even ftp). In 99.9% of the cases it's completely enough.
- snoopen 1mo ago
  There is absolutely such a thing as a web app. What else would you call Google Docs, MS Word and the like?
  - aboardRat4 1mo ago
    Google Docs is a program for Android written in java and compiled into dalvik/art byte code. MS Word is just a program for Windows, written C/C++.
    - satvikpendem 1mo ago
      Sometimes I wonder how people like this navigate real life with such strong opinions and trying to redefine common definitions.
      - aboardRat4 1mo ago
        https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes
satvikpendem 1mo ago
Lots of people here not reading the post and offering knee jerk responses when the author clearly states when and when not to use canvas rendering. For example, you could try making Figma in DOM but it is quite slow compared to Wasm and canvas rendering, as others like Penpot have seen. For canvas rendering in general, this is essentially what Flutter and a lot of newer GUI frameworks like Composer Multiplatform and Rust based GUIs do. Accessibility is possible for these as there is semantic tree support but it's not as "free" as the DOM so it takes a bit more work.
arjie 1mo ago
Huh of course. I have a timeline element in our family EMR that I implemented in html out of ignorance. I just accepted the clickiness of zooming etc. I wonder if rendering it in canvas would make for a smoother zoom or if this is because I implemented it wrong. Lots of interesting work in web UI design.
tomkarho 1mo ago
For the tiniest of moment websites were made using Flash. Granted the technology was mostly games and video but on occasion a site popped up where everything was an interactive flash instead of plain old html. And before that there was java applets. This feels like a similar attempt.
xnx 1mo ago
Page doesn't even seem to mention HTML in Canvas? https://html-in-canvas.dev/ https://html-in-canvas.dev/ https://github.com/WICG/html-in-canvas https://github.com/WICG/html-in-canvas
asdfsa32 1mo ago
Thank you for putting this out, it helps me make sure that I don't touch anything from Hivekit before I can even tell what it is.
frollogaston 2mo ago
People who work on web browsers have ranted that HTML/CSS isn't a very natural interface into the engine, so it's inefficient and has nasty edge cases. I know nothing about browser engines but do find CSS awkward as a user when I'm not making a plaintext website, so have been relying heavily on React for side projects. Been thinking about doing a toy project where I try to build my own alternative to HTML/CSS that runs on top of Canvas, drawing inspiration from how Wayland is actually less abstracted than X11.
- xscott 1mo ago
  You might find this video useful or interesting: https://youtu.be/by9lQvpvMIc https://youtu.be/by9lQvpvMIc I've been tempted to do something similar for browser canvas, perhaps with some slightly different choices than he made. His approach uses a very elegant way of looking at things though.
- satvikpendem 1mo ago
  That's basically Flutter.

42 points by wolframhempel 2mo ago

Not a word in here about accessibility, of course. If you’re blind you’re blind to the canvas as well without a lot of work, it’s much more straightforward to make the DOM accessible

martinbooth 1mo ago
It says: > For most web apps, the DOM remains the better choice. It gives you accessibility, responsive layouts, text selection, input handling, and countless other features for free
- evan_ 1mo ago
  Ah, so literally a word. I was thinking you could probably get a fair bit of accessibility by using <div>s for your text rendering- or by maintaining a separate, hidden outline of DOM elements mirroring what’s on screen.
  - anticrymactic 1mo ago
    > maintaining a separate, hidden outline of DOM elements mirroring what’s on screen. Is there any analysis on the efficacy of this approach? This is always my first thought in these discussions. Performance of WASM with native text IO. Being fully "hidden" one could just use semantic elements, skipping most layout div's, maybe in turn reaping untold accessibility benefits? Being such a simple idea I cannot believe that it wasn't tried and abandoned before.
josephg 1mo ago
Yep. Accessibility isn't just a nice to have. Its a legal requirement for a lot of websites under the ADA (Americans with Disabilities Act).

dinkelberg 1mo ago

The dev tools in the browser become much more useless when you draw everything in a canvas. It's gonna be sad when everyone starts using frameworks that draw on canvases. Arguably more sad than when Webassembly came. One could probably write new dev tools for those frameworks though. I also imagine this will be a big setback for web accessibility.

bryanrasmussen 1mo ago
yes, and a big setback for the companies that do this when all the accessibility lawsuits hit them.
- bryanrasmussen 1mo ago
  evidently people do not like to be reminded that if they do inaccessible things they will be sued for it various jurisdictions, and I have been downvoted for not bringing good news.

everdrive 1mo ago

I block all canvas requests. When I can no longer do so, I will just try to use the web less.

aboardRat4 1mo ago
Until you have to submit your tax declaration.

zarzavat 1mo ago

Canvas is a last resort if you absolutely cannot build the thing any other way. When you use canvas you're giving up on not just accessibility but also optimizations that the browser does for you transparently when you use the native render tree. There's no guarantee that your app will be faster in canvas, it could easily be slower. Do you really think you can beat the browser's C++ by writing code in a language that doesn't even have a native integer type? Perhaps you can, but your base assumption should be that you can't.

sghiassy 1mo ago
Can WASM write to Canvas though?
- SPascareli13 1mo ago
  You need some JS in the middle but yes, you write your image to a buffer and share it with JS, then in the JS you put it in the canvas.
- josephg 1mo ago
  WASM can call javascript, and javascript can call canvas. You can use JS bridges to let WASM do more or less anything.
muglug 1mo ago
You’re not “giving up” on accessibility. You’re just not getting it “for free” — though it was never free to begin with. When you’re dealing with things like spreadsheet viewers, disengaging from the DOM for sighted users can actually make accessibility simpler.
- josephg 1mo ago
  > disengaging from the DOM for sighted users can actually make accessibility simpler. Do you have any examples? In my experience, a lot of software written like this just doesn't work with screen readers at all.

bramadityaw 1mo ago

If you've decided to make your next webapp's interface in Canvas, you are jeopardizing what makes the web flourish in the first place: openness. I personally agree with DHH that View Source is one of the browser's most liberating feature. Others in this thread have also pointed issues in accessibility. It's a shame that this is what the web is trending towards with more and more enterprise interest in the internet.

groomlake 1mo ago

I’m always curious how Google, Microsoft and Co. build their web apps - given that they need to work well on any computer, from a top-shelf speed machine to a potato with wires. In my experience, Microsoft webapps (which now includes many of their desktop apps) are rather sluggish. Even the Copilot Chat website. How hard could it be to make a chatbox and a session transcript not be sluggish?

amiga-workbench 1mo ago
YouTube too. And I'm not even talking about the video player. Displaying a 4x4 grid of thumbnails seems to be some kind of herculean task.
- mister_mort 1mo ago
  I think some of the Youtube thumbnail stuff is lazy-loaded, so depending on the speed of your browser and connection it can just hang there doing nothing for a while.
  - amiga-workbench 1mo ago
    5800X3D and a 1gig symmetric line. I really don't know how much more system resource it wants.
slopinthebag 1mo ago
All of their webapps are garbage.
nilslindemann 1mo ago
The text entry of the Google AI is a catastrophe. Not scalable, sometimes text lines are half hidden, the cursor disappears on empty lines, it eats line breaks after sending the text. I reported it via mail, Google never answered.
esperent 1mo ago
Microsoft web apps are sluggish on my i7 with 64gb of RAM. But it's not performance issues, I think. It's networking, they have some crazy interconnected backend spread across about 20 systems and everything you do is going to need to wait for all of those to talk with each other. Switching HTML to canvas isn't gonna fix it.

lisperforlife 1mo ago

I call this the bluebox problem. Back when I worked for SAP there used to be this control called the bluebox control that embedded a browser (shdocvw) into a C++/MFC app. Almost every single annoying UI bug came from that control. I see the same now in the other direction. Every 5 years we come up with the bright idea to use browser as a distribution engine for a UI surface that is rendered by a box. This has historically never worked. I just wanted to recount applets, activex controls, flash, flex (also flash), silverlight, flutter ... and now this. The issue is developer tooling, screen readers, browser extensions and all the other small things that are difficult to account for.

phoghed 1mo ago
I’m pretty sure Google Sheets transitioned to this type of thing and it has been successful

johnasmith 1mo ago

Compose Multiplatform is an interesting framework that can render to a web canvas, including full accessibility support.

proc0 1mo ago

And of course, if you're going to go with Canvas, might as well go all the way and write the app in a cross-platform way in one of the many languages that supports Web Assembly and then compile to Web (which then gets embedded into Canvas). That way you could target more hardware and give users more options. There is some overhead but in my opinion browsers should be a backup UI for when you're away from a work station.

xnx 1mo ago

Canvas will be increasingly popular in the arms race against ad blockers.

tarcon 1mo ago
Had to remember how ads looked like when Flash was popular. We had fullscreen ads that interacted with the content! Interactive Flash Banner Ads Animation from the 2000s https://www.youtube.com/watch?v=w0Lu8BsjvK0 https://www.youtube.com/watch?v=w0Lu8BsjvK0

bob1029 1mo ago

> So don’t choose Canvas simply because it sounds fast. Choose it when your interface no longer behaves like a document and starts behaving more like a scene. Unity can literally deploy scenes to web canvases with its webgl target. If you are going to use canvas, why not use the most extreme form of it with the most complete tooling available? You can put the universal render pipeline in anyone's browser in 5 minutes. These deployed web assets are surprisingly small if we are responsible with art. Accessibility is even an option because we are leveraging a gigantic corporate engineering team and actually have time to try and solve this rather than reinventing basic layout and rendering concerns. https://github.com/mikrima/UnityAccessibilityPlugin https://github.com/mikrima/UnityAccessibilityPlugin

josephg 1mo ago

Please don't do this. Native controls have dozens to hundreds of subtle UI interactions. Consider a text input element. On macos there are text shortcuts - cmd+A to select all. cmd+left / right to go to the next or previous word. Page up / page down. Home / end. Spell check. A right click menu with about 10 more options, including OS based text services. Tapping on a text input element on ios or android will pull up the native on-screen keyboard, configured in system settings. Every major OS version, the UI changes in small and subtle ways. You simply can't reimplement this functionality in the web browser. Browser APIs don't let you intercept a lot of the keyboard shortcuts you need. You don't have access to macos text services, or the native iOS keyboard UI. Some people try to reimplement this stuff in the browser, but it always feels horrible to use. Nearly native, but laggy. Nothing looks quite right. You can't select text on the page properly. Fonts render slightly wrong. I have muscle memory for keyboard shortcuts that don't work. I hate it.

satvikpendem 1mo ago
Read the post. The author talks explicitly about when canvas is useful (unsurprisingly, for canvas shaped apps) versus when to use native DOM elements.
sunnybeetroot 1mo ago
Please read TFA > for most web apps, you’re much better off with good old DOM elements. Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers…
- josephg 1mo ago
  I did read the article. It is not a balanced piece. The title is “You might want to build your webapp in canvas instead”. Almost the entire article - basically everything except for that paragraph - is talking about canvas rendering. About when and why it might be better. There is nowhere near enough discussion of the downsides. If you read this article you could walk away thinking Google docs is implemented entirely on top of the canvas API. This couldn’t be further from the truth. There are a lot of comments in this thread excited by the idea of turning my web browser into a dumb frame buffer for someone’s home grown, laggy, half baked UI framework that cannot function on par with the DOM for hard technical reasons. I don't want to run software like that.

chrismorgan 1mo ago

> The document in Google Docs is a Canvas. This is only mostly true, and no justification at that. I’ll just quote myself from a couple of years ago <https://news.ycombinator.com/item?id=42253177 https://news.ycombinator.com/item?id=42253177>: > Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&type=comment https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications. I haven’t ever examined Google Sheets closely, but it looks to use a similar approach, but worse in scrolling (it’s very obnoxious compared with native on my device—lags fiercely, and breaks inertia). Excel I can’t comment on. Docs should definitely have stayed HTML. Sheets and Excel should probably be HTML, or possibly SVG. For Hivekit’s scheduling interface as shown, I’d say most of the area should be HTML, but that I wouldn’t object to canvas or SVG for the centre area. Now, for their reasons. • Speed: at the level of complexity they’re talking about, this is flat nonsense. Yes, the browser does more than necessary, but a lot of effort has gone into making it perform far better than it has any right to, and DOM performance is not your bottleneck. (I mean by this that, if it looks like it is, it would be if you did the same thing with canvas too.) And as soon as it comes to things like scrolling, you cannot perform or behave as well as the browser, because the browser is a compositor and you can’t work at that level. Even in the rest, unless the entire thing is owned by a single small team skilled at saying “no” and at implementing everything from scratch rather than leaning on others’ libraries, your code is very unlikely to do better than the browser. • Control: it undermines its own point completely by talking of scrolling. You must use real DOM for the scrolling, or else it will be horrible to use on a reasonably large fraction of devices. Note how the likes of Google Docs and Sheets use real DOM and render slices with the adding and removing and such that it criticises. • Consistency: you only get this if you do all the text rendering yourself from first principles, which Google Docs and Sheets don’t do because it performs terribly. So no, this one falls flat too. (I’ll continue more later, got to go again.)

aboardRat4 1mo ago

There is no such a thing as a "WebApp". There are "web pages", which are just plain text html downloaded over http (or even ftp). In 99.9% of the cases it's completely enough.

snoopen 1mo ago
There is absolutely such a thing as a web app. What else would you call Google Docs, MS Word and the like?
- aboardRat4 1mo ago
  Google Docs is a program for Android written in java and compiled into dalvik/art byte code. MS Word is just a program for Windows, written C/C++.
  - satvikpendem 1mo ago
    Sometimes I wonder how people like this navigate real life with such strong opinions and trying to redefine common definitions.
    - aboardRat4 1mo ago
      https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes https://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes

satvikpendem 1mo ago

Lots of people here not reading the post and offering knee jerk responses when the author clearly states when and when not to use canvas rendering. For example, you could try making Figma in DOM but it is quite slow compared to Wasm and canvas rendering, as others like Penpot have seen. For canvas rendering in general, this is essentially what Flutter and a lot of newer GUI frameworks like Composer Multiplatform and Rust based GUIs do. Accessibility is possible for these as there is semantic tree support but it's not as "free" as the DOM so it takes a bit more work.

arjie 1mo ago

Huh of course. I have a timeline element in our family EMR that I implemented in html out of ignorance. I just accepted the clickiness of zooming etc. I wonder if rendering it in canvas would make for a smoother zoom or if this is because I implemented it wrong. Lots of interesting work in web UI design.

tomkarho 1mo ago

For the tiniest of moment websites were made using Flash. Granted the technology was mostly games and video but on occasion a site popped up where everything was an interactive flash instead of plain old html. And before that there was java applets. This feels like a similar attempt.

xnx 1mo ago

Page doesn't even seem to mention HTML in Canvas? https://html-in-canvas.dev/ https://html-in-canvas.dev/ https://github.com/WICG/html-in-canvas https://github.com/WICG/html-in-canvas

asdfsa32 1mo ago

Thank you for putting this out, it helps me make sure that I don't touch anything from Hivekit before I can even tell what it is.

frollogaston 2mo ago

People who work on web browsers have ranted that HTML/CSS isn't a very natural interface into the engine, so it's inefficient and has nasty edge cases. I know nothing about browser engines but do find CSS awkward as a user when I'm not making a plaintext website, so have been relying heavily on React for side projects. Been thinking about doing a toy project where I try to build my own alternative to HTML/CSS that runs on top of Canvas, drawing inspiration from how Wayland is actually less abstracted than X11.

xscott 1mo ago
You might find this video useful or interesting: https://youtu.be/by9lQvpvMIc https://youtu.be/by9lQvpvMIc I've been tempted to do something similar for browser canvas, perhaps with some slightly different choices than he made. His approach uses a very elegant way of looking at things though.
satvikpendem 1mo ago
That's basically Flutter.