What if, one took the amazing base that is Redox, and wrote a UI layer (maybe keep the window manager, but write a new desktop environment) with Electron… http://electron.atom.io/
Then, you could have the benefit of having an incredibly solid base, and the immediately influx of a ton of software.
Thoughts?
Concerns?
Death Threats?
Sincerely,
Someone who manages to love Rust and see value in Javascript somehow.
I have tried running Atom on a less-than-3GHz laptop with less than 4Gb of RAM. I failed. Electron is so suboptimal that it’s not even funny.
Besides, that would require node.js with V8 which is essentially a huge architecture-dependent JIT compiler in C. Also node.js happens to lack any backwards compatibility whatsoever so the more modules you use the deeper you descend into dependency hell. I have all of this at work right now and I cannot overstate staying away from that thing for any projects that you want to actually work.
And that’s before you try to plug all the Redox window system abstractions into Electron…
There is probably an even more backwards way to run UI on Redox, but I can’t think of one right now.
yet at the same time, regarding application support, the man’s got a valid point.
I find the electron software lineup far from compelling. It’s mostly web applications brought to desktop with a tiny bit of integration. Those that are not just web applications are not cross-platform and would not run on Redox without a fair bit of additional porting work.
Just write a React runtime to Redox runtime translation and then boom 
For what it’s worth, there are plans to build a runtime mostly compatible with Electron, but using Servo and SpiderMonkey. The former is at least Rust 
I don’t like the idea. Running JavaScript is a bad idea. Always and forever.
I’m a software engineer who currently works on a Node.js powered payment network that processes hundreds of thousands of transactions per day like clockwork. Over my ~10 years working in the software industry and I’ve got to say, some of the best projects I’ve worked on have been based on Node. (I also work on lots of Rust and Go stuff too, two new favourite languages of mine). Modern JavaScript is a great language for developing software. The non blocking concurrency model makes for some very quick programs. Programs are usually simpler due to the dynamic type system, and testing is very easy. The language also has a universe of very good tooling. If you’re scoffing at the language simply because it’s JavaScript, then I have to say you don’t know JavaScript. If it’s based on experience screwing around in IE6 or Netscape back in the day, then you have no idea what modern JavaScript is. If you dislike browser APIs, I probably agree with you in some instances, but these API’s have nothing to do with the language. There has been massive improvements over the last decade, and it continues to improve at a rapid pace. Most of the JavaScript rejection I see from otherwise very bright and reasonable engineers is usually based on unreasonable prejudice usually due to the fact that they just don’t get the language, or are familiar with a very old version.
That all said though I think it might be nice to see Redox offer JS as a supported language, it should be a bonus objective at best in my opinion. It’s probably true that V8 and Spider Monkey aren’t going to be easy port overs to Redox, thus it’s probably better to focus on the development of Orbital. I’d love to see JS based UI, but I don’t think Redox is ready for that yet.
Just my two cents.
Cheers!
I don’t know what happened with your trial of the editor, my office of 30 or so engineers don’t seem to have any issues running Atom. I have an old ass PC with a Pentium (2.4Ghz, 2GB of RAM) from back in the day that I use as a server. I have a copy of Atom on it and it runs fine.
As for your experience with Node. You might want to check your work with someone who has experience developing node projects. The only time I’ve seen this kind of thing is when someone tries to develop node programs without knowing how. I’ve worked on several very large node projects in my career. My current project is a payment network driven by 12 node powered micro services all with sophisticated permissions and authentication. The code base is maintainable, and the engineers enjoy working on it.
This is glorious, and I meant my comment seriously, and genuinely love and see great value in both Rust and JavaScript. I’m just glad I sparked conversation about the subject, and got some good/real answers.
For those thinking Electron is mostly for “websites”, check out the new Hyper terminal. A beautiful, cross-platform terminal built on Electron that’s also screaming fast.
However, I think ultimately, it’d be better to have a web-based UI solution without the overhead of Electron. For example, Elm is a super awesome language/framework for building UIs. Arguably better than React. Elm is great because it’s a language that can be compiled to any other language. Currently it’s only being compiled to JavaScript. But in the future, it’ll be compiled to WebAssembly and could also be compiled to Rust or Assembly for super fast performance.
But the downside of compiling a UI language to something like Assembly is you lose the ability to use browser dev-tools (like in Electron) to inspect then entire OS UI and tweak it to your liking.
Yea, the intention was to give people the tools they’re already used to, and make it incredibly easy to port applications. However using a servo port of electron, or at least providing a similar API would be much better, and would be a great middle ground I think.
As much as I love JavaScript, having it used for this integral a part of the OS would, in my opinion, be a horrible idea. Having native support for JS apps, or for a JS overlay on the desktop would be awesome - but I don’t think I’ll ever use an Operating System in which I can’t start a bare-metal desktop and taskbar without also starting electron.
@daboross, oh god no, not an integral part! That should stay purely rust! What I would love, is to just be given the ability to fire up a window manager, separately from the GUI, and then be able to start electron applications inside of that context, and make a separate desktop environment that would be optional. I considered doing this in Linux, as the infrastructure is already there, but I really think this project has more long-term potential for my own uses.
One could use advance UI system, which gives user more choices. Example is beaker browser. Separate frond end and backend. I also share the same ideas as OP. Why not make it native, and have users gain control on the front end. End users uses dynamic languages, and only need to obtain static information from the network. Gain control of the UI to suit their needs. Instead of having developers focusing on the UI design, it should focus on the backend core design.
Additional thoughts on this, I was researching DOM designs. I found two comments which affirms my thoughts that I am not alone about this idea. Either use virtual dom like react, or ditch the dom idea, and go with simpler format, imgui.
The vision is quite clear.
In highly specialized tiling window manager. Each window is tagged with name, and URI mapping. Whenever you click a link, it opens at specific location you explicitly told to. So you have bottom right corner for chat. Mid column for the multiple main apps such as libreoffice, wiki, etc. Left column for other reasons. Chat would always overlap other managers, and you would never have to resize or move it again.
irc:// link -> Window.bottomrightcorner.overlap { chat: irc / discord / matrix / etc }
https:// link-> Window.fullsize { browser, libreoffice, wiki, etc }
ipfs:// link -> Window.midcolumn { browser, libreoffice, wiki, etc }
fuse:// link -> Window.leftcolumn { file manager }
One could build layout section that specialize in certain areas. Research mode. Hack mode. Game mode. etc.
This gets really interesting. Say you start running game. The UI part is still on your end, and how you want to control it. You can still have chat window in bottom right corner, and play the game. Game itself no longer have to create their own chat UI anymore. All they have to do is give them the URI mapping to the chat room. It is scraped from their system. This leads to less resources, bandwidth, and time. Maybe… Tilling manager conjunct with wasm.
I think it’s not a bad idea to implement a UI layer that interprets HTML into a window. But implementing Electron as it is is too bulky and would be more trouble than its worth.
I think it’d be better to implement an API from the ground up that draws the window.
One could open up a html:NewWindow/NAME URL and then write HTML data to the connection to draw up a window. From here a program could interact with the window by sending instructions to the API to modify the DOM, much like Javascript DOM APIs.
For sending instructions asynchronously, the same program could open up the same connection by calling html:Window/NAME, and assuming the current process has ownership of the window, or if the owner process gave this process permission, then the API will let it send commands to the DOM.
Honestly, it’s basically a web browser Layout Engine built into the DE, and although it would make developing graphical applications extremely easy, it probably won’t be as efficient.
Fantastic wording of choice,
web browser Layout Engine built into the DE
With wasm, I believe it will be possible to create this scenario. It should be contained/sandbox. Each URL mapping -> Window will create it’s own container, so it doesn’t leak any information outside of the container. This might be resource heavy design but docker gave a proof that it doesn’t have to be resource heavy.
Implementing WASM into the engine wouldn’t be bad, but the only reason you need a scripting language would be to interact with the DOM anyways.
It might be a better idea to offload the processing power to the program connecting to the API, instead of having the Layout Engine handle it. Thus, any Javascript engine should be built into the program accessing the API, and not the Layout Engine itself.
I believe that there is lots of value in this idea, even if I probably wouldn’t use it personally. But that also sounds like an insane amount of work. Would you feel up to porting Node.js (or SpiderNode) to Redox?
Oh boy, I’d be more interested in getting Servo running well in Redox, and then porting Electron to Servo, since the API is compatible with CEF. But that’s gonna take some time.