Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check https://xhr.spec.whatwg.org/.
Promises are Ok as they are async. Fetch() had issues with some browsers, needed polyfill, when I started this work.
Axios is extremely popular still, see below ? In my code the calls are wrapped so easy to migrate to fetch() or XIOR or anything else if you want. A few minutes work. I wrote this years ago so was not a concern back then and not a big issue for me now, as I am not producing a product for sale or have any SLRs to meet… If these are an issue for you then maybe go with fetch() now. I do use fetch() in other apps of mine, not really fussed. Mostly use angular that uses HTTPClient.
Also this is about the Prolog not Javascript so not really a concern here, whatever web-sevice stuff works… e.g. the code also uses JQuery that is not needed anymore and I will remove as I go. I did upgrade to Bootstrap 5 that no longer depends on JQuery.
I just updated the Prolog to use Dictionaries and Meta-Predicates from Jans advice.
The main point is today don’t use prolog to create the HTML, like a JSP, but build an independent Web App, and call APIs on the prolog server.
electronJS would be an ideal option for all platforms, and i considered to use it, but at a certain point i understood that on Macintosh they actively Disabled the possibility for electronJS on mac OS.
On windows a local webserver is treated as vey odd by virus scanners and possibly also by windows itself.
and most web-browsers will give 3 warnings if you try to run http without https and will change the url for you, and will it ever be possible to acquire and distribute an SSL certificate for localhost ?
currently i have only an 32-bit Imac and i have the impression almost nothing runs on it since they went to 64bit , though swi prolog does run on it
What is the state of XPCE? I was wondering if the “easiest” solution wouldn’t be to write a runner for XPCE that would run in browser, talking to a pengine holding XPCE objects. The runner would be “just” handling rendering and passing input back to pengine. Upside would be that existing XPCE apps would run in browser
XPCE is in a deep sleeping state. It won’t be dropped, but it is also unlikely to be further developed. Of course, unless someone has big plans I guess the first plan needs to be to move way from the low-level X11 and Win32 API to something modern and portable that deals with basic window handling and drawing. Currently, XPCE implements all widgets on top of simple graphics (lines, arcs, filling, text and draw images, all at the pixel level). This step is probably doable as we already have two bindings for this low level stuff (X11 and Win32). The portable layer consists of about 100 C functions that vary between a few lines and complicated stuff to fight one of the base APIs.
A big question would be whether to move widgets to some modern framework. That would make it look nice, but it would not be 100% compatible.
I was thinking that XPCE engine/runloop that handles events and draws stuff using X11/Win32 API could be extended to talk to a remote process in a browser instead. This “runner” would then take commands coming from the XPCE engine and then either draw directly to a canvas element or render primitives using DOM manipulation, and also relay DOM events back to the engine…
But now that I think about it, the easiest way to do get a demo of this would be to run an X server in the browser, and let XPCE XLib talk to it via websocket Bit crazy but given an existing X server implementation that runs in browser, it would be mostly plumbing work…
Not sure if it has practical value though… It’s bit like running a VNC viewer to a server where XPCE runs, just integrated, but this is far away from a modern UI library
I think you’ve described a variant of Wafe (there’s a diagram part-way down the page, although you’ll get better information in the paper that’s here).
I used it a long time ago, so I’m fuzzy on the details (e.g., I don’t recall it depending on Tk/Tcl); basically, it’s a bidirectional asynchronous stream between the front end (display) and back-end (controller); it’s language-neutral although slightly biased towards Prolog or other languages that can easily handle complex structures. As I recall, it’s also somewhat similar to how Java’s “Spring framework” works, except it’s fully bidirectional (Spring, as I recall, allows putting “Runnable” items on a display queue, so decoupling the responsiveness of the display from the controller’s processing).
I created an office program with the use of XPCE and the whole application is based on a listbox to choose a string from a list, and a box to enter and get a string
