Discussion on: Rewriting an old project! Part 2: JavaScript

[Jonas Winzen]

Awesome! Thanks for sharing!
Canvas is an interesting and powerful thing and we're using it way less it deserves to be used. Maybe a proper UI library that eliminate the verbosity of working with canvas would make it more attractive.

The expressiveness of Javascript increased orders of magnitude more, than anyone would expect. The rewrite of the Dot constructor makes it immediately visible. It's shorter, easier to understand and less error prone, than the ternary typeof checks of arguments. A single ! there is easily overseen or accidentally introduced and yields somewhat around an hour of debugging fun.

I'm looking forward to your next article. 👍😁

[Ken Bellows]

You know, now that I'm thinking more about it, there actually is a group of libraries that attempts to do this, and I think they use the canvas: CreateJS, and specifically EaselJS, their main drawing library. I played around with it several years ago and remember having a pretty good experience with it, but I didn't do anything super advanced with it.

[rhymes]

Jonas, you mean something like d3.js or chart.js or an actual UI library with components and such?

[Jonas Winzen]

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).

[rhymes]

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!

[Ken Bellows]

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 😬

[Jonas Winzen]

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.)

[Jonas Winzen]

Entire web apps in a Flash style are hopefully gone for good though 😬

Hahaha, yeah ...hopefully 😂

[rhymes]

@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.

[rhymes]

BTW it seems that the HTML5 standard is quite strongly against text editing controls implemented in the canvas.

[Ken Bellows]

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

[Ken Bellows]

As for WASM, I haven't looked into this topic yet, but I have two questions:

1. 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?

2. 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.

[rhymes]

For good reason

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?

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.

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?

I think you can access WebGL from WebAssembly:

• WebAssembly.org demo of Unity + WebGL
• Unity WebGL is switching to wasm as a target
• Using WebGL shaders in WebAssembly

There's a lot going on :D

[Ken Bellows]

Thanks for the compliment! 😁

One thing I find really interesting is the emphasis that the TC39 working group (that is, the folks that develop the ECMAScript spec that becomes JavaScript) often put on intentionally writing very low-level APIs, with the express intention that community members should layer more convenient libraries on top of them. This way everyone isn't stuck with a high-level API that a lot of people dislike. A good recent example of this kind of low-level API is the Shared Memory & Atomics proposal that adds some very important concurrency features to the language. Using these APIs directly would probably be horrible, but there are lots of ways for people with deep understanding of concurrency to layer very useable convenient concurrency libraries on top.

All that to say, I think you're right on the money about Canvas: it could really benefit from some higher level libraries layered on top of it to make it more usable. It's rather tedious to use by hand for anything more complicated than jSphere, but I think that's by design. We really need someone to come along and publish that perfect library that will make the canvas easier to use...

[Jonas Winzen]

Thanks for your answer! 😃

Low level APIs are the very common across recent Browser/Web APIs. Working directly with those low level APIs usually works out until you approach a certain degree of complexity. At some point you are required to build an abstraction layer on top of these low level apis, that serves your needs.
The Shared Memory and Atomics, you mentioned is one example. Another currently very emerging example are Web Component. Writing Web-Components with the browser APIs only is certainly not as verbose as fighting with concurrent memory management, but starts becoming verbose as soon as you want to sync more than two attributes with props of your web component.
Within the last year a lot of libraries for building web-components were released. Each with their own benefits and promises.

So you're absolutely right: low level APIs are a very common and necessary pattern (to serve everyones needs).