3 ms·

It is the present. We try to maximise the features and reduce the cost. For example, no one develops apps in assembly by hand anymore, it’s not productive. 130

It is the present. We try to maximise the features and reduce the cost. For example, no one develops apps in assembly by hand anymore, it’s not productive. 130kB minified is nothing unless you make an app for people in Africa or very remote parts of the world. It is cached and is loads instantly on most connections. Check the network speeds of your users, it’s very likely more than fast enough to load a 130kB file once. https://en.m.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds https://en.m.wikipedia.org/wiki/List_of_countries_by_Interne...

Existenceblinks 4y ago
There is a javascript size usage graph yearly .. I don't have a link bookmarked but it's getting insane. Note that 130kB is without starting writing any application.
- speedgoose 4y ago
  Yes no one cares about the JavaScript bundle size until it becomes a problem.
  - 6510 4y ago
    I prefer not to create problems for myself.
    - speedgoose 4y ago
      Sure, but it’s more challenging to keep the bundle size very low for no reasons if you want to use modern tooling and work in a team. It’s fine for your personal hobby website, but people at work shouldn’t waste times and create problems to avoid a small and rare problem.
- randomtwiddler 4y ago
  The amount of friction a designer gets for adding several multi MB images to a page, in every organization I've worked for, is very little. 2 MB minified, compressed, ball of js is nothing. I've even seen companies accidentally put their debug builds in production (>15MB js ball) with without noticing or getting complaints. I'm much more sensitive to page weight than most, and every sizable dev shop should have someone who is. But even I realize that current business reality is it didn't matter nearly as much as sensitive tech people think.
6510 4y ago
You not just count the js framework. All parts of a website contribute to the bloat. Things get exponentially slower for each thing added. I will for example "excessively" test how many images in what resolution I can get away with. Is my json to big? Can I use a custom font? Do I need to start the "infinite" scrolling fiasco? In what order are things loaded? Are we requesting a html document that when parsed has us request a js file? Is its execution delayed by the dom state? Then it parses out html? And then that html requests media that loads lazy? If I would find myself there the 130 kb (and its overhead) would persistently bother me. When I get to it it will get ripped out and replaced with inline vanilla js. It's not just that I want my application to be snappy and appear instantly. I also want to see instant results when testing it. There is no build time. It doesn't exist.
xigoi 4y ago
Are you implying that it's okay for a web app to be unusable by people in remote areas unless it's specifically designed for them?
- speedgoose 4y ago
  It’s not unusable, just a bit slow to load.

Existenceblinks 4y ago

There is a javascript size usage graph yearly .. I don't have a link bookmarked but it's getting insane. Note that 130kB is without starting writing any application.

speedgoose 4y ago
Yes no one cares about the JavaScript bundle size until it becomes a problem.
- 6510 4y ago
  I prefer not to create problems for myself.
  - speedgoose 4y ago
    Sure, but it’s more challenging to keep the bundle size very low for no reasons if you want to use modern tooling and work in a team. It’s fine for your personal hobby website, but people at work shouldn’t waste times and create problems to avoid a small and rare problem.
randomtwiddler 4y ago
The amount of friction a designer gets for adding several multi MB images to a page, in every organization I've worked for, is very little. 2 MB minified, compressed, ball of js is nothing. I've even seen companies accidentally put their debug builds in production (>15MB js ball) with without noticing or getting complaints. I'm much more sensitive to page weight than most, and every sizable dev shop should have someone who is. But even I realize that current business reality is it didn't matter nearly as much as sensitive tech people think.

6510 4y ago

You not just count the js framework. All parts of a website contribute to the bloat. Things get exponentially slower for each thing added. I will for example "excessively" test how many images in what resolution I can get away with. Is my json to big? Can I use a custom font? Do I need to start the "infinite" scrolling fiasco? In what order are things loaded? Are we requesting a html document that when parsed has us request a js file? Is its execution delayed by the dom state? Then it parses out html? And then that html requests media that loads lazy? If I would find myself there the 130 kb (and its overhead) would persistently bother me. When I get to it it will get ripped out and replaced with inline vanilla js. It's not just that I want my application to be snappy and appear instantly. I also want to see instant results when testing it. There is no build time. It doesn't exist.

xigoi 4y ago

Are you implying that it's okay for a web app to be unusable by people in remote areas unless it's specifically designed for them?

speedgoose 4y ago
It’s not unusable, just a bit slow to load.