Nostromo wurde ursprünglich nach dem Prinzip Convention over Configuration entwickelt. Das bedeutet, dass Code einer bestimmten Konvention entsprechen muss. Tut er das, passiert vieles in Nostromo automatisch. Dieses Prinzip ermöglicht eine schnelle Entwicklung stellt aber neue Entwickler oft vor Probleme. Die Oberflächen werden komponentenbasiert entwickelt. Das bedeutet, dass die Oberflächen erstellt werden, indem PHP Objekte ineinander verschachtelt werden. Diese Baumstruktur wird erst ganz am Schluss der Pipeline in HTML gewandelt. Jedes Control ist dabei selbst für seine Wandlung verantwortlich. Dieses Vorgehen erlaubt eine hohe Wiederverwendbarkeit, sowie das automatische Generieren von Oberflächen. Allerdings ist man damit natürlich nicht so flexibel, wie wenn man den HTML Code direkt schreiben würde. Besondere Herausforderungen bestehen in der Einbettung von JavaScript. was developed when convention over configuration was the way to go. This means that as long as classes, directory structures and other things conform to a certain convention the framework will pick them up automatically. While this enables a very fast dev flow when you are used to the conventions, it slows down anyone that is not fluid with them, resulting in a quite steep learning curve. Over time explicit configuration came en vogue again, because it is easier to test as certain aspects of the application flow can be easier mocked during testing if you are able overrule the default. As time went by both approaches mixed in Nostromo, which makes it quite hard to understand, when something just works automagically and when you have to configure stuff.
Nostromo started when Symfony was in its early stages and the predominant PHP framework was CakePHP. The quality of available frameworks was just lightyears behind stuff like MVVM Lite for C# or Ruby on Rails. This (and the component based UI) was the reason to start our own framework. In recent years we tried to decouple Nostromo much more and exchange parts of our own code with community standards like Monolog or Symfony Debug. Over the long run we wll migrate to Symfony or Laravel. Migration to Symfony will be much easier as it is not as opinionated as Laravel.
The UI is build in a component-based manner similar to how you build UIs for desktop applications (i.e. Swing). You build object trees that are only rendered to HTML at the very last moment before the output. This enables us to create UIs programmatically and have different output by using another rendering method for that object tree. It takes some getting used to, because you rarely see any HTML and if you do it just looks weird and out of place because you have to switch concepts with these mixins. In the long run we will probably switch to view models and use libraries like inertia.js to connect single page apps with our server side logic.