This would be a good idea, and the same library could be used in non shell based interactive pages.
By leveraging the Prolog load_scripts/load_string it is possible to have people modify the Prolog code and refresh the page. The code can also be saved in the browser localStorage.
I made a (very simple) sudoku webapp to show the students that they can alter the rules and see the effect somewhat live.
What do you mean with a “framework” here?
It is possible to yield from foreign predicates. As is, it is not possible to yield from e.g. read/1 though as there is too much state in there.
This all is not needed though. Just gave chat a try. It reads using get/1 and get0/1. What is needed is that all these one character reading predicates, when reading from user_input
This is not particularly hard. read/1 can also be handled this way by reading a line and if parsing returns an unexpected EOF syntax error, read another line and retry.
I was just musing what should be the behaviour of such
a WASM shell when the input is finished. Or when the
user enters end_of_file token?
I currently find that it hangs:
When I press abort, nothing happens…
How do? I’m actually working on a little project that you might find interesting to inform your design decisions here, and @torbjorn.lager’s $0.02 are insightful. I honestly haven’t been following closely enough to have sufficient context to make any arguments here, but I can share with you what I’m up to and thinking if you find that useful.
So, because I have a background in education and AI, I’m building a typing intelligent tutor system at https://typingwiz.com, currently you’ll see it’s just got typing tests and then analysis components in there. It’s about a month old. The whole thing is built using VueJS as a framework. The UI components are complex, for example the typing test input isn’t just a form input, and the analysis speedometers are generated SVGs. So like torbjorn.lager was saying, it’s a complex end-user application adopting a JavaScript framework.
So why the JavaScript framework? Not only are the components complex and reused, but the in-page logic is updating and replacing parts of the interface within the page depending on user action. I need to say “hey, if this value changes go and update that UI over there”. I don’t want to rewrite all that complicated logic and component management. This isn’t so much a website as it is an application in a browser. I’ll add more reasons in the following paragraphs.
So where does Prolog fit in? Well if you look in your browsers local storage you’ll see that I’ve captured a lot of data about your typing when you took a test, which is what the analysis is based on. Tests are also captured over time. My intention is to use Prolog to implement the intelligent part of an “Intelligent Tutoring System”, that is to say it will use a rule-based AI to offer feedback, mark progress, and develop custom exercises for each individual learner catering to their own needs. So that means I will pass data to the Prolog and get data out of the Prolog, I don’t want it touching the UI at all.
So why client-side Prolog and not server-side Prolog? Well a server costs money. Currently the website is static and so free for me to host. I also don’t need to deal with user accounts, personal data, or any of that regulated overhead. By using Prolog in the browser I hope to get this thing to a point where it starts to generate income to pay for itself. Otherwise I’ll just kill the project, it’s business after all. If it does start to generate income then I’ll move the Prolog to server-side for better persistence and cross-device support. That’s another reason I don’t want the Prolog to touch the UI, it means I can move it from the client to a server.
What concerns me about using Prolog for this? Size down the wire. Bearing in mind I don’t know how big the files are that go down the wire, but this is the pressing concern for everything. The business success of this application will be made or broken by SEO, I need to appease the search engines to get to the top. I’m currently being penalized for large screen updates on loading that are caused by the navbar and footer being rendered by the JavaScript instead of in the HTML (it’s on my TODO list!), so load times are very important. Now I suspect I’ll be able to load the Prolog ITS asynchronously in the background because its functionality wont be required until some interaction takes place, but size and speed of loading is really important. A CDN could help here. I liked the way Tau-Prolog would let you choose to exclude certain libraries you didn’t need so you could further reduce the size. This is another reason for the JavaScript framework, it’s small so my application is running soon after the initial request.
I hope you find some value in this insight into how I, as an application developer, am thinking about WASM Prolog. I’m sure others may think differently but because we’re so few I thought I’d share.
p.s. I hate JavaScript and would much rather only write Prolog all day 
p.p.s. but I’d rather have a successful application than only write Prolog all day 
As is, the SWI-Prolog WASM version is rather versatile. For the browser it comes in two tastes: swipl-web.js and swipl-bundle.js. The latter has a version swipl-bundle-no-data.js. Roughly, the WASM component and JavaScript wrapper is about 2.5Mb. That is sizeable, but in these days no longer a show-stopper I think. The default data is about 4.3Mb of libraries. You don’t need these. You can generate a minimal saved state.
It seems like there is a lot to gain. We could distribute the library as .qlf files rather than .pl files. As SWI-Prolog can also load from .zip files we can probably also provide the resources as .zip. That probably strips to down from 4.3 to about 1.5Mb, improving performance as well Next might be to generate large libraries as .qlf files that are kept on the server and loaded when needed.
Then, how to use this. The shell now provides a reasonable start at a Prolog with debugger. If you use SWI-Prolog without the shell, this is lost. Well, maybe not. It should be feasible to write a debugger that pops up as a modal window. For short, I think it is possible to achieve a fair development environment for integrating Prolog in web development. That is quite some work though and it will still require a (cacheable) download of about 2.5-3Mb.
Same if you run ?- halt. It is easy enough to change that, but there is not much
sensible to do. Best might be to remove halt/0,1 and trapping end_of_file. Too minor to worry about.
Hi @PaulBrownMagic - that’s a nice app and a great illustration of what I was trying to say! I’m terribly slow with my keyboard, so I might use it myself.
I envy the speed with which my daughter is able to compose text messages using only her thumbs. Have you thought about a version that works on a mobile phone as well? Well, I suppose that’s a very different scenario.
Sorry Jan, I think I was a bit too quick with my first entry into this discussion, in particular after such a long time without engagement from my side in discussions at this forum. (I have been lurking here all this time however, following the development of SWI-Prolog quite closely - almost every day in fact.) I really should have started with a praise of what you have accomplished with SWIP-Prolog compiled into WASM, because it really looks great. It’s also nice to see the work around PIPs that you and others in the community have made over at the All Things Prolog web site. In particular, I hope the discussion around dicts will lead somewhere, as they are perfect for representing JSON.
I must confess that I know almost nothing about how JS talks to the Prolog WASM process in your demo implementation. I guess I wonder if you see a chance for your approach to spread to other systems that may also want to implement JS → WASM-Prolog interaction - an approach that might be captured in a PIP? It would be great if there was a way for the community to develop applications such as playgrounds (and more sophisticated web-based IDEs) which can be shared by many systems. I thought that would be easier with a ‘standardized’ protocol over JS → Prolog connection using web workers, but maybe I’m wrong?
Due to their asynchronous nature and use of events and message passing, JS talking to Web Workers, WebSockets and Pengines seems to have a lot in common (or can be designed to have a lot in common) - things that might make it possible to think about this communication on a more abstract level, and make it possible for implementations to share certain aspects such as the representation of messages, ordering constraints, etc.
Keeping JS and Prolog as separate as possible and enforcing communication over well-defined APIs that can be employed by many Prolog systems, allowing the Prolog community to join forces and (with the help of front-end programmers that really know what they are doing) build things like a playground and a sophisticated IDE that can be used by any system that supports these APIs, just seems to me to be a good idea. But perhaps your approach would allow that too.
That makes sense. As @j4n_bur53 says, you can get a richer UI using developments on web consoles. The alternative would be to wrap Prolog systems capable of running inside the page into some JS class that would be the basis of a shared IDE. A disadvantage of that is that it requires more substantial changes to the Prolog core, i.e., allowing to yield from the VM, both providing “foreign” predicates that can be completed using yield/resume and to provide a debugger interface that can do this. This is not rocket science and altogether didn’t take more than a week to implement. Ideally we’d come up with a common C API
Another question is why we want to implement a Prolog system running in the browser? One obvious application is education and demo pages. Education has never been the primary motivation for SWI-Prolog’s developments. Is Prolog in the browser good for more things? Is it a good idea to give Prolog access to the web page, allowing it to act on events and manipulate the DOM? I don’t know. It is surely nice as a toy. It probably can make richer (but less portable) user interfaces. Being able to comfortably talk to the browser can also support cute demos and skeletons that can be used by students to create something more attractive than a console app.
On the other hand, how many serious applications run completely in the browser? How many of those would profit from Prolog? After all we are far behind when it comes to frameworks to create and manage dynamic web pages. Yes, if there is some application logic involved you want to do so in Prolog. But, quite often there is a server involved anyway, so you can also run this logic there.
One of the things I was wondering about is whether https://htmx.org/ is interesting. I’ve used it quite a bit on the server side. It is a good match to (SWI-)Prolog as we still have an excellent infrastructure for generating HTML snippets. If we could modify the htmx triggers that now contact the server to call Prolog predicates, one might have a quite powerful page manipulation language. It is a bit hacky though. One could also look at a proper declarative approach.
Clients in client-server applications don’t need to be dumb,
there is a trend from rich clients, i.e. off loading server HTML, SVG
etc… generation, to smart clients with a broader responsibility.
Many AI-powered web applications use JavaScript or WASM for:
Efficient tokenization & text processing (e.g., subword segmentation)
Compression & decompression (to reduce payload sizes)
Cryptographic operations (for secure communications)
Custom UI rendering or interaction
What else…?
Intrestingly ChatGPT mostlikely uses service web workers:
Yes, ChatGPT’s front end uses a Web Worker to handle background
tasks like streaming responses without blocking the main UI thread.
Who else…?
Edit 28.02.2025
But of course you find camps thinking of AI applications in terms
of micro services only. But this heavily ignores Edge AI.
Funny enough, SWI-Prolog can run in the main browser task without blocking it The performance implication is neglectable. I’ve also seen JavaScript code that breaks long running tasks into chunks, returning to the browser event loop in between. With the SWI-Prolog WASM you get that for free. But, a web worker can use another core. If you want that, you need to run SWI-Prolog in a web worker. That should work fine.
I didn’t even know it existed. But then, I’d assume you can simply create a little JavaScript file embedding swipl-bundle.js in e.g. swipl-worker.js and do
const myWorker = new Worker("swipl-worker.js");
Any reason why that should not work?
It might be a remain of an attempt to use workers for Prolog multi-threading. That didn’t work by then. It is not so interesting anyway as you need to create the threads upfront. Now that can have concurrent asynchronous engines I think there is not that much reason to continue in that direction.