How deeply integrated is the WebView to the scripting engine? As posted on the Steam Client thread, there is a TypeScript compiler that would work gloriously if those 2 sections could be decoupled and used separately.
I’ve moved your post because it was not related to the topic of haikuwebkits move to codeberg. I have no clue what my quote has to do with your question, and I also don’t know what you want answered.
It feels a bit like the “Put down the cholate covered banana”… What is your end goal? I have no clue.
Is there a javascript engine? Yes? You can link it in, it is in a shared library, or even accesible as a commandline app… but on it’s own it is usesless, it doesn’t do much, you can do math in it badly I guess. But you need some sort of runtime or OS integration to do any usefull work.
1 Like
Thank-you. The idea is to split the huge code base into smaller parts as a means to make the online presence both maintainable and more modular. Using a TypeScript compiler with a webview but without the JavaScript core as a requirement would be an example use-case.
1 Like
What? who? why? Have you looked at the webkit codebase?
You can’t use typescript without javascript
The link above cuts out the middle-man of JavaScript and generates native code statically. It is literally a TypeScript compiler for static code-generation using LLVM.
Okay? Have fun I suppose. I don’t see how this related to webkit then 
Any TypeScript code that assumes access to a webview will need the webview module but NOT need the JavaScript core or any JIT overhead associated with it. It splits the dependency chain.
An Example
Earlier I started making a YAB to C++ transpiler but it generated crappy-looking C++ code becuase the C++ code bases were so tied into standard conventions that the YAB language, as a non-structured programming language, couldn’t cleanly represent as equivalent.
Compiling TypeScript to JavaScript does exactly the same thing. JavaScript requires garbage-collection and other features that the TypeScript source language doesn’t need directly and shouldn’t need to use. It adds needless overhead to continue using JavaScript as an intermediate representation. LLVM is already a much more low-level representation than JavaScript so why continue using JavaScript when it only adds overhead and a lot of it!?
I am not interested in maintaining a third runtime for webkit, especially one that is incompatible with most websites…
We only need JSC, we already have it. It works. It is compatible with webistes. Adding more dependencies is a waste of development time, especially when the end result is massively less capable.
You really really don’t need a faster Javascript runtime.
1 Like
Modular vs. Huge Monolithic Blobs
I’m not interested in using JSC if my codebase only needs a webview independently of the JSC. The JSC can continue to operate separately if needed but there are other applications of using a webview independently of JSC: Dart Native.
Dart Native is used to make apps for mainstream mobile and desktop operating systems but is a wrapper for the underlying architecture. I was impressed that on my Linux box I was able to compile the example program into a 22k executable when the web-app was considerably larger and slower.
Implementation
What I’m proposing is that a fixed API can be used to interface between any runtime and webview. This would include JSC, Dart Native as well as TypeScript. There would be parallel dependencies between the different runtimes but the webview itself would be separate and independent of the runtimes. This would allow the runtimes to each be independently administered and maintained from the webview code base.
Native Code
Why most Haiku users shun code that is not perceived as “native” is that it is often inefficient and doesn’t use system resources effectively. Furthermore, the user-interface is often inconsistent with the operating-system and duplicates efforts.
By splitting the webview into a separate project, it could be used to supplement or replace the non-native gadgets used within it with native ones. Also, if JSC is made into a soft-dependency of less projects in favor of direct binary generation into a .SO file using TypeScript or Dart Native source, JSC can be deprecated into more specialized use-cases over time until we don’t need it any more, allowing web-apps to be converted into “native” apps without any added effort.
I’m not sure why you write in this wierd paragraph style, it is super difficult to read.
In any case, I already answered your querry. I’m not interested in adding any more runtimes to haikuwebkit, and i doubt the other 1 and a half devs (as time permits) are interested either.
Webkit is open source, and HaikuWebkit is open soucre. If you want to use it for other purposes… feel free… but that doesn’t mean I want to have to maintain another API, especially considering the prospect that we want to upstream our port completely.
I’ll try to put it into simple terms: If you want to maintain JSC, fine. If I want to maintain TypeScript code-generation, fine. Why duplicate the webview between them if they could both use the webview separately as an independent dependency?
I don’t know why you want to do this… Your posts often elude me
Here’s a maintenance angle: If you wanted to hand over the webview support to someone else but keep maintaining JSC, could it happen? Only if they were split. That’s all I want to happen.
That’s not a scenario I care about. I want webkit to work for haiku. And that means as a full web engine for the web browser first, and later on using the html part for some applications like Mail.
If webkit integrates v8 tommorow and JSC doesn’t work anymore, well, that may be unfortunate, but as long as it works for us I won’t shed any tears over it. We have our own “Native” api over webkit, your application will get “something like a webview” and not have too care too much about the internals. WebPositive doesn’t care if it’s JSC providing the javascript runtime or something else.
You are asking to add a second native api that facilitates plug-and-play for “something like a javascript interpreter”. That is much more than just them beeing split. They are in different directories of the source tree of webkit already. You can probably just use the Webview without JSC if you really want to…
1 Like
If I understand this correctly,what he wants is using only the HTML part of WebKit as you already suggest for using in Mail.
Again,if I understand this correctly,he wants to connect the non-JS WebKit to a natively compiled Typescript app as some sort of faster,more native Electron replacement.
That should be already possible,or at least it will be possible at the point it works for the Mail app,and it doesn’t need to split the codebase of WebKit.
1 Like
To my knowledge, this has a high chance of being a really large project. It could take us years to achieve it! For the most part, we’re interested in getting WebKit2 over to Haiku, which will probably take at least a year.
Of course, one can always imagine what we could do if we had unlimited time and people. Or one person who is really interested in the problem.
2 Likes
JavaScript interpreters and JITs introduce more overhead than they are worth. If there is already an HTML viewer used for the eMail stuff, I may find other ways to add the missing parts to that and remove the dependency on WebKit partially or entirely.
The planned HTML view for emails isn’t a WebKit replacement.
It’s just WebKit with Javascript disabled and probably a few other safety features (loading external content only on user request and such).