"Do everything in Emacs" isn't really so different from "Do everything in the browser."
Arguably, modern browsers are more heavyweight and complex at that. They certainly eat a hell of a lot more RAM than my Emacs ever does.
It allows you to embed GTK widgets INSIDE an emacs buffer, effectively allowing one to create actual GUIs inside of emacs.
This also allows you to embed a full webkit-based browser (with javascript support!) right into emacs, and use it like a regular browser.
Just clone the emacs repo, build it with gtk3 and xwidget support, and run 'M-x xwidget-webkit-browse-url' to get a full-fledged browser with proper rendering right inside emacs.
https://www.emacswiki.org/pics/static/EmacsXembedScreenshot....
https://en.wikipedia.org/wiki/Eww_%28web_browser%29
I don't believe there is any Javascript support, though, so you'll be out of luck for many modern pages...
Only Powershell comes closer to how this was used.
The difference is the data structure which is passed around. Is it bytes, Cons, or objects?
UNIX shells don't allow to call functions declared in .so, execute scripts applied to elements selected with the mouse, apply functional algorithms over data.
Well, you can write external commands in another programming language, but then it isn't a REPL anymore.
What do you do when you have to debug a pipeline? You do not have direct access to the data that flows, you need special tools to examine core dumps, and you have to have had enabled saving the dumps beforehand, you need to verify that the command syntax is correct, you have to understand what each program emit, and make sure you filter out all irrelevant data like logging etc., you don't know which part of the pipeline failed, where, you don't know if it is a wrong parameter or the program has a bug. And in order to fix bugs in programs that make up the pipeline, you have to know in whatever language the buggy one was implemented:
</var/log/my-service.log ag 'Response: 505' | sed 's#(<timestamp>) (<path>) Response: (\d{3}) (\w+)#\1,\2,\3,\4#' | python create_report.py --output-to latex > /tmp/report.tex && latex /tmp/report.tex && dvi2pdf /tmp/report.tex && [ -f /tmp/report.pdf ] && sh /home/gkya/utils/mail_report.sh --report /tmp/report.pdf
Don't let them tell you that Unix was developed to ONLY run small composable tools and that this is the only true way to use applications under Unix.
If you look at Mac OS X as a Unix, the typical application has a GUI, only one instance is running, it works for multiple documents and often users keep them running for a long time. When browsing the web, one would not leave Safari/Firefox/Chrome after each web site visit...
I would argue that the original developers of Unix over at Bell Labs were horrified at X and the "monolithic" applications that were being developed for Unix.
So much so that they wrote an entirely new operating system, Plan 9 that pushed composability to a new level and also included its own windowing system called 8½ (which was rewritten later as Rio).
Rob Pike had this to say about 8½ [2]:
> The entire system, including the default program that runs in the window — the equivalent of xterm pasting between windows — is well under 90 kilobytes of text on a Motorola 68020 processor, about half the size of the operating system kernel that supports it and a tenth the size of the X server without xterm... The small size of 8½ does not reflect reduced functionality: 8½ provides service roughly equivalent to the X window system. 8½’s clients may of course be as complex as they choose, although the tendency to mimic 8½’s design and the clean programming interface means they are not nearly as bloated as X.
[1] https://en.wikipedia.org/wiki/Unix_philosophy [2] http://doc.cat-v.org/plan_9/4th_edition/papers/812/
What about Acme's architecture?
> Acme is about 8,000 lines of code in Alef, a concurrent object-oriented language syntactically similar to C [Alef]. Acme’s structure is a set of communicating processes in a single address space. One subset of the processes drives the display and user interface, maintaining the windows; other processes forward mouse and keyboard activity and implement the file server interface for external programs. The language and design worked out well; as explained elsewhere [Pike89, Gans93, Reppy93], user interfaces built with concurrent systems can avoid the clumsy top-level event loop typical of traditional interactive systems.
That does not sound like Unix philosophy. Communicating processes in a single address space application. On Plan 9. Written by Rob Pike at Bell Labs.
We've seen companies like SUN, IBM, HP, DEC/Compaq/whatever they are called now/..., etc. earning zillions on big fat applications. Big fat GUI applications and big fat server applications.
From any Oracle DB, to any Java application, to basically every desktop application - none follows the so-called 'UNIX philosophy'. Thus tools like GNU Emacs have zillions of similar applications under UNIX and GNU Emacs is nothing special at all.
Plan 9 is more Unix than Unix. First, Acme is no longer written in Alef, but in C (on Plan 9) or Limbo (for Inferno). Second, I don't think you understand how Acme works; try reading the Acme paper or watching Russ Cox's introductory screencast.
Plenty of monolithic software runs on modern Unices, but very few can be traced back to a tradition of monoliths.
It's a bit crazy to call Emacs bloated these days; vim is big, too, so is Eclipse, so are most useful programs. I don't like Emacs one bit, but its size is the last thing that bothers me.
netpbm?
Actually, once upon a time, there was a web browser called "Chimera", it used external commands to handle many types of files. For example, it used djpeg to load inline JPEG images.
Just because a program has the illusion of being monolithic doesn't mean that it should shed the lessons of combining smaller, more stable parts.
Emacs does only one thing. And does that one thing very well - "Extensibility"