As you may have guessed, STAAX is something we have been working on in the background while we've been busy developing our online web-based software, which combines several technologies into a single source repository. This is called STAAX and it comprises of the following:

• S - Strapi, the thing used for the backend. What makes Strapi so great is the fact that you can build custom types and manage the content for those types within the application for use later. With the fact it can produce simple JSON files that are easily readable, we can leverage Haxe macros to generate types at compile-time based on these files, thereby eliminating the time needed to create separate types for both the client and server.
• T - Tailwind. Almost every modern website today uses Tailwind due to its simplicity and CSS generation suitable for production use. Furthermore, laws and regulations are used to enforce specific CSS rules in certain scenarios, and thus having Tailwind reduce the legal burden on designers is a great advantage.
• A - One A is for Alpine. Unlike jQuery, we've found that Alpine does some neat and small interactions which is generated for the loaded page, making front-end interactions that much more easier to accomplish.
• A - The second A is for Axios. This is perhaps the more important feature of the STAAX web stack as this gives us an easy to use method for communicating between the client and the server with JSON-formatted data. Moreover, it goes hand-in-hand with Strapi, making it the ideal solution for communication.
• X - The X is simply the X found in Haxe, of course.

Putting all this together into a single source repository is something we are currently working on, and we are currently in the midst of expanding what we've already put together and integrating the various options.

So, what have we done so far?

• Router - As with with all frameworks, a router is practically essential. We have options for adding static directories and routing URL paths which can include parameters. These routes accept callbacks in Haxe which we have put together as Callback taking no parameters, or Callback1, Callback2, Callback3, etc. for the number of parameters required in these cases. Why not use Rest arguments? Mainly because you want to be strictly typed, especially when dealing with models which we will discuss once we've implemented this.
• Pages and Components - Components can have child components. Each component can have a starting HTML code and ending HTML code. Each component can be "executed", which means you can pass in a Dynamic structure which follows Haxe Template rules. Next, you can create what's called StackPages. A Stack Page is a page containing a stack of components. You get the idea. Basically, to create your web page, you construct a Stack Page and add Components to it. Pretty simple, huh?
• Targets - Currently, only NodeJS is being used for testing, but there are plans to test on PHP as well, most likely using NGINX. All other targets are either too complicated to setup or just not worth looking at. C# and Java are used in enterprise environments and most large organisations would stick to those languages than teach their thousands of employees to switch. Python in the web world is limited to only certain environments and most web developers use Python as a secondary language rather than a primary language. In reality, we're only likely to be considering JS and PHP as target languages for STAAX.
• Tailwind implementation - I have a personal Tailwind UI license which I am currently using as a testing grounds for implementing the various code snippets for my own purposes. There isn't going to be much with this "implementation". The extent of this "module", if you like, will be incorporating commands like "npx tailwindcss --watch" for automating CSS generation and some small backend options to allow Tailwind to pick up changes in a compiled output. There may be other options if needed, but unlikely to be an inconvenience if it weren't there.

STAAX is not ready to be published yet as it's currently being used in a specific environment, but it will eventually become more generalised for public use.

Currently, the main focus is using Tailwind UI and incorporating it's many code snippets into my own workflow, but this will be expanded to include our own code snippets. As the software we're working on grows, a lot of repeatable code will be incorporated into STAAX, including:

• Front-end hash routing
• Non-routed HTML code generation in DOM elements when working on complex interfaces (overlays, etc.)
• Incorporate a loose MVVM architecture for database interactions and obtaining views (STAAX will have no concept of controllers).
• And probably more things...