5 ms·

> 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

> 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 5y 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 5y ago
  Everything lately in the frontend world seems to be optimized for developer comfort, not performance.
  - sabellito 5y 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 5y 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 5y 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 5y 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.

> 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 5y 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 5y ago
Everything lately in the frontend world seems to be optimized for developer comfort, not performance.
- sabellito 5y 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 5y 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 5y 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 5y 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.