Building a browser GUI is simple. I would even argue extremely trivial. Here is a video demo of one I built in the not too distant past (github link at the end): http://mailmarkup.org/sharefile/demo1.mp4

It took me a little more than 2 weeks to write and test the GUI in that video. From this experience I have learned the following:

* If you are comfortable working with the DOM and vanilla JS you should be spending more effort writing the content and services that populates the GUI rather than the GUI itself. I would say this ratio of time should be something like 20% GUI and 80% content starting out and scaling towards greater content effort as the requirements upon the GUI increase.

* A JavaScript based GUI can be extremely fast and responsive. The video demo was captured on a 4k resolution and it performs, at least to human interaction speed, just as responsively as the OS's GUI even in VMs. That high resolution also explains why the video text is hard to read on a small mobile device. I intentionally wrote this to be fast though using vanilla JS and the standard imperative DOM methods, because that is the fastest way to execute things in the browser. It stands to reason if you go about things in a much slower way it will likely perform slower, possibly slow enough that the user notices a huge difference.

* A JavaScript GUI can be extremely lightweight with tiny code. This is only true if you are comfortable working with the DOM without a bunch of code decoration and abstraction nonsense.

* If the code is organized well it will scale well even in the face of numerous competing enhancements. I solved the problem of scale with TypeScript interfaces and constant refactoring.

* There is one aspect that does not scale well, which any feature that requires complex algebra. One example is dragging a highlight rectangle over some elements for a mass selection and ensuring that highlight rectangle is confined to the containing element and that it knows which elements of the parent element are visually occupying the same space and which ones aren't. Another example is that the CSS property text-overflow only works if dimensions are statically available to the current element or its parent node. That means calculating a dimension for an element in order to set the value upon the element, which requires some calculation written by you instead of relying upon something like display:block;width:auto.

* All presentation, and I do mean absolutely everything except dynamically modified display, opacity, position, and specified dimensions should be in CSS. The presentation that is not in CSS is directly on the DOM node by dynamically reassigning new presentation values on user interaction where necessary. This allows for smaller and more scalable code.

* All icons are Unicode characters. The only one other graphic, because the desktop background, is an SVG spinner. SVG, being XML, can be adjusted with CSS just like the rest of the DOM.