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

Sneak Peek at WebAssembly Studio

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 103 posts

Re: Sneak Peek at WebAssembly Studio

#91

Post by epicide »

jeswin wrote: post #78
epicide wrote: post #17

Earlier quoted context omitted.

You've clearly never tried to support more than one browser. That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc. Are there downsides? Sure, but the upsides vastly outweigh them for most users.

> You've clearly never tried to support more than one browser. Please be as polite in a forum as you would be during a face to face conversation. You'd never start an office/remote work conversation with that line, would you?

I actually have started face to face conversations like that, but admittedly had tone of voice to soften it.

I can see how it can sound harsher than intended in text-only.

Re: Sneak Peek at WebAssembly Studio

#92

Post by tom_mellior »

AnonCoward222 wrote: post #79

I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.

Well, that's kind of what the README file is there for.

Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me.

Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file.

So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.

Re: Sneak Peek at WebAssembly Studio

#93

Post by dmix »

tyingq wrote: post #74
dmix wrote: post #61

Earlier quoted context omitted.

It might be a bit early to claim success though. We're still basically waiting for some mainstream well-regarded adoptions and use-cases. Not to say it's any less exciting in regards to it's potential. But it's important to keep expectations balanced by present outcomes.

The wasm folks will add gc, polymorphic inline cache, dom interop, some time soon. That will enable things like browser side Perl, Python, Go, Ruby, etc, without having to push the whole runtime. Nonetheless, the bloat train will resume at that point. And, the frontend will start having the same amount of fragmentation as the backend. Good news for us, though, is job security. The resulting complexity helps us, at le…

> Good news for us, though, is job security. The resulting complexity helps us, at least in one way.

I don't think I despise an incentive as much as this one, even if it is a natural side-effect, not intentional. It's the reason why large and top-heavy bureaucratic organizations end up being a net-negative as a result of their structure. Despite their well intentioned attempts at 'fixing' the bumps in the road that natural free flowing systems generate, with top-down control and extreme risk management.

Instead of fostering common-sense and individual talent, it creates incentives and attracts people who care more about the organization itself, and their position within it, rather than the outcomes and value creation for which the organization was originally created.

Re: Sneak Peek at WebAssembly Studio

#94

Post by mbebenita »

tom_mellior wrote: post #92
AnonCoward222 wrote: post #79

I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.

Well, that's kind of what the README file is there for. Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me. Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particula…

That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.

Re: Sneak Peek at WebAssembly Studio

#95

Post by angersock »

sctb wrote: post #60
angersock wrote: post #41

WebAssembly Studio is a neat project, and I'm very impressed at the quality of tooling. It's just a shame that WebAssembly itself is a concept so deeply flawed in conception that it is unsalvagable, and that it'll hurt developers and users alike. Does opening the door to frontend development in C, Rust, Java, and the whole menagerie really seem like such a good idea? Consider the mess we've made with Javascript--the…

Would you care to add some information about why you feel this way?

Summed up here, pretty neatly: https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7

Re: Sneak Peek at WebAssembly Studio

#96

Post by bm1362 »

erikpukinskis wrote: post #72
epicide wrote: post #17

Earlier quoted context omitted.

You've clearly never tried to support more than one browser. That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc. Are there downsides? Sure, but the upsides vastly outweigh them for most users.

> You've clearly never tried to support more than one browser. Why do I keep seeing this style of comment on HN lately? Someone expresses an opinion about software architecture and someone begins their response “obviously you have zero experience working in this domain...” It’s such an insulting way to start a conversation. And quite often a false assertion.

It seems like it’s becoming more and more toxic. It’s a place to get your product or project criticized and reduced to the sum of its parts, rather than support.

Re: Sneak Peek at WebAssembly Studio

#97

Post by stronglikedan »

collinmanderson wrote: post #87
zaarn wrote: post #82

Earlier quoted context omitted.

With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)

> It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?

Being able to use it without internet connectivity, as well as the local file system access and efficiency gains that another commentor pointed out.

Re: Sneak Peek at WebAssembly Studio

#98

Post by collinmanderson »

imtringued wrote: post #89
collinmanderson wrote: post #87

Earlier quoted context omitted.

> It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?

Most likely filesystem access and other native features like desktop notifications. Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing per…

so is web or electron more efficient?

Also, web now has desktop notifications - right?

Re: Sneak Peek at WebAssembly Studio

#99

Post by tom_mellior »

geokon wrote: post #83

The tools for working with WASM are here: https://github.com/WebAssembly/wabt The compiler/converters are here: https://github.com/WebAssembly/binaryen Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone c…

> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?)

Yes.

> So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right?

Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer.

> I don't really get if WASM has memory-managment / garbage-collection by default

It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.

Re: Sneak Peek at WebAssembly Studio

#100

Post by zaarn »

collinmanderson wrote: post #87
zaarn wrote: post #82

Earlier quoted context omitted.

With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually. It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)

> It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one) What do you see as the advantage of native at that point - having its own window?

Electron is basically a standalone browser tab. This is quite resource expensive.

If WASM apps simply use their own rendering, ie the Qt Toolkit they get a much more native feel on top of having a rendering engine that is more optimized for out of browser use (due to not having a DOM, etc.)

It would also slim down the applications a lot, notably when you dynamically link against the toolkit (which also means you share the lib with other apps instead of every app having it's own copy of electron)

Post reply on HN