This is a brief list of love and hates of the TroopJS framework from a UI developer's perspective, sort of my reflections as a TroopJS developer for one year, willing to inspire those who have used it in the past, or is likely to embrace it in the near future.
Component composition is sweet, signals are perfect for component lifecycle events, component is a nature isolated organization of UI feature.
Completely AOP, mix-ins are perfect for augmenting component feature, never have to adjust hierarchical structure, never have to call "papa". Decorators are cheap way of customizing existing behaviors, event arguments passed into constructor can be altered.
Query are both efficient and robust way of accessing client object graph, data is always correct as guaranteed by the server API, cache is perfect for constructing semi-offline application, as well as mocking up client states.
Synchronization is transparent and on-demand, properly batched that reduces a lot round-trips, server response automatically update or expires the client cache, all you need is properly set up the expiration.
Service is perfect for application global construct as both hub events provider and consumer, implement plug-and-play functionality couldn't be easier.
Structure expressed in HTML (as data-weave), which is enchanting for designers and amateur (Look’ma no JS, magic!), but hard for serious JS development.
Widget is hard to construct - object in constructor has to be passed in through the DOM bridge (aka "data-*" lifting).
Widget is hard to update - impossible to mutate widget state from just re-rendering, without explicit inquires - check for woven first, create one if the widget is not yet weaved, otherwise, publish a data change to the widget to update it. Do I really have to do this on my own?
Asynchronous rendering is brittle, widget spreading out all children without herding them, consequentially results in page flicks.
Forcing each widget to live as a separate module, sending back to the old-dark Java days - we want to visit widgets in a closure sometimes, it makes their state management super cheep.
Interested data arrives even before the widget is created, water comes out of a tap even before I got the bottle, memorized hub is an obscure hacks.
Stateless widget is easy for the library but not for you, manging state change on widget, and conditionally kick out re-rendering is entirely on your own effort, plus the facts that hub events can arrive on widget in any random sequence, integrity guarantee is at your own risk.
The hub is sometimes like a echoing wall, where I publish a message, expecting there's someone consuming it out there, but if there's not, my original message returned as is, and I am like... :D
Abstract layer can solve many problems, except of having too many abstract layers, since the missing of alias or a unified TROOP namespace, everything I would have to import a module for every single small thing, from composing an object, specifying an event runner, to utilize helpers.
Quite likely to need more "specials" to connect widgets to global events in the browser in production: cache changes, URL routes changes, screen size changes, network requests occurs, etc.
Troop modules is tend to be changed once in a while, which is a good thing for framework, but pain for you.