4 ms·

> this is bad for consumers, this is bad for you How? Why? Efficiency? My company does complex cloud and on-prem web-based apps, JS front and back. These ine

> this is bad for consumers, this is bad for you How? Why? Efficiency? My company does complex cloud and on-prem web-based apps, JS front and back. These inefficient frameworks make our developers more productive and allow us to design, deliver, and fix fast. Storage is cheaper, bandwidth is cheaper, processing cycles are cheaper, all are cheaper than developer time. And these powerful frameworks give us great speed in iterating new features, which makes our customers happy. The article is too focused on efficient use of computing resources at the expense of ignoring developer costs and customer satisfaction.

blakehaswell 5y ago
> great speed in iterating new features […] makes our customers happy For me this is a leap. I can't think of many examples of software which I use where new features have actually made me happy. Normally it's just change which forces me to learn something new while I'm in the middle of trying to accomplish something actually productive. I think our industry over-estimates the value of "new features". But in my experience 90% of new features provide neutral or negative value. If—instead of a new feature—the software I used released a performance improvement, then that would actually help make me more productive.
- PeterWhittaker 5y ago
  I don’t mean new features in the frameworks, our customers don’t care (and don’t know what frameworks we use, AFAIK). They care about the features in our products and the frameworks we use allow us to do cool fast.
- cerved 5y ago
  there are lots of publicly available feedback channels, should be possible to verify your hypothesis
chmod775 5y ago
> My company does complex cloud and on-prem web-based apps, JS front and back. Then you've certainly run into power users. Chances are browsers can load and display a 2MB server-generated HTML table faster than the DI system in your 5 MB angular app can start all the required services to be ready to launch your pagination component. However once it is ready it may be quickly apparent that users would be much more productive using that giant table and CTRL+F than a laggy angular app that would struggle even handling that much data at once in an idiomatic way. Of course I am making this up to illustrate a point. However I use "one giant HTML table" as a sort of bar to meet when developing in modern frameworks. If with this insanely complicated and large array of tools I can't even do better than that (faster to implement!) competing solution, I might as well not bother. That "a bunch of large server-rendered HTML tables" just so often happen to be the previous solution that was in place, and power users are likely to complain if we do worse, is just the cherry on top. To do better we often have to avoid certain things that would be considered modern. Like not putting lots of empty space in our layout, no server-side search that would introduce too much (pointless) latency compared to client-side, and some un-idiomatic stuff to actually handle large[1] amounts of data without change-detection/updating in our framework of choice eating user's CPUs for breakfast. [1]: The amount of data/elements at which change detection in idiomatic Rust and Angular becomes slow wouldn't have been considered 'large' 15 years ago. Though obviously people then had to put thought into this stuff and it certainly wasn't automatic.
- cerved 5y ago
  I want all my data in a gigantic HTML table, said no user ever
  - fake-name 5y ago
    Hi. I'd love this. I'm a user.
- reboog711 5y ago
  > in your 5 MB angular app Related anecdote: I just did a production build of the Angular 13 app I'm working on and it was 686K. That includes all the Angular framework, and a component library which includes a data table.
  - chmod775 5y ago
    Well. Good work then! Your build is half the size of twitch.tv's vendor.js. If you go on their front page, then click a stream, your browser will have loaded around 15MB of JS (~3.4MB over the wire). To be fair they're a video streaming service so they probably don't care about a few extra megabytes here and there, but on lower spec'd hardware you'll feel all that JS: a solid 5s of CPU time just spent executing JavaScript on my thinkpad during that test, not including the time to load it. And it's not like they're done. If you then do pretty much anything, it'll have to load even more. Apparently if you click a name in chat, it has to load another 998.96KB JS file (features.chat.components.viewer-card-*.js) to render those tiny cards that contain maybe 50 bytes of information. That's a good bit larger than your entire application! There's operating systems that fit in less than what twitch needs to show a glorified tooltip. On my hardware they could probably boot in that time too.
- PeterWhittaker 5y ago
  Well, if our apps resembled these large tables of which you speak, maybe…. :-) Our apps are related to compliance and risk management with a good sprinkling of custom developed workflow. Most of the screens users see are fairly light. It isn’t the amount of data that matters to our users, it’s what we do with it. And how quickly we can new things when they realize they need new.
