Skip to content

Design Philosophy

Paul Mansour edited this page Feb 14, 2024 · 13 revisions

Overall Design

Abacus uses WebSockets to connect the browser to APL. The browser might be an HTMLRenderer object in the APL workspace, communicating with the same APL instance, or the browser might be on a client machine communicating with APL on a server.

Browser DOM and APL DOM

On the APL side there is an APL DOM. This is the DOM. The browser DOM is merely a representation of the APL DOM. Because all communication between the browser and APL is asynchronous, the browser does not always know the precise state of things, which only the APL DOM knows. For example, if in the browser the user is repeated pressing Ctrl+Insert and inserting new rows into a table, the browser may think there are, say, 10 rows in the table, even though the APL DOM has 15 rows, because the messages coming back from APL have not updated the browser yet. The browser however does not need to know the state of things, as it delegates everything to the APL DOM.

No Native Graphical User Interface

Unlike Electron, Abacus makes no effort to support native forms, settings, themes, and look and feel, in Windows, Mac, etc. For or better or worse, everything is in the browser. For example, dialog boxes will look identical across all platforms.

No Frameworks

No frameworks or tools other than this one. Pure HTML + CSS + APL. There is no need for heavy duty third party frameworks. HTML and CSS are very advanced as is, and APL is the most powerful programming language in the universe. What more do we need? No need for compatibility across browsers, we are all in, for better or worse, with CEF. Regardless, even if we switch browser engines, the result will be consistent, if not identical, as the whole point of HTMLRenderer is distributing the browser with APL.

No JavaScript

Abacus puts a very small amount of JavaScript into the HTML. This JavaScript responds to specific events and calls into APL. There is no result or action taken back in the HTMLRenderer to this call. APL then handles the call, doing whatever it needs to do in APL, and (often) updating the APLDOM which automatically updates the HTMLRenderer (using ExecuteJavaScript) to keep the APL session and the browser in sync. Virtually everything is done in APL.

Know HTML and CSS

There is no escaping a good understanding of HTML, CSS and the DOM. If, in the past, we wanted to want write GUI in APL using the Win32 API, we needed to know ⎕WC. If now we want to write GUI in APL using the browser, we must know HTML. HTML with CSS is ⎕WC. There is no useful way to hide the HTML. For example, just as we must understand the Attach property in ⎕WC, we must know about the flexbox layout in CSS. Arguably HTML and CSS are much higher level concepts than ⎕WC. It does not make sense to re-create ⎕WC with HTML.

Know Events in the DOM.

We need to know about event bubbling, etc.