If you're pushing a solution that's worse than existing practical widely used well supported alternatives, you're wasting everyone's time.
I have already proposed an extremely practical, totally open, standards compliant, easily predictable, inevitable solution. What is your response to my posts about pushing something like Electron down to the bare metal?
It's not as if there aren't already thousands of extremely talented people across hundreds of different companies and organizations, all working towards towards making that possible and efficient. It's not as if the tooling doesn't already exist and isn't widely supported and rapidly evolving.
There is no need for X-Windows, and no need for Wayland, because a web browser running on bare metal could do everything they do, and so much more, in a vastly more flexible, standards compliant, modular, powerful, efficient way.
And it would be a much better platform for implementing a shell, user agent, desktop, window manager, and even a visual programming environment than the half-assed mish-mash Turing Tarpit of shell scripting languages Unix has suffered with for so many decades, which themselves don't even adhere to the so-called "Unix Philosophy".
AND it would be truly extensible (even capable of gasp multiplying floating point numbers and doing non-trivial string manipulation without forking heavy weight processes), which X-Windows and Wayland are not, which means it can be fundamentally much more efficient, by downloading code to implement application specific protocols and local interaction, like NeWS did decades ago, but X-Windows and Wayland foolishly and stubbornly refused to do by design. (It's not like the ideas behind NeWS were unknown to the designers of X-Windows and Wayland -- they just chose to ignore them. And now here we are.)
You've got JavaScript and WebAssembly for programming, WebGL and <canvas> and <video> and DHTML and CSS for drawing (including low latency rendering with desynchronized canvases), JSON and XML and ArrayBuffer for data representation, HTTP and WebSockets and WebRTC for networking. What is it missing?
That design has been well proven and is widely used throughout the industry. It's not a new idea, but kids these days refer to it as "AJAX". There's no need for a bunch of useless layers underneath the web browser any more. It's time for X-Windows and Wayland to fade away into the depths of history.
I saw the Electron mention, but didn’t know what to make of it. What does a “web window system” have to do with unix shell script limitations? I still don’t know.
I find web programming inelegant honestly, with three languages instead of one, a clumsy interpreted programming language that doesn’t multithread. Webasm may help with the last parts, perhaps. What about performance? How to run native code in windows?
At least I’d know how to use it, that’s a big plus. There would need to be some standardization around gui widgets, don’t like how they have to be built from scratch in every project.
Gnome3 uses js and css in its desktop widgets.
Finally Wayland is pretty lean, folks complain it doesn’t do enough already. You’d have to implement a driver and drawing layer anyway, right? So not much is “useless,” perhaps the window manager.
So three languages instead of one is bad for the web, but just fine for bash+awk+sed+expr+bc+grep+egrep+cut+sort+find+etc?
(Plus the other languages you need to switch to and rewrite from scratch once your bash script becomes more than 12 lines long.)
"After a shell script reaches a dozen lines, it's time to port it to Python." -mixmastamyk
Why would anyone in their right mind ever start out with a language that can only handle 11 line scripts?
And are you under the impression that bash is multithreaded? That it has good performance? A just in time compiler? An ahead of time compiler? A module system? A large ecosystem of reusable modules that can plug together and call each other without conflicts? An object oriented programming system? A debugger? An IDE?
Can you compile C++ and other languages into compact BashAssembly code, call it back and forth directly from Bash, and run it really fast across all platforms?
In case you weren't aware, a hell of a lot of people write JavaScript code that runs in node.js, instead of bash scripts, and are very happy with it. And of course Electron can run any code that runs in node.
So yes, running JavaScript in node or Electron is a fine alternative to running bash scripts. It can even handle file names with space in them without shitting itself! What rocket science! And you don't even have to rewrite your scripts in another language once they reach 12 lines -- what a relief!
What I was describing that you didn't understand is implementing a visual programming shell in Electron. And if you prefer a text command line shell with a different syntax than plain JavaScript, then simply implement that syntax and the command line interpreter in JavaScript itself, so you have the complete power of JavaScript and all its libraries to draw from (including extravagant luxuries you're not used to, and couldn't imagine you'll ever need, like floating point math and string manipulation), and you can import and call any JavaScript module. That blows bash out of the water.
You say you're not even aware that there are libraries of user interface widgets for JavaScript, and falsely claim they have to be "built from scratch in every project". But there are many, some of them quite good.
So have you ever even heard of or used the Chrome debugger JavaScript console window, or have any clue what high power integrated convenience and debugging features it supports?
How does that compare to your favorite bash integrated development environment and debugger? Care to tell me which one you use, and link me to a tutorial that shows how much better it is than the Chrome debugger?
Or do you firmly believe that ALL people who write bash scripts NEVER need to debug them, set breakpoints, catch errors, examine stack traces and scopes, single step through code, browse the values of variables and data structures at runtime, just like they never need to use floating point or do non-trivial string manipulation?
I admit that might be the case if you always rewrite your bash scripts in Python once they reach a dozen lines, as you say. But in the real world, most bash scripts are much longer than that, and often suffer from lots of bugs.
You sound like one of those people who complains about hating Lisp because it has too many parenthesis, then goes and writes code in bash or perl with so much punctuation and different kinds of parens and brackets and braces and single letter abbreviations and syntactic syrup of ipecac, that it looks like you lifted the phone out of your 300 baud modem's acoustic coupler and shouted into it.
As I said, you're blind to the problems and limitations of your favorite tools, and hypocritical in your criticisms of better tools.
The preface of the Unix Haters handbook perfectly describes the problem you're suffering from:
“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your
body is covered with lice and flies, you are malnourished and you
suffer from numerous curable diseases. But, as far as young East
Africans can tell, this is simply the natural condition and they live
within it. By the time they find out differently, it is too late. They
already think that the writing of shell scripts is a natural act.”
— Ken Pier, Xerox PARC
My favorite tools are Python and fish, so your insults about the others don't really hurt. I almost never use bash because I don't care for it either. Those other Unix command-line tools are arcane too, but they have a mostly compatible syntax. Don't use many of them besides a grep alternative and an occasional sort perhaps.
There are languages optimized for interactive use, and others for writing batch scripts and programs. Fish is great for interactivity, Python not so much. So they compliment each other quite well. There have been a few attempts to do both (xonsh/iPython), but none have been big hits yet.
Performance is important for long-running and/or computationally expensive apps, which are typically not interactive. When I brought it up, was thinking of Gimp filters, not "ps -ef | grep FOO".
Javascript is probably good enough these days. If you want to create a "jsh" interactive shell with the good parts have at it. Believe it is doable by a single person in a reasonable time. I'd guess a few might already exists and could use contributors.
Re: widgets, meant that few are standardized/built into the browser already and have to be downloaded, not that none exist. A silly situation (as someone who wrote GUI apps in a single language in the 90s), yet could be rectified.
But in thread about GUI Window systems you are going on and on about the limits of bash, which is why your arguments are not well received. It's really neither here nor there regarding Wayland. Shell scripting hasn't held me back since '98 or so, if it ever did. It's like complaining about vi when Sublime Text and VSC exists.
I get that you appreciate good software design, me too. But "worse is better" is the reality we live in. Things get better, eventually.
