[HN Gopher] Orca: WebAssembly Apps Without the Web
___________________________________________________________________
Orca: WebAssembly Apps Without the Web
Author : todsacerdoti
Score : 125 points
Date : 2024-07-30 02:34 UTC (20 hours ago)
(HTM) web link (orca-app.dev)
(TXT) w3m dump (orca-app.dev)
| afavour wrote:
| I had to dig around to find out what language these apps are
| written in... it appears to be C.
|
| Still interesting though, I'm always fascinated to see what uses
| come from the WASM sandbox. But I personally won't be hand
| crafting UIs in C if I don't have to.
| rererereferred wrote:
| I think it's part of the Handmade community so C is a given,
| but it runs wasm files so you can probably use whichever
| language can output wasm.
| pjmlp wrote:
| Well, they could at least help to improve the world safety
| and use Zig instead, which is also part of the community, and
| at least bring us back to 1978's Modula-2 in terms of safety
| in systems programming.
| wh33zle wrote:
| WASM shouldn't care about which language the host is written in
| vs what the apps are written in.
|
| Writing the host in C seems like a bad choice though. Isn't
| that exactly the kind of software you want to ensure is memory-
| safe?
| bvisness wrote:
| Designing the platform APIs around C is generally the right
| move in our opinion. Of course we want Orca to support multiple
| languages, but we also want APIs that will bind well to many
| languages and that will be flexible and performant.
| Furthermore, WebAssembly today is a great fit for C-like
| languages, and...less of a great fit for other paradigms.
|
| We already have strong WIP bindings for Odin and Zig, and
| intend for our documentation to strongly feature all three of
| C, Odin, and Zig when we launch the next major version.
| feverzsj wrote:
| It's weird that Linux is not supported for a cross-platform
| project.
| khimaros wrote:
| it looks like there is some interest and effort in this area
| https://github.com/orca-app/orca/pull/49
| bmitc wrote:
| Quit naming projects after endangered species. When people search
| for "orca", they shouldn't be pointed to random software projects
| but instead research and advocacy groups fighting for orca rights
| and wellbeing.
| mav3ri3k wrote:
| I did not know that Orcas were endangered up until now. Seems
| like this approach is working for raising awareness.
| zigzag312 wrote:
| Maybe these projects should add a note to their websites that
| the project is named after an endangered species.
|
| I think that would be a wonderful way of raising awareness.
| spencerflem wrote:
| This was downvoted, and tbf it is a rather niche complaint.
|
| But fwiw its something I've been thinking about a bit recently.
| Naming something, parodying something, etc. all siphon off the
| legitimacy and good will of the thing they're referencing.
|
| Kinda like how Bill Waterson never made Calvin and Hobbes
| spinoffs, so anyone who experiences C&H does so through the
| comics first and not ads or shirts or movies. Having those
| would devalue the comic.
|
| Anyways no real conclusion, other than to be mindful of what
| you crib & to be offended when big marketing firms try to
| degrade the Mona Lisa into a Coke marketing vessel.
| muzani wrote:
| Is it really a niche complaint? I'm getting confused with the
| minimum effort generic names too. Orca. Fork. Cursor. Apple.
| Wheat. There's probably thousands of AI projects named Jarvis
| out there too. At work, we use Localize and Lokalise, two
| different products that get confused a lot.
|
| I liked it when we were at minimum variation. Call it Mega
| Dolphin or something.
| spencerflem wrote:
| I was being a little generous, since it seemed like the
| consensus was that OP was in the wrong.
| pjmlp wrote:
| Just target the JVM or CLR, enjoy 25 years of ecosystem maturity
| in libraries, and bytecode instrumentation, and be done with it.
| progfix wrote:
| Can you run JVM or CLR apps in the browser?
| pjmlp wrote:
| Where is the browser in "Orca: WebAssembly Apps Without the
| Web."?
| meiraleal wrote:
| Where is Orca in "Can you run JVM or CLR apps in the
| browser?"
|
| If you don't have an answer you can help us all not
| replying
| pjmlp wrote:
| Nowhere, you apparently missed the point this isn't
| related to the Web, too eager to reply anything.
| meiraleal wrote:
| The person was just curious about another thing, you
| apparently missed that you are in HN.
| netghost wrote:
| Welcome to the future!
| https://en.wikipedia.org/wiki/Java_applet
| RandomThoughts3 wrote:
| This is not Java applet. The browser can already run WASM
| code natively.
|
| This is the JVM but using WASM as bytecode, which is to say
| it is yet another WASM interpreter but this one provides a
| runtime with a canvas.
| pjmlp wrote:
| Basically a Apple II running UCSD Pascal.
| camgunz wrote:
| Why would you need to if they run outside the browser?
| rictic wrote:
| It is way easier to get someone to click a link than to get
| them to download and run your app.
| pjmlp wrote:
| Orca requires to download and run your app.
| mcosta wrote:
| Then what is Orca useful for?
| pookha wrote:
| Maybe replacing containers...I had a better developer
| experience and a better overall quality of life when I
| deployed war files into a servelet container (tomcat). I
| wasn't patching operating system vulnerabilities across a
| jagged sea of micro service images or patching vendor
| supplied images either (literally had to do that with
| Kafka). I deployed a fucking war file. That's it. And I'd
| also imagine that a WASM module\app would have a much
| snappier start time without having to lug around the
| overhead of a container...And "Alpine Linux" can go ahead
| and kiss my ass (no offense).
| txdv wrote:
| Yes, there are multiple efforts which compile JVM bytecode
| and CIL bytecode to WASM.
| useerup wrote:
| Microsoft has ported CLR (.NET Core) to Webassembly and it
| runs in the browser. You can indeed run CLR code in the
| browser. That is how Blazor works
| tracker1 wrote:
| It's pretty bloated and slow compared to alternatives. This
| may improve if WasmGC gets integrated instead of part of
| the payload, but it's still not a great solution,
| especially on constrained devices. The flip side, is
| running in server mode means the laggy round trip actions
| that feel somewhat painful in contrast, reminding me of
| ASP.Net WebForms and how painful that was in practice.
| cedws wrote:
| Better performance too.
| vbezhenar wrote:
| Mature desktop Spring Boot app, eating 500 MB and starting 15
| seconds.
|
| I'm not joking, no...
| pjmlp wrote:
| Already chosing Spring for a desktop application was the
| first major error.
| dualogy wrote:
| > _Just target the JVM or CLR_
|
| In that case: or transpile to Go. Just as cross-platform, but
| native binaries, fast build, and probably simpler code-gen.
| Still get GC, still get a fine ecosystem & stdlib, still can
| make wasm from the generated Go code, still can use
| boxing/unboxing (`any` instead of `object`) if the source lang
| is not-statically-typed.
|
| Unless you have C deps or "native GUI" needs (ie. C deps) of
| course =)
| lolinder wrote:
| Does Go have a mature cross-platform GUI toolkit?
| freeone3000 wrote:
| wasm doesn't either :)
| lolinder wrote:
| JVM does.
| Deukhoofd wrote:
| JVM and the CLR are great, but what WASM offers that those do
| not is sandboxing. Being able to load in external plugins
| without having to worry about them opening random files they
| shouldn't, or starting network connections is some extremely
| useful functionality.
|
| For this case, where the entire application is WASM you could
| get benefits if you for some reason have a malicious
| dependency. Instead of it being able to run with full user
| permissions, it will be limited by the interface offered.
| pjmlp wrote:
| Until it becomes a juicy attack vector, worth exploring
| monetarily like everything else.
|
| "Everything Old is New Again: Binary Security of WebAssembly"
|
| https://www.usenix.org/conference/usenixsecurity20/presentat.
| ..
|
| Just one of the papers slowly coming up on USENIX and other
| security related conferences.
|
| Want a proper sandbox outside the browser?
|
| Use OS processes, containers and OS IPC.
| Deukhoofd wrote:
| To a degree, everything can be exploited, for sure. Memory
| safety always remains an issue. The sandboxing I was
| referring to however was the sandboxing from arbitrary
| syscalls. While some operating systems have functionality
| to do so (for example OpenBSD's pledge), this is
| unfortunately still very much a niche feature.
|
| Containers solve this problem to a degree, but running GUIs
| or plugins within them is non-trivial for end users.
| actionfromafar wrote:
| Or use OS processes etc _and_ WASM sandbox.
| vbezhenar wrote:
| Browser engine is a very juicy attack vector. So it makes
| sense to use browser engines IMO.
| hackcasual wrote:
| If you think using containers provides improved security
| over WASM I don't think you understood the paper. At no
| point did they demonstrate compromising the host of the
| WASM program, just corrupting the state of POC's. There are
| obviously risks associated with that, but nothing that
| improves by going with isolated/containerized native code.
|
| Yes currently lacking ASLR and read-only memory sites
| increase some risks, but strongly typed function pointers,
| control flow restricted to function entry points and call
| stack isolation more than make up for it
| pjmlp wrote:
| I think a lot about security, during the last 30 years,
| and worshiping WASM sales pitch isn't one of them.
|
| Also I explicitly mentioned that is the first paper of
| many others, that are starting to appear on cyber
| security conferences.
| hackcasual wrote:
| It's a 4 year old paper, and the biggest issue it brought
| up, malleable read-only data, is currently being
| addressed with the memory control proposal. The fact that
| a virtual environment can't prevent all types of
| erroneous program behavior is not particularly
| noteworthy. The fact of the matter, in particular when
| comparing WASM against containers, WASM is a generational
| step forward in terms of permissioning and isolation.
|
| For my bonafides, this is me discussing this class of
| vulnerabilities 8 years ago:
| https://groups.google.com/g/emscripten-
| discuss/c/gGjklbJiX1c...
| FpUser wrote:
| Personally I've been running native apps on Windows / Linux
| for ages. No problems so far. I do not see any real value in
| sandboxing in my environment. What I do see is how crippled
| sandboxed apps are comparatively to native desktop apps.
| Muromec wrote:
| >I do not see any real value in sandboxing in my
| environment
|
| I would not like to run stuff with an implicit permission
| to read my browsing history and all the ssh keys.
| shortrounddev2 wrote:
| > but what WASM offers that those do not is sandboxing
|
| The OS's themselves offer sandboxing, not the app platform.
| Mac has a locked down permissioning system and Windows has
| App Containers. Linux has a few sandboxing options available,
| like flatpak
| gbraad wrote:
| Must be me, but the page shows nothing now except for an 'empty'
| page (logo and the statement: "web assembly apps without the web"
| and top nav "blog", "code", etc. Navigated to
| https://github.com/orca-app/orca and at least can see what this
| is all about. Perhaps something was removed or edited?
| dathinab wrote:
| it shows "latest posts" for me maybe they changed it recently
| or maybe your ad-blocker remove that "news feed" due to
| classifying it as ad or unwanted noise
| amne wrote:
| have we come full circle? are we there yet? where is the "x64-to-
| wasm" compiler?
| apignotti wrote:
| X64 is not yet supported, but we got good results for x86
| already: https://webvm.io
| progbits wrote:
| Kind of but wasm provides some security properties you don't
| get from x86/64. I think it's more like a lightweight JVM.
| Muromec wrote:
| I would totally compile wasm3 to wasm to support wasm
| experimental features my wasm host is not supporting because
| they are experimental. And them app itself will include another
| copy of wasm3 to support plugins. And plugins will have plugins
| too. And the will all make asynchronous HTTP calls that don't
| handle timeouts, never retry and assume all operations making
| three HTTP calls in a row (to have a cleaner API design) assume
| they fail atomically.
|
| And then I have a cup of coffee enjoying the glow of a nuclear
| power plant supplying the energy needs of this. And the power
| plant control interface will also run WASM. And then somebody
| will do experimental shutdown procedure after the plant was put
| into operation using this control interface. And that's how I
| know to celebrate my birthday
| revskill wrote:
| It is still hard to beat typescript on the language level.
| pshirshov wrote:
| We badly need something like this but mature. Cross-platform UI
| development is a total mess with literally zero solutions ticking
| all the boxes.
|
| If you want to write an app which will target all the major
| platforms (3 desktops and two mobiles), want a native look and
| minimal effort for every platform you target, there is nothing
| apart from QT. And it's a real pain to deal with unmanaged
| memory. Also, QT is a mess, you cannot define your interfaces
| declaratively (with QML) and easily interact with them from C++
| code, you won't have any typings. So, you either have to go the
| ancient way of imperative UI definitions or do everything in QML
| which is total mess.
|
| If you drop native look requirement, some small things like
| https://www.egui.rs/ might work for you.
|
| If you drop the minimal effort requirement, all the webivew based
| mess might help you but it won't be easy due to multiple reasons.
| Muromec wrote:
| Or just face it -- making a crossplatform app is a work for 30
| people and a QA department, not a hobby project.
| JackMorgan wrote:
| In the 1800s we could have faced that ploughing 300 acres
| would always need 30 horses and 30 strong laborers.
|
| Or that 64kB of RAM was plenty enough to make all the
| software we needed.
|
| I would rather always dream big and help invent the future.
| CSSer wrote:
| It's not that we don't want to dream. I'm right there with
| you. The issue with your examples is that they aren't
| political but UI design languages are. Imagine if the UN
| appointed one ambassador to unilaterally represent every
| Slavic country simply because they all happen to speak
| similar languages or be located close to one another.
|
| The issue lies not with the implementation but the
| requirements themselves. Each platform has its own design
| philosophies that either conflict with other platforms or,
| in some cases, are simply so vague as to be incoherent.
| Sometimes it even looks like competitive subterfuge.
| Muromec wrote:
| >Imagine if the UN appointed one ambassador to
| unilaterally represent every Slavic country simply
| because they all happen to speak similar languages or be
| located close to one another.
|
| That would immediately bring the world one step closed to
| the peace in the Middle East
| foldr wrote:
| > That would immediately bring the world one step closed
| to the peace in the Middle East
|
| There was a line from the Onion's vox pop series that
| summed the situation up perfectly:
|
| "In these times of division and strife, they should turn
| to the Bible for help."
| shortrounddev2 wrote:
| I think tailoring each app to the platform you're targeting
| will always look better than cutting corners. Especially if
| you can integrate your app into the native styles of the
| target platform rather than just embedding custom CSS into
| every application so the target platforms lose all
| character entirely
| Muromec wrote:
| It depends on who you ask whether software development is
| like agriculture or like some other types of work. Building
| a cathedral still takes about a 100 years like it did half
| a millenium ago.
| pshirshov wrote:
| Unfortunately, yes. More or less. But it shouldn't be like
| that.
| pjc50 wrote:
| > will target all the major platforms (3 desktops and two
| mobiles), want a native look
|
| This is always a very serious pain point no matter what
| solution you pick: the native platforms all have different
| controls and ideas about what your UI should look like. It's
| inherently not possible to have a cross platform true native UI
| - the best you can get is reuse of models and controllers, with
| a different UI layer on top.
| pshirshov wrote:
| > It's inherently not possible to have a cross platform true
| native UI
|
| QT does a relatively good job at that. It is possible. Of
| course there will be severe limitations, but in any case it
| would be better than total impossibility of building good
| looking multiplatform apps single-handedly.
| dathinab wrote:
| in my experience for companies this "limitations" get very
| fast sever enough for them to stop doing it
|
| doesn't mean they don't use QT on all platforms
|
| but with different impl. for each with very little shared
| UI code if any
|
| (but often shared code behind the UI, e.g. business logic,
| data validation etc.)
| afavour wrote:
| IMO this is an impossible dream and folks need to stop chasing
| it. Particularly when you're trying to do desktop and mobile in
| one, they're just totally different paradigms.
|
| The alternative, which I have found far more preferable: code
| app logic in Rust, which can be mapped to Swift, Kotlin and JS
| (via WebAssembly). I'm sure Go, Zig or whatever is capable of
| similar, I've never explored it. Then map that shared code to
| native UI.
|
| SwiftUI and Android Compose are far from perfect but they're
| 100x more understandable than what came before and have a lot
| in common with the React model of UI. It's more work upfront
| but in the longer term I think it's better to be using OS UI
| frameworks directly rather than adding a dependency between you
| and the OS.
| Groxx wrote:
| Yeah. The more time I've spent writing code, the more I'm
| convinced that a largely agnostic core and a thin UI per
| target is the only reasonable option.
|
| That "thin UI" can leverage a cross-platform toolkit for the
| long tail of lower value targets, that's completely
| reasonable because that's what they excel at. But you'll pay
| (a lot) for it later if it's not aggressively simple and
| disconnected from your internals, because those tend to have
| very painful major version migrations.
|
| As a bonus: doing it this way generally gets you MUCH simpler
| and more testable core systems, and MUCH better
| accessibility.
| tracker1 wrote:
| As much as it sucks in a lot of ways, I think Tauri and
| similar embedded browser control options may be the best
| option today for cross-platform mostly native application
| logic. The browser's support of HTML+CSS is just that good. I
| would like to see tighter integration into at least platform
| configurations for the primary background, activity and
| accent colors and typography/fonts. Beyond this approaches,
| such as Material, etc are common enough that they don't feel
| too alien in applications. Maybe more so on mac, but still.
|
| At this point, if a tool doesn't support Windows, Mac _AND_
| Linux, I 'm pretty unlikely to touch it. I know Linux is a
| minority here, but it's disproportionately large for
| developers on their own hardware at this point. I'm tired of
| working with things that don't advance what I can use on my
| own.
| smokel wrote:
| _> We badly need something like this_
|
| One might also argue that we badly need just one desktop OS.
| For some reason this is not reality. Zooming in on the Linux
| platform, there is not even one native user interface to target
| for.
|
| If you really want this, then your best option is probably a
| web-based user interface.
| Jean-Papoulos wrote:
| Flutter has all platforms (at least when it comes to pure UI)
| with native appearances. It won't take you very far though,
| mainly because a desktop app is wildly different in usage to a
| mobile app. I don't know why people keep insisting on having
| everything in the same codebase, which not have a page for
| Desktop and a page for mobile, with the business logic in
| common only ?
| tracker1 wrote:
| Don't get me wrong, I like Flutter... but it isn't exactly
| native UX on any platform. And it's a large part of why my
| own take is that embedded browser platforms (Tauri, Electron,
| etc) aren't actually so bad for a UI rendering surface and
| that you can go a long way with component styling that is at
| least closer to what the platform is doing (colors, fonts,
| etc).
|
| You can use a Material approach, and enough apps are similar
| enough to this, even in the various platforms that it can
| look "close enough" for many or even most things. Though Mac
| will be more oddly out as their apps tend to be far more
| consistent than with Windows or Linux.
| dathinab wrote:
| > want a native look and minimal effort for every platform you
| target
|
| IMHO this is impossible (through a bit dependent on how you
| would interpret the previous sentence)
|
| the way you would properly structure a app from a UI and
| especially UX perspective on mobile is often fundamental
| different then for desktop. Partially due to one group being
| mainly keyboard+mouse and one being mainly touch, partially due
| to one being mainly on "small screens" and one being mainly on
| at least 13" screens (tablets and very small Laptops are in a
| unlucky in-between spot)
|
| to make things worse iOS and Android have diverged quite a bit
| wrt. "what is intuitive/expected"
|
| through you can ease that issue by having just a slightly
| native look, but that can easily fall into a uncanny valley,
| and for proper UX you need to at least follow the native input
| handling, as in keyboard shortcuts, gestures, navigation
| patterns
|
| this is why IMO "Cross-platform UI development is a total mess
| with literally zero solutions ticking all the boxes." is a mess
| because solutions end up either in a uncanny valley by being
| somewhat but not quite native for all platforms or in a good
| for one but not other platforms corner or you need to add a lot
| of manual platform specific customization. Worse it's often a
| mix where for some features some of the points above apply but
| for other features others...
|
| through this doesn't mean you can't share stuff, e.g. sharing
| app business logic is quite viable, sharing complicated UI/UX
| logic for unusual custom elements is harder but should also
| work, but in the end (if you can afford it) using a platform
| specific UI library for Android, iOS is probably the right way
| to go. Through for desktop IMHO outside of having to have
| different Keyboard shortcuts you probably could use a mostly
| one size fit's all solution with at most slight tweaks.
| looop101 wrote:
| There is one solution and it's Lazarus IDE, and I'm yet to see
| a better/easier solution that delivers what it delivers.
|
| - Native and easy UI on the three major platforms along with
| many more.
|
| - Self-contained executable. (Zero dependency)
|
| - Completely free and open-source.
|
| - No restrictions on commercial products (unlike Qt).
|
| Assuming no specific OS calls (or contained within IFDEF
| checks), you get your project you created on Windows and simply
| compile it on any Linux distro and you get a self-contained
| that will work for any other distro by simply publishing the
| executable.
|
| It's a shame that this tool isn't mainstream for what it can
| deliver. Most complains I see are of those "old is bad, new is
| good" or "I want mah curly braces", referring to Pascal.
| Muromec wrote:
| And it used wasm3, which is maintenance mode according the readme
| because of _reasons_.
|
| I don't like this timeline. I can't visit home and I can't have
| typed continuations in a lightweight wasm interpreter either.
| dmkolobov wrote:
| because "[his] house was destroyed by Russians who invaded
| [his] country"
| lolinder wrote:
| I think OP understood that very well:
|
| > I don't like this timeline. I can't visit home ...
| evacchi wrote:
| interesting that they are shipping their own libc
| https://github.com/orca-app/orca/blob/main/src/orca-libc/not...
| dathinab wrote:
| They are currently only targeting desktop but I wonder how would
| you port something like this to iOS, I don't think iOS let's you
| run a WASM AOT/JIT or similar on iOS. Would you AOT compile WASM
| to ARM64 and ship that?
| SirGiggles wrote:
| a-Shell [1][2] has WebAssembly (and WASI) support and ships
| with a compiler that compiles to, you guessed it, Wasm. Though
| there are limitations on what can be done, such as no sockets,
| no forks, and etc...
|
| [1] https://github.com/holzschu/a-shell
|
| [2] https://holzschu.github.io/a-Shell_iOS/
| nanomonkey wrote:
| Sadly this only supports wasm3 (WebAssembly 1.0) and doesn't yet
| have a Linux installation (Windows and Mac only). So no WasmGC
| (modern garbage collection included version).
___________________________________________________________________
(page generated 2024-07-30 23:02 UTC)