Hacker News Reader

Comment by frik | Hacker News Reader

We should sometimes pause, and think about the disadvantages a new technique will bring to the web.

I am completely fine with asm.js.

Though WebASM is a like a wet dream for big corp with mass of legacy code in C++. We will see Office running on WebASM and other closed binary blobs in near future. It's very contrary to the concept of the open web - do you want to live in AOL-land again, were everything is closed off? No? Anyway great you helped them. I fear WebASM has several downsides that will harm young startups a lot in near future - only unicorns and big corps will benefit, it will be a win-win, less competition, because of harder entry to market, and they can ship their decades old C++ blobs as a service. It's time to wake up, and stop WebASM or severe limit it's functionality. Where is Mozilla foundation? Or is the new Mozilla just another startup, backed 90% by Google money.

View on HN

I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript. If a startup relies on JavaScript to keep out competition from C coders, well, too bad. They will be decimated in terms of performance. The web will be ruled by the best performing apps written in the language of the Linux kernel.

Performance in web apps is not a goalpost for everybody. While there's certainly web apps that are problematic in terms of performance, you're unlikely to be running at 100% CPU the whole time, so it's not like using C will be the right solution.

I can see how C/C++ (and, well, more likely Rust) will become a de-facto solution for when you need performance or some type of robustness to your apps (ie probably the right thing for Figma). But the potential performance improvement might be negligible on most makes, and unlikely to offset the fact that you'd be working off a completely different stack making things like debugging and inspecting much harder.

What I think is likely is that using WebAssembly will allow new types of web apps to become popular. Things like video encoders, image editors, etc. Things that you just wouldn't do with JS anyway, at least not in the heavy parts. Thing of a standard web app that uses ffmpeg on the background.

>Performance in web apps is not a goalpost for everybody.

But in 2017 startup and companies are starting to understand how fast response times (on a website/web-app) are of critical importance for gaining a good user base.

True, but in my experience bad UI response times are more related to something goddamned dumb like running a series of super expensive scroll events or watching DOM changes for some idiotic reason, more than about raw processing power.

A C solution might make the former faster, but it'd still be a dumb architecture. A cheaper solution than migrating your whole codebase to a separate language and build process is knowing how to deal with events and how to parallelize (or delegate) stuff correctly.

>I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript.

Not only you but many, many programmers out there in other languages, wishing for more performance, or for a higher level of abstraction. I will brace myself for the amazing applications that will be built now for the web.

afaik you can not just take a C++ blob, compile to WebASM and be done. Your business logic can be there, but the User Interface would still need to be JS and HTML in the end, unless you want your app to just draw to a canvas, but even that would only work if you rewrote the rendering as webasm has no access to OS level libraries

>unless you want your app to just draw to a canvas,

Don't count this out; there opens up the opportunity for creating new, good looking toolkits that are faster to use than coping with html + css' limitations.

not sure if that's a viable alternative for the web. It will most likely consume more computing resources which makes it hard on mobile and the responsive web goes out of the window. It can make sense for certain interactive elements though.

The rendering of (html+css) to the screen already uses resources on regular web browsing. This wouldn't be needed (if using a GUI toolkit under Webassembly) and could probably run much faster.

The open web should be most concerned with users. If big corporate products is what they want on the web, then so be it!

Reply on news.ycombinator.com