[HN Gopher] UIs are streaming DAGs [video]
___________________________________________________________________
UIs are streaming DAGs [video]
Author : simongray
Score : 91 points
Date : 2022-04-30 17:08 UTC (5 hours ago)
(HTM) web link (www.hytradboi.com)
(TXT) w3m dump (www.hytradboi.com)
| dataflow wrote:
| This is cool, but how is state managed here? Does the server need
| to maintain any per-client state between renders? Does that have
| scalability or concurrency implications? I'm having trouble
| discerning the ramifications.
| com2kid wrote:
| Modern stateless rest microservices are popular for many
| reasons, including ease of scaling and ease of reasoning about
| performance.
|
| This entire system seems very stateful.
|
| Also, in the real world, requests to one web service end up
| cascading out to multiple web services, with differing
| permissions models. For example user comes in with a token,
| makes a request to a web service, which then has its own secret
| store that it fetches an API key from to make a request to
| another web service.
|
| Very rarely in life has it been as simple as "fetch data from
| this API". It is "fetch data from this API given this auth
| token and that API takes that auth token and uses it to get
| another auth token, attaches some tracing info for diagnostics
| in case things go wrong, writes some metrics to a DB so the
| team can track API usage, then goes out to a couple more
| services, gets data from them, collates it, and eventually
| gives some data back to the user."
| raydiatian wrote:
| So... React, but in Clojure?
| capn_duck wrote:
| Did you watch the video?
| mjd wrote:
| I misread this as "UIs are screaming DAGs". So disappointed!
| meowtimemania wrote:
| Looks really interesting. Is there a way to play around with it?
| Programming in that way feels a bit mind bending but would be
| interesting to try out!
| lgas wrote:
| Looks like this might be it
| https://github.com/hyperfiddle/hyperfiddle
| Hermitian909 wrote:
| On the surface it looks really cool, but I'm deeply skeptical
| because they've intentionally put off handling what I think is
| the hardest part making the idea production ready: handling
| network unreliability.
|
| from the talk:
|
| > Photon is at least as reliable as today-era web applications,
| there are lots of well-understood ways to approach reconnecting
| local-first etc. We have not done this work yet
|
| I think this really understates the truly immense amount of
| engineering work that goes into making modern web system software
| appear reliable to users. Maybe Photon has a good solution but if
| my years in engineering have taught me anything it's that every
| line of code written and design decision made before tackling the
| hardest part of a problem need to be redone, so you should start
| with the hardest part first.
|
| I am hopeful that I'm proved wrong though :)
| dustingetz wrote:
| (Speaker here) We appreciate your concern, the risk is real,
| and you're right - the hard parts cannot be put off. And we
| have not put them off. We've already thought through how to
| implement recovery, resync, long running sessions. We have
| several wiki pages worth of notes answering questions like how
| we will deal with network partitions, reconciliation, durable
| session state, dealing with OS sleep timer state, OTA code
| updates, etc.
|
| What we have not yet done is the _implementation work_ ,
| because our pilot use case driving our eng priorities - an
| internal support app for a Series B SAAS startup - does not
| actually have this theoretical problem you describe. Photon's
| protocol today is tolerant to arbitrary delays, IFF you can
| guarantee message delivery and ordering, which is the problem
| TCP solves. We do already have pending/loading states, which is
| trapped locally through reactive try/catch.
|
| BTW, the Photon codebase is only 2k LOC (analyzer, compiler &
| interpreter for JVM and JS targets, standard library) and a
| substantial part of that is redoing parts of the Clojure/Script
| analyzer infrastructure.
|
| _" truly immense amount of engineering work that goes into
| making modern web system software appear reliable to users"_
|
| That's a bit much for me. The current industry state of
| commercial SAAS/crud apps is a dumpster fire, Photon's speed
| and responsiveness is already miles ahead of literally every
| laggy SAAS tool we all suffer where programmers are manually
| hand-coding the network in the form of REST calls, manually
| split HTTP routes, backends-for-frontends, client side ORM,
| GraphQL resolvers, etc. How often do you Cmd-R your gmail or
| notion because it stopped working? React.js-era software is
| rotting to death, "reliable" is not a word that describes it
| aaaaaaaaaaab wrote:
| I get the idea, but I'm not convinced about its usefulness. I
| fear that it would make it really easy to write horribly
| inefficient apps, interspersing client and server code willy-
| nilly, ending up with an entangled async mess that noone can
| really reason about. I saw this unfolding first-hand in
| functional reactive codebases...
|
| Sometimes explicit boundaries are a good thing. In fact, I would
| argue that they are more often than not.
| convolvatron wrote:
| I really can't see how unifying the value domain and language
| semantics of the back and front end necessarily involves more
| complication than maintaining the mapping between them.
| aaaaaaaaaaab wrote:
| ORM frameworks also unify the value domain and the language
| semantics of the database and the host app, and make it very
| easy to shoot yourself in the foot with the N+1 query issue
| and such.
|
| This will suffer from the same issues once you move beyond
| toy examples.
| infogulch wrote:
| This reminds me of:
|
| Bonsai, a UI state machine composition library -
| https://opensource.janestreet.com/bonsai/
|
| DatalogUI, Build UI declaratively with Datalog. -
| https://github.com/datalogui/datalog
| Twisol wrote:
| HYTRADBOI (the conference the OP was presented at) also had a
| talk on DatalogUI! https://www.hytradboi.com/2022/datalogui-
| rubbing-datalog-on-...
| Twisol wrote:
| This talk blew my mind when I saw it "live". The lexical
| separation between client and server, within the same program
| description, reminded me a lot of Distributed Algol (see the
| chapter in Practical Foundations for Programming Languages). DA
| uses a "spatial" type system to track which site a fragment of
| program executes at, and it's _ridiculously_ cool to see this
| kind of thing leveraged for realsies. The site-based program
| slicing in Photon, and the API synthesis across that boundary, is
| really exciting!
| SemanticStrengh wrote:
| They should port it to the de facto standard benchmark.
| https://krausest.github.io/js-framework-benchmark/2022/table...
| Until then I can't trust performance expectations.
| wrnr wrote:
| Maybe also the 7 GUIs https://eugenkiss.github.io/7guis/tasks
| SemanticStrengh wrote:
| THANK U! I have _always_ looked for a set of GUI rendering
| tasks benchmarked across different GUI libraries (chromium,
| QT, GTK, flutter, etc) and see the effect on performance and
| energy consumption metrics. edit: wait they seem to only
| measure code quality and not publish rendering /FPS
| performance ? such a missed opportunity...
___________________________________________________________________
(page generated 2022-04-30 23:00 UTC)