What are the remaining gaps in the elixir ecosystem?

I would like to see a scenic-like solution for desktop apps that is based on a NIF which uses the same crates as in zed code editor. This way we would have a native desktop apps that are rendered using by GPU where each UI component could have it’s own beam process.

Headless browsing could use more love

What do you mean? What’s a problem with headless browsing?

There are no real problems with it considering it can be done. I think there’s room to improve developer experience though. The exact implementation I don’t know but I’m imagining a library composed similarly to Membrane but for the browser stack.

Many years ago I have used a hound package with headless Chrome session, so I’m not sure what can be done if it’s already working and I believe that across all those years there are many alternative solutions too.

Sometimes I just want pieces of a browser and I’d want those pieces to be under my supervision tree if possible.

For example: Imagine I want to see the difference in rendering between chrome and safari then take a screenshot of both.
It would be nice to make one network request and pipe that response to a chrome renderer and a safari renderer instead of making the request in each headless browser.

In other cases I already have html (I like to archive) and want to resume browsing from that state skipping the network request altogether but still requiring the Javascript to load

I guess it would require a dedicated NIF for every browser engine. I’ve not ever heard that some people needs to do that from their app, so I don’t believe anybody would be interested working on that, but of course I may be wrong …

That’s not possible at all. This is because there are many cases where the data would be simply obsolete. Let’s say we want to work around that and skip most requests and just use the latest ones. Even that would be impossible in many cases. You would have to track every property in the state and cache it somewhere, so you would have any idea which requests you really need. Even if you do that the smallest change on the page would make your code fail.

People already do this. They package the entire browser sans UI. Not every browser vendor offers a headless mode unfortunately. And even fewer offer the modularity to pick just one piece of the browser stack to wrap as a standalone component. Chrome itself is really good about this though. You can get chrome, headless chrome, stand alone pieces of headless chrome like v8, stand alone pieces of v8 etc.

We, the theoretical maintainers of this theoretical library, would need to see which of these standalone pieces, in which layer we’d want to wrap but seems doable

I personally think that OTP libraries, specifically telecom ones, such as ASN.1, SNMP, diameter are not getting enough love. While their documentation and code quality is absolutely great, I would love to see more tutorials, blogposts etc.

This replay ability is exactly what the granularity I want. I thought “resume” was the correct term. I took it from the Qwik guys. Like I said I do archiving and I want to be able to proxy the network requests through my server and apply my data changes to the UI being rendered. I can already do this by just proxying all requests to a server I’m running but I can’t help but feel like there’s a more idiomatic OTP way of doing this