5 ms·

Should we also force our users to download a 30mb update every week? Just to really emulate the native app experience!

by arkanciscan 7y ago

twobat 7y ago
This linked page alone has 10 MB.
- 72deluxe 7y ago
  Insane and grotesque! Think of all the CPU cycles on all hardware (clients + network devices) and energy used just to fetch web "content" these days. Might as well return to just burning coal at home to keep warm, thinking of the net effect on the environment. It's absolutely stupid.
  - smoe 7y ago
    And all the people who don't have $500+ phones, unlimited data plans and fast internet connections. I used a ~$50 android and pre-paid plans for over a year while traveling Latin America. Wast swaths of the internet are basically inaccessible unless you have tremendous patience and nerves as well as leftover money to throw at the ISPs.
- jgalt212 7y ago
  It fits with Linus's MO of making videos of how to build computers and systems 10-100X more powerful than you need.
mhd 7y ago
The neat thing about modern SPAs backed with your average feature-flagged CI/CD setup is that you're getting a new 30 mb download each time.
- kreetx 7y ago
  I belive you but could you elaborate for those who don't know what you mean? :)
  - arkanciscan 7y ago
    I think they are talking about bundling before code-splitting (like we did back in the Browserify days) and that's true, but we have Webpack, or ESModules now.
  - nothrabannosir 7y ago
    Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache of the entire app at every payload. Imagine having to download an app update every time someone merged to master. That’s most SPAs.
    - arkanciscan 7y ago
      In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.
      - mhd 7y ago
        Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed). Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
        arkanciscan 7y ago
        Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().
TheRealSteel 7y ago
Well it's a modern web page so it's 30mb every time you load it
- arkanciscan 7y ago
  Browsers have caches

Should we also force our users to download a 30mb update every week? Just to really emulate the native app experience!

twobat 7y ago

This linked page alone has 10 MB.

72deluxe 7y ago
Insane and grotesque! Think of all the CPU cycles on all hardware (clients + network devices) and energy used just to fetch web "content" these days. Might as well return to just burning coal at home to keep warm, thinking of the net effect on the environment. It's absolutely stupid.
- smoe 7y ago
  And all the people who don't have $500+ phones, unlimited data plans and fast internet connections. I used a ~$50 android and pre-paid plans for over a year while traveling Latin America. Wast swaths of the internet are basically inaccessible unless you have tremendous patience and nerves as well as leftover money to throw at the ISPs.
jgalt212 7y ago
It fits with Linus's MO of making videos of how to build computers and systems 10-100X more powerful than you need.

mhd 7y ago

The neat thing about modern SPAs backed with your average feature-flagged CI/CD setup is that you're getting a new 30 mb download each time.

kreetx 7y ago
I belive you but could you elaborate for those who don't know what you mean? :)
- arkanciscan 7y ago
  I think they are talking about bundling before code-splitting (like we did back in the Browserify days) and that's true, but we have Webpack, or ESModules now.
- nothrabannosir 7y ago
  Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache of the entire app at every payload. Imagine having to download an app update every time someone merged to master. That’s most SPAs.
  - arkanciscan 7y ago
    In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.
    - mhd 7y ago
      Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed). Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
      - arkanciscan 7y ago
        Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().

TheRealSteel 7y ago

Well it's a modern web page so it's 30mb every time you load it

arkanciscan 7y ago
Browsers have caches