Hacker News Reader

Comment by colordrops | Hacker News Reader

HTML and CSS are slowly losing ascendancy as the main render surface for web apps. The canvas provides a standard pixel buffer for both JS and compiled applications, making HTML's limitations no longer a restriction.

View on HN

Except that rendering everything to canvas is not accessible to people with certain disabilities.

Also mentioned recently here https://news.ycombinator.com/item?id=16347216

At least until we get the AOM: https://github.com/WICG/aom/blob/gh-pages/explainer.md

Sadly, I would that 99% of companies don't care, unless mandated by government regulation.

Simply doing things with HTML doesn't magically solve accessibility issues, either.

A simple DOM representation could be used as a fallback, if possible.

The whole point of the web was not to have people write directly to bitmaps, to leave the presentation up to the rendering platform.

In the quest for eye candy we're losing what made the web great to begin with.

It's not about eye-candy, the Web has become an application platform (against all resistance) and it can't thrive on standards bodies to deliver every bit and piece required. Even in 2018, web applications are shunned by many professionals for their poor quality and performance.

> compiled applications

A lot of HN comments dismissed my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.

A lot of people seem to be focusing on the benefits of new technological changes ("no longer a restriction"), when they should first be concerned with the potential risks that change will create.

[1] https://news.ycombinator.com/item?id=10211050

>my prediction[1] that WebAssembly will bring opaque "compiled applications" that treat the canvas as a "standard pixel buffer", allowing adblocking CSS and request filters to be bypassed.

They could already do that. It's called serving the whole page as an image

Or as a Flash blob, which used to be distressingly common.

<canvas> by its specification mandates pixel buffer to be placed in memory with per pixel access. This reduces GPU acceleration options to the ground.

I don't believe that's true for any modern browsers. They all use hardware accelerated rendering in the common case of drawing to a canvas that will be composited on-screen, and make a copy into process memory only when you access the pixels with a call like getImageData().

Composite operations ( https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende... ) are achievable only on bitmap/frame buffers. And OpenGL's frame buffers are not famous for their performance.

I was referring to compositing the DOM objects onto the screen, which is GPU-accelerated in most cases.

The internal canvas compositing operations you mention are also GPU-accelerated in most cases.

Last I checked, many browser vendors only GPU accelerate specific blend modes. If you do anything fancy your canvas ops silently drop to software.

What are you talking about? You’re able to access random pixels, yes, but first you need to copy them to normal RAM. Canvas 2D and WebGL are both hardware accelerated.

I’ve actually noticed a return recently to simple “HTML native” UI design on the web. Not as many people trying to emulate an “OS native” experience by adding a bunch of extra DOM elements to render borders and effects and such.

From your lips to God's ears.

Reply on news.ycombinator.com