3 ms·
I've been working on a canvas-mostly render library. Some things like text input would require using the native component to some degree; e.g., the input elemen
by kizer 5y ago
I've been working on a canvas-mostly render library. Some things like text input would require using the native component to some degree; e.g., the input element could be invisible while the canvas would render the text field in its place.
Honestly, why even bother with the DOM? Even for "article" sites; you can have pixel perfect control over your rendering, especially if you even implement your own anti-aliased bezier curve rendering algorithms. There's already a library that processes fonts (opentype.js) and returns the parameters of the bezier curves that need to be drawn to construct the glyphs.
You're fine still using HTML/CSS for a bunch of reasons (lighter static sites, already have developed codebases for each).
But, why not own the whole thing in TS/JS? For web applications, you'd then have pixel perfect consistency across browsers and mobile devices. There are two ways Flutter, for example, compiles to a web application[0]: either to a mix of canvas, CSS, SVG, and HTML, or just to pure WebGL Canvas using a WASM build of Skia (that's right - the engine that renders HTML/CSS in the first place).
So with WebAssembly and the Canvas, especially taking into account the upcoming WebGPU API which will unlock even better render performance, I'd rather have my whole application be defined in JS/TS and own all of the experience down to the pixel -- complete control. Obviously this is assuming convenient libraries (in WASM/JS) for rendering text/curves/etc. to canvas will exist.
Would be awesome for certain web app usecases.
[0] https://flutter.dev/docs/development/tools/web-renderers https://flutter.dev/docs/development/tools/web-renderers