Live data from Hacker News

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

151–160 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#151

Earlier quoted context omitted.

> In fact I'm pretty sure you'll see more opening for C++ developers on the front-end than Javascript ones. I would be happy to take a bet that this will not be the case. The fact is that JS is much easier to learn than C++, has a broader ecosystem in the browser , is faster to write than C++ due to memory safety among other considerations, and is fast enough for app logic. Think about it. C++ code has been supported…

If you're dissatisfied with objc_msgSend performance, you can write C or C++ seamlessly - or use that other language that's partially designed to address the dynamic dispatch nightmare. If you're dissatisfied with JavaScript call performance, you have no choice.

> If you're dissatisfied with JavaScript call performance, you have no choice.

Other than the topic of this article?

Re: Compiling to WebAssembly: It’s Happening

#152

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

> people there routinely download and install new applications

You should look at the data on that.

Re: Compiling to WebAssembly: It’s Happening

#153

Earlier quoted context omitted.

We will eventually come to terms with the fact that Flash was 15 years ahead of everything else on multiple fronts and we ought to have been just chastised the terrible developers doing awful and horrendous things with pretty technically sound software.

HTML5 _still_ isn't able to deliver the quality interactive experiences (Games) without applying a lot more effort. Even "simple" things like cross-browser low-latency sound effects are still difficult. Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up.…

For all the problems Flash had, one problem it didn't have was a lack of mature tooling (compared to its alternatives at any given point in time). A lack of tooling makes making HTML 5 games very difficult, the abstraction layers that existed for Flash don't for HTML 5, at least not to the same level. Even if HTML 5 were capable of precisely the same level of performance, or better, as Flash today it would still be some time before the experience of a content creator reached parity with what already existed for Flash.

At no point has the debate between Flash and HTML 5 content ever included "Content creators will have an easier time with HTML 5". It's an ecosystem that has to develop over time, and HTML 5 the content platform has only approached feature parity with Flash in the past couple of years.

Re: Compiling to WebAssembly: It’s Happening

#154

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.

We should have had a standard like WebAssembly from the beginning. The lack of it is the reason for the outrageous explosion of features in web browsers. At first html made sense: it was ideal for quick transfer and rendering of documents. But today that's not enough. So we keep tacking on layers atop already fat abstractions. And all this fat is trying to support a moving target. At first it was about rendering text, but then it was animations, and then videos, and 2D games, and advertisements, and now 3D games and full fledged apps. Notice that operating systems don't play this game trying to build an abstraction for every possible use of a computer because it's unwinnable. And now, some 25 years since its inception, the web is learning the same lesson.

Web browsers have been like operating systems all along, because they execute programs, albeit with different performance and safety characteristics. That the two are converging upon the same solution to the problem of hosting apps should be reassuring, not concerning.

Re: Compiling to WebAssembly: It’s Happening

#155

Earlier quoted context omitted.

And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but ra…

> people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? Er, because that would be really silly. I like reading HN from time to time. I would never install an app, because I don't use it frequently enough. I definitely would never go through the pain of installing a H…

I don't imagine HN requires web assembly or javascript to work, so it isn't a good example. But your point is right.

I think maybe application sandboxing is an OS job, and the browser should do the caching and invoking of the operating system sandbox.

Re: Compiling to WebAssembly: It’s Happening

#156

Earlier quoted context omitted.

I think you are right, this is a high technical debt solution for letting lay persons install software more easily. App stores already did a pretty good job at this anyway, and have the added benefit of curation. The number of layers of in our software stacks grow faster than Moore's law can handle.

> App stores already did a pretty good job at this anyway Then why isn't the Mac App Store (to name an example) a runaway success?

I kind of answered this with a comment above that mentions "try before you buy". Of course I am just guessing.

Re: Compiling to WebAssembly: It’s Happening

#157

Earlier quoted context omitted.

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anyt…

