10 ms·

UIs are streaming DAGs [video]

235 points by simongray 4y ago

SemanticStrengh 4y ago
They should port it to the de facto standard benchmark. https://krausest.github.io/js-framework-benchmark/2022/table_chrome_101.0.4951.41.html https://krausest.github.io/js-framework-benchmark/2022/table... Until then I can't trust performance expectations.
- wrnr 4y ago
  Maybe also the 7 GUIs https://eugenkiss.github.io/7guis/tasks https://eugenkiss.github.io/7guis/tasks
  - SemanticStrengh 4y ago
    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...
- dustingetz 4y ago
  (Speaker here) Our approach is to issue point writes to the DOM like Solid.js (no virtual DOM), so we hope our numbers are in the ballpark of that. You're right, we need to start measuring it, it's been on the backlog. hopefully soon. We do have 7GUIs btw
  - SemanticStrengh 4y ago
    Ryansolid, the author of solidJS has made a small library dedicated to enabling optimally efficient dom writes: https://github.com/ryansolid/dom-expressions https://github.com/ryansolid/dom-expressions It's the core behind Solid.js and he has brillantly ported it to Vue.js making this vue fork on par with solid https://github.com/ryansolid/vuerx-jsx https://github.com/ryansolid/vuerx-jsx so you would probably benefit from using and contributing to it. Also, where is the github repo of ur project so that I can follow it?
    - dustingetz 4y ago
      Thank you, had not seen that! Github is still private, we're entering technical alpha right now. Best place to follow is https://twitter.com/dustingetz https://twitter.com/dustingetz or the email capture form at https://www.hyperfiddle.net/ https://www.hyperfiddle.net/ for major announcements
      - SemanticStrengh 4y ago
        I'm perfectly fine with side projects but it seems you are making it a lucrative company? What's ur business model then ?
Twisol 4y ago
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!
mjd 4y ago
I misread this as “UIs are screaming DAGs”. So disappointed!
meowtimemania 4y ago
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 4y ago
  Looks like this might be it https://github.com/hyperfiddle/hyperfiddle https://github.com/hyperfiddle/hyperfiddle
infogulch 4y ago
This reminds me of: Bonsai, a UI state machine composition library - https://opensource.janestreet.com/bonsai/ https://opensource.janestreet.com/bonsai/ DatalogUI, Build UI declaratively with Datalog. - https://github.com/datalogui/datalog https://github.com/datalogui/datalog
- Twisol 4y ago
  HYTRADBOI (the conference the OP was presented at) also had a talk on DatalogUI! https://www.hytradboi.com/2022/datalogui-rubbing-datalog-on-uis https://www.hytradboi.com/2022/datalogui-rubbing-datalog-on-...
  - simongray 4y ago
    There's also this in the Clojure ecosystem: https://github.com/oakes/odoyle-rules https://github.com/oakes/odoyle-rules
aaaaaaaaaaab 4y ago
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 4y ago
  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 4y ago
    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.
    - convolvatron 4y ago
      just for your one example, it seems pretty clear from the discussion that the datalog planner here making the cut across the network connection specifically to minimize data motion. certainly people can build bad things. there is however a very real likelihood that a programming model which includes distribution will turn out to be effective
    - dustingetz 4y ago
      (speaker here) Photon is not an object mapper, we do not have an N+1 problem and in fact that is the exact topic of this talk. Photon is designed to scale in complexity without loss of performance or ability to reason. The computational structure that achieves this is single directional dataflow with pure functions; the abstraction is “referentially transparent” which means it composes mathematically the way pure functions compose. Strong composition as a basis for abstraction scalability (in the domain of UI) is the core innovation here.
dataflow 4y ago
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 4y ago
  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."
  - Twisol 4y ago
    I'm hopeful about this approach, honestly. We do build stateful flows in web applications, today, but we have to manually manage the serialization of that state to a shared store so that whichever worker the next request hits can pick up where things were left off. It seems to me that a system like Hyperfiddle / Photon could automatically manage the collection and persistence of this kind of state, so that the "server"-located code can be scaled horizontally without change to the written program. I can even imagine an Erlang-like solution to updating application code, so that existing flows can gracefully upgrade or time out. "Could", of course, is the operative word! But given that we have to manage state now anyway, this seems like an approach with a lot of potential.
    - dustingetz 4y ago
      Sure, i think you're basically describing distributed actors with durable state, and yes the Photon model can be viewed as distributed actors (with amazing syntax). Other great teams are working on the infinity scale streaming infrastructure, we'd like to be the last-mile UI for next-gen end-user applications.