kreeben 5y ago
>> These inefficient frameworks make our developers more productive and allow us to design, deliver, and fix fast. This is good for humanity, how? You hire a bunch of n00bs that can't work together so you separate their code into small chunks of absolute crap that get glued together because "hail react" and all of a sudden, your piece of crap software, all though it drains all of my battery, works, and this is a good thing?

blakehaswell 5y ago

> great speed in iterating new features […] makes our customers happy For me this is a leap. I can't think of many examples of software which I use where new features have actually made me happy. Normally it's just change which forces me to learn something new while I'm in the middle of trying to accomplish something actually productive. I think our industry over-estimates the value of "new features". But in my experience 90% of new features provide neutral or negative value. If—instead of a new feature—the software I used released a performance improvement, then that would actually help make me more productive.

PeterWhittaker 5y ago
I don’t mean new features in the frameworks, our customers don’t care (and don’t know what frameworks we use, AFAIK). They care about the features in our products and the frameworks we use allow us to do cool fast.
cerved 5y ago
there are lots of publicly available feedback channels, should be possible to verify your hypothesis

chmod775 5y ago

> My company does complex cloud and on-prem web-based apps, JS front and back. Then you've certainly run into power users. Chances are browsers can load and display a 2MB server-generated HTML table faster than the DI system in your 5 MB angular app can start all the required services to be ready to launch your pagination component. However once it is ready it may be quickly apparent that users would be much more productive using that giant table and CTRL+F than a laggy angular app that would struggle even handling that much data at once in an idiomatic way. Of course I am making this up to illustrate a point. However I use "one giant HTML table" as a sort of bar to meet when developing in modern frameworks. If with this insanely complicated and large array of tools I can't even do better than that (faster to implement!) competing solution, I might as well not bother. That "a bunch of large server-rendered HTML tables" just so often happen to be the previous solution that was in place, and power users are likely to complain if we do worse, is just the cherry on top. To do better we often have to avoid certain things that would be considered modern. Like not putting lots of empty space in our layout, no server-side search that would introduce too much (pointless) latency compared to client-side, and some un-idiomatic stuff to actually handle large[1] amounts of data without change-detection/updating in our framework of choice eating user's CPUs for breakfast. [1]: The amount of data/elements at which change detection in idiomatic Rust and Angular becomes slow wouldn't have been considered 'large' 15 years ago. Though obviously people then had to put thought into this stuff and it certainly wasn't automatic.

cerved 5y ago
I want all my data in a gigantic HTML table, said no user ever
- fake-name 5y ago
  Hi. I'd love this. I'm a user.
reboog711 5y ago
> in your 5 MB angular app Related anecdote: I just did a production build of the Angular 13 app I'm working on and it was 686K. That includes all the Angular framework, and a component library which includes a data table.
- chmod775 5y ago
  Well. Good work then! Your build is half the size of twitch.tv's vendor.js. If you go on their front page, then click a stream, your browser will have loaded around 15MB of JS (~3.4MB over the wire). To be fair they're a video streaming service so they probably don't care about a few extra megabytes here and there, but on lower spec'd hardware you'll feel all that JS: a solid 5s of CPU time just spent executing JavaScript on my thinkpad during that test, not including the time to load it. And it's not like they're done. If you then do pretty much anything, it'll have to load even more. Apparently if you click a name in chat, it has to load another 998.96KB JS file (features.chat.components.viewer-card-*.js) to render those tiny cards that contain maybe 50 bytes of information. That's a good bit larger than your entire application! There's operating systems that fit in less than what twitch needs to show a glorified tooltip. On my hardware they could probably boot in that time too.
PeterWhittaker 5y ago
Well, if our apps resembled these large tables of which you speak, maybe…. :-) Our apps are related to compliance and risk management with a good sprinkling of custom developed workflow. Most of the screens users see are fairly light. It isn’t the amount of data that matters to our users, it’s what we do with it. And how quickly we can new things when they realize they need new.

kreeben 5y ago

>> These inefficient frameworks make our developers more productive and allow us to design, deliver, and fix fast. This is good for humanity, how? You hire a bunch of n00bs that can't work together so you separate their code into small chunks of absolute crap that get glued together because "hail react" and all of a sudden, your piece of crap software, all though it drains all of my battery, works, and this is a good thing?