Earlier quoted context omitted.
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.
Bringing the web up to speed with WebAssembly
161–170 of 172 posts
Re: Bringing the web up to speed with WebAssembly
#162Earlier quoted context omitted.
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.
Even Google’s OCR utility can’t reliably detect German Umlaute in fancy fonts.
Re: Bringing the web up to speed with WebAssembly
#163WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a element.
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.
Re: Bringing the web up to speed with WebAssembly
#164WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a element.
Re: Bringing the web up to speed with WebAssembly
#165Earlier quoted context omitted.
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.
If I understood properly: yes, I do share the bitterness.
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!
Re: Bringing the web up to speed with WebAssembly
#166Earlier quoted context omitted.
Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.
Sure it does, https://github.com/graalvm/sulong http://dl.acm.org/citation.cfm?id=3132204
Re: Bringing the web up to speed with WebAssembly
#167Earlier quoted context omitted.
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.
Re: Bringing the web up to speed with WebAssembly
#168Earlier quoted context omitted.
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.
Re: Bringing the web up to speed with WebAssembly
#169I suspect that the use cases for WebAssembly will be something like this: - - 60% ad and tracking obfuscation - 20% annoying scrolling and transitions - 10% hostile code
The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.
Re: Bringing the web up to speed with WebAssembly
#170WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
>Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are go…
Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors