kyoto VS gosqlparser

the only thing i need to do is port the htmx code to golang and then cross compile to wasm for web and then to mobile and desktop. I am currently seeing that there are other htmx style systems out there that are already written n golang. for example: https://github.com/kyoto-framework/kyoto

But this baby here https://github.com/kyoto-framework/kyoto is in the early development stages, which is a nice approach imho.

htmx requires you to return markup for specific components. So, you’ll need to maintain component template definition in two ways: embed directly into page template, and serve it as an api. IMO htmx is cool, but requires some tooling around it to simplify work. Our team is developing and using kyoto library, focused on server rendering and components approach: https://github.com/kyoto-framework/kyoto

For learning, I built components of the database engine like an SQL parser, a file-based B+ tree, a log-structured merge-tree. And I planned to merge them into the simple database engine. But I paused the project due to the changes in life obstacles.

As part of my toy database development, I wrote a simple SQL parser as a dedicated library. I decided to share it with the community to get feedback and be useful 👉 github.com/krasun/gosqlparser.

Hey 👋 I recently finished writing a SQL parser for my toy database (in Go). I absolutely love the language and the simplicity it markets. I can share my story with Go. Let me know if you are interested.