4 ms·

This made me laugh out loud. What a commentary on the current state of front-end development. - Chrome uses a ton of memory. Is this necessary? - V8 is incred

This made me laugh out loud. What a commentary on the current state of front-end development. - 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?)

sabellito 6y ago
> but front-end developers have somehow found a way to slow it down [...] That take is a bit shallow, do you really believe that is the crux of the issue of V8 rendering being slow sometimes?
- morelisp 6y ago
  As someone coaching "experienced" (many years, little depth) front-end developers in better practices, I absolutely believe a shitload of performance is left on the table because they write tremendously inefficient code. I'm not talking about "tricky" stuff, but "accidentally quadratic" kind of stuff, or a map where a filter would do.
  - andrewzah 6y ago
    Everything lately in the frontend world seems to be optimized for developer comfort, not performance.
    - sabellito 6y ago
      I'm genuinely interested to understand your point of view to have that impression, as your argument is a bit broad and someone disingenuous could argue that everything other than C/assembler is optmised for developer comfort.
  - sabellito 6y ago
    Ah with that of course I agree: inexperienced developers write code that performs poorly, even in obvious cases. That's hardly to do with V8, front-end, and React, wouldn't you agree?
    - morelisp 6y ago
      I don't think the ratio of bad:good new developers varies much by the stack, but I think some stacks push developers "up or out" more than others. Browser frontend has some of the least pressure here because the performance problems are generally paid by someone else's computer. 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. 0: https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/
      - sabellito 6y ago
        Good link, hadn't read that yet. 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.
ignoramous 6y ago
> V8 is incredibly fast, but front-end developers have somehow found a way to slow it down You're not wrong with your commentary which is basically surmised by https://en.wikipedia.org/wiki/Parkinson%27s_law 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-future-of-computing/ https://blog.mightyapp.com/mightys-secret-plan-to-invent-the...
- seoaeu 6y ago
  The thing is that RAM is really cheap. Right now on my machine Firefox is using 5GB of RAM, which at current prices would cost about 75¢/month amortized over three years. It seems hard to justify paying 40 times that amount for this service
- ori_b 6y ago
  > Correct me if I am wrong, but to an extent, isn't the memory bloat inherent to Chrome's sandboxing model? 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.

sabellito 6y ago

> but front-end developers have somehow found a way to slow it down [...] That take is a bit shallow, do you really believe that is the crux of the issue of V8 rendering being slow sometimes?

morelisp 6y ago
As someone coaching "experienced" (many years, little depth) front-end developers in better practices, I absolutely believe a shitload of performance is left on the table because they write tremendously inefficient code. I'm not talking about "tricky" stuff, but "accidentally quadratic" kind of stuff, or a map where a filter would do.
- andrewzah 6y ago
  Everything lately in the frontend world seems to be optimized for developer comfort, not performance.
  - sabellito 6y ago
    I'm genuinely interested to understand your point of view to have that impression, as your argument is a bit broad and someone disingenuous could argue that everything other than C/assembler is optmised for developer comfort.
- sabellito 6y ago
  Ah with that of course I agree: inexperienced developers write code that performs poorly, even in obvious cases. That's hardly to do with V8, front-end, and React, wouldn't you agree?
  - morelisp 6y ago
    I don't think the ratio of bad:good new developers varies much by the stack, but I think some stacks push developers "up or out" more than others. Browser frontend has some of the least pressure here because the performance problems are generally paid by someone else's computer. 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. 0: https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/
    - sabellito 6y ago
      Good link, hadn't read that yet. 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.

ignoramous 6y ago

> V8 is incredibly fast, but front-end developers have somehow found a way to slow it down You're not wrong with your commentary which is basically surmised by https://en.wikipedia.org/wiki/Parkinson%27s_law 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-future-of-computing/ https://blog.mightyapp.com/mightys-secret-plan-to-invent-the...

seoaeu 6y ago
The thing is that RAM is really cheap. Right now on my machine Firefox is using 5GB of RAM, which at current prices would cost about 75¢/month amortized over three years. It seems hard to justify paying 40 times that amount for this service
ori_b 6y ago
> Correct me if I am wrong, but to an extent, isn't the memory bloat inherent to Chrome's sandboxing model? 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.