With Phoenix, Liveview, Ash, Oban Web, Nx, Livebook, Beacon, Liveview Native, Flame, Nerves etc all getting mature, are there any major gaps in the elixir ecosystem that means its not suitable for some popular use case out there?
What is the next big space it is going to get a kick-ass solution for?
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.
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
IMO the biggest thing missing from the ecosystem is a proper database. Mnesia doesn’t cut it, so we’re all left using Postgres et al which feels like a total waste of the BEAM’s potential.
I actually started an experimental side project in this area several months ago and it has been going surprisingly well. Will have to make a post about it soon.
Speaking of which, a proper cross-platform UI framework – probably made with Rust as there are several of them in the last years – and wrapped in OTP actors, would be probably the last ever UI framework invented. Or I hope so. Because having each UI element accept messages individually while still having “parents” is IMO the best paradigm for UI.
Haha, I came here to say the same thing. I’m hoping to add bulkwalk PR to snmp-elixir in the coming weeks. I may try and break out some of my network management framework to release as open source as well. Would be curious to hear your needs in this area.
A higher level and simpler (i.e. lower in code) web framework would be nice to have. Not even on the levels of Django, but Rails. Convention over configuration, simpler DB access interface that does more out of the box and requires you to write fewer queries, exposing fewer abstractions to the end programmer.