Software Engineer at InVision. Full-Stack JavaScript dev, with passion for front-end development.
Psytrance DJ on weekends, playing in local clubs (yeah, that means: Goa Parties!) :D
Well both libraries serve the needs for data visualizations.
What I meant, were libraries to build full blown interactive UIs, based on canvas. In the (not so recent) past, there was a boom of super fancy Web Apps Sites using Flash only to render their contents.
Building user interactions within canvas is quite verbose, same for rendering UI elements (accessibility could be shimmed by an underlying html construct to support screen readers and text selection).
From what I've heard there is a React renderer that renders to canvas. I don't know how usable it is in reality - but I think that goes into the direction I was thinking of.
Edit:For drawing UI elements I found React Canvas and for drawing interactive graphic content I found React Cova. Their use cases seem to be orthogonal to each other i.e. you cant replace one with the other).
What I meant, were libraries to build full blown interactive UIs, based on canvas. In the (not so recent) past, there was a boom of super fancy Web Apps Sites using Flash only to render their contents.
I have only one question: why? Why this would be something that's needed? I'm not sure I understand. Thank you!
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Games are the first thing that come to my mind. Title screens and menus and such with clickable components. Entire web apps in a Flash style are hopefully gone for good though 😬
Software Engineer at InVision. Full-Stack JavaScript dev, with passion for front-end development.
Psytrance DJ on weekends, playing in local clubs (yeah, that means: Goa Parties!) :D
Google Maps is a prominent example, that uses interactive canvas to render large pieces of the UI. Typical use cases would include any interactivity, that goes beyond the capabilities of boxes and text (like zoomable super high resolution images, virtual flip-charts or street maps.)
Software Engineer at InVision. Full-Stack JavaScript dev, with passion for front-end development.
Psytrance DJ on weekends, playing in local clubs (yeah, that means: Goa Parties!) :D
@kenbellows
right, games! I have the feeling that we'll skip canvas UI libraries to go straight to WebAssembly for that type of apps.
For general apps (games included) I'm curious to see if Flutter's Hummingbird will amount to something. With Flutter they are targeting Skia, a 2D graphics library Google built in C++. With Hummingbird they might be able to target the Canvas instead.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
For good reason, I've tried it and there are so many problems that have to be solved just to get it to act like a regular text input, not to mention the accessibility nightmare it creates! (Although I suppose any predominately canvas based app is going to face huge a11y issues...) If I ever need text input in a mostly-canvas-based situation again, I'll just absolute-position an actual <input> tag where I want it and set focus to it or something
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
As for WASM, I haven't looked into this topic yet, but I have two questions:
How much canvas access does WASM have? Wouldn't you still need JS for the actual draw actions, even if some other heavy processing of game states happened in WASM? Is there a planned future where WASM has canvas access, if it doesn't now?
How does how does WASM relate and compare to WebGL for heavy canvas processing? I've actually seen some significant use of WebGL over the last few years for browser games, FPSes and such, and the results have been pretty impressive.
Agreed, the list of reasons not to do that it's quite long on the HTML5 spec :D
How much canvas access does WASM have? Wouldn't you still need JS for the actual draw actions, even if some other heavy processing of game states happened in WASM?
Is there a planned future where WASM has canvas access, if it doesn't now?
They are working on something to help with that. Right now wasm only understand numbers and that doesn't really help if the goal is to have it talk to the DOM. Look for "Easy and fast data exchange" in this article.
How does how does WASM relate and compare to WebGL for heavy canvas processing?
Well both libraries serve the needs for data visualizations.
What I meant, were libraries to build full blown interactive UIs, based on canvas. In the (not so recent) past, there was a boom of super fancy Web
AppsSites using Flash only to render their contents.Building user interactions within canvas is quite verbose, same for rendering UI elements (accessibility could be shimmed by an underlying html construct to support screen readers and text selection).
From what I've heard there is a React renderer that renders to canvas. I don't know how usable it is in reality - but I think that goes into the direction I was thinking of.
Edit: For drawing UI elements I found React Canvas and for drawing interactive graphic content I found React Cova. Their use cases seem to be orthogonal to each other i.e. you cant replace one with the other).
I have only one question: why? Why this would be something that's needed? I'm not sure I understand. Thank you!
Games are the first thing that come to my mind. Title screens and menus and such with clickable components. Entire web apps in a Flash style are hopefully gone for good though 😬
Google Maps is a prominent example, that uses interactive canvas to render large pieces of the UI. Typical use cases would include any interactivity, that goes beyond the capabilities of boxes and text (like zoomable super high resolution images, virtual flip-charts or street maps.)
Hahaha, yeah ...hopefully 😂
@kenbellows right, games! I have the feeling that we'll skip canvas UI libraries to go straight to WebAssembly for that type of apps.
For general apps (games included) I'm curious to see if Flutter's Hummingbird will amount to something. With Flutter they are targeting Skia, a 2D graphics library Google built in C++. With Hummingbird they might be able to target the Canvas instead.
BTW it seems that the HTML5 standard is quite strongly against text editing controls implemented in the canvas.
For good reason, I've tried it and there are so many problems that have to be solved just to get it to act like a regular text input, not to mention the accessibility nightmare it creates! (Although I suppose any predominately canvas based app is going to face huge a11y issues...) If I ever need text input in a mostly-canvas-based situation again, I'll just absolute-position an actual
<input>tag where I want it and set focus to it or somethingAs for WASM, I haven't looked into this topic yet, but I have two questions:
How much canvas access does WASM have? Wouldn't you still need JS for the actual draw actions, even if some other heavy processing of game states happened in WASM? Is there a planned future where WASM has canvas access, if it doesn't now?
How does how does WASM relate and compare to WebGL for heavy canvas processing? I've actually seen some significant use of WebGL over the last few years for browser games, FPSes and such, and the results have been pretty impressive.
Agreed, the list of reasons not to do that it's quite long on the HTML5 spec :D
Yeah, wasm still needs JS. It doesn't have direct access to the canvas but you can access the wasm memory. This is an example of the game of life written in Rust and the canvas API.
They are working on something to help with that. Right now wasm only understand numbers and that doesn't really help if the goal is to have it talk to the DOM. Look for "Easy and fast data exchange" in this article.
I think you can access WebGL from WebAssembly:
There's a lot going on :D