The first issue here is that _nothing like `GtkTreeView` is built into JavaScript or the browser_. Your typical classical desktop framework (Swing, Qt, wxWidge

The first issue here is that _nothing like `GtkTreeView` is built into JavaScript or the browser_. Your typical classical desktop framework (Swing, Qt, wxWidgets, WinForms, Gtk) all have a huge available list of widgets with built-in behavior. That simply does not exist in a browser. You get a set of moderately capable and partially customizable form input elements, inconsistently implemented across browsers, and made worse by having a wide range of available browser versions actually in use. Beyond that, you end up having to build your own functionality out of a language that was "designed to make the monkey dance when you mouse over it", and a layout system that was originally designed to show _document_ content. There's also been a steady shift from building "web _sites_ with a bit of interactivity", into full-blown _applications_ that just happen to live in a browser, all while dealing with a unique set of constraints. JS had no built-in module system, the standard library is beyond minimal, every page is downloaded in full and so you have to minimize bundle size, and the language is quirky. They also deal with updating a stateful persistent data model that's already built into the browser: the DOM. So, every app is trying to simultaneously fill in a bunch of missing functionality, work across a wide variety of browsers, come up with some sort of themed appearance from scratch, and deliver all the functionality in the smallest possible byte size over the wire. Because of all this, web apps have followed a very different evolutionary path than desktop apps. I've covered some of this background in some slides and articles [0] [1] [2]. As for the design of the frameworks themselves: there certainly were some "classical" OOP-style widget-class-hierarchical frameworks that were out there around 2008-2010. For that matter, the GWT framework let you compile Java to JS, and had both its own built-in widget system and third-party libs like SmartGWt that provided a full desktop-like widget hierarchy. So, it's not that that's never been tried. Those got replaced by the first wave of what were, at the time, known as "JS MVC frameworks": AngularJS, Ember, and Backbone, each of which took very different approaches to structuring data and updating the UI. React took over from those three because it was easier to work with than AngularJS or Ember, solved the UI composition and event trigger problems of Backbone, and was far more structured than trying to update complex UI than jQuery. React itself was strongly inspired by some PHP-based patterns at Facebook. So, it's really a very different problem space with a very different set of constraints, following a completely different evolutionary path. [0] https://blog.isquaredsoftware.com/2016/10/presentation-modern-web-dev-overview/ https://blog.isquaredsoftware.com/2016/10/presentation-moder... [1] https://blog.isquaredsoftware.com/2019/05/presentation-js-for-java-devs/ https://blog.isquaredsoftware.com/2019/05/presentation-js-fo... [2] https://blog.isquaredsoftware.com/series/how-web-apps-work https://blog.isquaredsoftware.com/series/how-web-apps-work