IDE in browser

@flip111 You can't get around building a server-side app to interface with GHDL, python, C++ and various stuff.

Agree. However, with golang it is straightforward to get any AJAX POST request and execute the payload in the shell, then return the log and/or artifacts. This is quite risky to be done in your machine. Not so much in a docker container with limited privileges. I.e., I am thinking of a 'server-side' docker container, including all the required tools.

@flip111 If you use any of them for the critical parsing section you have to deal with additional latency of your HTTP request.

I am considering to use it locally, thus, both the server (container) and the client (browser) are running in the same machine. I think the latency is negligible compared to e.g. the time required to read a medium-large codebase from disk.

Yet, I must admit that in the current setup I use a reverse proxy (traefik) and a local DNS server (dnsmasq) in order to access the IDE with ghdl.ide.dev, instead of 127.0.0.1:5000 or localhost:5000. This can add some delay.

Shall the server be remote, networks delays could be meaningful, of course. Still, we can use play-with-docker to test the performance in this context.

@flip111 For this reason editing code in the browser as a real IDE is already out of the window (a real IDE has code analyses on the fly like with vhdl-tool LSP).

As explained above, I am considering a use case without internet connection. Therefore, the browser is just a replacement for a 'native' toolkit such as Gtk or Qt. This, along with putting everything inside a single docker container, makes the proposal multiplatform. Actually, docker is supported in more platforms than GHDL now.

At best you can do something similar to github which is good enough to make very simple changes to your code.

Well... jsfiddle, pythonfiddle, tour.golang, remix.ethereum, jupyter, codeanywhere, thestrukture/IDE...

Still, I agree with you about possible performance issues. However, I can't see a equally complex solution avoiding web technologies. Say we take Qt, how easy is it to support windows, linux, macos, desktops machines, notebooks, netbooks, pads...? With the docker/web approach, just run it on your desktop machine (let it be windows, linux or macos) and use it from any device local or (if you set it up) remote.

---

For example, a browser-based alternative to atom (i.e. replace nodejs with a golang/C++/python backend) would be:

• hacdias/filemanager is a lightweight web-based file manager written in go. It allows not only to explore, but also to edit, move, create, remove... both files and foldes.
  • Uses Vue.js yet (another) JavasScript framework, such as AngularJS used by @Nic30.
  • Uses CodeMirror, a versatile text editor implemented in JavaScript for the browser. It supports multiple languages, including VHDL.
  • It is a plugin in abiosoft/caddy-docker. See https://henriquedias.com/filemanager/.
  • Can be deployed as a single 5.5MB (zipped) static binary, or as a 22MB docker image.
• Wavedrom, or a D3.js/Three.js replacement (see below) for waveform visualization.
• D3.js/Three.js for schematic visualization.
• jgraph/mxgraph for interactive (meaning browsable, expandable/collapsable and editable) schematic visualization.

The core of the application is a relatively lightweight static binary written in go with embedded js and css files. It should be extended to rely on external libraries/tools, such as OGDF, GHDL, VCD2SVG, etc. to process heavy tasks. Running it natively or in a docker container is a matter of taste.

For example, adding dir watchers is less than 100 lines long. Indeed, Hugo has an embedded web server with livereload capability. Note that it generates a relatively large website in hundreds of milliseconds. Therefore, it is straighforward to use a script to periodically run GHDL/pyVHDLParser, update the data structure and have the website updated.

I have a working example of the livereload scheme described above. I took the concept from Grunt and gruntjs/grunt-contrib-watch, but I wrote it in golang, in order to drop the dependency on NodeJs. If anyone is interested, I can clean it up and create a docker image for development.

@flip111 In this case better to enable an option "upload on save" in your favorite editor. Your linter can be local and low latency.

The interesting part of the docker container is that you can ignore the web API (even disable it) and all the tools will still be available through the shell in your host. That is, you can use the with quick actions in atom. This is interesting because the same linter with the same options can be used locally and in a ci platform to check the quality of any code contribution.