Try looking at the source of Google.com and saying all it's doing in under a minute. You could look at the APIs it's using - why is it calling XMLHttpRequest or looking at the user's cookies? - but you can do the same with binaries, you just have to use a tool, e.g. 'nm -D ' shows you the external functions the program calls. I held the same position until circa 2008 (?), when JS minifying became truly widespread; no…

So, just give up?

(Please mind that there has to be a strict relation between a minified code and a plain source code provided at some repository. This is not true, at least in terms of the resources needed to verify this and the probability of this being covered by average budgets, for binary codes. – Recommended reading: "Reflections on Trusting Trust" by Ken Thompson)

Edit: At best you're winning a year's worth of Moore's law in performance and are paying for it in terms of page load. On the down-side, binary code is just as bad an idea as e-voting: You're putting the interests of your users against literary trillions of dollars of interest in exploiting the system (yes, the leverage would be enorme) – and if the worst has become true, it's already too late to revert.

Re: Compiling to WebAssembly: It’s Happening

#158

Earlier quoted context omitted.

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anyt…

Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.

Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.

Re: Compiling to WebAssembly: It’s Happening

#159
post #146

Earlier quoted context omitted.

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anyt…

Probably solve it the way we do with the rest of shared libs and open computing: Require the source. Download compiled code from trusted sources. Download a nuget package; dll's. Download an apt package; binaries and so's. This won't blow up web.

Not your everyday real-life story. Client: "Integrate this (see attachment)". You, "No, they have first to hand over the source code in order to allow me auditing their software." Client: (gone).

As for the real-life example given above: The third party is billing the client only a few bucks, since the real business is in profile building and exchanging profiles. So, are they expected to hand out the source code for 5 bucks or so? Probably not. Who is to lose? Everyone visiting the website.

Re: Compiling to WebAssembly: It’s Happening

#160
post #130

Earlier quoted context omitted.

I'm sorry, this is going to be a rant. Feel free to ignore if you don't care about my opinions on the subject. The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. It's why we use JSON or XML instead of ASN.1 for our daily work. The open web is a web where no company is the gatekeeper. It's a web where we have mul…

I agree with you on some points, and disagree with you on others. > The open web is a web where no company is the gatekeeper. Absolutely! > The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier, it's a technical solution to a technical problem. I think "view source" was essential to the web we have today. It's not just a technical solution to a technical problem -…

I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites.

As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can and did teach many other people to make websites the same way.

Nowadays it seems to me like you don't have a hope in hell of hand writing a website (maybe some people still do seem like an exercise in frustration to me). Everything is all frameworks and scripting languages.

Earlier this year 20 years after I wrote html pages for my school's web site I had cause to write some HTML again. I work as an engineer (the non software type) in an industrial plant. I needed to display some non critical data to our plant operators on a screen in the control room. I thought 'hey I'll put it on a web page'. It would save me from having to mess around with C which is what our HMI system is written in. So I built something using 1990's era HTML mostly from my memory (although I did move on to using tables instead of frames) It worked.

A few weeks later some one asked to make it possible to view historical results so I built a simple html form (also 1990's era technology) to allow user to input the date range he wanted to view results from. It worked but did no input validation was finicky about the format you enter dates into it etc...

A few weeks later I decided I'd modernise it - modern websites have things like popup calendars which allow the user to "pick" a date instead of having to type dates into a text field. I found a framework written in javascript which provided those sorts of things and attempted to use it. Seemed to work but a lot of subtle bugs kept popping up.

When you clicked on a date in the calendar such as 12th of January the framework passed it to the form in US style 01-12-2015 format I live in Australia we use 12-01-2015 as out date format. I could find no way to change the way the framework functioned. I searched google and a few other people complained about the same issue seemed to be no solution. I thought I'd dig into the javascript file try to edit the program to provide date in format I needed it to be in. The file was 'minified' impossible to read javascript. I gave up and modifed my script to assume US style date input instead.

Maybe I'm just to old to learn new tricks now but I miss the older simpler web sometimes.

Post reply on HN