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

141–150 of 168 posts

Re: Wasmer 1.0

#141

Post by KronisLV »

charrondev wrote: post #38
anderspitman wrote: post #27

Earlier quoted context omitted.

The web is a great way to distribute native programs. Click a URL to download, then run.

I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.

I think this is mostly a problem with how the modern operating systems work. Your point is still definitely valid for the real world consequences of this, but i think that theoretically things could be way more simpler.

1.) Click "download" to get a piece of software you need (a static executable)

2.) Put said piece of software in a folder called "/apps/$APP_NAME"

3.) Run said software and have it persist all of its data to "/apps/$APP_NAME/data" or some other convention like that.

Perhaps that'd need to be enforced with sandboxing and limiting access to directories, which would then make sharing data across them more difficult, which would end up with something like "/data/$APP_NAME", which brings us back to the horror of Windows' "AppData" and "Documents" and "Program Data", or other folders like that, resulting in what can only be described as an Eldritch nightmare, in which you don't have any idea in which of the 20-30 different folders which particular stores its data...

But theorethically things could be simpler, i've heard people mention how easy installing apps used to be on Apple devices back in the day. And recently, after running the Godot game engine ( https://godotengine.org/ ), which is literally a single executable, i'm inclined to agree somewhat.

Re: Wasmer 1.0

#142

Post by CyberRabbi »

singularity2001 wrote: post #132
CyberRabbi wrote: post #95

Earlier quoted context omitted.

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.

You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)

Can you provide an example of a situation where it would make sense for both client and server to use the same build?

Typically client and server play different roles and require different builds anyway.

Re: Wasmer 1.0

#143

Post by steego »

CyberRabbi wrote: post #142
singularity2001 wrote: post #132

Earlier quoted context omitted.

You DO need webassembly to run C++ on the server AND client(browser) side. (unless you want to use some hacky c++ to js transpiler)

Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.

The point isn’t to run client code in the server and server code on the client.

The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense.

Embedding SQLite is a perfect example.

Re: Wasmer 1.0

#144

Post by justsomeuser »

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…

I like WASM for technical reasons, but I do not think it will stand the test of time and become a major part of how programs are run.

Mainly because the areas where it used have other solutions that are “good enough”. In the browser JS is good enough. On the server Docker + your typical Linux program is “good enough”. In time things like KVM will offer great sandboxing to containers.

Another issue is that server side programs depend on system interfaces of Linux, which are battle tested, observable and trusted. With WASM you need to replicate that with some message passing system.

Re: Wasmer 1.0

#145

Post by programmarchy »

CyberRabbi wrote: post #95
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.

You’re missing the point. It’s about containerization.

To quote a Docker cofounder:

> If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!

[1] https://twitter.com/solomonstre/status/1111004913222324225?s...

Re: Wasmer 1.0

#146

Post by CyberRabbi »

programmarchy wrote: post #145
CyberRabbi wrote: post #95

Earlier quoted context omitted.

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.

You’re missing the point. It’s about containerization. To quote a Docker cofounder: > If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! [1] https://twitter.com/solomonstre/status/1111004913222324225?s...

I’m not. You’re making a different argument for why webassembly is relevant than the post to which I originally responded.

Re: Wasmer 1.0

#147

Post by Ajedi32 »

anderspitman wrote: post #30
Ajedi32 wrote: post #29

Earlier quoted context omitted.

They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.

Huh? When you click the back button in your chat app, if it happens to do something intuitive it's because that behavior was hand-coded by a JS developer using the history API. And good luck even getting to back button from your news site through all the ads, lazy-load images causing reflow, and auto-play videos that wouldn't be possible in a nicely designed minimal document viewer. It might be harder for news site o…

The same goes for hitting the back button in an Android app. Just because it's _possible_ for apps to misbehave doesn't mean it isn't good for those standard OS features to exist.

Re: Wasmer 1.0

#148

Post by CyberRabbi »

steego wrote: post #143
CyberRabbi wrote: post #142

Earlier quoted context omitted.

Can you provide an example of a situation where it would make sense for both client and server to use the same build? Typically client and server play different roles and require different builds anyway.

The point isn’t to run client code in the server and server code on the client. The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense. Embedding SQLite is a perfect example.

> The point is to allow JavaScript to be able to use excellent C++/Rust code in a sandboxed environment when it makes sense.

That seems useful for the client side but you don’t need webassembly to do that on the server-side. E.g. https://github.com/mapbox/node-sqlite3

Re: Wasmer 1.0

#149

Post by coldtea »

pjmlp wrote: post #96
coldtea wrote: post #83

Earlier quoted context omitted.

> 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.e…

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

Because they can't possibly be pushing very diminishing return features, or stuff that only applies to niche markets ?

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

It's not like "used for enterprise software" is a great endorsement :-)

Re: Wasmer 1.0

#150

Post by coldtea »

jcelerier wrote: post #126
coldtea wrote: post #81

Earlier quoted context omitted.

That's on them ("regular computers"). Their OSes could offer the same capabilities to map to. That said, it's not: (a) as if there aren't cross platform photo apps that run on iOS and "regular computers". Photoshop and Lightroom come to mind immediately, Affinity Photo also. And those aren't just iOS and Mac, they're also on Windows. So there's that. (b) as if what would slow you down / prevent you from doing such a…

> (a) as if there aren't cross platform photo apps that run on iOS and "regular computers". Photoshop and Lightroom come to mind immediately the only thing in common between the mobile and desktop versions is the name

Yes. That and most of the codebase, including the UI abstractions Abobe/Affinity have.
Post reply on HN