DaedalOS: Desktop Environment in the Browser
dustinbrett.com
dustinbrett.com
https://en.wikipedia.org/wiki/Daedalus
Father of Icarus. From https://en.wikipedia.org/wiki/Icarus
> Icarus and Daedalus attempt to escape from Crete by means of wings that Daedalus constructed from feathers and wax. Daedalus warns Icarus first of complacency and then of hubris, instructing him to fly neither too low nor too high, lest the sea's dampness clog his wings or the sun's heat melt them. Icarus ignores Daedalus’s instructions not to fly too close to the sun, causing the wax in his wings to melt. He tumbles out of the sky, falls into the sea, and drowns. The myth gave rise to the idiom "don't fly too close to the sun".
Github was a bit hard to find: https://github.com/DustinBrett/daedalOS
- the app usually takes several dozens of seconds to load
- the phone becomes warm
- any text I typed is not restored after a crash or a page reload if the developers have not explicitly saved my keystrokes in the local storage.
- each key press in an input takes a good fraction of a second (if not one full second) to appear on the screen
For the last one, I feel the lag on a decent laptop too (even if the lag is shorter). I know why: it is good practice to feed back any input into the state of the React component so everything is in sync. This triggers a re-render and if the devs were not careful, a good chunk of the app is re-rendered, which does not necessarily lead to a browser re-render / a blink, but definitely makes React execute a lot of render methods and re-diff virtual DOM trees. So each key press makes the browser run some JS that makes useless computation and accesses to the DOM. It's called "controlled component" [1]. Well, this is good practice for the devs, but it is user hostile. I wish more things were designed user-first instead of dev-first.
React + React-dom alone is around 130 KiB, 42 KiB Gziped [2]. It's without counting the usual dependencies (classname, Redux, browserlist, polyfills…). It's also more than three times the size of the entire frontend of the SMS app I'm building with Svelte. The heaviness is insane.
It is probably possible-ish to build an almost lean app with React. Signal seems to be kind of an exception and feels quite fast on my laptop (can't tell on the phone). It leaks memory and gets OOM killed quite often but React might not be to blame here. But React apps usually come with a awful lot of dependencies, to add insult to the injury.
It's render and diff'ing lags, fan takeoffs and RAM exhaustion all the way down.
[1] https://reactjs.org/docs/forms.html#controlled-components
[2] taken there, as linked in the tutorial (https://reactjs.org/docs/add-react-to-a-website.html): https://unpkg.com/react-dom@17/umd/react-dom.production.min.... and https://unpkg.com/react@17/umd/react.production.min.js
I used to this. A better approach is to use the onBlur event of the input field to update the text to state. The text itself can be accessed via a reference to the input field in the onBlur event (created with useRef). This makes it so that not every typing action rerenders the whole component.
Edit: I wonder if its some kind of functionality causing the slow down? Perhaps Safari doing something stupid? Have you tried Chrome or another browser?
The background does take up some CPU, have you tried if it's still slow when you change it to a static picture? Side note: it's absolutely insane that you can change the background! Amazing work, such detail.
A different framework would not make a difference per se, maybe less re-rendering could help a bit, you can easily do that in React. And btw I'm not hating on the other frameworks mentioned; absolutely legit choices, but React is as well.
There are many very performant and user friendly apps written in React, and you can easily write shitty apps in all frameworks (React included).
I'm very impressed by this app, so much functionality and details, honestly insane.
Thanks for noticing the detail, I spent quite a bit of time trying to get as much details and features as I could. Now for this year I want to make it more robust and take all the feedback I've got to make it even better.
Really amazing work, I can only imagine the time and effort this took!
Please have a look here, you will love it : https://github.com/zriyans/awesome-OS
Hee hee.
I've tended to get around this by adding a query to the URL bar -- seems to trick whatever browser it was that I encountered this behavior on.
I think Firefox OS was the farthest that this got, but I think it has potential. Such an OS would basically just be Linux + Headless Chromium + web browser API abstractions for things like USB (WebUSB), etc.
I'm thinking of a desktop environment where everything was truly web - there was no native toolkit.
Sadly, too advanced to its time, it was acquired but dismantled some time later.
Edit: it is the project the_only_law posted below
Either the user does that, or we signal to the browser that this is a 'fullscreen only app and you must run it fullscreen' but that would be bad user experience, since most users would struggle to exit it.
The OS booted ASAP to a fullscreen Chromium instance, until we added support for running Linux apps too later on. I didn't work on the windows management so can't say more about this technical side.
Another is enthusiasm to share your own work with the world.
Neither is bad, but just something to be aware of.
I saw this in my own early work before I reached an equilibrium of spontaneous original designs.
Unless the unique design is the goal on its own why waste time?
I'm thinking most of the issue might be the wallpaper. Its cool and all, but its a huge CPU drain.
Thanks for checking it out anyway! I hope one day you can try it with a smoother experience because when it works, it can do a lot, although it's a lot of just messing around. :-)
(I found the pizza recipe btw)
Web apps running in a frame could postMessage requests for selected services from the desktop environment. It could potentially allow for a app to easily support a large number of different environments.
(volume warning)
I'm not sure when the buyout happened, but a few years ago Sencha became the shadiest, nastiest organisation I've ever dealt with. I'm keen to see what Synology do / have done to displace it.
Most of the conventions of window-based desktop UIs inside a web browser is silly because it is, itself, a window. You are likely better off using multiple browser tabs than a fake windowed UI inside a single browser tab.
...Are you going to upgrade your home page to Windows 11 though? ;)
So the general idea is good, but I do not like the windows clone style of this one too much, also it is very slow. But that might be different, if locally installed.
Btw. it took me some time, to find the github link
By launching Doom and Blog Posts simultaneously, I caused some kind of deadlock on Firefox 96.0b10 (64-bit) Developer Edition on Windows 10.
You lost me at the title already.
I suppose next they would want to integrate that web browser into of systemd and then I know I've fully arrived in hell.
One thing is certain when comparing the two - I have a LOT to learn from this project. The inspiration goes both ways.