Please elaborate on this. AFAIK websites are documents and browsers are viewers for this kind of documents. I understand this is a new model, but every time i see a “new approach” i cant forget my experiences with the previous “new hot things”. I somewhat belive every “new approach” is a proof for informatics and comp sci is not a real science, but a bunch of ad-hoc, ductape based solutions which will sadly stick. (See unix).
A scientific approach would be something previously defined and then implemented, but wasm seems to be simply as a standard way to ductape things. But now even deeper.
How would the user have control - if any - to select which non-user-readable program should run on their computer? How this makes the web experience better for the user? Saying it is “rust” is sadly not understandable answer, please get down to our level to answer this question. Thank You.
Okay - how is C++ supported? Can I write code in BeAPI and it run through WASMER? That would at least be useful.
Emscripten, Go, Rust and Zig are absolutely not interesting. I think Rust and Zig probably don’t need WASMER to be ported, and I guess Go also.
Wasmer has a package manager. It can install software like HaikuDepot does with native apps.
Also i do know js exists but from my pov it is overly-abused. Obviously a strict html4 browser wouldnt bring user satisfaction, but how does wasm changes this? Do not forget i can read js, but i cant do this with wasm.
Do you mean i will have to install packages for being able to view (sorry… to run) websites? Why do we have servers then? (Naive question).
BeAPI is for native code. It doesn’t use Wasmer directly. Writing C++ in BeAPI and targetting WASI will be Haiku-specific. It is possible to implement but I haven’t finished looking into it.
As for how to run C++ on Wasmer, there was a fork of Emscripten for WebAssembly called Binaryen. For maintainability, it has been merged back into Emscripten. It runs faster than the JavaScript backend especially under Wasmer which is 30% faster than WebAssembly in the browser.
Data will still be loaded through either a network or disk as before but viewing the data will be handled through a document type-specific viewer. No more trying to view audio and video files through a viewer that is better suited to hypertext.
You aren’t really answering my question. Why would I use WASMER to write UI code that doesn’t target the BeAPI? What is the point? I feel like anything you could write in WASMER you could equally write in portable C++ and then why do we need WASMER. That is the thing you don’t seem to be able to answer. I originally understood that you wanted to solve the “write once run anywhere” issues that Haiku targeting multiple platforms would have… but now it seems like this is just a port of a runtime to run some {to be defined} code from {unknown/undefined source} that you haven’t really got a great use case for. I know you can do this, but why do we need it? Can you explain why we need WASMER?
I don’t want to seem like I am attacking your work. I just can’t understand what actual use it will have if your primary target is not making Haiku Apps using the native API become processor independent.
BeAPI doesn’t have much software. Wasmer will wrap BeAPI with a thin layer, allowing WebAssembly software targetted to WASI to run on Haiku. It takes the pain and time consumption out of porting.
As for running BeAPI software, that’s a future exercise for once the proof-of-concept Wasmer has been ported.
Well, the BeAPI is the native API. Unless you target it, you are literally just creating more issues and disparity. I can see taking a WASM based BeAPI app and running it on IA32, X64 and RISCV… but if you don’t target the BeAPI, you are basically creating something extremely niche. You are creating a software silo and it will only be fed by those who don’t really care if Haiku is a clean OS and only care about shovelware crossplatform apps.
As I said, I could port a DotNet Interpreter in a day or two (it is very portable) and probably get command line apps working same day as I finish the port and taking massive short cuts I could get UI apps running at the most basic level in about a week. But it would be a complete dead end. I’ll keep porting it to the PSP instead because it is at least slightly useful… but even with this port, I am surfacing Native API calls as much as possible.
I tought ffmpeg does it most of the time. Basically the document viewer embedds a media view. How does wasm changes this? Is it better? If so: how?
I mean i get the point: lets do the runtime do everything, but how is it different than java? It also (fixme) targets a virtual machine and uses binary files. It is not assembly tho, but then comes the question: why would we want to use asm in web at all? I get it, webgl and stuff, but how is it a progress from java? What can i do with wasm what i cant do with html5 / java?
Speed is not necessarily an answer.
Also a question: while informatics / CS is a part of STEM, it doesnt looks like science anymore to me. Web was so far a ductape work of art, how can a yet another layer change it? Forgive me my ignorance/arrogance but is this really the way out? Millions of humans asking this looking back what CS did for the money so far. Naive people like me would ask the question: is this really the ultimate solution? Will they stop now building ductape things on the ductape tower? If not, then - at least from my pov - it is not a solution. But i also know CS is a marketing motivated science, so no answer exists. But should we dive into this loophole?
Dont get me wrong: new things for Haiku is always a nice thing, but using a 3rdparty ui in web is not something i can support wholeheartedly, but i also dont have anybody to ask about this. Is this the penultimate solution?
Re:Java
The Java runtime is its weakest link. The bytecode would have been more useful without legal representatives forcing Classpath down our throats. Somebody actually wrote a JVM for the Commodore Amiga that ran an Amiga-specific runtime in under 1 meg of RAM using an AOT compilation strategy. The bytecode is not the problem, it’s the heaviness of the runtime library.
The same goes for .NET runtimes. JIT compilation is great until it drags in too many dependencies.
Can you give us a quick rundown how the future web would look like from the user perspective? Security and anonimity would be a significant thing, i assume, but i dont see where it happens. Hope you can give a hint.
Please, if you could port dotnet (even Mono) that would be amazing. I think many developers would welcome this.
I tried but it wasn’t easy… though I have to admit that I didn’t try for very long.
On topic: I don’t know how anyone could complain about having additional software available on Haiku, even if you’d never use it. Saying it’s useless is wrong.
Re: new Web
The Web will just be a file repository for storage and retrieval. Some will be behind a paywall and others will not. There will still be servers here and there, sharing data, but the format of hypertext will be exactly that: Text with buttons in it to link to other documents in the Web. The thing we once called the browser will instead become one of several GUI widgets in the runtime library. Instead of being built on scripting languages that were needed for security, the documents once written in HTML will now be written as PDF documents. CSS will be replaced by OS level theme management. JavaScript will just plain go away once its functionality is fully absorbed into the WebAssembly bytecode. If you think JavaScript is readable code, you perhaps haven’t seen minified JavaScript. Anonymity will be the same as always: your IP address will be everywhere you go and spyware will be supplied by software manufacturers and operating systems that are closed-source. Open source will be the answer to all auditing questions for privacy.
DotNet has supported AOT for the longest time. This is even a bare metal example app, including one that runs on EFI with no OS installed : GitHub - MichalStrehovsky/zerosharp: Demo of the potential of C# for systems programming with the .NET native ahead-of-time compilation technology.
@SWY1985 well, don’t get excited. The runtime I am thinking of isDot Net Anywhere. It is plain C, and so very portable. It also runs on small memory footprint devices and reimplements corelib, so you need very little to make it work. I even got it to run on the PSP, which does not allow linking of external libs. It was used to bootstrap Blazor. It can run very modern C#, but has quite a few shortcomings. It also does nothing to solve the compiler issue.
Also - no one is saying we don’t want more apps, we just want the apps to be native.
Do i understand correctly the only pro is being able to serve multiplatforn spyware? Anything else?
The rest of the code will be multiplatform too. Other than that, the only option is offering choice to the people. Windows 10 is loaded with spyware as are the Google Apps in Android. How many people would keep using them if they had another choice like Haiku. Open source is good for the privacy of its users.