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?
I did some quick profiling and it is doing quite a lot of re-rendering, but I do not see any of the common issues you see in actual slow React apps. For me it performs well, even on 6x slowdown there is no visible lag or "stickiness" (I'm on a Macbook Air M1).
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.
Thank you so much for this comment/analysis. I do intend to work more on performance this year but it's good to hear some people are having a performant experience as is. I actually did try and keep my React "clean" and performant, but I know there are places to improve. The wallpaper does indeed seem like the biggest issue. I may need to consider just a static if I detect performance issues, although that can be hard to detect.
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.
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.
> 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.
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).
I have Macbook Air M1 8GB, it ran smoothly on my side. The highest CPU usage I seen from that is 30%. Doom and Nuke Dukem 3D is running smooth in there as well. And my NUC (i7 8559U) have a tiny input delay but overall ran smoothly on it. I use Vivaldi for my Macbook and Firefox for my NUC.
Glad to hear it went well. I had this going on a 4th gen i7 and it also wasn't too slow, so I think it depends on a few factors as to how quick it is for others.
Quite interesting since on my mobile (OnePlus 6 with Chrome) seems kind of performant.
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?
Thanks for the appreciation. In general at least for me I found it quite quick on Chrome/Windows, so at least under some scenario it can be reasonably quick. If it is slow, it's likely not React as I have quite a few other things that run slower, like the wallpaper. I haven't tested Safari much as I don't have a Mac, but I will continue to try and optimize. Thanks for feedback!
Glad to hear that, thanks for checking it out! Chrome is indeed the best case scenerio browser as it's what I developed on. For me locally and when coming from CloudFlare, I find it quite fast, but some libraries can cause slow down such as Three.js and some of the emulators.
