Hacker News Reader

Comment by lmkg | Hacker News Reader

I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.

View on HN

I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)

I've said the same, but you just know somebody comes along and says "If we render our entire site into a <canvas> it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.

Agreed. There will also be the "This will prevent scrapers" excuse. Whatever the silly rationalization for all-Flash websites was will be invoked, as well.

Oy, that has to be the most depressing thing I've read all day.

Good luck for that site getting indexed by Google ;)

Just like with AJAX sites, Google will simply support it.

But writing third-party search engines will become even more impossible.

OCR is really not that hard to do.

For english. Do it reliably for many 27 languages, with many different fonts, and the results are useless.

Even Google’s OCR utility can’t reliably detect German Umlaute in fancy fonts.

We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)

Yeah, and V8, so we could just write JavaScript again and wouldn't have to deal with WASM. With a bit support from WASM and a few tweaks to V8 it could run near native JavaScript speed. Let's call it JavaScript paravirtualization.

Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/master/FutureFeat...

If you strip out the legacy cruft it should be much faster. Reduce it to just the components used!

If I understood properly: yes, I do share the bitterness.

<troll> Look at us introduce this great new lang! It will potentially get rid of 99.99% of the current web developers and prevent any future script kiddies from getting in the game!

Behold the speed of our sealed box environment little jimmy!

Stay tuned for next weeks episode of Tech%20Elitism where we cover DRM for the web and public discourse policing!

Most ad blocking is about intercepting specific urls, which can work at a layer below javascript.

They can also do server side ads and make the url indistinguishable from another image asset. They haven't, so it isn't 'dire' enough yet.

HTML is also much a more convenient encoding for content than writing on the canvas. It's fully declarative¹ and everything.

Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common.

1 - You just write your content, and it's there. There isn't more declarative than that.

HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.

Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.

> But that does not explain why people send their text based pages as javascript.

Probably because they're using front-end javascript frameworks which do that, and because they were taught that this is the best and most efficient way to render anything on the web. No one wants to make a special case for text because it seems inelegant.

But it's not the best and most efficient way to render everything. If you have a mostly static site, you don't need the front-end framework.

Canvas is too slow and handles text rendering poorly. If browsers really want to take another step in that particular direction, they're going to have to expose a lower level API for graphics and text rendering.

Yes, something like OpenGL.

Say... WebGL?

Maybe. OpenGL has a lot of history and baggage. I'm pretty sure the current browser engines don't use OpenGL for 2d graphics. I think they still use Skia (Chrome) and Cairo (WebKit). It could be as "easy" as allowing calls to be made directly to those graphics libraries in WebAssembly.

In any case, it should be hierarchical. It should be simple and efficient to move an object and all its children around.

I think you're missing the point. An object and child hierarchy is too high level for what I'm suggesting. Just expose the graphics library and let the programmers handle the rest. If you want something hierarchical that's simple and efficient to move an object and all its children around, great. You write that for your applications. Make it into a framework if others want to use it. But if somebody wants to use a different approach for their application, they should be able to do so.

Well, I'm all for a low level approach. But going a little higher allows the GPU to handle a lot of things. Or do you propose to incorporate something like CUDA/OpenCL into WASM?

SVG perhaps?

Skia makes use of OpenGL, DirectX or Vulkan.

Same here.

I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.

Nothing intrinsically wrong with plugins that are instantly available on every platform.

Hope you keep being positive when Flash, ActiveX, Java, Silverlight get reimplemented in WebAssembly.

That would actually be fantastic. We'd get to preserve all the old stuff built with them, while running it in the browser's sandbox rather than giving it full access to the machine.

I don't think so, at least not from non-professional content producers. There will still be a desire to have an easily written, shared, and rendered document upon which you can give your thoughts.

HTML has always been best at that, and will still be good at that in the future. The only contender I know of would be markdown, which fulfills many of those needs while being even easier to write. Its greatest pitfall in a contest against HTML is that it is by design non-standard, as it is meant to be a pre-render stage document, and presumably your render stage will smooth out any non-standard markdown elements, giving you a standard document in a format like HTML.

Alas poor applets, they were before their time.

The web is mostly documents, with a few apps sprinkled here and there. HTML will likely be around, and in good use, for a long time.

Even the apps will use HTML's model via their DOM tree.

Yes, and there will be a default WASM code that interprets and renders the rest of the HTML! (in case anybody still wants to use HTML as W3C defined it).

It can't be that and that alone unless browsers somehow decide not to support the rest of HTML... which seems very unlikely.

Reply on news.ycombinator.com