4 ms·

the problem is developers having fast modern machines. if they were forced to use slow machines, they would not be able to put out crap like that

by slt2021 1y ago

__alexs 1y ago
It is garbage even on my extremely high end desktop PC.
mrbombastic 1y ago
M4 macbook pro and almost unusably slow
- lowwave 1y ago
  Ah the wonders of SPA! I know there are lighter ones, but it is not the first time hearing things like React being slow. Of course, when one start to do sntax highlighting on the client side....
  - humpty-d 1y ago
    Various comments and links throughout the discussion of this post indicate that the problem is a mix of the sheer number of nodes and css. It has nothing to do with React or being a React SPA, which it's also not, unless you have some proof otherwise.
    - bythreads 1y ago
      React and the most commonly used pattern inherently promotes an way to complex html Node structure and shitty css, especially if stuff like tailwind is used. Now you CAN so it so that is not the case, but tbh i have never seen that in the wild -
      - troupo 1y ago
        Lol. If anything, Tailwind isn't shitty CSS (because it's a very limited number of classes) unlike the gazillion one-off classes that CSS-in-JS or even BEM encourages Edit: here's a good investigation on a real-enough app https://www.developerway.com/posts/tailwind-vs-linaria-performance https://www.developerway.com/posts/tailwind-vs-linaria-perfo...
        typpilol 1y ago
        Yes what's with his comment? Tailwind is probably one of the best considering you can use Vite to literally strip out all unused css easily. And I think tailwind v4 does this automatically
  - Tadpole9181 1y ago
    > When native software is slow, it's bad software. When web software is slow, react is bad software. This is such a tired trope.
    - const_cast 1y ago
      Its not really a trope, the opposite is much more common. People are much more quick to mindlessly blame SSR for slowness like with ROR or PHP. The reality is both can be slow, it depends on your data access patterns, network usage, and architecture. But the other reality is that SPAs and REST APIs just usually have less optimal network usage and much worse data access patterns than traditional DB connected SSR monoliths. Same goes for micro service. Like, you could design a highly scalable and optimal SPA. Who's doing it? Almost nobody. No, instead they're making basically one endpoint per DB table, recreating SQL queries in client side memory, duplicating complex business logic on the front and back end, and sending 50 requests to load an dashboard.
      - whstl 1y ago
        React also has a class of problems that doesn't really happen in other types of apps: re-renders. Even other frameworks like Vue.js, Solid or Svelte don't really suffer from it as much. It simply happens a couple order of magnitudes more often in React than any other framework.
can16358p 1y ago
While I agree about devs should be testing on slow devices, the particular target audience of the site generally have pretty decent machines (including two that I have) and there isn't much reason for the site lag. It's not really doing any 3D rendering with complex shaders or video filtering; it just shows changed lines in two files. That shouldn't lag.
- m0llusk 1y ago
  I code on ten year old laptops and use Bitbucket CLI in part because of all this.
- chipsrafferty 1y ago
  It should be the same speed as running git diff in your console. And it should support histogram style diff...
ponector 1y ago
Only in the ideal world, where developers test results of their work on their machines. Test for real, with real db, not with empty or mocks.
const_cast 1y ago
I don't think so, I think the problem is their devs work on tiny play pretend codebases or micro service architecture. GitHub is big software, but not that big. Huge monorepos and big big diffs grind GitHub to a pulp.
- Atotalnoob 1y ago
  GitHub runs a mostly monolithic architecture
  - guappa 1y ago
    So? You can still do a PR of 1 line and the diff will only show that 1 line.
aleph_minus_one 1y ago
> the problem is developers having fast modern machines. > if they were forced to use slow machines, they would not be able to put out crap like that Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time. The only things that forcing developers to use slow machines will bring is developers quitting (and quite a lot of them would actually love to see the person responsible for this decision dead (I'm not joking) because he made the developers' job a hell on earth). What you should rather do if you want performant software is to fire all the project managers who don't give the developers the necessary time (or don't encourage the developers) to write highly optimized code (i.e. those idiot project managers who argue with "pragmatism" concerning this point).
- otabdeveloper4 1y ago
  > because they take time No they don't. It's literally just a skill issue.
  - aleph_minus_one 1y ago
    Fast algorithms are often more complicated. To give just one simple example: to get the textbook complexity bound for the Dijkstra algorithm, you need some fancy mergeable heap data structures which are much more complicated, and thus time-intense to implement than the naive implementation. Or you can get insane low-level optimizations by using the SIMD instructions that modern processors provide. Unluckily, this takes a lot of time and leads to code that is not easy to understand (and thus not easy to write) for "classically trained" programmers. Yes, you indeed need a lot of skills to write such very fast algorithms, but even for such ultra-smart programmers, finding and applying such optimizations need a lot of development time, which is why this is often only done for code parts that are insanely computation-intense and performance-critical such as video (and sometimes audio) codecs.
    - slt2021 1y ago
      the most common cause is architecture, not algorithms

