It’s probably the biggest platform there is. There’s 3 billion people on Facebook, how many people online? How much force is behind web tech? A lot! Y’all already know this. :) It’s just crazy to think about.
Most GUIs aren’t even called GUIs, they’re just “webapps” or “a site”. But I’m bringing this up because I think there was an interesting split. If you built a GUI before the .com boom (or whatever boom early web), you probably did it with some GUI toolkit tied to a language. Now, you can write in almost any backend language and the details are hidden from the user except for maybe a rogue /cgi-bin or .aspx in the URL. The web has many backend languages, fat GUIs have fewer. But the point is, we kind of stopped building fat desktop apps.
There’s a few things we lost. We lost a layout tool like how Xcode has now, something that has alignment and quick feedback instead of save/refresh. There’s maybe some tools that have tried to get this back (rapid mockers or markup generators). But if you look at VB or iOS dev, you see that the native walled garden lets you flip back and forth. That was nice to me but of course it’s not required because if you look in the world people are building complex GUIs in web tech no problem.
There’s another thing I think we lost which goes even farther back. If you wanted a GUI for a “backend thing”, say git splits. Git just punts this to the $EDITOR or an interactive prompt. The TUI. Or a curses window for other programs. I’m hoping one day we have tooling that is so good and powerful that backend people don’t feel unable to start in the ecosystem and a TUI wouldn’t even be an option, much like a mainframe screen (F1/F2..) app wouldn’t be created. I think the problem here is complexity and specialization. I don’t know if the entire problem can be simplified or generalized to even approach without dealing with the DOM or switching toolsets.
Will we always have TUIs? Is text-mode always usable? Can web tech become universally useful or simple? Can we put a wall between unix CLI composition and something like curses (flags and pipes and the unix way continue to be proved)? What would this even look like? You have a CLI that takes flags and args but if you invoke without these things, it runs in interactive mode but it stays in the terminal using some magic future tech and the programmer didn’t have to step outside their backend expertise or ecosystem to get this done? I have no idea. I can’t even imagine it.
I 100% agree with everything except for the TUI. Text is awesome, being a web developer myself, I really enjoy using git in the terminal for instance. Far more powerful than any GUI I’ve been able to use.
Long live the web and the TUI.
I think it would have been really nice for UIs if web browsers had historically supported unix sockets as HTTP endpoints, so arbitrary programs could use the web browser as a local GUI without having to worry about exposing a sensitive API over TCP
That is not as good. With a unix socket, the listening process can set the usual user/group/other permissions. With a TCP socket on 127.0.0.1 you’re exposing your service to everything on the same machine.
Plus TCP sockets suck at namespacing. Unix sockets are no worse at namespacing than the filesystem.
even with things like dbus, there are limits to the security model of unix sockets. I’d much prefer a better capabilities system or we can just accept that auth has to be handled by the receiver in some fashion.
We’re talking about using a browser as an alternative to a TUI. There would be little point worrying about any model more complicated than marking the socket 0600 because the user who started the tool is the one and only user you want to be able to access the tool’s API.
That’s a lot of effort for not a lot of payoff. I don’t remember BSD jails ever being usable by ordinary unprivileged users. ezjail meeded root for example. You’re going to have to put the browser in the same jail too if you want to limit access, which is kind of a non starter. You can’t grant access to only one uid or gid. They were ime always pretty slow and troublesome - you had to arrange a whole root filesystem for each, for starters.
Kinda / sorta. It’s a little bit harder these days to simply Inspect Source and snoop somebody’s unminified JS or CSS like you could back in the days.
But I agree overall, and find it analogous to what I hear emacs users describe when they talk about their pervasive programmable TUI toolkit: https://ambrevar.xyz/emacs-everywhere/
Yeah, I agree. I’ve actually been drafting a “Why I don’t minify my files”-post alongside this one, but got kinda stuck on the file savings comparisons (getting unminified versions out of common software Like Wordpress or MediaWiki turns out to be surprisingly tricky!)
I make a point not to minify any handwritten JS, but when you use the web as a GUI toolkit for a language that isn’t JS, the JS it compiles to may remain inspectible, but hardly editable. Bucklescript is impresssive in that it generates readable and debuggable JS, but it’s still a) quite large and not minifying it is a serious bandwidth compromise for users with slow or metered connections b) its output likely makes little sense for a person unfamiliar with OCaml idioms it translates to JS.
It’s funny how basically everything in this bullet list also applies to using Emacs as an application toolkit, but moreso:
You can zoom pretty much any content as large or small as you like.
More cross-platform than pretty much anything else.
Open anything in a new context (tab or window).
Copy/paste anything.
Search any text with e.g. Ctrl+F.
Back button. [this one isn’t well-defined in Emacs unless you mean for operations that open new buffers]
Modifying anything easily; even if you’re not doing this directly yourself this has huge benefits in the form of e.g. some simple bookmarklets or your adblocker.
I would argue that really the last one is very badly supported in the browser; there is no standard mechanism for changing key bindings, so that kind of thing is very error prone, and sometimes the browser itself straight up refuses to allow you to bind certain keys. (ctrl-n is off the table, for instance)
From my own personal experience, elisp is dramatically more portable than applications written in JS due to the huge memory requirements of the two mainstream browsers. In addition the buffer switcher is several orders of magnitude more useful than the tab bar, and being able to split the screen in various configurations somehow still isn’t a standard browser feature.
My Dell Dimension 5150 (P4) cries everytime that someone believes that browsers are a good way of implementing GUI (electron and friends). Sadly we are not giving much better solutions (GTK, QT)
This is definitely a new and interesting way to think about web development. I’ve always found it to be super intimidating as someone who has very little talent for web design :)
This also makes me think about Remi , a Python library that’s a traditional API style GUI toolkit that outputs interactive web.
It perhaps is easier for you as a developer but I’d argue that a lot of web applications should be local software that can be used without an internet connection and GB’s of RAM. Let’s not forget what the web is doing with regards to surveillance capitalism (ie messing up democracies because it makes some people money) and climate change.
Isn’t that less a problem with the web platform and more of a problem with specific web sites? Additionally, surveillance conducted on the user of a web site is much easier to see, simply by dint of the developer tools built into all browsers. The effort you need to put into seeing what a desktop application is phoning home about is much greater.
In some cases, that’s completely true. But for some other use cases, i refuse to install a software when the service could be equivalently used as a website (this especially applies to mobile apps).
Also, be aware that applications are as capable of surveillance (if not more) as web apps. The app that hosts all others for most people being Windows, is actually a a spying machine.
It’s probably the biggest platform there is. There’s 3 billion people on Facebook, how many people online? How much force is behind web tech? A lot! Y’all already know this. :) It’s just crazy to think about.
Most GUIs aren’t even called GUIs, they’re just “webapps” or “a site”. But I’m bringing this up because I think there was an interesting split. If you built a GUI before the .com boom (or whatever boom early web), you probably did it with some GUI toolkit tied to a language. Now, you can write in almost any backend language and the details are hidden from the user except for maybe a rogue
/cgi-binor.aspxin the URL. The web has many backend languages, fat GUIs have fewer. But the point is, we kind of stopped building fat desktop apps.There’s a few things we lost. We lost a layout tool like how Xcode has now, something that has alignment and quick feedback instead of save/refresh. There’s maybe some tools that have tried to get this back (rapid mockers or markup generators). But if you look at VB or iOS dev, you see that the native walled garden lets you flip back and forth. That was nice to me but of course it’s not required because if you look in the world people are building complex GUIs in web tech no problem.
There’s another thing I think we lost which goes even farther back. If you wanted a GUI for a “backend thing”, say git splits. Git just punts this to the
$EDITORor an interactive prompt. The TUI. Or a curses window for other programs. I’m hoping one day we have tooling that is so good and powerful that backend people don’t feel unable to start in the ecosystem and a TUI wouldn’t even be an option, much like a mainframe screen (F1/F2..) app wouldn’t be created. I think the problem here is complexity and specialization. I don’t know if the entire problem can be simplified or generalized to even approach without dealing with the DOM or switching toolsets.Will we always have TUIs? Is text-mode always usable? Can web tech become universally useful or simple? Can we put a wall between unix CLI composition and something like curses (flags and pipes and the unix way continue to be proved)? What would this even look like? You have a CLI that takes flags and args but if you invoke without these things, it runs in interactive mode but it stays in the terminal using some magic future tech and the programmer didn’t have to step outside their backend expertise or ecosystem to get this done? I have no idea. I can’t even imagine it.
If you design things carefully and minimally, you can still have that experience.
Writing HTML markup isn’t quite as straightforward as VB, but it’s close enough, in my opinion.
The w3m browser lets you switch to vim for editing textareas.
I 100% agree with everything except for the TUI. Text is awesome, being a web developer myself, I really enjoy using git in the terminal for instance. Far more powerful than any GUI I’ve been able to use. Long live the web and the TUI.
I think it would have been really nice for UIs if web browsers had historically supported unix sockets as HTTP endpoints, so arbitrary programs could use the web browser as a local GUI without having to worry about exposing a sensitive API over TCP
You can bind to 127.0.0.1
That is not as good. With a unix socket, the listening process can set the usual user/group/other permissions. With a TCP socket on 127.0.0.1 you’re exposing your service to everything on the same machine.
Plus TCP sockets suck at namespacing. Unix sockets are no worse at namespacing than the filesystem.
even with things like dbus, there are limits to the security model of unix sockets. I’d much prefer a better capabilities system or we can just accept that auth has to be handled by the receiver in some fashion.
We’re talking about using a browser as an alternative to a TUI. There would be little point worrying about any model more complicated than marking the socket 0600 because the user who started the tool is the one and only user you want to be able to access the tool’s API.
Not if you’re using a jail.
That’s a lot of effort for not a lot of payoff. I don’t remember BSD jails ever being usable by ordinary unprivileged users. ezjail meeded root for example. You’re going to have to put the browser in the same jail too if you want to limit access, which is kind of a non starter. You can’t grant access to only one uid or gid. They were ime always pretty slow and troublesome - you had to arrange a whole root filesystem for each, for starters.
Which is one of the reasons why unprivileged/rootless containers as provided by e.g. podman are really promising.
They were always incredibly useful IME.
Yeah for like full time sysadmins to set up daemons to run for years. Not for one off things like we’re discussing here.
Indeed, I’ve seen several applications do exactly this.
For example Google Refine: https://www.youtube.com/watch?v=yNccGtn3Wb0?t=1m12s
Kinda / sorta. It’s a little bit harder these days to simply
Inspect Sourceand snoop somebody’s unminified JS or CSS like you could back in the days.But I agree overall, and find it analogous to what I hear emacs users describe when they talk about their pervasive programmable TUI toolkit: https://ambrevar.xyz/emacs-everywhere/
Yeah, I agree. I’ve actually been drafting a “Why I don’t minify my files”-post alongside this one, but got kinda stuck on the file savings comparisons (getting unminified versions out of common software Like Wordpress or MediaWiki turns out to be surprisingly tricky!)
I make a point not to minify any handwritten JS, but when you use the web as a GUI toolkit for a language that isn’t JS, the JS it compiles to may remain inspectible, but hardly editable. Bucklescript is impresssive in that it generates readable and debuggable JS, but it’s still a) quite large and not minifying it is a serious bandwidth compromise for users with slow or metered connections b) its output likely makes little sense for a person unfamiliar with OCaml idioms it translates to JS.
It’s funny how basically everything in this bullet list also applies to using Emacs as an application toolkit, but moreso:
I would argue that really the last one is very badly supported in the browser; there is no standard mechanism for changing key bindings, so that kind of thing is very error prone, and sometimes the browser itself straight up refuses to allow you to bind certain keys. (ctrl-n is off the table, for instance)
From my own personal experience, elisp is dramatically more portable than applications written in JS due to the huge memory requirements of the two mainstream browsers. In addition the buffer switcher is several orders of magnitude more useful than the tab bar, and being able to split the screen in various configurations somehow still isn’t a standard browser feature.
Or acme 😉
My Dell Dimension 5150 (P4) cries everytime that someone believes that browsers are a good way of implementing GUI (electron and friends). Sadly we are not giving much better solutions (GTK, QT)
Note I didn’t even consider Electron when I wrote this; I was just thinking about in-browser usage.
This is definitely a new and interesting way to think about web development. I’ve always found it to be super intimidating as someone who has very little talent for web design :)
This also makes me think about Remi , a Python library that’s a traditional API style GUI toolkit that outputs interactive web.
It perhaps is easier for you as a developer but I’d argue that a lot of web applications should be local software that can be used without an internet connection and GB’s of RAM. Let’s not forget what the web is doing with regards to surveillance capitalism (ie messing up democracies because it makes some people money) and climate change.
Isn’t that less a problem with the web platform and more of a problem with specific web sites? Additionally, surveillance conducted on the user of a web site is much easier to see, simply by dint of the developer tools built into all browsers. The effort you need to put into seeing what a desktop application is phoning home about is much greater.
In some cases, that’s completely true. But for some other use cases, i refuse to install a software when the service could be equivalently used as a website (this especially applies to mobile apps). Also, be aware that applications are as capable of surveillance (if not more) as web apps. The app that hosts all others for most people being Windows, is actually a a spying machine.