4 ms·

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 acce

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

wlesieutre 9y ago
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.
- EvanAnderson 9y ago
  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.
- vvanders 9y ago
  Oy, that has to be the most depressing thing I've read all day.
- gbuk2013 9y ago
  Good luck for that site getting indexed by Google ;)
  - kuschku 9y ago
    Just like with AJAX sites, Google will simply support it. But writing third-party search engines will become even more impossible.
    - Jyaif 9y ago
      OCR is really not that hard to do.
      - kuschku 9y ago
        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.
- vbezhenar 9y ago
  We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)
  - weinzierl 9y ago
    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.
    - jfbastien 9y ago
      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/FutureFeatures.md#platform-independent-just-in-time-jit-compilation https://github.com/WebAssembly/design/blob/master/FutureFeat...
    - dispo001 9y ago
      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!
- mahyarm 9y ago
  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.
marcosdumay 9y ago
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.
- goatlover 9y ago
  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.
  - marcosdumay 9y ago
    Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.
    - krapp 9y ago
      > 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.
      - deleted 9y ago
        [deleted]
      - goatlover 9y ago
        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.

wlesieutre 9y ago

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.

EvanAnderson 9y ago
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.
vvanders 9y ago
Oy, that has to be the most depressing thing I've read all day.
gbuk2013 9y ago
Good luck for that site getting indexed by Google ;)
- kuschku 9y ago
  Just like with AJAX sites, Google will simply support it. But writing third-party search engines will become even more impossible.
  - Jyaif 9y ago
    OCR is really not that hard to do.
    - kuschku 9y ago
      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.
vbezhenar 9y ago
We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)
- weinzierl 9y ago
  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.
  - jfbastien 9y ago
    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/FutureFeatures.md#platform-independent-just-in-time-jit-compilation https://github.com/WebAssembly/design/blob/master/FutureFeat...
  - dispo001 9y ago
    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!
mahyarm 9y ago
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.

marcosdumay 9y ago

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.

goatlover 9y ago
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.
- marcosdumay 9y ago
  Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.
  - krapp 9y ago
    > 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.
    - deleted 9y ago
      [deleted]
    - goatlover 9y ago
      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.