[HN Gopher] Wasmer 1.0
___________________________________________________________________
Wasmer 1.0
Author : wiqar
Score : 157 points
Date : 2021-01-05 19:02 UTC (3 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| genpfault wrote:
| > Wasmer is an open-source runtime for executing WebAssembly on
| the Server.[1]
|
| [1]: https://docs.wasmer.io/
| rapidlua wrote:
| 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 MiB (V8/Node.js).
|
| Clang.wasm itself is 45 MiB.
| eyberg wrote:
| Was reading through https://www.diva-
| portal.org/smash/get/diva2:1451494/FULLTEXT... - what's the
| current status/eta of raw sockets? Last time I checked wasm
| consensus seemed to suggest they will never be supported?
| CyberRabbi wrote:
| Congratulations to Peter and team!
| anderspitman wrote:
| Browsers are not the right tool for sandboxing applications. I
| don't think it was a mistake, but it's time to take what we've
| learned and move to the next level.
|
| With a bytecode like wasm, you can create an "app runner" program
| that's at least an order of magnitude less complicated than
| current browsers. Just ship apps as wasm binaries with a simple
| interface (maybe WASI, haven't taken the time to dig into it yet)
| for requesting/providing filesystem, networking, graphics, etc
| resources (if you think this sounds like java, see [0]).
|
| And I think there's room for diversity here. I can imagine a
| world where it's normal to have 3-4 different app runners
| installed on your system. Developers would target one of these
| runners for their app, depending on needs (performance, GUI libs
| provided, security guarantees, etc), and tell you which app
| runner you need for the app.
|
| [0]: https://steveklabnik.com/writing/is-webassembly-the-
| return-o...
| bastawhiz wrote:
| > Developers would target one of these runners for their app,
| depending on needs (performance, GUI libs provided, security
| guarantees, etc), and tell you which app runner you need for
| the app.
|
| We had this. ActiveX, Flash, Director, Air, Silverlight, Java.
| It was a mess, and I think you'd be hard pressed to find very
| many folks who found it desirable.
| anderspitman wrote:
| There are reasons each of those failed that have little to do
| with the core concept.
|
| And to be honest, I think Flash was killed before there was a
| suitable replacement to fill the gap. It took more than 10
| years since it "died" to actually get rid of it, because
| HTML5 isn't actually up to the task.
|
| I think the fact that it survived so long proves there's a
| use for these types of runtimes.
| danShumway wrote:
| I've commented before on this subject, but Flash didn't
| survive because it took HTML5 10 years fill in the gap.
| Flash survived because:
|
| A) enterprises don't upgrade or move away from technologies
| period (we still support IE11 and old Windows Server
| deployments at my current company).
|
| B) Flash _the authoring tool_ never got replaced. It 's not
| about whether or not HTML5 is up to the task of being a
| Flash-equivalent runtime, nobody built a replacement for
| Macromedia/Adobe Flash targeting any runtime anywhere. To
| this day, there is not a vector animation tool on par with
| Flash for any platform, and that has nothing to do with the
| capabilities of the web.
|
| People blame HTML5 when what really happened was Adobe
| abandoned their authoring tools and nobody built an
| alternative because we expected the W3C or somebody to do
| it for us. But a programming language will never be a
| replacement for a full-featured content creation tool and
| IDE.
|
| Even WASM is not going to replace Flash unless some company
| or group somewhere actually sits down and writes a native
| program that can target it and that is actually competitive
| with what Flash the authoring tool offered devs. I have not
| seen serious effort in that direction, so if you're hoping
| WASM just magically makes these problems go away, I'm a
| little less optimistic about that. WASM is just going to be
| another runtime target -- a good one, but not a replacement
| for an IDE.
| anderspitman wrote:
| Yes, my point would more accurately be made by replacing
| "HTML5" with "HTML5 platform/ecosystem". Your point about
| Wasm not automatically guaranteeing this is important.
| But it would be much easier to build such a tool for a
| simple greenfield runtime than for a modern browser.
| danShumway wrote:
| I have reasonably high hopes for WASM as a runtime, so
| I'm trying to thread a line between agreeing with you and
| disagreeing with you.
|
| I do think that compiling C code to WASM is easier than
| compiling C code to Javascript, and I do think that WASM
| is going to open some doors to sandboxed native
| applications that the web just can't handle.
|
| But at the same time, even forgetting about the cross-
| platform part, I have not seen an application framework
| for any platform -- even closed-down, highly consistent
| platforms like game consoles -- that offers the same
| feature-set as Flash.
|
| So WASM may make this easier, but we have platforms
| already today that are extremely easy to target. If
| you're targeting PS4/XBox, you know exactly what drivers,
| software, and graphics stacks are going to be installed.
| And a Flash replacement doesn't exist for any of those
| devices. So I urge some caution about assuming that the
| tools you want are going to be quickly built for WASM.
|
| In some ways, this is exactly the mistake that HTML5
| advocates made with Flash. They assumed that all they
| needed to do was have APIs, and Adobe would do something
| to save Flash. But Adobe never really seemed to care.
| They had some half-hearted efforts to target devices like
| Android, but the Air runtime was never really good at
| that, and it didn't take over as a cross-platform desktop
| target the same way that modern Electron has. It seems
| intuitively obvious that if a cross-platform runtime
| existed that everyone loved, somebody would make a good
| graphics stack for it that was easy to use and that
| didn't require programming, but I'm not 100% certain
| that's actually true.
| anderspitman wrote:
| I think we're disagreeing less than you think, mostly
| just focusing on different things. I'll defer to you on
| Flash. I've never programmed in it directly. My
| observations are purely from the outside. I was just
| using it as an example for why I see potential in app
| runtimes.
| hctaw wrote:
| You've just described the hardest parts of a web browser, while
| ignoring the necessity of a JIT compiler for your bytecode.
|
| To give proof by counterexample, the "simple wrapper" is a
| graphics stack like GTK alongside the POSIX APIs. It turns out
| this is insufficient for application development.
|
| Some things you're missing are text layout and accessibility.
| Neither are small or simple.
|
| The browser is the new OS and they're big and complicated like
| OSes by necessity, not accident.
| amelius wrote:
| All the things you mention could be available as a shared
| library, to be run inside the sandbox along with the
| application.
|
| Let's keep the sandbox as simple as possible. We can build
| complexity inside it, and not make complexity part of it.
| This makes security guarantees much simpler.
| nynx wrote:
| While it's probably true that a full gui ecosystem could be
| built on top of wasi+webgpu+windowing, it would mean that
| programs would often reinvent the wheel. Perhaps that's not
| a bad thing.
|
| Speaking of moving complexity into sandboxed code, browsers
| could potentially run js engines inside the wasm vm,
| reducing a lot of complexity there.
| reader_mode wrote:
| >While it's probably true that a full gui ecosystem could
| be built on top of wasi+webgpu+windowing, it would mean
| that programs would often reinvent the wheel.
|
| You can compile existing GUI libraries you just need to
| port the rendering backend and input.
|
| Flutter, Qt, GTK, etc.
| hctaw wrote:
| The issue I see is we don't need a sandbox at all for this,
| we need capability based security models for applications
| provided by the OS vendors (like iOS, Android). Apple has
| taken the right steps towards such a model, yet get
| lambasted by developers for it. We have flatpaks and snaps
| for Linux, the former isn't really targeted by many and the
| latter is similarly lambasted by users and developers. I
| don't even know what Microsoft recommends today, since no
| developer is going to use it and that rec will change
| tomorrow.
|
| While technically, complexity is not necessary,
| pragmatically the sandbox offers next to nothing for users
| or developers without OS vendors enforcing its usage, or
| the sandbox being so compelling a target for developers
| they accept the limitations of the sandbox - which is why
| the only platforms with robust sandboxes are mobile and the
| browser.
| anderspitman wrote:
| IMO iOS and Android are terrible examples of how to do
| this. They break decades of convention in how to write
| POSIX-like applications, and force developers into
| locked-in practices.
|
| Android gives lip service to the NDK, but in practice you
| can't really run many useful C/C++/Golang/Rust/etc
| programs on Android, because the system breaks POSIX. You
| can't keep a simple webserver running without starting a
| foreground service, which requires Java/Kotlin. There's
| no /etc/resolv.conf for DNS resolution, so you have to
| use custom servers or use the Android NDK compiler (which
| can be a huge pain). Plus they lock down the filesystem
| more each year. Android 10/11 are a complete mess on this
| front. Fortunately they've rolled back some of the more
| draconian changes, but only because of developer outcry
| The fact that they even wanted to do some of the things
| in the first place is sad.
|
| I'm not saying this is an easy problem to solve, but it's
| obvious that the big boys have only made a token (if
| that) effort to build a good, open way of doing it.
| remexre wrote:
| I think proper sandboxing on a traditional Unix is hard
| enough that ~nobody does it right; you can't let any apps
| run as the user if you want to prevent them from snooping
| on each others' files, but the user needs to be able to
| control all of them.
|
| I don't know of a justification for removing
| /etc/resolv.conf, but I guess "applications' networking
| should be under the control of the user" is sorta
| necessary; I think it'd make more sense to do it with
| network namespaces or iptables rules or something, but
| /shrug.
| amelius wrote:
| People (developers) want a target (sandbox) that is as
| "open" as their browser. This means that by definition
| the slightest presence of business-motives would ruin the
| entire idea (your example of Ubuntu's snap and Apple's
| iOS and Google's Android).
| josephg wrote:
| Text rendering and accessibility APIs both need to access
| the host OS's APIs to work correctly. (Text rendering is
| subtly different on macos and windows, and app rendering
| behaviour should follow the platform.)
|
| I think we can expose standardised APIs to applications for
| this stuff, but the API will probably need on the order of
| hundreds of methods.
| brundolf wrote:
| As others are pointing out here: the cross-platform value-add
| of browser based apps _is_ the GUI layer, not the code runtime.
| We 've had the JVM for decades, and it even has a GUI layer,
| it's just a much less powerful GUI layer than today's web.
|
| People have been trying to create a simple, native, platform-
| agnostic GUI layer for as long as GUIs have existed. Nothing
| but the web has ever come close to succeeding. It may be a
| flawed solution, but it's what we have, and it works, and I
| wouldn't hold my breath for a greenfield alternative
| supplanting it any time soon.
| anderspitman wrote:
| Sorry, but I think there's some stockholm going on here.
| People use the web for apps because people use the web for
| apps. It was in the right place at the right time and an
| extinction event chose JavaScript. That doesn't mean we can't
| make something better (doesn't mean we can, either).
| brundolf wrote:
| If you're trying to build out an arbitrary UI, there is no
| GUI layer today that's more flexible than the web (in terms
| of screen sizes, customizability, layout styles, look and
| feel). Maybe you could argue that this flexibility arose
| because of the popularity it gained by being in the right
| place at the right time, but at this point the network-
| effect is not the only reason we use it. It has genuinely
| become a more powerful platform than the alternatives.
|
| I'm not saying we couldn't do better - the CSS API has a
| lot of warts and the DOM has performance issues if you
| don't know how to avoid them - but I am saying we had
| decades to do better and didn't, so there must be something
| very difficult about doing better and we shouldn't discount
| the only thing that's ever really succeeded.
| pjmlp wrote:
| 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?
| k__ wrote:
| First, Stockholm syndrome isn't a thing.
|
| Second, there were a bunch of alternatives and the Web won
| instead of them and not just because they weren't there.
|
| I know, some people like running around telling everybody
| Qt, GTK, Swing or whatever were or even are better, but
| they are seemingly not for the points that matter for most
| of GUI apps.
|
| But yes, we should make something better going forward.
| josephg wrote:
| The other big thing the web provides a standard way to do
| distribution. Unlike JVM apps, I don't need to install Gmail
| to use it on my computer.
| anderspitman wrote:
| The web is a great way to distribute native programs. Click
| a URL to download, then run.
| charrondev wrote:
| 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.
| skybrian wrote:
| It depends on what kind of application you mean. Headless
| servers doing basic file and network I/O are pretty reasonable
| to sandbox. This is what Docker does.
|
| But GUI applications are a whole different thing. The standards
| simply don't exist to make that easy. It's not just basic
| graphics. Things like internationalized text rendering, text
| input, and accessibility are ridiculously hard and only a few
| mostly-complete implementations exist. (Such as in browsers and
| operating systems.) And they need to keep moving as the culture
| changes; you want to support the latest emojis, right? Well
| maybe you don't, but your users will.
|
| Furthermore, these implementations are at least partially
| specific to particular programming languages. If you want
| something portable, you might build on the Skia graphics
| library but that won't give you a way to build an app on its
| own.
| Ajedi32 wrote:
| Indeed; the web provides far more than just a standardized,
| sandboxed, cross-platform runtime with multiple independent
| implementations. There are also lots of higher-level
| components which benefit from standardization. Text rendering
| and input are just the tip of the iceberg.
|
| For example: navigation (back, forward, refresh, etc), URLs,
| permission management, text search, image/video rendering,
| scrolling, credential management, etc; the list goes on.
|
| That isn't to say there couldn't some day be a simpler
| alternative to the web offering similar features; but it has
| some pretty stiff competition. The only thing that even comes
| close today are modern operating systems like iOS and
| Android; and none of those are open standards like the web
| is.
| anderspitman wrote:
| Most of the things you listed apply to web documents more
| than web apps. I'm an advocate for separating the two. The
| UX for browsers is great for what they were designed to do.
| Running apps is not it.
| Ajedi32 wrote:
| 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.
| anderspitman wrote:
| 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 operators to fill their
| sites with junk if they had to explain to their users why
| it needs to run in an app browser with 20 privileges
| rather than in their default document browser.
| nynx wrote:
| A significant point of wasm is runtime-independence. If a
| runtime implements the right apis, any wasm module that uses
| them should be able to run (performance aside).
| eitland wrote:
| 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.
| devwastaken wrote:
| 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 cannot use seperate threads
| to render to webgl without using less performant
| workarounds.
|
| Lack of proper threading means bad page performance.
|
| There's lots more dumb bugs and features firefox said it
| would support and simply never did. Understand there's real
| reasons as to why chrome is the preferred. _it works_ and
| it actually puts in the necessary features.
| AnIdiotOnTheNet wrote:
| > If a runtime implements the right apis, any wasm module
| that uses them should be able to run
|
| That sounds great right now, when the APIs are relatively
| small, but will quickly become a nightmare when they grow in
| complexity.
|
| I mean, technically any browser that implements the right
| stuff can run any web page on earth, yet somehow we still
| manage to have incompatibilities even when there are only 3
| implementations. Or how about POSIX? How much software needs
| no special casing to run on all POSIX systems?
|
| This is the pattern: we abstract things farther with the
| (mistaken) belief that it will save us from having to deal
| with messy reality, but as soon as you try to do anything
| more than simple stuff you find that reality is, in fact, a
| mess and you have to work around your abstraction to deal
| with it.
| syrusakbary wrote:
| Completely agree with that.
|
| I think Wasm has the potential to become the lingua franca for
| software. It allows containerization in a much lighter way than
| virtualization (KVM), but also in a platform-agnostic way.
|
| We have a very interesting future ahead of us!
___________________________________________________________________
(page generated 2021-01-05 23:00 UTC)