framework VS zillion

I'm working on a framework inspired by React/Next.js which turns Haml into Ruby. It's 100% server side, but it runs pretty fast. I'm currently working on a rewrite, I just wish I had more time to work on it.

https://github.com/mayu-live/framework

https://mayu.live/

Mayu, a server side web framework written in Ruby, inspired by React. Been working on it for over a year, and I'm currently doing a complete rewrite now that I have a better idea of how it should work.

https://github.com/mayu-live/framework

Mayu Live[1] has components, it works kinda like React. I have been thinking about making rdom[2] work with Rails but I got a memory leak to fix first. It's possible to do all this in Ruby though.

1. https://github.com/mayu-live/framework

2. https://github.com/aalin/rdom

Thanks, yes mayu.live is a close thing, but I looked at its examples, it's overcomplicated, if done a bit differently, the counter code it shows as example would be 3 times shorter. Nice experiment, same principle as LiveView, but not quite there.

I've been working on a React-inspired framework in Ruby [1,2]. It only requires a few kilobytes of JavaScript, and only includes the relevant stylesheets for each page. Works pretty well and I guess I'm in a rural area (about 90 minutes down the river from Iquitos, Peru) on a 4G connection.

I recently did another experiment [3] where each static DOM tree becomes a custom element, which also reduces the amount of data that needs to be transferred.

I should probably make a Show HN post soon...

1. https://github.com/mayu-live/framework

2. https://mayu.live/

3. https://github.com/aalin/rdom

I've also been frustrated when testing out tools that kinda keep you locked into one predetermined view, table, or set of tables at a time. I made a semantic data modeling library that puts together queries (and of course joins) for you as it uses a drill-across querying technique, and can also join data across different data sources in a secondary execution layer.

https://github.com/totalhack/zillion

Disclaimer: this project is currently a one man show, though I use it in production at my own company.

https://github.com/totalhack/zillion

Semantic data warehousing and analytics tool written in python. It has experimental/half-baked NLP features to query your warehouse by interacting with the semantic layer with AI, instead of the normal approach of having an LLM write SQL and needing to know your entire schema.

Hey All, I wanted to share Zillion -- an open source Python data modeling and analytics library with experimental natural language features powered by OpenAI, LangChain, and Qdrant. Zillion acts as a semantic layer on top of your data, writes SQL so you don't have to, and easily bolts onto existing database infrastructure via SQLAlchemy Core.

Built it for me, but available to all -- Zillion: a python data modeling and analytics library.

https://github.com/totalhack/zillion

More details/docs can be found in the GitHub repo: https://github.com/totalhack/zillion

Nice work. I had considered implementing something similar in https://github.com/totalhack/zillion down the road, probably as a layer on top.

Zillion: https://github.com/totalhack/zillion

A python data warehousing / modeling / analytics library that can unify multiple datasources and writes SQL for you. It's alpha level at the moment and I just slowly chip away when time allows, though I'm using it in production in another project (which does make money).

This seems fun, but certainly unnecessary. All of those questions could be answered in seconds using a warehouse tool like Looker or Metabase or https://github.com/totalhack/zillion (disclaimer: I'm the author and this is alpha-level stuff, though I use it regularly).

At first glance this seems more confusing, particularly the grouping/aggregation syntax, though I suppose that's something I'd just get used to. Some of the syntactic sugar is nice, but some things are also unlike SQL for no apparent reason which just makes adoption harder than necessary (join syntax for example).

IMO the main selling point would be the "database agnostic" part, but I already achieve that through SQLAlchemy Core and/or a warehouse layer like https://github.com/totalhack/zillion (disclaimer: I'm the author and this is alpha-level stuff, though I use it regularly). It seems like many newer DB technologies/services I'd want to use either speak PostgreSQL or MySQL wire protocol anyway.

The roadmap is worth a read, as it notes some limitations and expected challenges supporting the wide variety of DBMS features and syntax. That said, I can see where this might be useful in the cases where I do have to jump into direct SQL, but want the flexibility to easily switch the back end DB for that code -- that's assuming it can cover the use cases that forced me to write direct SQL in the first place though.