It's been a couple of weeks since I last posted about Davaux. It's been an interesting and exciting couple of weeks. The last time I wrote about it, Davaux was basically a web server that could serve web pages, static files, or an API from a file-based routing system. I intended to keep the server simple, code-wise, but it felt too restrained. The more things I tried to build with it, the more I realized it needed to be somewhat complex, but I needed to build it in a way that kept it as simple as possible to use.

Middleware

Davaux has most types of middleware you may need built-in. You can easily choose from various types of presets to set a default middleware configuration, using app.config(). By default, most middleware is turned off, even when using app.config alone, you have to choose a preset to turn on most of them or you can turn them on (or off) and configure them individually within app.config.

Routing

I really loved the file-based routing, as it was conceived, but I realized middleware could become an issue with this approach, when also using it as an API server or the other possible uses. I expanded routing to have route initialization, where you can set the middleware for that specific route, if wanted. This means Davaux has the typical app.route and app.[method] functions to declare routes. Each route can have a different middleware configuration, including using a preset or the manual overrides. Routes can also be extended with a special routing extension provided by a middleware; if you want to handle SSE routes specifically, you can enable the SSE middleware and then set a route using app.sse, for instance. This then only enables the necessary HTTP Methods for that route to perform SSE, which can also be manually overridden.

Layouts & Pages

Davaux features a fully functional Layout System, which overlays a Page System. By default, a /layout folder serves your layouts and a /pages folder serves your pages - these are in your app and can be configured. A layout path matching a page's path will override the default layout for that page. An HTTP method being requested on the root route will attempt to match an HTTP method function, such as GET or POST in the corresponding page file.

Components

Davaux is a reactive web server by default. It doesn't use React or any other framework for reactivity. It simply uses Signals to store and manage state. Components are rendered into plain HTML and Javascript and served to the client, there is no bundling or building, it just serves as a route. Any GET function in a page component file can be served as a page, which is handled by the file-based routing in the root route. Components also have some really cool options for how they are called or used, which are quite unique to Davaux.

UI

Davaux isn't like any other web framework, as far as I know, so it needed to have it's own UI framework. The good news is it's not an overly unique UI framework, on the surface. It's mostly just CSS, which uses naming much like other popular CSS frameworks. Under the surface, it does have a few secrets that make it entirely unique and necessary. Honestly, if I could have avoided building a UI package, I would have, so I've kept it fairly simple and not overly opinionated. One good feature, though, is it supports multiple color schemes and multiple color modes. This means you could have a Gruvbox theme that is dark, darker, or darkest. The modes are easily toggled without reloading the page.

Development Server

There is a dev package, which offers a development server to use with Davaux. The development server uses more relaxed middleware settings and features Hot reloads, as well as extensive debug logging for routes and middleware. It has some other interesting features, but I wont get into that yet.

Static Site Generator

While Davaux is a server-side rendering server by default, it also offers an ssg package to act as a Static Site Generator. The pages generated are exactly like they would be served from Davaux, so you don't lose any functionality by serving static files, compared to server side render pages. There are helper functions included that allow you to generate pages with fetched data, to make the pages dynamic by utilizing an API server (served from the same code base you generated from), or to render different types of markup. To me, the greatest part of Davaux's SSG functionality is you can have a single app and render it with SSG or serve it server side, there's no real difference between the two. You could start out with a simple SSG site, grow it into a full blown server-rendered site with various APIs and never have to rebuild anything.

Create Davaux Application

I've started on a create-davaux-app CLI tool, but it isn't finished yet. I do plan to build several different templates to have as starting points. I also plan on having a user registry for templates, as there are so many potential use cases.

With all of these features, there has to be a drawback, right? Well, the drawback is it's something completely new. It's also very easy to use and very fast. I'm sure there are some drawbacks somewhere, but I plan to find them and fix them.