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

Wasmer 1.0

medium.com

Post reply on HN
Print view View original

91–100 of 168 posts

Re: Wasmer 1.0

#91

Post by robbywashere_ »

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs?

The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today.

Web-assembly is the next step and evolution of this runtime. I can only imagine the sheer number of man hours poured in to javascript to offer the functionality it has today while balancing with security and sandboxing. Nodejs is a different story; Take a look at Deno and its origin.

Web-assembly is sandbox-able run anywhere, ubiquitous runtime which isn't owned specifically by a corporate overlord, and is also which has/or is set to have the evolutionary pressure javascript has. This is huge! Way to go Wasmer :)

Re: Wasmer 1.0

#92

Post by nine_k »

rapidlua wrote: post #28

The article doesn't mention the number/class of CPUs in the system used for the benchmark. It claims that 'Singlepass' compilation of clang.wasm took 2s and 'Cranelift' took 9s. Running the same benchmark myself in Linux on a 4CPU VirtualBox on a MacBook Pro, I see 11s and 42s respectively. For reference , V8/Node.js compiles the same file in 27s. Compiled files were 339 MiB (Singlepass), 640 MiB (Cranelift) and 90 M…

A VM is not the best environment to test speed and compare it to a native environment speed.

I noticed that certain operations take longer on a VM, and e.g. disk performance may differ a lot (and sometimes be faster than the host FS's!)

Also, things being in the page cache can speed up the second and subsequent runs much faster.

Re: Wasmer 1.0

#93

Post by nine_k »

_TA_12_ wrote: post #88

>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside). Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime. On the…

No need to recompile means you can run the same, guaranteed known, signed, etc code everywhere.

Purpose-built sandboxing means you can run untrusted code more safely — e.g. at the network edge, like a Cloudflare worker, a lambda, etc. Same for third-party plugins in apps, etc.

An open standard and open implementations gives you some assurance against lock-in, licensing changes, patent suits, etc.

Re: Wasmer 1.0

#94

Post by nine_k »

philips wrote: post #79

This makes me think why deno[1] wouldn’t be a thing that people use to run WASM. [1] https://deno.land

I suppose a very different runtime would require a very different standard library, which is a key part of environments like node or deno.

Re: Wasmer 1.0

#95

Post by CyberRabbi »

robbywashere_ wrote: post #91

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution…

You don’t need webassembly to run JavaScript on the server side.

You don’t need webassembly to run C++ on the server side.

You don’t need webassembly to run Rust on the server side.

Etc.

Node was necessary because you need node (or compatible) to run JavaScript on the server side.

Re: Wasmer 1.0

#96

Post by pjmlp »

coldtea wrote: post #83
pjmlp wrote: post #34

Earlier quoted context omitted.

Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?

> Houdini is still barely capable comparable with native drawing. Which is neither here, nor there. The web stack (sans Houdini) is powerful enough for 99% of things an app will need to draw. > Layout managers were already a thing in Motif. Too bad Motif was crap and is irrelevant today. > Where is the great web tooling capable to beat Delphi/VB workflows? One could also reverse the question: where is the Delphi/VB t…

If that was the case, Google wouldn't be pushing Houdini, and everyone else pushing WebGL and WebGPU.

By the way, already mastered all CSS tricks to force hardware rendering?

Motif might be irrelevant, yet its ideas live on across all modern toolkits for native programming and the Web had to wait for the WPF team to bother submitting WPF grids to W3C as base concept.

Delphi and VB are doing pretty well.

https://www.embarcadero.com/products/delphi?aldSet=en-GB

https://visualstudio.microsoft.com/vs/features/net-developme...

And their ideas influence one of the best Web RAD tools, that only we in enterprise care to use.

https://www.outsystems.com

Re: Wasmer 1.0

#97

Post by pjmlp »

nicoburns wrote: post #42
pjmlp wrote: post #34

Earlier quoted context omitted.

Houdini is still barely capable comparable with native drawing. Layout managers were already a thing in Motif. Where is the great web tooling capable to beat Delphi/VB workflows?

Canvas isn't far off. The web is excellent for the types of UI that people often want to build for application: nestings of boxes interspersed with text.

Modern native canvas are hardware accelerated, browser canvas can be, but you never know, which is another reason why HTML 5 games are a glimpse of what Flash achieved.

Re: Wasmer 1.0

#98

Post by Santosh83 »

brundolf wrote: post #78
dmitriid wrote: post #75

Earlier quoted context omitted.

> Have you ever tried to play an old game on a widescreen monitor? Even a lot of modern, triple-A games have weird HUD layouts on ultrawide monitors because they have to be re-hard-coded for that aspect ratio. So if they haven't, you just get the layout they're hardcoded to for widescreen monitors. Have you ever seen any UI on the web that approaches the complexity of game UIs? I haven't [1]. Anywhere there's such co…

> Have you ever seen any UI on the web that approaches the complexity of game UIs? I have personally built tools on the web more complex than the game UIs in your link. > Anywhere there's such complexity on the web, you get lots and lots of hardcoded values: from hardcoded media breakpoints to entirely different layouts for different resolutions and screen sizes. ...and I didn't use a single media breakpoint in any o…

Sorry for butting in on this interesting conversation but regarding media queries being code smell, I currently see no other portable way to deliver multi-resolution background images. :-( Without JS libs that is...

Re: Wasmer 1.0

#99

Post by kaba0 »

josephg wrote: post #72
anderspitman wrote: post #49

Earlier quoted context omitted.

That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.

Thats still way more awkward than what the web provides. - I don't need to uninstall / delete a website when I'm done with it - I don't need to pick an executable format. (Portable or installed? windows mac or linux? dpkg or rpm? From the dev's website or through homebrew/apt? Is a portable executable even available for this application?) - I don't need to give the author of the webpage access to all my local files.…

The facebook website managed to eat 1GB of ram alone multiple times.

Re: Wasmer 1.0

#100

Post by kaba0 »

devwastaken wrote: post #19
eitland wrote: post #10

Earlier quoted context omitted.

Don't underestimate programmers and especially web developer when it comes to making software dependent on IE or Chrome just because they can't be bothered to do any QA ;-) Full disclosure: I am a developer, and I use and always used Firefox, for both pragmatic and ideological reasons.

Chrome impliments the necessary features for wasm and webgl. Here's a test: checkaux.github.io Mobile firefox lacks simd, i haven't been able to get its shared memory to work on a local or deployed environment because of bugs in what it thinks is a 'secure context' Desktop and mobile Firefox does not support OffscreenCanvas without turning on flags. It's been years since this was meant to be made. Therefore you canno…

Then there is no point in having a browser platform, because we are back where we started from. Then why don’t we simply run JVM apps, there are at least a handful of implementations, and it has at least a decent GUI (half joking here). But really, the JVM is where WASM may be several years later.
Post reply on HN