Nimetic – Zero-JS Single Page Applications with Nim, Datastar and YottaDB

[K.S. Bhaskar]

We again welcome Lothar Jöckel to the YottaDB blog, with his second guest post, based on a talk he gave at NimConf2026 about his software, Nimetic. Modern web development is drowning in JavaScript fatigue, but there is a powerful alternative that allows you to build Single Page Applications (SPAs) with zero user client-side JavaScript. Read his post at https://yottadb.com/nimetic-zero-js-single-page-applications-with-nim-datastar-and-yottadb/ and of course send us any comments. Thank you.

Regards
- Bhaskar

--
YottaDB - The most scalable key-value database engine in the world?
Find out for yourself.

[Rob Tweed]

Avoidance of Javascript (JS) in the front-end of web applications has always been possible and the web app industry has seen repeated swings in fashion between doing everything in the front-end (where JS is the only scripting language you have available), versus doing all your run-time logic in the back-end (using whatever language you prefer), and of course hybrid systems that do a bit of both.  Some of that move to server-side logic is driven, of course, by aversion to some of the more heavy-handed front-end JS frameworks such as React, but you can't ignore the massive dominance and usage of such JS frameworks out there in the wider web app industry.

If aversion to front-end JS is persuading you to do everything in the back-end and you're using YottaDB as the database, then I have to ask: why use a different language than M for the back-end logic and session management?  I'm sorry but I don't see the benefit of what's on offer here: it just adds needless back-end complexity and performance/scalability inefficiencies.  Server-side JavaScript (ie Node.js or Bun) makes a great deal of sense, as you have a single language at work and to maintain at both ends (and there are lots of JS developers out there who won't be fatigued by it), but otherwise, just use the language native to YottaDB.

Server-side web application development using M is what we were doing way back in the mid 1990s when we started MGateway, with EWD (early 2000s) being probably our most well known and most widely used M-based framework (which, of course, was made available for YottaDB decades ago).  Today, if you want a pure M back-end with the smallest possible pathway between an industrial-strength web server and YottaDB (and therefore delivering the highest possible performance and scalability), I'd suggest looking no further than our mgweb and mgweb server products - they can be used to underpin any style of web app you like with any mix of front-end JS logic or back-end M logic, single page, multi-page, REST-based etc etc.

[K.S. Bhaskar]

Since I know very little about front-end technologies, I'll stay out of client-side vs. server-side part of the discussion.

However, I will note that a key distinguishing feature of YottaDB is that without taking anything away from the tight coupling between the M language and the M database, we have added a language-agnostic tight coupling - a native C API - to the M database (https://docs.yottadb.com/MultiLangProgGuide/cprogram.html). Since C APIs are the lingua franca of computing, this means that the M database can be natively accessed from any language that can call a C API. You can access the database natively from the language of your choice - Go, Python, Nim, etc. - rather than having to use M.

Regards

- Bhaskar

[Lothar Jöckel]

Hi Rob,

Thank you for your input.

My goal was to create an environment that enables web application development with the lowest possible level of complexity.

At the same time, I wanted to leverage the strengths of M-based databases without having to write applications in M itself.

While M offers unique advantages through its tight integration with the database, I don't think the language itself is comparable to modern statically typed languages. Languages such as Nim provide powerful features like compile-time meta-programming, which allowed me to implement a YottaDB DSL. As a result, the database can be accessed almost as if it were a native part of the language, much like in M.

In my view, this largely eliminates M's primary backend advantage—the close integration between the language and the database.

It is true that M achieves outstanding performance through this integration. However, the performance of the Nim DSL demonstrates that similarly excellent results can be achieved while benefiting from the capabilities of a modern programming language.

For me, equally important are qualities such as efficiency, expressiveness, and elegance. These characteristics make it possible to write software that is both concise and highly maintainable.

On the frontend, DataStar patches the DOM with only the minimum changes required. This keeps network traffic very low while still allowing applications to be built using standard HTML and CSS, without the complexity of large client-side frameworks.

I hope this helps explain the motivation behind my approach a little more clearly.