< PreviousChapter 11ConclusionChapter 11: Conclusion292Chapter Contents11.1 Reached Goals ................................................................ 29311.1.1 Mastered Requirements Suite ..................................... 29311.1.2 Proven Component-Oriented Software Architecture .......... 29311.1.3 Proven Component-Oriented Technology Stack ............... 29311.2 Lessons Learned .............................................................. 29411.2.1 Rapid Evolution of Web Technologies ............................ 29411.2.2 Recurring Reinventions of the Wheel ............................. 29411.2.3 Subtle Component System Details ................................ 29411.2.4 Abstractions and Features over Scalability on the Market .... 29511.2.5 Corresponding Technology Framework .......................... 29511.2.6 Integrating Technology Stack ...................................... 29611.2.7 Best Match for Rich-Client Architecture .......................... 29611.2.8 Architecture Adaptability on Server-Side ........................ 29611.3 Future Prospects .............................................................. 29711.3.1 Reusable Patterns in Practice ...................................... 29711.3.2 Full Business Data Model Synchronization ...................... 29711.3.3 Migration to ECMAScript 2018 World-Order .................... 29711.3.4 Adoption in Other HTML5 SPA Technology Stacks ............. 29811.3.5 Adoption for Other Rich-Client Architecture Platforms ........ 29811.3.6 Adoption for Thin-Client Architecture ............................ 298Reached Goals29311.1 Reached GoalsMy goal is simple. It is a complete understanding of the universe, why it is as it is and why it exists at all. — Stephen Hawking 11.1.1 Mastered Requirements SuiteWhen the author started this doctorate six years ago, he just had a vi-sion: to improve state of the art in HTML5 Single-Page-Application de-velopment with a consistent Component-Oriented Software Architecture. Then he wrote down the first draft of the Requirements Suite and be-gan working on the Hierarchical User Interface Component Architec-ture (HUICA) concepts and the corresponding ComponentJS technology framework.Six years later, at the end of this doctorate, after countless days of academic and practical investigations, he is personally pleased with the achieved results. The Requirements Suite, although slightly shifted and extended over the years, finally was reasonably well fulfilled (compare especially Section 10.1 on page 279).11.1.2 Proven Component-Oriented Software ArchitectureThis dissertation now finally documents all essential aspects of the HUICA. For de-tails, especially compare the Solution in Chapter 6 on page 111. Although HUICA over the first years of this doctorate project had to be extended and revised multi-ple times, it is fully stable since about 2015.It even proved to be a successful underlying Software Architecture in over a dozen industrial Software Engineering projects (compare especially the Experi-ence in Chapter 9 on page 253) and is regularly lectured in university and indus-try contexts.11.1.3 Proven Component-Oriented Technology StackThe HUICA always had first-class support in practice through a corresponding tech-nology stack. In the first years of this doctorate project, this stack had no name. It just consisted primarily of the Component System framework ComponentJS and companion libraries. Later, the View library VueJS extended the stack. Finally, all these libraries and frameworks were integrated into a consistent overall technol-ogy stack. In 2016 it finally received its name: GemstoneJS.This GemstoneJS technology stack since 2016 is the technology sibling of HU-ICA and since this time the technological basis for all HUICA-based applications. It fully proved to be a successful implementation of HUICA in practice. Meeting own stated re-quirements is harder than it looks on the first spot, especially because practical experience con-tinuously extends those requirements over time.Chapter 11: Conclusion29411.2 Lessons LearnedThere’s a lesson to be learned from this, but I’ll be damned if I know what it is. — Ed O’Neill, as fictional character Al Bundy11.2.1 Rapid Evolution of Web TechnologiesOver the six years of this doctorate project, Web technologies continuously evolved at a dramatically high pace. It is tough to keep up with this from both an architec-ture and development perspective. Libraries and Frameworks come and go. Old concepts revive under new confusing names. New concepts are easily overlooked because of the overwhelming amount of news published every day.Still no sight of change. Moreover, all this, although technologies are already three decades old. Hence, the first lesson learned is that in a continuously evolving IT landscape, it is important to find fixed points. A consistent Software Architecture proved to be such a fixed point.11.2.2 Recurring Reinventions of the WheelIt is terrifying how often old proven concepts, like Component-Orientation, had to revive. It sometimes even seems as if the knowledge about them is lost every decade in the Software Engineering community.The particular pattern one can observe here is: first, someone has an idea for a feature. Second, this feature becomes popular. Third, the overall complexity caused by the feature’s overuse makes trouble. Fourth, once again Component-Orienta-tion is found to master the complexity. It occurred this way the last time with W3C Web Components.11.2.3 Subtle Component System DetailsThe Component System ComponentJS is the core of the technology stack underly-ing HUICA. Although it sounds like just an average development task at the first spot, experience showed that getting such a Component System correct and bug-free is extremely hard. Especially three aspects suffered from subtle details and special cases and required an effort far above the ordinary: Traits, Life-Cycle, and Guards.First, as until ECMAScript 2015 there was no standardized way to define OOP classes in JavaScript, ComponentJS provides a Scala-inspired Trait mechanism for defining Components based on base and mix-in classes. For simple scenarios, this is easy to implement, but the complex scenarios in large industrial Business Infor-mation Systems multiple times discovered subtle bugs in the Trait mechanism. The world of Web Tech-nologies is both an ex-citing and nasty one be-cause of its fast evolution pace.Lessons Learned295Every time it caused great efforts to both fully understand the scenario and its in-tended results and fix the bugs.Second, the Life-Cycle management of Components is undoubtedly the heart of the Component System. Here the two invariants have to be ensured whenever state changes are triggered on arbitrary Compo-nents. Although already present since the earliest days of ComponentJS, it required multiple attempts to get it right due to the many subtle spe-cial cases in practice.Third, the Life-Cycle management has a feature which is essential in practice: Guards, which temporarily prevent the state changes to further progress on some Components. As there is no possibility to wait in JavaScript synchronously, those Guards have to be implemented in an asynchronous fashion, too. Experience showed that this Guards feature makes the Life-Cycle management dramatically more complex than initially expected.11.2.4 Abstractions and Features over Scalability on the MarketDuring this doctorate project, many other frameworks and libraries were released. It became obvious that nearly nobody of their authors initially had the scalability of their solution to many hundreds of Dialogs in mind. As the release logs of Google Angular, Aurelia, Ember, and ExtJS and other major products indicate, their vendors seemed to initially have been focused primarily on providing cool abstractions and features and only during the life-cycle of their product also started to take care of true scalability.However, in the context of industrial Business Information Systems, the scalabil-ity to many hundreds of Dialogs is very important. Hence, HUICA focused on this aspect already from its initial days.11.2.5 Corresponding Technology FrameworkAs a Software Architecture, the HUICA primarily is just a conceptual solution and exists in its own right. Nevertheless, experience clearly showed that such a kind of Software Architecture could not be applied in practice without explicit support by a corresponding technology framework like ComponentJS. Without this support, HUICA’s aspects are too hard to implement in practice, because at least the transitive Life-Cycle management and hierarchical communi-cation of Components cannot be done manually and individually from within the application code.Getting the HUICA Life-Cycle management of Components correctly implemented in Compo-nentJS was a very hard task and required many iterations.Chapter 11: Conclusion29611.2.6 Integrating Technology StackThe first years, the HUICA was supported in practice by a set of frameworks and li-braries like ComponentJS, jQuery, VueJS, I18Next, and many more. They originated from both the HUICA author and foreign authors, hence were just loosely related and had to be ad-hoc integrated for every HUICA-based application. This recurring integration caused both extra efforts and “boilerplate code” in every new HUICA-based project.In 2016 the HUICA author had the idea of pre-integrating the individual frame-works and libraries required for HUICA into a consistent technology stack: Gem-stoneJS. This step dramatically simplified the development and mainte-nance of HUICA-based applications and also increased the acceptance of HUICA by the developers. Experience showed that a Software Architec-ture like HUICA really needs a companion technology stack in practice.11.2.7 Best Match for Rich-Client ArchitectureAlthough the HUICA theoretically could be applied to both Thin-Client Architec-ture and Rich-Client Architecture, it best matches the Rich-Client Architecture.Hence, HUICA primarily focuses on this context, although it inherently is not tied to it. However, since many years the Rich-Client Architecture is the dominating User Interface architecture. So, HUICA’s focus is no restriction in practice but should be kept in mind.11.2.8 Architecture Adaptability on Server-SideThe HUICA always tried to be aligned as closely as possible to the Component ar-chitectures existing on the server/backend side of applications. In 2015 the author had the idea to apply most of the HUICA concepts to a new Component System for the server/backend side.The result is the Microkernel framework for Node.js, which resembles Compo-nentJS. It also provides Components with Life-Cycle management and communica-tion mechanisms like Events, Services, Hooks, and many more. The major difference just is, that Microkernel does not orchestrate the Components in a programmatical-ly created Component Tree, but orchestrates the Components in a linear list, which is the result of a topological sorting of the Components, based on Component dependencies and Component group memberships.The effect of this adaptation of ComponentJS to the server/backend side is that developers now can follow the same Component-Orientation paradigm and use a very similar Application Programming Interface (API) on both the client/frontend and server/backend side.The GemstoneJS technol-ogy stack is essential for the acceptance of HUICA in practice.Microkernel is to Node what ComponentJS is to HTML5 SPAs.Future Prospects29711.3 Future ProspectsThe best way to predict the future is to invent it. — Alan Kay11.3.1 Reusable Patterns in PracticeThe HUICA comes with a set of structure and behavior patterns. It is not hard to implement them in practice, but the recurring task of implementing them over and over again is both time-consuming and error-prone.Here file generators for the structure patterns and code snippet generators for the behaviour patterns would be reasonable to have. Op-timally, those generators would be available as reusable libraries which can be used from both a Command-Line Interface (CLI) tool and from within an Integrated Development Environment (IDE) plugin.11.3.2 Full Business Data Model SynchronizationThe HUICA knows about Business Model Data Binding (see Section 6.10 on page 168). This allows HUICA to support the requirement [REQ-C4] Near-Real-Time Up-dates (see Subsection 4.2.2 on page 62) just fine. However, to also reasonably meet the requirement [REQ-C3] Potential Offline Operation, a plain Data Binding mechanism, based on something like GraphQL, is not sufficient. For this, a full Data Model Synchronization mechanism is required where multiple Data Models are merged, and either conflicts can be entirely avoid-ed, or in case of conflicts, even a powerful conflict resolution strategy can be ap-plied.The most promising approach for this seem to be the so-called Conflict-Free Replicated Data Types (CRDT) [Letia et al. 2009] [Preguica et al. 2018]. 11.3.3 Migration to ECMAScript 2018 World-OrderThe HUICA-focused Component System ComponentJS was implement-ed during the years 2009-2015, and since this time it was just bug-fixed. As a result, it is based on just the old ECMAScript 5 (until 2015) stand-ard and does neither internally use nor externally leverage from newer programming language and run-time environment features: the ECMAScript 5.1 Object::defineProperty API, the ECMAScript 2015 class, Promise and Proxy mechanisms, the ECMAScript 2018 async/await mechanism or the W3C DOM Mu-tationObserver API.HUICA structure and be-haviour patterns should be supported with gen-erators in practice.ComponentJS could benefit from the newer ECMAScript 2018 world-order.298Hence, ComponentJS could be migrated to ECMAScript 2018, or even re-imple-mented from scratch with the full ECMAScript 2018 “world-order” in mind, and this way become more modern again, both internally and in its external API.11.3.4 Adoption in Other HTML5 SPA Technology StacksDuring the six years of this doctorate project, many HTML5 Single-Page-Application focusing technology stacks were released, most prominently Facebook React and Google Angular.Although those technology stacks already inherently have some aspects of the HUICA, it could be at least educational, and optimally even practically interesting, to further extend them to adopt as much of the HUICA aspects as possible.11.3.5 Adoption for Other Rich-Client Architecture PlatformsThe HUICA primarily focuses on the Rich-Client Architecture and the HTML5 Single-Page-Application context. Nevertheless, HUICA at least is not tied to the HTML5 Single-Page-Application context and hence could also be applied to other Rich-Cli-ent Architecture Platforms like the Eclipse Rich Client Platform (RCP) or the ORACLE JavaFX platform.From the perspective of the HUICA author, no conceptual aspects of HUICA have to be changed for such an adoption. However, the underlying frameworks and libraries, most prominently ComponentJS, have to be rewritten for the new contexts due to different programming languages (Java instead of Java-Script), Application Programming Interfaces (Java SE vs. JavaScript/DOM) and run-time environments (JVM instead of JSVM) of those contexts.11.3.6 Adoption for Thin-Client ArchitectureAlthough the HUICA primarily focuses on the Rich-Client Architecture, it could also be adopted to the Thin-Client Architecture approach for User Interfaces (UI).The major difference here would be that the HUICA-based UI fron-tend would then run on the server instead of the client. As a result, the View Components in HUICA would have to generate and remotely send out View Masks to the client and remotely receive back DOM events from the client.One can imagine an approach similar to the “RISC-HTML” of CaptainCasa in the Java ecosystem, where a generic microkernel on the client performs the actual DOM rendering and remotely communicates with the server for the View Masks and DOM events. HUICA actually would perfectly fit this approach, as all DOM ren-dering is located in the dedicated View Components only. So, everything in HUICA can be conceptually kept as is and the corresponding View Mask management im-plementation library just has to adopt this microkernel approach.HUICA could also be ap-plied to Eclipse RCP or ORACLE JavaFX.HUICA could also be ap-plied to the Thin-Client Architecture approach with the help of a generic DOM-managing micro-kernel.PartEpilogNext >