the problem is developers having fast modern machines. if they were forced to use slow machines, they would not be able to put out crap like that

__alexs 1y ago

It is garbage even on my extremely high end desktop PC.

mrbombastic 1y ago

M4 macbook pro and almost unusably slow

lowwave 1y ago
Ah the wonders of SPA! I know there are lighter ones, but it is not the first time hearing things like React being slow. Of course, when one start to do sntax highlighting on the client side....
- humpty-d 1y ago
  Various comments and links throughout the discussion of this post indicate that the problem is a mix of the sheer number of nodes and css. It has nothing to do with React or being a React SPA, which it's also not, unless you have some proof otherwise.
  - bythreads 1y ago
    React and the most commonly used pattern inherently promotes an way to complex html Node structure and shitty css, especially if stuff like tailwind is used. Now you CAN so it so that is not the case, but tbh i have never seen that in the wild -
    - troupo 1y ago
      Lol. If anything, Tailwind isn't shitty CSS (because it's a very limited number of classes) unlike the gazillion one-off classes that CSS-in-JS or even BEM encourages Edit: here's a good investigation on a real-enough app https://www.developerway.com/posts/tailwind-vs-linaria-performance https://www.developerway.com/posts/tailwind-vs-linaria-perfo...
      - typpilol 1y ago
        Yes what's with his comment? Tailwind is probably one of the best considering you can use Vite to literally strip out all unused css easily. And I think tailwind v4 does this automatically
- Tadpole9181 1y ago
  > When native software is slow, it's bad software. When web software is slow, react is bad software. This is such a tired trope.
  - const_cast 1y ago
    Its not really a trope, the opposite is much more common. People are much more quick to mindlessly blame SSR for slowness like with ROR or PHP. The reality is both can be slow, it depends on your data access patterns, network usage, and architecture. But the other reality is that SPAs and REST APIs just usually have less optimal network usage and much worse data access patterns than traditional DB connected SSR monoliths. Same goes for micro service. Like, you could design a highly scalable and optimal SPA. Who's doing it? Almost nobody. No, instead they're making basically one endpoint per DB table, recreating SQL queries in client side memory, duplicating complex business logic on the front and back end, and sending 50 requests to load an dashboard.
    - whstl 1y ago
      React also has a class of problems that doesn't really happen in other types of apps: re-renders. Even other frameworks like Vue.js, Solid or Svelte don't really suffer from it as much. It simply happens a couple order of magnitudes more often in React than any other framework.

can16358p 1y ago

While I agree about devs should be testing on slow devices, the particular target audience of the site generally have pretty decent machines (including two that I have) and there isn't much reason for the site lag. It's not really doing any 3D rendering with complex shaders or video filtering; it just shows changed lines in two files. That shouldn't lag.

m0llusk 1y ago
I code on ten year old laptops and use Bitbucket CLI in part because of all this.
chipsrafferty 1y ago
It should be the same speed as running git diff in your console. And it should support histogram style diff...

ponector 1y ago

Only in the ideal world, where developers test results of their work on their machines. Test for real, with real db, not with empty or mocks.

const_cast 1y ago

I don't think so, I think the problem is their devs work on tiny play pretend codebases or micro service architecture. GitHub is big software, but not that big. Huge monorepos and big big diffs grind GitHub to a pulp.

Atotalnoob 1y ago
GitHub runs a mostly monolithic architecture
- guappa 1y ago
  So? You can still do a PR of 1 line and the diff will only show that 1 line.

aleph_minus_one 1y ago

> the problem is developers having fast modern machines. > if they were forced to use slow machines, they would not be able to put out crap like that Lots of developers are rather obsessed with writing good, performant code. The problem is rather that many project managers do not let them do these insane optimizations because they take time. The only things that forcing developers to use slow machines will bring is developers quitting (and quite a lot of them would actually love to see the person responsible for this decision dead (I'm not joking) because he made the developers' job a hell on earth). What you should rather do if you want performant software is to fire all the project managers who don't give the developers the necessary time (or don't encourage the developers) to write highly optimized code (i.e. those idiot project managers who argue with "pragmatism" concerning this point).

otabdeveloper4 1y ago
> because they take time No they don't. It's literally just a skill issue.
- aleph_minus_one 1y ago
  Fast algorithms are often more complicated. To give just one simple example: to get the textbook complexity bound for the Dijkstra algorithm, you need some fancy mergeable heap data structures which are much more complicated, and thus time-intense to implement than the naive implementation. Or you can get insane low-level optimizations by using the SIMD instructions that modern processors provide. Unluckily, this takes a lot of time and leads to code that is not easy to understand (and thus not easy to write) for "classically trained" programmers. Yes, you indeed need a lot of skills to write such very fast algorithms, but even for such ultra-smart programmers, finding and applying such optimizations need a lot of development time, which is why this is often only done for code parts that are insanely computation-intense and performance-critical such as video (and sometimes audio) codecs.
  - slt2021 1y ago
    the most common cause is architecture, not algorithms