Phoenix frontend without the HTML stack?

Phoenix Forum Chat / Discussions
, , ,
1

The Elixir community and more specifically the Phoenix community have always been involved with some form of frontend development. Initially through server side rendered HTML/CSS/JS directly in Phoenix, passing through some native integrations like Scenic and recently through LiveView Native project. There are also many geared towards the embedded landscape that I am not familiar with…

The main target for Elixir frontend is usually the traditional web (HTML/CSS/JS, DOM model and so on). The platform is awesome for building web apps with easy to add real time capabilities using websockets/server sent events and so on.

The problem, in my opinion, is that the world of 2D GUI applications is trying harder and harder to move away from DOM and web specific architectures. Nonetheless, I think the Elixir community is going on the opposite direction… I’ve seen José’s talk about performance optimizations for LiveView which are now in the process of optimizing because we know we handle HTML/CSS/JS, recent LiveViewNative posts about transliterating HTML to SwiftUI and some other solutions…

In my humble opinion, HTML/CSS/JS is a horrible paradigm for 2D applications. More modern and functional approaches have been developed. Most of them use some kind of DSL to express view trees and interactions (QML, Jetpack compose, SwiftUI, etc, etc). Our approach in Elixir-land has been to re-use HTML and HTML based approaches (like tag based components) to drive UI even though the language is perfect for DSLs.

Also, most of the modern ones favor immutable data components for the view tree and need to invent some kind of message passing for handling events or interactions and Elixir is perfect for that.

Also again, many toolkits are now using compute runtimes to make it possible to use GPUs seamlessly. Nx is here just for that :slight_smile: . We seem to be heading in an awesome direction here too.

Also the third time, many applications are using a client/server architecture to provide “concurrent users” like Zed, Lapce (both code editors but full 2D GUI applications). Everything is a CRDT in Zed (from its docs) and we have CRDTs in Phoenix Presence since the beginning…

I guess that what I am trying to say is that from an outside perspective we are betting on the web. It seems we either have something special for keeping the HTML model and make it work better as a frontend toolkit or we are not actually agreeing these seem more modern and better at all.

I have a deep respect for everything the community is building on top of the HTML stack and it is absolutely awesome to see it running in things like LiveBook and so on. I feel confident to say we have the best SSR web framework possible. I just think that maybe we are still far away from the full potential of the BEAM/Elixir for a cross platform 2D application solution. Some more steps will be needed here.

What do you people think about it?

P.S.: One excellent post about frontend architectures and how different approaches can be achieved recently is this one from Ralph Levien in the Rust community. It is naturally more geared towards the Rust ecosystem but it is a nice read overall.

Have a nice day you all :slight_smile:

3 Likes
2

Is it really though? Yeah, there are the frameworks that you refered to, but they aren’t web focused, qml is mostly used embedded and jetpack compose and swiftui mostly mobile (and backed by two trillion dollar companies that have control over the platforms where they are used), and as such they have a different set of constraints than the web, but for the web all I see are experiments and DSLs that in the end are compiled to html+js+css.

The parts about client server UIs in desktop land in my opinion in the same area, desktop software have a different set of constraints than the web.

Elixir isn’t betting on the web, but I think that the phoenix framework is betting on the web, it is (aside from liveview native and desktop) mainly a web framework and has to work with the constraints of the web, which at the moment are HTML, CSS and Javascript, all the abstractions will have to run as html+js+css and work with the DOM anyway.

So, what I think is that I’m a big fan of the small “magic” of the framework, I don’t think another abstraction would do any good for adoption or even development, quite the opposite, it would create an even bigger barrier for adoption.

What we have on the web is far from perfect, but I don’t think it is something that should be the focus of the community, otherwise it would be even more niche than it already is.

3 Likes
3

I think the frameworks that weren’t web at first are trying to become more webby. Most of them are not anymore only “desktop” in the traditional way… they handle more form factors and input features than they used to. In my opinion, to separate them with “desktop”, “mobile” and “web” is not the best way… all of them can export to the web with different approaches…

Client ↔ Server is more than HTML web too. Most games, productivity suites and even text editors are currently client/server and many without the HTML.

I totally agree that we are not in a moment we can simply “drop” the web as it is. I just think there are better UI models than the ones HTML web brought us too. It will always be nice to have HTML for the original purpose of hyper linking documents but I think that our current UI/UXs are way beyond that… even in the HTML web, there is no shortage of abstractions that put the developers away from the HTML world.

Many current frameworks (SwiftUI, Jetpack Compose with Kotlin Multi Platform and Flutter) can use the same client/server deployment architecture of client applications. Those can still be driven from the server if desired and still follow HTTP but with better paradigms for expressing UI/UX.

I just fear we will always stay behind a wall of "DIV"s :slight_smile:

4

Please name some. SwiftUI is proprietary and single platform. so is Flutter. Web is not perfect but it is the best we got.

2 Likes
5

I am 100% for an open standard and not be tied to a proprietary format. But even though these examples are somewhat proprietary, its architecture and source aren’t. I am not saying we should just “use Swift UI or Flutter”. I think (and probably am wrong about it) that modeling components with <div>, <a>, <p> and so on is not a good way of modeling 2D GUIs.

The web itself is absorbing many other standards for graphics programming like webgl and so on. Many platforms can render game engines completely on these new standards (all with the starting point of HTML/CSS/JS but not based on that model… I mean, not trying to find ways to make DOM work for them but simply having a canvas and working their way from that).

Android, as an example, started with a very static XML-based description language in a way that resembles HTML architecture (they are very different but still somewhat similar in principles). That didn’t scale well. They are switching to a richer DSL for writing UI/UXs. That not only seems to make developers happier to build UIs but it also provides better performance paths for them.

So, my point here is that maybe a topic of research would be to have some view DSL that is more approachable than HTML/CSS/JS for modeling UI/UX and that would make cross platform for anything other than the web better. My feeling is that this seem to be a trend in 2D GUI development… but maybe I am just wrong and nothing will change in the next 5/10 years besides AIs writing the code for us :slight_smile:

6

I am keeping my eyes on slint, which matches your description (DSL based 2D GUI). It should be possible to use Elixir for the data layer and business logic and Rust for the presentation layer.

3 Likes
7

Has anybody used Elm UI? GitHub - mdgriffith/elm-ui: What if you never had to write CSS again?