Live data from Hacker News

DaedalOS: Desktop Environment in the Browser

dustinbrett.com

41–50 of 130 posts

Re: DaedalOS: Desktop Environment in the Browser

#41
post #31

Earlier quoted context omitted.

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it so much hence people bought into the hype. And now it has the big ecosystem, which is one of the main arguments to use react for many people…

Because it's amazing to develop in and if you are good at development it's not hard to make performant applications. Don't blame the framework for a lack of skill

If the trigger goes off just being looked at, maybe the manufacturer shares blame…

Re: DaedalOS: Desktop Environment in the Browser

#42
post #37

On my test computer which is an i7 m620 and no GPU it is very slow and takes the CPU to 100% on all cores while idle. opening a window will just get stuck at "working on it". While it looks nice this has probably been the slowest and least efficient web desktop I have opened on this computer and I have looked at a lot because I am building my own.

To be fair, that is a 12 year old processor, so many modern websites are probably hard

Re: DaedalOS: Desktop Environment in the Browser

#43

Appreciated what has being put into this effort. Quite slow on macbook pro with 16gb of ram. This makes me question the usability of React. Wouldn't something like this better written in something more lightweight such as Mithril or SolidJS, Vue, etc?

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it so much hence people bought into the hype. And now it has the big ecosystem, which is one of the main arguments to use react for many people…

On my PinePhone, I can immediately tell whether an app is built with React.

- 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

Re: DaedalOS: Desktop Environment in the Browser

#44
post #31

Earlier quoted context omitted.

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it so much hence people bought into the hype. And now it has the big ecosystem, which is one of the main arguments to use react for many people…

Because it's amazing to develop in and if you are good at development it's not hard to make performant applications. Don't blame the framework for a lack of skill

This is breathtakingly wrong. Performance bottlenecks are notoriously hard to fix in ReactJS. Once you've exhausted memoization, hoisting, even propagating state via message passing, you have to fight tooth and nail to rip a hot path out of ReactJS' grip. It's horrible. And it's the prize you pay for using a framework everybody and their grandmother can learn reading only a 5 minute blog post (the true value proposition here).

Re: DaedalOS: Desktop Environment in the Browser

#45
post #37

On my test computer which is an i7 m620 and no GPU it is very slow and takes the CPU to 100% on all cores while idle. opening a window will just get stuck at "working on it". While it looks nice this has probably been the slowest and least efficient web desktop I have opened on this computer and I have looked at a lot because I am building my own.

To be fair, that is a 12 year old processor, so many modern websites are probably hard

You would be surprised, most sites work well actually. OPs site is probably one of the slowest sites I've visited with this laptop.

Re: DaedalOS: Desktop Environment in the Browser

#46
I wonder if someone will eventually make a desktop OS that is entirely web-based. No GTK or WinUI - everything is a web app. Except that the DE would also be, technically speaking, a web app itself that shows other web apps. Kind of like this, except imagine if the example apps ("File Explorer") were real web apps loading into the web app desktop environment.

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.

Re: DaedalOS: Desktop Environment in the Browser

#47

I wonder if someone will eventually make a desktop OS that is entirely web-based. No GTK or WinUI - everything is a web app. Except that the DE would also be, technically speaking, a web app itself that shows other web apps. Kind of like this, except imagine if the example apps ("File Explorer") were real web apps loading into the web app desktop environment. I think Firefox OS was the farthest that this got, but I t…

How far is ChromeOS / ChromiumOS from what you described?

Re: DaedalOS: Desktop Environment in the Browser

#48

I wonder if someone will eventually make a desktop OS that is entirely web-based. No GTK or WinUI - everything is a web app. Except that the DE would also be, technically speaking, a web app itself that shows other web apps. Kind of like this, except imagine if the example apps ("File Explorer") were real web apps loading into the web app desktop environment. I think Firefox OS was the farthest that this got, but I t…

How far is ChromeOS / ChromiumOS from what you described?

Not there yet, because ChromeOS's user interface is not written as a web app. (Think close, minimize, maximize, window frame, taskbar, etc.) Same for it's native user interface (Settings menu).

I'm thinking of a desktop environment where everything was truly web - there was no native toolkit.

Re: DaedalOS: Desktop Environment in the Browser

#50
post #43

Earlier quoted context omitted.

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it so much hence people bought into the hype. And now it has the big ecosystem, which is one of the main arguments to use react for many people…

On my PinePhone, I can immediately tell whether an app is built with React. - 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…

> I know why: it is good practice to feed back any input into the state of the React component so everything is in sync.

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.

Post reply on HN