List of feature requests about wolfram-js-frontend

[JerryI]

Hi @userrand,
This is true. I am planning to commit a huge update this week, which will bring the most important features including sort of Iconise[]. It is automatically called, when the output string is too long (>1000 symbols) and iconizes the object.

Regarding the installation issues, well, the current version of the project was more like a concept proof, now it is getting more serious. 127.0.0.01:8090 means it runs a local web-server at your localhost and 8090 is a default port chosen in a way not to conflict with some other applications running on the default 80s port. I general the installlation steps will look like

git clone https://github.com/JerryI/wolfram-js-frontend
wolframscript start.wls

that's all. Everything else is for developers.

might try this in the future. I am currently learning Javascript and I might try to understand the code and add features in the future. Is the current framework limited to 3D graphics via threejs or is it possible to include other features related to Dynamic?

Back at the time I was fed up with glitchy Mathematica's Frontend and wanted more control over it and flexibillity. To check the limitations of the Graphics3D, one can check this page. Sure you can display any Mathematica's object as Plot[x, {x,0,1}]//SVGForm, however, there is a lack of interaction. Therefore, to bring it back one had to write an interpreter in JS of Wolfram Language expressions, which would translate the commands and recreate objects using three.js. It was done already will be developed further. There is no limitations from three.js side, it just requires some time and efforts ;) The same can be done with all Graphics[] objects as well, using, for instance d3.js. I personally recreated only ListPlot and LinePlot using ploty.js, which was quite easy.

All interactive objects are wrapped as

FrontEndExecutable["some-id to the association which holds the data"]

which actually means that the content will be executed by the simplified JS interpreter of Wolfram Language. The content of the function can determine if the results will be displayed as HTML block or not. There are a lot of flexibility on that.

The whole binding between JS (or DOM in general) is easily scalable. Since any Wolfram symbol/function ca be expressed as

core.NameThisFunction = function(args, env) {
  console.log(interpretate(args[0]))
}

and we can call it from Wolfram Engine as

WebSocketPublish[server, NameThisFunction["Hello World!]]

And that's all! No exports or some tricky bindings/bridging.

In principle it opens up a new branch of mixing two technologies. In the same manner the whole Graphics3D. One can go even further and embed any DOM object in this fashion

HTMLForm["<script>alert('Hi!')</script>"]

or add some new definitions to the JS interpreter

HTMLForm["<script>core.MyFunction = function(args, env) { } </script>"]

For the JS side we can also call any Wolfram's functions

socket.send('Print["This has to popped up in your Wolfram console"];')

Moreover, since we are using Wolfram Script Pages (a hypertext post processor, similar to PHP by the syntax), it allows to make dynamic pages, generate HTML content and so on.

Taking everything into consideration it is possible to make a nice analog of Dynamic and Manipulate with even more features compared to the Mathematica's Frontend. I am planing to implement sliders and other simple stuff to show the potential of this combo.

I am using this stack of technologies in my research a lot and in sort of production, thus I would say, this has some good potential.

[JerryI]

2. done ;)

Release 0.8

The rest you listed in other opened issues, so, I would like to close this one. It is also quite outdated.

[userrand]

Nice, thank you for the detailed explanation. The update sounds like it is going to be quite cool (:

[userrand]

answer to multiple coding languages: copy pasted from #5 (comment)

CodeMirror supports mixed and multicode syntax highlighting. However for the autocomplete (or autosuggestions) it might be tricky, there is a packet from Wolfram called Language Server, which provides Lang docs onfly via TCP, which can be redirected to websockets.

One has to be careful, since the front-end and the cell structure highly depend on Wolfram backend and designed for that. Then, any other kernels (js, python) have to be connected to the Wolfram Engine first via Link library

[userrand]

My reply on multiple coding languages :

One has to be careful, since the front-end and the cell structure highly depend on Wolfram backend and designed for that. Then, any other kernels (js, python) have to be connected to the Wolfram Engine first via Link library

I am not referring to direct communication between mathematica and other languages via library link. I meant that notebook cells belonging to different languages would be completely independent, no library link involved. On top of that the community can include translators if they want and add it to a separate repository but the default behavior would be independent kernels and independent languages just in the same notebook for the convenience of copy-pasting results.

Basically, I would like to know if there are parts in the code that are strongly hard coded that would not allow adding more web sockets to other languages independently of the presence of Mathematica.

It seems you can already do this with JSRun but I would like syntax highlighting and documentation. The same for python. I can look into this but I wanted to know if the present code has parts that prevent adding another language or that make it difficult

[userrand]

reply by owner on multiple coding languages copied from : #5 (comment)

I see. In principle, the master kernel, which serves the page, takes care about saving notebook and so on has no idea, what was evaluated. It feeds the string to so called xEvaluator with a callback on creating a new child cell, which can be a remote kernel, any kind of process in theory. In this sense, I would not suggest to get rid of Wolfram kernel fully, because someone would need to do all this supporting stuff. Also the code for the making cells depends on WSP extension for Wolfram Engine.

Expanding the frontend to any languages I can see the following problem pop up

Graphics3D and other possible implementations of interactive objects from Mathematica will have to be recreated in Python or any other languages. I follows the paradigm of Wolfram Language, that everything is a symbol, which is not a part of all programming languages.
TableForm and others now is a part of frontend, of course, one can get rid of them and move to the sort of extension, but in the end the resulting frontend will be the simplest REPL machine with cells and no other fancy stuff.

Summering all of this, at this stage this project might be still too small and young to pretend to be a multitool, as you described. Bringing Dynamics might involve some architectural changes, but I will keep everyone up to date with it.

[userrand]

Nice !