Axios is a promise-based HTTP Client for node.js and the browser. It is
isomorphic (= it can run in the browser and nodejs with the same codebase).
On the server-side it uses the native node.js http module, while on the
client (browser) it uses XMLHttpRequests. Getting Started | Axios Docs
Well XMLHttpRequests is deprecated in the browser, use fetch() instead.
And nodejs has fetch() since release 21.x.x as well. So they have become
isomorphic making AXIOS obsolete:
Notable Changes - Oct 17, 2023
The recent update to Node.js, version 21, includes an important
change to the fetch module as well as WebStreams . Both modules
were marked as stable after a recent update. Node.js — Node.js 21 is now available!
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.
Popularity is maybe not the right measure for adopting Axios when
you start a new development. Its often proportional to technical debt.
The more popular something is the older it is, and the more troubles
you are inheriting concerning adaptation to the changing browser
landscape. The above LogRocket Blog article had an update “Updated
on 29 January 2024”. It leaves only one argument for Axios:
One of the key features of Axios is its ability to intercept HTTP requests.
On the other hand with webstreamsANDfetch, it shouldn’t be
that difficult for example to write a download progress indicator.
webstreams made it also into nodeJS version 2.x.x.
Its part of the WHATWG demo. The Fetch API allows you to fetch
resources across the network, providing a modern alternative to
XHR. It has a number of advantages, and what is really nice
about it is that browsers have recently added the ability to
consume a fetch response as a readable stream. You can do
transformations in a few lines:
Dislclaimer: The advise to not adopt old technology in new projects
is my personal opinion. Feel free to not agree. I don’t see that Prolog
would require old technology, can you explain?
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
