Here goes again — late-breaking notes and random thoughts
This site and the framework connected to it are personal hobby projects and challenges. There is nothing else behind them. The framework is currently licensed under MIT; I hope to release it completely at some point. I call it a library, even if it behaves like a framework.
The initial motivation was a visual, component-based code editor. I think it comes from something I used to like about Delphi or Visual Basic. Unreal, Blender, and countless others use the kind of concept I had in mind. While building it, I inadvertently drifted toward a web editor prototype and, more specifically, the engine that eventually became this framework. Consequently, the framework was never intended to be manipulated by hand or used to write complex, tedious JSON files. From day one, it was designed as portable infrastructure to act as a connector between a server-side editor and a client interface. Looking ahead in broad strokes, the plan is to reconnect the editor and develop desktop applications once I decide on the language. "Spacepeech" was originally going to be the editor's name — a play on design space and speech that I read somewhere.
I barely like the site's design; I would prefer something more brutalist or anti-design. Something freer and stripped of the monotony of so many other websites. For now, it stays with this initial zombie style, though it will definitely change quite a bit in the future.
I started without using any AI assistance. Later on, it felt like a good idea to bring in Claude for design, analysis, and debugging, with Gemini as my work companion (?) to get things done. It becomes crucial in a moderately complex project built with scarce resources. A secondary issue is that language models are trained on conventions, habits, or paradigms that can get in the way when you are designing something different, though that pales in comparison to the benefits.
The genuinely hard part here is QA: thoroughly testing a project across devices, platforms, browsers, security, scalability, and so on. There are no client-defined requirements shaping the goals other than something as vast and fuzzy as interface development — where similar solutions probably already exist without my knowledge. None of this is feasible without clear architectural rules from the very beginning. I initially used JavaScript to prototype, which eventually evolved into this framework, even though my intention was to migrate or transpile it to desktop (excluding Electron or similar runtimes, for now). The public web integration was a side effect. From the outset, it was conceived as a foundation for strongly typed languages like C++, Java, or C#. WebAssembly is also a possibility, though ruled out for now. And as mentioned before, there are no requirements to fulfill other than building a free library/framework that connects an interface through JSON.
Right now I'm deploying the website while already working on the next iteration of the framework with several updates, none of which break the core beyond optimizations. I should date-stamp everything I write here... not today, not tomorrow...