
Ask HN: Why are there no front end languages for desktop GUIs - 0_gravitas
In a webapp, you have your separation of concerns, a backend that does backend stuff, a server that interacts with that backend and sends stuff to a given frontend, and the frontend which only really knows about and interact with the server. The backends and frontends don&#x27;t need to be the same languages&#x2F;stack (in fact, they mostly aren&#x27;t). Why isn&#x27;t this the case in the desktop world (ignoring electron), where every GUI seems to be married to it&#x27;s language without any real room for a clean separation? I wish I could write something with Rust as a backend and have some equivalent of Elm or some sort make up the frontend, and have those communicate through an API like any webapp.
======
photawe
My take is that you're thinking like a web dev, and not like a desktop dev.
Why would you want to use 2 languages? If you use a single language,
testing/debugging is waaaay easier.

There may be some places where you'd be inclined to use another language for
speed, but that's where the .net ecosystem comes into play. Even then, with
proper profiling, you'll usually find that you don't need to switch language.

------
zozbot234
The frontend-backend pattern is actually very common in traditional GUI
programs as well. It just doesn't have a "language" associated with it,
because literally all you need is some IPC mechanism for the GUI to interact
with its backend. For instance, xcdroast is a pure frontend to cdrecord (now
mostly replaced by wodim). See e.g.
[http://www.catb.org/esr/writings/taoup/html/ch11s06.html#id2...](http://www.catb.org/esr/writings/taoup/html/ch11s06.html#id2958899)

------
juststeve
> Why isn't this the case in the desktop world (ignoring electron), where
> every GUI seems to be married to it's language without any real room for a
> clean separation?

I think the separation is in the code itself with View classes or markup like
XAML, and checked at compile time. I mean, if you didn't want the client code
compiled with the backend code, why not just write a webapp in the first
place? otherwise, just write your client app in another tech (gwt, qt, swing,
win32) and call rust over HTTP?

------
mikst
A lot of non-network programs work in that way. There are many ways to
implement it, from having a background process responding to calls, to
spawning new process on button press.

------
matijash
Even if writing it all the in the same language, you could still separate the
concerns - having different modules for e.g. fetching data and rendering.

Is there a particular application you are working on?

------
itronitron
Every GUI is married to its language, regardless of whether it is a desktop or
browser based application. You can 'easily' implement the backend and frontend
in different languages and manage the interface through a socket, an API, DB,
or MQ.

