DAVAUX Posts

about 2 hours ago

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.

David D.

0
0
0
2

Davaux has begun to mature somewhat. It is now a full featured web server, with built-in support for middleware such as CORS, cookies, JWT, sessions, authentication, and others. It's still possible to run it with no configuration, as it adjusts middleware settings based on the environment, but you can also choose presets for different deployment types and security levels. Currently, you can even build an app and just run the Davaux server package directly from npm to run the server, you don't even have to import it anyway.

It still doesn't require compiling anything, is runs as ESM on the server, and it has no dependencies, outside of it's own packages. It serves browser-ready HTML, CSS, and Javascript, with built-in reactivity, there's no bundling or large file transfers. This means it is responsive on any device and can run on any server that can run node.js. In my tests, even pages with a heavy load of reactivity, the total served file sizes are just under 50K.

It has a full featured router for serving any request type and built in layout handling that supports the same nesting as routes. You simply add a Javascript file in the pages folder, or within a deeper folder, and that's your first route. If it contains a GET function, it serves a page, if it has a POST function, it serves an API, if it has both it does both. No additional configuring of routes is necessary, it just works. Layouts work the same way, except they go in a layouts folder and return a template.

My focus recently was getting the middleware built-in and working by default. I've also taken care to make it all work as simple as possible. If you know Javascript, HTML, and CSS, you already know how to use it. Now that I'm happy with that, I'll be working toward full stack territory. I want to be able to server MPAs (what it does currently), SPAs, APIs (also currently), and generate Static sites, with or without built-in API support. It sounds like a lot, but I've put careful thought into the architecture in an attempt to easily make anything possible. I'll actually be focusing on the Static site generation next, as I think that is likely a market in need.

This is all going to be open source, I just haven't released anything yet. I want it to be as perfect as possible and I want to have the Davaux website/documentation online before anyone else uses it. It's about keeping it simple and letting developers focus on building and deploying, not tooling.

David D.

0
0
0
72
27 days ago

PKA is a Node.js CLI tool that was created by Claude AI to generate the Project Knowledge files for Claude to use in projects chats.

Install in with NPM: npm install -g @davaux/pka

Then run it for the folder you want to generate Project Knowledge files for: npx davaux-pka .

See the NPM package or the Github repository for more info.

David D.

0
0
0
117

I've gone around in circles for years trying to piece together the perfect platform with React. I was happy with Remix, but then they gradually de-bundled their stack. I tried to emulate it with Zulu, but the stack became too heavy. I may go back to that one day, but I'm thinking I may never need to.

Davaux is something new I'm working on that doesn't use React or much of anything else at all. It is ES6, so no compiling is required at all. There will be an optional TypeScript version, which would need to be compiled with tsc, but otherwise you just write the code and run the server. There is no configuration required by Davaux, if there's anything to configure it's because you added it. You write a component for a route, serve it, and Davaux takes care of all of the client side reactivity, it's just HTML and Javascript.

In my initial tests, which did include a full page layout and several different types of reactivity, the page sizes were around 34kb, including my added components' code/styling and the client side library served by Davaux - and that's the dev server, before stripping out dev tools for production. That did not include an UI framework, like Bootstrap or anything like that, that would of course add some overhead.

It all seems too simple, so I've scoured the web looking for anything remotely close. There's not anything I can find. It feels like everything overthinks it, while I just keep turning left and try to make it as simple as possible. It's time to turn web development back into checkers and leave the chess to the content creators.

David D.

0
0
0
195

David Dyess .com

Copyright © 1999 - 2025