Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

Post reply on HN
Print view View original

151–160 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#151

Post by lizhang »

dingo_bat wrote: post #52
Figs wrote: post #36

Earlier quoted context omitted.

> when the entire contents of the page - including the ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of obfuscated code. Your site would also be unreadable by Google, meaning that you'll be heavily penalized in search ranking and no one will find your abomination of a website designed this way.

If it becomes the norm Google crawler will start running the pages and looking at the content.

Google crawler can already index client side rendered react apps

Re: Introduction to WebAssembly: why should we care?

#152

Post by pecg »

tskaiser wrote: post #101
_red wrote: post #45

Earlier quoted context omitted.

These things are cyclical: * Early computers (1960-1980s): Dumb Terminal - Remote Server * Early PCs (1980s-1995): Local Processing - Remote Storage * WWW (1995-2010s): Dumb Terminal - Remote Server * JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will…

Yet each of those steps solved a different problem. Early computers did not have the local processing power needed to run heavy jobs. Early PCs did not have the storage. WWW solved an entirely different problem, namely distribution and communication. JS et. al. solved the problem of responsiveness and interaction ie. latency. I don't really see those as exhibiting cyclical traits, at best I see it as a correlation ie…

> WWW solved an entirely different problem, namely distribution and communication.

> JS et. al. solved the problem of responsiveness and interaction ie. latency.

I don't think either of these statements is correct. There wasn't a problem of 'responsiveness' and 'interaction' on http to begin with, in fact what Sun and Netscape did with javascript was to overengineer the web because they saw it as a business opportunity to add client-side code. http was designed (badly) to exchange hypertext documents, not to perform transactions over the server, or render video-games, or play music and videos, and certainly not to transfer files, for the latter ftp was desgined (also badly).

Re: Introduction to WebAssembly: why should we care?

#153

Post by [deleted] »

JSONwebtoken wrote: post #30

I haven't been able to find many examples of working WASM projects or experiments for a topic I have been hearing about for years, but here's one that seemed pretty well made: https://d2jta7o2zej4pf.cloudfront.net/ However it appears all the video editting effects render slower through WASM than JS, what's the deal?

[deleted]

Re: Introduction to WebAssembly: why should we care?

#154

Post by jokoon »

azakai wrote: post #125
jokoon wrote: post #13

The toolchain feels pretty clumsy and bloated, there are many intermediary stages that should be done automatically. I hope better alternatives will quickly become available, or at least some package where you don't to install a thing inside the thing you already downloaded and installed.

What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.

I'd prefer a C++ compiler that directly compiles to wasm.

Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake.

I have read tutorials about binaryen and emscriptem, I did not have a fast computer nor a fast internet connexion, and it was so painful and unclear I gave up.

I get that asm.js was great, but it was mostly a hack, wasm should be much cleaner. I don't understand the choice of emscripten.

Re: Introduction to WebAssembly: why should we care?

#155

Post by arnioxux »

People should look at existing emscripten projects to see what the future will be like since compiling to asm.js is already pretty mature (just a bit slow and bloated as noted in the article). Any emscripten project can compile to WASM trivially by adding a `-s WASM=1` compilation flag.

Example projects:

- OCR (tesseract): http://tesseract.projectnaptha.com/

- Computer vision (opencv): https://docs.opencv.org/master/d5/d10/tutorial_js_root.html

- Physics engines, retro games/emulators, entire operating systems, and many many more: https://github.com/kripken/emscripten/wiki/Porting-Examples-...

Re: Introduction to WebAssembly: why should we care?

#156

Post by pjmlp »

kbenson wrote: post #137
pjmlp wrote: post #37

Earlier quoted context omitted.

Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.

So, viral GPL FTW? Seriously, there's no shared libraries in compiled monolithic WebAssembly, is there? I think[1] that means included GPL code will require exposure of the source. Maybe if we're lucky some best practice will emerge that the source is often available as a sourcemap so companies don't have to worry about being sued for infringing the GPL. It sure would be nice to finally see an outcome of companies er…

Shared objects are planned for WebAssembly.

In any case most companies are busy moving away from anything GPL related.

GCC just got kicked out of Android and all Linux alternatives for IoT are using MIT like licenses.

Re: Introduction to WebAssembly: why should we care?

#157

Post by v_lisivka »

AboutTheWhisles wrote: post #126
rekado wrote: post #27

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don'…

I don't understand this fear of webasm. Anyone can run their javascript through minifiers, or compile C++ to asm.js right now. Webasm doesn't move the needle of obfuscation much at all. The binary format can be turned into the textual ast representation directly. http://ast.run/

Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly.

Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS. IMHO (I'm developer myself), main reason is better obfuscation of the code.

Re: Introduction to WebAssembly: why should we care?

#158

Post by zeveb »

feelin_googley wrote: post #143

There is no "war against Javascript" as the author suggests. It just happens to be the chosen language of the now insidious ad-driven corporate-sponsored web browser. It is not Javascript per se , but the so-called "modern" browser that creates problems for so many users. The problem is not even that this program exists. The problem is that users are coerced to use it and it is controlled by a third party that needs…

> It is not Javascript per se, but the so-called "modern" browser that creates problems for so many users.

I think that it's both-and, not either-or. JavaScript itself is a terrible, horrible, no-good language; the modern browser environment is also a terrible, horrible, no-good invasion of privacy and destruction of security.

I do not believe that there is any purpose for which JavaScript is a suitable language (absent considerations of popularity, e.g. as on the web browser), although I could be wrong and am open to counterexamples.

Re: Introduction to WebAssembly: why should we care?

#159

Post by pjmlp »

AboutTheWhisles wrote: post #132
pjmlp wrote: post #2

I am betting when WebAssembly gets mature all Web sites will look like Flash, just coded on the framework of choice, thus finally making the browser just yet another VM.

What does webasm enable that would cause such a massive difference in how people create web pages? Everything it does could be done now with javascript or asm.js, all webasm does is enable the same things to run faster. I can't think of a single site that works like you are saying, yet webasm would only be a 2x-8x speedup over existing techniques.

I guess you missed all those sites using Flash, Silverlight, Applets, WebStart, ClickOnce and many other plugins.

WebAssembly on the long run will enable to bypass JavaScript and target the browser as if it is yet another OS.

Re: Introduction to WebAssembly: why should we care?

#160

Post by [deleted] »

jokoon wrote: post #154
azakai wrote: post #125

Earlier quoted context omitted.

What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.

I'd prefer a C++ compiler that directly compiles to wasm. Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake. I have read tutoria…

[deleted]
Post reply on HN