Electron as GUI of Python Applications

It's a (poorly designed) API, usually written in js, that allows you to read and modify a markup document on the fly:

   https://en.wikipedia.org/wiki/Document_Object_Model

The other commenter is right, but I'll break it down a bit further. There are actually two related ways of using the word DOM.

Usage 1: the set of rules (API) for manipulating a document

HTML is a way of writing down a webpage so you can send it over the internet to the browser. The browser then reads in the HTML and uses it to build the "actual" webpage in memory. Different browsers may represent the webpage in different ways internally, but they try to provide a common set of rules and methods for interacting with and manipulating it. That common set of rules and methods is the Document Object Model. These rules include things like the way forms work or the kinds of properties input boxes are allowed to have (such as placeholder text, a current state, etc.).

Well, a "common set of rules and methods for interacting with something" is exactly what an API is. This is why the other commenter can correctly say that the DOM is "an API ... that allows you to read and modify a markup document."

Usage 2: the document itself

HOWEVER, while "DOM" technically refers to the API for manipulating a thing (the markup document), people most often use the word to refer to the document itself. This makes sense, since you never interact with the browser's internal representation of the document, you only interact with its public interface, and so gradually you come to think of the interface as the thing itself.

This double usage is why it's confusing to put the DOM on the same level as HTML, CSS, and JS. Technically it may be true that it's a separate and parallel technology, but since the document itself is built by reading in HTML and CSS, and then can be modified through JS, it's probably easier to think of it as one level above them (or below or whatever).

Edit: to reply to your questions more specifically:

- SAX/DOM: ignore this, it's arcane and not relevant

- schema for data exchange: no, that's exactly what HTML is — a format for sending data between computers. the DOM has more to do with how they represent that data to themselves after they receive it

- web tech vs. native UI: if you're trying to understand the DOM, don't worry about the UI of the browser, just worry about the web page itself

The DOM is exactly that, an API to interact with nodes of a XML like document. XML and HTML are obviously different but the underlying structure isn't. You have different levels of DOM, usually only level one is implemented in most XML libraries. SAX is evented which means you don't have to read the whole XML document to be able to interact with it.

To be precise the DOM is 2 apis, one for OO languages(Elements with a type hierarchy) ,the other for C like languages (nodes)

Does Electron run on mobile platforms?

I have an MS in CS and am now working in a science lab. Most scientists (much less grad students!) are not professional programmers. As such I'm working on moving my GUI code from PyQT to html5 based UI's because it simplifies what non-professionals need to learn. By capitalizing on advances in html they can learn some html/js and use it in reports, for UI's, and sharing data, instead of learning Python and QT, while trying to figure out formatting documents in latex or word, and creating their code Matlab or C or Python and then outpatient plots.

Electron and html5 have a ways to go, but the synergy that can be gained will be well worth the effort, IMHO. Using a browser for quickly sharing research and making basic UI's to interact with computations actually fits rather nicely into the vision Tim Berners-Lee had when created html for browsing information at CERN.

As far as statefullness, GUIs really would be better off moving away from implicit state to ReactJS functional style approaches.