How will wasm accomplish this?
Okay, so fantasy future - so nothing you say about the web is particularly feasible or usable in the short term, and only potentially possible if people buy in to the new model. So basically - not going to happen. Well - or it will be BETAMax vs VHS vs Video2000 or HD DVD vs Bluray. Someone might win, but predicting is not easy or feasible.
I think your biggest issue is that it is just another runtime platform. If it gets traction, cool. Otherwise itâs just another runtime platform. Also, it does not actually solve the issue with cross platform UI. Whatever you need to use still needs to exist on the target it some usable way. All it does it side step the issue and make it the maintainer of the port of Wasmerâs problem.
So putting on my old man hat and reading through this, it sounds like WASM is yet another variation of the VM/portable runtime/bytecode thing like Java, dotnet, nodeJS, etc. which is supported in some browsers, so essentially a lot like what Java applets or ActiveX (shudder), Silverlight were doing way back when?
So what this would then do is allow you to run those apps that can run in browsers on Haiku?
WASM is a bytecode not unlike the JVM in Java or .NETâs bytecode. As memsom observed, there are lighter runtimes for .NET that donât require Windows, but hardly run a lot of software because they are so limited. Most .NET software assumes the Windows DLL files will be there. The ones that donât will work on Mono but still, thatâs a huge runtime. Making the runtime light enough that it will work on everything but require almost nothing is the trick.
@memsom
My problem with Web Browsers is that they are about a 64 megabyte minimum. That doesnât even count the website itself, nor the software and scripts imported by WASM and JS, nor the pictures and media that are imported by the website. They are too big and donât take advantage of the underlying OS features.
Re: UI
The main advantage of Wasmer is that it generates native .so/.DLL/.dylib files on all supported platforms. It also generates native binaries using its headless mode. If the headless mode doesnât work, it can fall back to a JIT or AOT runner using LLVM or CraneLift.
@watto
Thatâs where it starts but using Wasmer lets us lose the browser and go almost straight to the OS. See what I wrote above about 64 MB browsers.
1 Like
Cheers, understood. From what I can see it does appear to be widely supported on popular browsers anyway and is being developed within the W3C, so does have a good chance at gaining some traction. Iâm not sure why the negativity is necessary, youâre free to work on whatever you likeâŚ
2 Likes
Hmmm - this shows a real lack of understanding of what DotNet is and what it does. So, DLL is an unfortunate naming convention, a DotNet âDLLâ is an assembly in DotNet Parlance, and it contains pretty much only bytecode and pre jitted assembly code. Dot Net Anywhere uses DLLâs as well, and it has almost nothing to do with Windows. On a Mac, we use DLLâs too. The native code lives in whatever library your native OS uses and DotNet has a very simple platform symbol import mechanism called P/Invoke that allows DotNet code to call any C style function with any calling conventions that is supported by the runtime.
Well with WASM you are just shifting the dependency to a massive runtime⌠so I donât really see a difference. If the runtime needs to be run multiple times you will eat up the same RAM, and if you can run it once and open multiple apps, you will still see the memory footprint creep up.
Thatâs a cop out. If it has no native tool kit for creating UI, it is a bit pointless. If it has one built in it will unfortunately force that to be used, and if you just use one compiled in to WASM, the Wasmer still needs to be able to interface to something native on the platform. I donât think you have really understood the real issue - another UI toolkit is not something anyone needs.
No - it really doesnât - you would still need to run this mythical browser in WASM and so it would still allocate similar memory footprint. Deferring something to another process doesnât make the requirement go away. You just have deferred it to another process.
Rust has a lightweight macro system that is different from the template system and preprocessor on C++. Iâm hoping it will be possible to write thinner abstraction layers than it has been in the past. Also, Wasmer is written in Rust so that will ease the maintenance cost of the code. On my first attempt at writing Rust code on Linux using an MS Code derivative, Intellisense picked up all the bugs before I could even hit âcompileâ.
Edit
I forgot to mention that there is a project Iâve been following on GitHub that involves a Transpiler to a macro language in Rust for GUIs. The mainstream OSs are stuck on GTK3 but since that hasnât been ported to Haiku yet, Iâll probably transpile from the language (or custom bytecode if it ends up that way) to native BeAPI support. All the overhead will reduce out in the transpiler.
Sorry, this is really off-topic, but I need to comment on this. This for sure will not happen, PDF is simply not suited for this. PDF is a format very well suited to describe the layout of a document with fixed dimensions and positions. It is not well suited for representing structure, semantic or for flexible layout. As such it is not well suited as the only format for a hypertext web.
If you output a document as PDF you still need some source format that makes it convenient to describe such a document, a format thatâs easy to edit. Some markup language like HTML + something to describe the styling 
PDF can for some use cases be a great render target, but if the goal is output on the screen you probably would do different rendering.
PDF has some interesting properties that frequently surprise users who take it as a format to store text. And then they wonder why something simple as copy and paste does not give desired results, or why PDF editors are so limited.
Youâre absolutely right. I only chose PDF because it is tokenized binary instead of SGML derived markup. HTML and XML share the same ancestry and require Zip compression to come close to being compact.
Going back to the discussion on UI layout, having a bytecode for a GUI will be much more compact and easier to parse than text markup. It should be like the BSON from JSON conversion but applied to SGML derivatives. In fact, the inline text formatting should be independent of the UI layout engine. Does anyone know if UTF8 supports an escape character like ASCII 27? If so, ANSI terminal codes would probably be sufficient for most formatting. Only links would remain unaccounted for.
1 Like
Iâd personally like to see QT be a native api for haiku, alongside tge haiku/beos api.
iirc they share a lot of design principles and having a native qt implementation would make haiku very attractive to development if 3d acceleration was available.
that said, the haiku api is good, maybe extending with qt apis where haiku falls short and design a porting tool to translate where possible to make porting easier.
i agree, haiju has a lot of external tool kits, most of which are garbage
Ok, this is where you lost me.
Do you really think using escape sequences made for teletypes are the best way of doing this? Really?
There have been claims in the past that Qt is or at least was at some point inspired heavily by BeAPI, to the point that porting between the two was just a matter of replacing function names.
No clue if there is any veracity to them, though.
1 Like
The web in itâs current incarnation was not created by computer scientists based on established best practice, it is instead a product of industry. There is a big difference between industrial products and real CS: Anyone can write and sell software, and to most users it is impossible to tell if they wrote code based on established principles or an inefficient mess that eats CPU time/memory and is about to crash.
Javascript is the butt of every joke amongst computer scientists; its poor design and nonsensical, undefined semantics embody the antithesis of 70 years of programming language research. And as you alluded to, much of the rest of the web is also a house of cards: CSS and HTML5 are not reliable tools for laying out documents, for example, so they have failed to meet their primary design requirement.
But computer scientists have created some beautiful languages, and CS includes many disciplines that are based on rigorous scientific method, principled solutions, and mathematical proof. I donât know how to stop industry from continually creating ever more broken web technologies, but I can tell you that computer scientists hate it just as much as you do!
2 Likes
I see. Thanks for the explanation. Good to know.
One prefix character, one command character, a numeric quantity and a semicolon is way cheaper than a pair of angle braces plus the word âstrikethroughâ and a matching tag at the end with a slash before the tag. Iâd rather use a markdown derivative than HTML. In fact this forum software already does!
The point I was making was that the GUI layout should be independent of the text in its content. Only the inline markups would remain and they can be done way cheaper if the other markup was moved elsewhere.
beniot schilling worked on both iirc
1 Like
This sounds a lot like 640KiB is enough for everyone.
If you had ever actually done any kind of UI Toolkit and mark-up, you would realise that having a descriptive representation of the data that is human readable is way preferable at design time, and that most uses outside of a web browser compile the UI code in to an intermediate state that is not âXMLâ, but a binary format that is easy to load at runtime. The Web is the only medium I know that processes the text on the userâs computer and created the âapplicationâ on the userâs browser. But the Web and html is only one implementation⌠you canât base everything on that. The problem you think exists is literally non existent in most other applications of UI design.
Well no. You need context. If I want a button on a screen in Xaml, I do this:
<Button Text="My Button"
Command="{Binding MyButtonAction}"
VeritcalAlignment="Center"
HoritontalAlignment="Top" />
Iâm not really sure how you can change that to use a mark-up and make it as easy and simple for a human to read when developing. The actual Xaml gets compiled in to byte code by the compiler. But that is part of the Dot Net Framework - you donât need to know or understand how that part works.
Whilst he did, I think Qt already existed. Qt and BeApi suffer the same issues⌠the C++ language was a lot less fully developed at that point, it didnât really have all of the data structures it does now. So a common thing was to define your own List class, define your own String class etc. Prefix everything with a letter to give a C style ânamespaceâ, you end up with BList (BeApi) vs QList (Qt) vs TList (VCL), BString vs QString, BButton vs QButton vs TButton.
But donât be fooled. Whilst the names seems quite similar (and when Borland made the CLX replacement for the Delphi VCL and used Qt for that, they discovered this), Qt does the despatching of events in a COMPLETELY different way to most other toolkits. Signals and Slots. There is a meta object compiler (MOC) that needs to parse the Qt based C++ and convert it to C++ that compiles with a regular compiler. So Qt is fine, but only if you use Qt⌠it used to be quite hard to jump between Qt and Native. I think you can manually write the code as it is parsed, but as with all these things it is quite ugly and harder to get right.
BeApi on the other hand relies on sending BMessages. It is a lot simpler to use conceptually, but if you want to do anything special you end up needing to subclass at the very least BApplication and BWindow. Also the rules about how you construct a UI in BeAPI are quite complicated⌠in a lot of UI toolkits you can just say âWindowâ, âAdd buttonâ, âDespatch click to this functionâ, and you are done. With BeApi, IIRC you create a BApplication subclass and override MessageReceived() to handle the quit message, you create at least one BWindow subclass and override MessageReceived() to handle all the BMessages from the UI elements, then you create one of more BViews where you can add other BControls (but often I believe creating a BView subclass was a thing.)
Yes is does. Itâs an extension to ASCII. But the teletype control codes are only really useful for telling a line printer how to align and indent a fixed sized mono spaced font. I donât think you really thought this through.
1 Like
Thatâs I think exactly what SamuraiCrow was suggesting things would move to for the web as well, at least in regards to web applications.
1 Like