- Chrome uses a ton of memory. Is this necessary?
- V8 is incredibly fast, but front-end developers have somehow found a way to slow it down (maybe through gigantic React apps that recompute the entire state tree with every user interaction?)
You're not wrong with your commentary which is basically surmised by https://en.wikipedia.org/wiki/Parkinson%27s_law
> Chrome uses a ton of memory. Is this necessary?
Correct me if I am wrong, but to an extent, isn't the memory bloat inherent to Chrome's sandboxing model? Having worked on a similar project, I firmly believe remote rendering is not only better speed wise but also efficiency wise. In some cases, might be better security wise, too.
Browsers are probably what I need keep open all the time along with other IDEs; and of the two, I'd prefer to teleport the Browser away to free up RAM (speak nothing of the battery). Right now, I see Firefox take up 75% of the available RAM starving other applications. Enabling swap only makes matters worse; and slows the PC to a crawl whenever page swaps to/from disk, which is usually the case when navigating between different IDE windows and the browser.
Given the amount of SaaS apps and the pace of its adoption across enterprises, Mighty, if it solves the problem it set out to, is likely to laugh all the way to the bank.
Edit: The launch blog post is worth a read: https://blog.mightyapp.com/mightys-secret-plan-to-invent-the...
It just puts each tab into a native process, so there's no inherent need for the per tab sandbox to be more heavyweight than a native process.
That take is a bit shallow, do you really believe that is the crux of the issue of V8 rendering being slow sometimes?
That's hardly to do with V8, front-end, and React, wouldn't you agree?
Backend inefficiencies traditionally will eventually saturate your RAM / CPU / I/O ("clouds" removes some of this but you still pay in the end - they also increase pressure in other areas since you're now always running alongside other things). In the browser you just need to be faster than the user's expectation or need, and user expectations are today at record lows and needs at highs (more and more "daily life admin" is web-only or web-first).
I also think "tribe 3"[0] developers are both more likely to gravitate towards the frontend, more likely to not think about performance, and (definitionally) more likely to not want to learn about fundamentals affecting performance.
My impression is opposite to yours, perhaps due to the type of software development we do. I can't remember how many times a performance problem was "sorted" by increasing CPU and RAM limits on a cloud instance. It just so happens that it's much, much easier to do that on the cloud instance than on a user machine. Of course performance problems do show up that need to be solved, just way less common than just spending more resources.
What I do agree with you (and I have no data on this just personal impressions that are most likely affected by observation bias, as I suspect is the case with you as well), is that in these waves of new programmers not going through the normal university route (which is absolutely perfectly fine in my book), they usually start off with front-end development these days, skewing the experience level ratio to more entry level people, and thus making entry-level mistakes. Perhaps 10 years ago the entry tech was Rails/PHP.