4 ms·

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

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 https://book.adama-platform.com/rxhtml/ref.html ) and it uses my modified JSON delta format ( https://book.adama-platform.com/reference/deltas.html 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.

nesarkvechnep 3y ago
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?
- mathgladiator 3y ago
  That's the old world, and the world I want has limited JavaScript yet fully interactive products.
  - danparsonson 3y ago
    REST with JQuery ;-)
    - mathgladiator 3y ago
      JQuery doesn't solve reactive data, and it's like building an interactive product in assembly.
nine_k 3y ago
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?
- mathgladiator 3y ago
  Auto-completion would update the view state which is gossiped back to the server, and the server can regenerate the list.
  - capableweb 3y ago
    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.
    - mathgladiator 3y ago
      No P2P; I'm using gossip as a background synchronization.
bullfightonmars 3y ago
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?
- rapnie 3y ago
  Yes, this was my first thought as well. https://www.phoenixframework.org https://www.phoenixframework.org
lelanthran 3y ago
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.
- mathgladiator 3y ago
  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 https://www.youtube.com/watch?v=bWYgChA_aYA&feature=youtu.be goes into more details.
  - lelanthran 3y ago
    > 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?

nesarkvechnep 3y ago

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?

mathgladiator 3y ago
That's the old world, and the world I want has limited JavaScript yet fully interactive products.
- danparsonson 3y ago
  REST with JQuery ;-)
  - mathgladiator 3y ago
    JQuery doesn't solve reactive data, and it's like building an interactive product in assembly.

nine_k 3y ago

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?

mathgladiator 3y ago
Auto-completion would update the view state which is gossiped back to the server, and the server can regenerate the list.
- capableweb 3y ago
  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.
  - mathgladiator 3y ago
    No P2P; I'm using gossip as a background synchronization.

bullfightonmars 3y ago

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?

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

lelanthran 3y ago

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.

mathgladiator 3y ago
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 https://www.youtube.com/watch?v=bWYgChA_aYA&feature=youtu.be goes into more details.
- lelanthran 3y ago
  > 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?