Comment by mathgladiator | Hacker News Reader

Comment by mathgladiator | Hacker News Reader

Another approach (which I'd love to see others pick up on) is treating the client as a dumb proxy to the server. This is the philosophy I'm embracing, and it's wonderful!

If you buy into the philosophy that the UI is a deterministic function of server state and ephemeral view state (ui = f(state, viewstate)), then the core question is medium.

With browser, embracing HTML is the only sane choice for business. As such, the function at hand needs to convert those two state objects into a blob of HTML. This is the classic HTML template problem.

However, if you treat the state(s) as streams, then you'll be where I am at in building a differential HTML engine. I'm calling this first (big) version: RxHTML ( https://book.adama-platform.com/rxhtml/ref.html ) and it uses my modified JSON delta format ( https://book.adama-platform.com/reference/deltas.html ).

The spiritual design question is what minimal things does HTML need with reactive data binding.

It's pretty awesome to be able to debug a user experience by having 4 views up at once, and then see a real-time update on all 4 views at once.

The tech at this time is beta quality, but I'm working through this as I build a real SaaS for everyday people. I'm having a bunch of fun especially as tailwind dramatically simplifies the styling.

This sounds similar to what the Phoenix team has done with LiveView. Is it a flavor of the same idea or are there other concepts I am missing. Can this also be rendered/hydrated by the server?

Yes, this was my first thought as well. https://www.phoenixframework.org

Firstly, I wish you luck. It's an ambitious undertaking to get something better adopted by the industry and a healthy dose of luck can only help.

But, having spent the better part of an hour trying to understand your proposal, I have to say that it isn't something that solves a proportionally sized problem.

Modified html with added tags for conditional processing has been done to death. I've done it. At least five former colleagues of mine has done it. At the end of it you'll come to the same conclusion as we, and everyone else, did and abandon it.

Secondly, this seems like a very overengineered solution, and it's not clear what the problem is. Your project will end up trying to be all things to all people because no one can tell at a glance what problem it should be used for.

If you're targeting a problem at a higher level then there's very little need to invent new low-level components; the existing ones should mostly be fine.

To be honest, if the browser allowed s-expressions and specified the evaluation of them, most current frameworks (and JSON itself) would be made redundant.

Thanks, I need all the luck I can get. Currently, I'm building a couple of products with my stack, and it's going well.

For conditional processing that you and your colleagues did, was it within the browser? I'm doing this as simple step such that I turn a giant "HTML forest" into lean javascript and DOM binding. It's working well for me, so I wonder what the gap is?

Personally, my stack is underengineering since I'm combining the roles of web server, database, messaging stack, queues, caches, load balancer, workflow into one cohesive platform. My dry run video: https://www.youtube.com/watch?v=bWYgChA_aYA&feature=youtu.be goes into more details.

> For conditional processing that you and your colleagues did, was it within the browser?

Yes - it's the most common way to do it (the script language that comes with htmx runs in the browser too).

> It's working well for me, so I wonder what the gap is?

It usually turns out that it's less work simply using JS in the browser than remembering the new language. I'm not saying that your effort would have the same result, but it's the result I've seen in the past for this sort of thing.

> Personally, my stack is underengineering since I'm combining the roles of web server, database, messaging stack, queues, caches, load balancer, workflow into one cohesive platform.

That's what I meant by over-engineered - too much is included in the project, much of which won't be used by most intended users. I accept that maybe "over-engineered" is the wrong word.

Tell me, what's the problem statement you had that prompted this development effort? What problem where you trying to solve when you started this?

Originally, it had to do with board games and running them in a web/cloud environment.

Using websockets made building the game easier, but now there is exceptionally complex state within the process (await/async). Generally speaking, the cloud is unforgiving place to hold state within a process.

I can speak deeply about streams at scale ( https://dl.acm.org/doi/10.1145/3477132.3483572 ).

Adama emerged as a tool to help define a "transactional document schema" which I could use to emit deltas to a logger (like Kafka), and once I added a notion of "privacy polices with code"... the potential exploded.

I believe I'm onto something with this platform, so I've decided to start hiring to build digital products that fit the thesis.

I would say I'm over-engineering in that I'm making the service available to others rather than leveraging in a portfolio of products, but I'd rather keep it open rather than have secrets.

(It's a good thing I'm retired because this is a large endeavor)

This approach is very old indeed, pioneered by first video terminals (as opposed to teletypes).

It assumes always-online, synchronous operation.

How do you in your model implement an auto-completion list? Do you allow it to re-generate not on each keystroke?

Auto-completion would update the view state which is gossiped back to the server, and the server can regenerate the list.

Where does P2P/distributed architecture come into your earlier comment? Seems like traditional server<>client communication.

Maybe it's just an unfortunate wording, but "gossip" has a specific meaning in P2P/distributed systems and I can't see how it fits in with what you've written so far.

No P2P; I'm using gossip as a background synchronization.

Your philosophy is nothing new. It’s called REST. Yes, REST must be hypermedia-driven and if your server and client “speak” the same media type, your client doesn’t have to keep state. Add HTTP caching to the mix and the result is beautiful. Of course, it’s easier to concatenate strings and write stores on the client. Or is it?

That's the old world, and the world I want has limited JavaScript yet fully interactive products.

REST with JQuery ;-)

JQuery doesn't solve reactive data, and it's like building an interactive product in assembly.

Reply on news.ycombinator.com