Hermitian909 4y ago
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 4y ago
  (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 are 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 have manually hand-coded 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 remotely describes my daily experience with web software today.
raydiatian 4y ago
So… React, but in Clojure?
- capn_duck 4y ago
  Did you watch the video?
  - raydiatian 4y ago
    I’ll be honest, I just flipped through the video without sound. It’s clear that I misunderstood the content of the talk.
MauranKilom 4y ago
No idea how long I'd have to watch the video for to have this question answered, so I'll ask here: What is DAG in this context? Directed Acyclic Graph? Please explain your acronyms.
- Twisol 4y ago
  Directed acyclic graph, yes.
- magicalhippo 4y ago
  For the record, you'd have to wait 1m38s if watching from the start.
  - pindab0ter 4y ago
    Which is after him first using the abbreviation.
grayrest 4y ago
For Dustin, since you're following the thread: The area you're covering is closely related to an active area of development within the JS frontend framework community. They consider it hydration perf work and the working terminology is partial hydration or resumption/resuming rendering (there's a couple approaches/tradeoffs). In particular, the Marko team has a system under development that works this way without explicitly defined client/server pieces. They're mostly solving it on the server and streaming the HTML down since they have a priority on page load perf but the models look very close to me. I don't have a definitive piece to link as an intro and the concepts haven't made their way into the broader JS community but I thought you might be interested. I'm happy that hyperfiddle is still going, I recall the Clojure NYC presentation and this is looking a lot more polished.
- hdjrudni 4y ago
  There's a lot of gotchas with SSR and hydration. I got bit just today because Next.js hid all the complexity from me so I was surprised when localStorage didn't work. Just popped up an error about it being undefined -- in my browser. How could that be? Took me awhile to realize it was trying to render it server-side.
  - grayrest 4y ago
    There's a lot of gotchas/drawbacks with the current approaches, which is why it's an active area of development. Remix, Astro, Qwik, and Marko are all taking different approaches at mixing client and server side rendering.
  - southerntofu 4y ago
    > There's a lot of gotchas with SSR and hydration I don't mean to be dismissive, but most of us still do classic SSR (like we did in 90s/00s except maybe with Rust/Go instead of PHP) and it's still awesome and resource-friendly (both for server and client). I assume you meant there's problems with "hydrating" client-side scripts (Next.js in this case) and templates for use server-side. Which is fine if you need it! I'd just like to point out that 99% of web pages don't need any form of client-side rendering logic (apart from the browser's HTML/CSS rendering engine) and are much more user-friendly without any scripts running at all, even if you leave aside memory/privacy concerns. And if you really need some client-side interaction for some reason, i've found HTMX to be a very refreshing approach to this question. EDIT: To be clear, i'm not saying this for you specifically, but for someone who would read through this topic and currently believes they need client-side scripting to build "modern" websites.
bfung 4y ago
The idea and explanation is great and sounds like it can work. To use the general startup cliche of “execution over ideas”, show me the code/demo ;) Would love to see this work (having toiled away for 20years writing FE/BE/DNS glue) and you can make a pretty penny too.
vlovich123 4y ago
Hopefully the author is still here. I skimmed the Twitter thread but couldn’t find the video referenced at the end. Can someone provide a link?
- dustingetz 4y ago
  The hypermedia demo video didn’t make it out on time (due to me not having time to narrate and produce the actual video). Soon!
pindab0ter 4y ago
Please, if you have to use an abbreviation in your title, define it in the synopsis. If you use an abbreviation in audio/video, use the unabbreviated term first and the abbreviation immediately after. I’ve never heard of DAG, yet it’s used as if it’s commonplace.
- 0xdeadb00f 4y ago
  I thought they meant Directed Acyclic Graph [0]. [0]: https://en.wikipedia.org/wiki/Directed_acyclic_graph https://en.wikipedia.org/wiki/Directed_acyclic_graph
- unglaublich 4y ago
  You have to make some assumptions about what is common knowledge in your target audience. Probably, the author didn't design the title for a general public on HN, but for Getz' fellow software UI researchers. Someone that's not in the target audience will have to do some extra work to get up to speed. Just like an undergraduate will have a hard time understanding a graduate text without a primer.
- DerSaidin 4y ago
  Should they have defined UI? Should they have defined DB? It is subjective where to draw the line for commonplace, and it depends on the audience. Is DAG a commonplace acronym for people attending HYTRADBOI? Maybe (I see 2 other talks mentioning graphs/trees in their title).
  - alpaca128 4y ago
    It costs nothing to use the full term once or twice. It can prevent confusion, and some people in the audience may not know the concept and googling a few letters is often not the best way to get useful results. Saving a couple syllables in a talk isn't worth it.
- arinlen 4y ago
  > I’ve never heard of DAG, yet it’s used as if it’s commonplace. DAG, as in direct acyclic graph, is indeed a basic concept of computer science. But indeed the author could do a better job with the text. One of the very basic principles of technical writing is to always introduce the definition when an acronym is first presented, something like "blablabla a direct acyclic graph (DAG)".
purpleidea 4y ago
I didn't watch this video, but https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ has a core concept of streams of DAG's since the beginning. I came up with the idea, but if there's a greater commons discussing these kind of algorithms, I'd be interested for more people to get involved!
- prox 4y ago
  That looks like a really good project!
- dustingetz 4y ago
  great project, for others here’s the best problem/solution overview i could find - https://purpleidea.com/blog/2018/02/05/mgmt-configuration-language/ https://purpleidea.com/blog/2018/02/05/mgmt-configuration-la...
sktrdie 4y ago
Isn't this what React Server Components [1] do? Where parts of the tree are executed on client or server or both. And the data is "streamed" to client. Their "DAG" is essentially the react tree. So sounds very similar. 1. https://www.youtube.com/watch?v=TQQPAU21ZUw https://www.youtube.com/watch?v=TQQPAU21ZUw
some1234 4y ago
So for their "ideal example" in the beginning, isn't it basically PHP? You can freely mix the HTML with PHP code and even query the database directly using the user's input. (We know how well that turned out...)
- some1234 4y ago
  OK so they actually mention this towards the end of the video. I guess this is more about how crazy Javascript frameworks and frontend in general has gotten, so it's time to step back and trim down some of the fat. Looks like an interesting project. One thing I worry about is debugging. I once had to help out with some weird bugs in a relatively simple RShiny application written using the reactive model, and it was a total nightmare.

235 points by simongray 4y ago

They should port it to the de facto standard benchmark. https://krausest.github.io/js-framework-benchmark/2022/table_chrome_101.0.4951.41.html https://krausest.github.io/js-framework-benchmark/2022/table... Until then I can't trust performance expectations.

wrnr 4y ago
Maybe also the 7 GUIs https://eugenkiss.github.io/7guis/tasks https://eugenkiss.github.io/7guis/tasks
- SemanticStrengh 4y ago
  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...
dustingetz 4y ago
(Speaker here) Our approach is to issue point writes to the DOM like Solid.js (no virtual DOM), so we hope our numbers are in the ballpark of that. You're right, we need to start measuring it, it's been on the backlog. hopefully soon. We do have 7GUIs btw
- SemanticStrengh 4y ago
  Ryansolid, the author of solidJS has made a small library dedicated to enabling optimally efficient dom writes: https://github.com/ryansolid/dom-expressions https://github.com/ryansolid/dom-expressions It's the core behind Solid.js and he has brillantly ported it to Vue.js making this vue fork on par with solid https://github.com/ryansolid/vuerx-jsx https://github.com/ryansolid/vuerx-jsx so you would probably benefit from using and contributing to it. Also, where is the github repo of ur project so that I can follow it?
  - dustingetz 4y ago
    Thank you, had not seen that! Github is still private, we're entering technical alpha right now. Best place to follow is https://twitter.com/dustingetz https://twitter.com/dustingetz or the email capture form at https://www.hyperfiddle.net/ https://www.hyperfiddle.net/ for major announcements
    - SemanticStrengh 4y ago
      I'm perfectly fine with side projects but it seems you are making it a lucrative company? What's ur business model then ?

Twisol 4y ago

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!

mjd 4y ago

I misread this as “UIs are screaming DAGs”. So disappointed!

meowtimemania 4y ago

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 4y ago
Looks like this might be it https://github.com/hyperfiddle/hyperfiddle https://github.com/hyperfiddle/hyperfiddle

infogulch 4y ago

This reminds me of: Bonsai, a UI state machine composition library - https://opensource.janestreet.com/bonsai/ https://opensource.janestreet.com/bonsai/ DatalogUI, Build UI declaratively with Datalog. - https://github.com/datalogui/datalog https://github.com/datalogui/datalog

Twisol 4y ago
HYTRADBOI (the conference the OP was presented at) also had a talk on DatalogUI! https://www.hytradboi.com/2022/datalogui-rubbing-datalog-on-uis https://www.hytradboi.com/2022/datalogui-rubbing-datalog-on-...
- simongray 4y ago
  There's also this in the Clojure ecosystem: https://github.com/oakes/odoyle-rules https://github.com/oakes/odoyle-rules

aaaaaaaaaaab 4y ago

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 4y ago
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 4y ago
  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.
  - convolvatron 4y ago
    just for your one example, it seems pretty clear from the discussion that the datalog planner here making the cut across the network connection specifically to minimize data motion. certainly people can build bad things. there is however a very real likelihood that a programming model which includes distribution will turn out to be effective
  - dustingetz 4y ago
    (speaker here) Photon is not an object mapper, we do not have an N+1 problem and in fact that is the exact topic of this talk. Photon is designed to scale in complexity without loss of performance or ability to reason. The computational structure that achieves this is single directional dataflow with pure functions; the abstraction is “referentially transparent” which means it composes mathematically the way pure functions compose. Strong composition as a basis for abstraction scalability (in the domain of UI) is the core innovation here.

dataflow 4y ago

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 4y ago
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."
- Twisol 4y ago
  I'm hopeful about this approach, honestly. We do build stateful flows in web applications, today, but we have to manually manage the serialization of that state to a shared store so that whichever worker the next request hits can pick up where things were left off. It seems to me that a system like Hyperfiddle / Photon could automatically manage the collection and persistence of this kind of state, so that the "server"-located code can be scaled horizontally without change to the written program. I can even imagine an Erlang-like solution to updating application code, so that existing flows can gracefully upgrade or time out. "Could", of course, is the operative word! But given that we have to manage state now anyway, this seems like an approach with a lot of potential.
  - dustingetz 4y ago
    Sure, i think you're basically describing distributed actors with durable state, and yes the Photon model can be viewed as distributed actors (with amazing syntax). Other great teams are working on the infinity scale streaming infrastructure, we'd like to be the last-mile UI for next-gen end-user applications.

Hermitian909 4y ago

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 4y ago
(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 are 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 have manually hand-coded 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 remotely describes my daily experience with web software today.

raydiatian 4y ago

So… React, but in Clojure?

capn_duck 4y ago
Did you watch the video?
- raydiatian 4y ago
  I’ll be honest, I just flipped through the video without sound. It’s clear that I misunderstood the content of the talk.

MauranKilom 4y ago

No idea how long I'd have to watch the video for to have this question answered, so I'll ask here: What is DAG in this context? Directed Acyclic Graph? Please explain your acronyms.

Twisol 4y ago
Directed acyclic graph, yes.
magicalhippo 4y ago
For the record, you'd have to wait 1m38s if watching from the start.
- pindab0ter 4y ago
  Which is after him first using the abbreviation.

grayrest 4y ago

For Dustin, since you're following the thread: The area you're covering is closely related to an active area of development within the JS frontend framework community. They consider it hydration perf work and the working terminology is partial hydration or resumption/resuming rendering (there's a couple approaches/tradeoffs). In particular, the Marko team has a system under development that works this way without explicitly defined client/server pieces. They're mostly solving it on the server and streaming the HTML down since they have a priority on page load perf but the models look very close to me. I don't have a definitive piece to link as an intro and the concepts haven't made their way into the broader JS community but I thought you might be interested. I'm happy that hyperfiddle is still going, I recall the Clojure NYC presentation and this is looking a lot more polished.

hdjrudni 4y ago
There's a lot of gotchas with SSR and hydration. I got bit just today because Next.js hid all the complexity from me so I was surprised when localStorage didn't work. Just popped up an error about it being undefined -- in my browser. How could that be? Took me awhile to realize it was trying to render it server-side.
- grayrest 4y ago
  There's a lot of gotchas/drawbacks with the current approaches, which is why it's an active area of development. Remix, Astro, Qwik, and Marko are all taking different approaches at mixing client and server side rendering.
- southerntofu 4y ago
  > There's a lot of gotchas with SSR and hydration I don't mean to be dismissive, but most of us still do classic SSR (like we did in 90s/00s except maybe with Rust/Go instead of PHP) and it's still awesome and resource-friendly (both for server and client). I assume you meant there's problems with "hydrating" client-side scripts (Next.js in this case) and templates for use server-side. Which is fine if you need it! I'd just like to point out that 99% of web pages don't need any form of client-side rendering logic (apart from the browser's HTML/CSS rendering engine) and are much more user-friendly without any scripts running at all, even if you leave aside memory/privacy concerns. And if you really need some client-side interaction for some reason, i've found HTMX to be a very refreshing approach to this question. EDIT: To be clear, i'm not saying this for you specifically, but for someone who would read through this topic and currently believes they need client-side scripting to build "modern" websites.

bfung 4y ago

The idea and explanation is great and sounds like it can work. To use the general startup cliche of “execution over ideas”, show me the code/demo ;) Would love to see this work (having toiled away for 20years writing FE/BE/DNS glue) and you can make a pretty penny too.

vlovich123 4y ago

Hopefully the author is still here. I skimmed the Twitter thread but couldn’t find the video referenced at the end. Can someone provide a link?

dustingetz 4y ago
The hypermedia demo video didn’t make it out on time (due to me not having time to narrate and produce the actual video). Soon!

pindab0ter 4y ago

Please, if you have to use an abbreviation in your title, define it in the synopsis. If you use an abbreviation in audio/video, use the unabbreviated term first and the abbreviation immediately after. I’ve never heard of DAG, yet it’s used as if it’s commonplace.

0xdeadb00f 4y ago
I thought they meant Directed Acyclic Graph [0]. [0]: https://en.wikipedia.org/wiki/Directed_acyclic_graph https://en.wikipedia.org/wiki/Directed_acyclic_graph
unglaublich 4y ago
You have to make some assumptions about what is common knowledge in your target audience. Probably, the author didn't design the title for a general public on HN, but for Getz' fellow software UI researchers. Someone that's not in the target audience will have to do some extra work to get up to speed. Just like an undergraduate will have a hard time understanding a graduate text without a primer.
DerSaidin 4y ago
Should they have defined UI? Should they have defined DB? It is subjective where to draw the line for commonplace, and it depends on the audience. Is DAG a commonplace acronym for people attending HYTRADBOI? Maybe (I see 2 other talks mentioning graphs/trees in their title).
- alpaca128 4y ago
  It costs nothing to use the full term once or twice. It can prevent confusion, and some people in the audience may not know the concept and googling a few letters is often not the best way to get useful results. Saving a couple syllables in a talk isn't worth it.
arinlen 4y ago
> I’ve never heard of DAG, yet it’s used as if it’s commonplace. DAG, as in direct acyclic graph, is indeed a basic concept of computer science. But indeed the author could do a better job with the text. One of the very basic principles of technical writing is to always introduce the definition when an acronym is first presented, something like "blablabla a direct acyclic graph (DAG)".

purpleidea 4y ago

I didn't watch this video, but https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ has a core concept of streams of DAG's since the beginning. I came up with the idea, but if there's a greater commons discussing these kind of algorithms, I'd be interested for more people to get involved!

prox 4y ago
That looks like a really good project!
dustingetz 4y ago
great project, for others here’s the best problem/solution overview i could find - https://purpleidea.com/blog/2018/02/05/mgmt-configuration-language/ https://purpleidea.com/blog/2018/02/05/mgmt-configuration-la...

sktrdie 4y ago

Isn't this what React Server Components [1] do? Where parts of the tree are executed on client or server or both. And the data is "streamed" to client. Their "DAG" is essentially the react tree. So sounds very similar. 1. https://www.youtube.com/watch?v=TQQPAU21ZUw https://www.youtube.com/watch?v=TQQPAU21ZUw

some1234 4y ago

So for their "ideal example" in the beginning, isn't it basically PHP? You can freely mix the HTML with PHP code and even query the database directly using the user's input. (We know how well that turned out...)

some1234 4y ago
OK so they actually mention this towards the end of the video. I guess this is more about how crazy Javascript frameworks and frontend in general has gotten, so it's time to step back and trim down some of the fat. Looks like an interesting project. One thing I worry about is debugging. I once had to help out with some weird bugs in a relatively simple RShiny application written using the reactive model, and it was a total nightmare.