The future of Hyperstack

[catmando]

Where is hyperstack going?

In our experience at catprint there are three big problems with hyperstack going forward: The impact of Claude.AI, performance, debugging, and getting developers up to speed.

• Claude.ai Given the ease at which claude.ai creates code / api's / and takes care of cruft is hyperstack really needed? On the other hand i discussed (with claude ha ha) what it takes to make ai coding tools aware of a project like hyperstack. That has been a big problem for us.
• Performance I think the solution here is leveraging ruby.wasm. I.e. create a true database on the client, and directly sync the data with the server database. This would simplify and speed up things greatly. My thought would be the core client-side gems would live on wasm side of things, and project code would continue in opal ruby.
• Debugging It might be with progress in the last couple of years (and especially with ai helping) we could get a true ruby aware debugger going in the client. This would be great.
• Developers Well actually if we got ai tools to "know" about hyperstack, the problem would be solved.

Look forward to a discussion, and all are welcome of course!

[mpantel]

Hello @catmando, it is nice to hear from you again!

I have a great time working with Claude and Hyperstack since last July. Actually it does a great job with our Hyperstack apps (3), testing and cleaning up. I managed to upgrade to Ruby3.2 from 2.9~ last November and 15 days ago I started migrating it to latest supported Rubies (3.4,4.0), latest Opal, React 17,18 and 19, Rails 7.2 and Rails 8.1 with many fixes. Keyword arguments transition was a nightmare, and I had tried before, but claude made it, not easily though. Second difficulty was Opal 1.6 to 1.7, then everything almost rolled. I think Ruby, Rails and Hyperstack conventions help any ai model flourish. The comprehensive test/spec suite (whole suite now run in under 10 minutes for one set of gem versions). The nice part is that now you can test and investigate issues with just a prompt and some token credits.

For our case the main motivation for this upgrade is security and performance for our apps - that is a team of two people. One problem/issue here: I didn't upgrade having backward compatibility I mind, but the path is recorded in the git repo. I do not have a spec matrix to test on different versions but green specs while transitioning. It is easier now to have an updated app than maintain a legacy. That said Hyperstack apps are easy to upgrade if you manage to upgrade the framework itself.

On the other hand, although it is easy to vibe code a new rails app from scratch with Hotwire in a couple of days, Hyperstack's isomorphic paradigm deserves a working framework. It is an architectural paradigm (although fragile - I realized we have to keep in sync four different frameworks/libs) and a matter of taste. Of course many updates and enhancements can be added.

As a Hyperstack user since 2018, as I remember, I would be happy to help continuing the maintenance of this project in my spare time,
but (this is an inclusive but):

1. Who decides the direction of this project and the way to move on?
2. Is it better to fork and go on?
3. Given the ease with which ai can help implement features and fixes it is very easy to derail any project and that is a concern.
4. I have no idea about Hyperstack's active user base

Those are my humble thoughts.

Have a nice evening!

[catmando]

your questions:

1. I would be happy to give you the lead, or certainly am happy to share making such decisions. Afterall if at some point I needed to I could just fork, but I dont think that will be an issue.
2. I doubt it. Whatever you have done, it should be good for everyone. If someone needs to stay back at the old version and make changes I think they should fork. You have moved in the correct direction (i.e. forward)
3. Yes. Its true AI is an assistant, but we the developers have to be the engineers.
4. I do not either. It may be just you. HOWEVER being on latest rails, having the tests sped up, finding that claude can help all make it possible we can attract more users. At anyrate I think you release the next version, and people can either upgrade or stay where they are at.

[catmando]

I want to discuss specifically an idea I have had for years, which now seems possible to implement.

Ruby.wasm now can run the full rails stack with a few caveats, and using the SQLite database.

I propose the following (for discussion)

Restructure how model updates flow between the server and client. Currently, there is a large amount of traffic, and computation that is done on the server to keep client scopes in sync. If a duplicate (of the allowed data) was kept on the client, and you have the rails ORM there, all that would need to be transmitted is the allowed data change. Once at the client, the client side can now figure out what scopes change and trigger any UI updates.

We would have to do some experiments to see how this would work but it seems quite possible and would eliminate one of the ugliest parts of the server side code base.