5 ms·

I'd like a browser that is just a nice browser. It should fit easily into a few 10s MB and start instantly. It wouldn't waste 100s of MB on implementing dangero

I'd like a browser that is just a nice browser. It should fit easily into a few 10s MB and start instantly. It wouldn't waste 100s of MB on implementing dangerous/pointless/wasteful javascript APIs, like battery state or physical screen APIs; it wouldn't support (literally) 4300 options; wouldn't save 200 MB of config data; and wouldn't load many MB of data just to start and display a blank page!

tbodt 6y ago
For the record, chrome on android is ~60MB, less than half the size of desktop chrome (~150MB). Android chrome supports the same set of javascript APIs. Clearly that isn't the whole picture.
- jan6 6y ago
  I'm preeettty sure that's just because it's relying on the separate WebView app, using WebView is also how it's possible for people to make sub-megabyte android browsers, such as [Naked Browser](https://play.google.com/store/apps/details?id=com.fevdev.nakedbrowser https://play.google.com/store/apps/details?id=com.fevdev.nak...) and [Via](https://play.google.com/store/apps/details?id=mark.via.gp&hl=en https://play.google.com/store/apps/details?id=mark.via.gp&hl...) *correction, according to https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...
  - tomgaga 6y ago
    Actually, you can select which Chrome to use for the Webview in Android developer settings if you have Installed multiple versions of Chrome. Chrome stands on its own.
  - tbodt 6y ago
    I measured Trichrome, which is the separate APK where the actual rendering engine is stored.
- arghwhat 6y ago
  So Chrome for Android is 10MB larger than the entirety of Damn Small Linux, which includes a desktop environment with three web browsers (firefox, dillo and netrik). While 60MB is still humongous, it does make sense that Google would at least care slightly on Android, as the majority of the Android market are low-to-mid-tier smartphones with reasonable performance instead of the "desktop-in-a-pocket" that are the current flagship phones. But while they care slightly on Android, they don't care at all on desktops. Remember kids: Large binaries are slow binaries.
  - anthk 6y ago
    >Large binaries are slow binaries. False. Loop unrolling is always faster.
    - JoeAltmaier 6y ago
      Depends largely on the state of code caches, microcode and bus structure. Loop unrolling can be the worst thing you can do, on some architectures. See, the hardware folks have listened in on the compiler people and their problems. They've done things like identify loops and rewritten them in microcode for optimization. If a short loop can fit entirely within the CPU code buffer, speed goes way up. Unroll the loop and blow the CPU code buffer, defeat the optimization and lose all that.
    - arghwhat 6y ago
      > False. Loop unrolling is always faster. Blatantly false, which is why heuristics decide when to unroll. Large code trashes instruction caches, and cache misses are very expensive. More code, more misses. For very small loops, the unroll can pay off, but these are often too small to have significant size detriment.
  - tbodt 6y ago
    Firefox on my mac is over 200MB. Is it smaller on Damn Small Linux? And yes, there is clearly only an incentive to care on Android. The automated tooling to track Chrome binary size only works on the Android build.
userbinator 6y ago
Dillo/NetSurf may be of interest to you. They fit the size requirement as well as the "lack of JS" requirement (i.e. no JS support at all). "appsites" will definitely not work in them, but the document-oriented web and things like HN are fine.
- bArray 6y ago
  I've used Dillo, but unfortunately most web pages are seriously malformed. Would be nice if it was possible to get some better CSS support. I would like to see better JS support, but the scope of JS is simply insane for such a small browser. It's unfortunate much of the web is completely unusable without running JS. Perhaps it's possible to first run the page through a larger browser engine and then send the processed content to the small browser (such as Dillo), that would massively widen the scope of what it could display.
  - anthk 6y ago
    Use dillo from HG, it has better CSS support. >But the scope of JS is simply insane for such a small browser. Edbrowse has JS support thanks to duktape.
    - bArray 6y ago
      > Use dillo from HG, it has better CSS support. Here? https://hg.dillo.org/dillo/ https://hg.dillo.org/dillo/ Seems to be still pretty old... > Edbrowse has JS support thanks to duktape. Huh, very interesting: https://duktape.org/ https://duktape.org/ I initially assumed by ducktape you meant "barely held together"!
stjohnswarts 6y ago
what you want isn't possible with the web being like MTV and moving far beyond it's original intention. The best you can get is get one of the small browsers and live with broken pages. Some people do just that. I think you should be think in terms of relativity though. Think about how much a "10 MB" only browser took up in main memory back in the day.
- bArray 6y ago
  > I think you should be think in terms of relativity though. > Think about how much a "10 MB" only browser took up in main > memory back in the day. This is exactly the point, software has swelled to use the resources available to it, so with each new iteration your machine gets faster but what it runs gets slower. It doesn't feel like this is something we should settle for.

tbodt 6y ago

For the record, chrome on android is ~60MB, less than half the size of desktop chrome (~150MB). Android chrome supports the same set of javascript APIs. Clearly that isn't the whole picture.

jan6 6y ago
I'm preeettty sure that's just because it's relying on the separate WebView app, using WebView is also how it's possible for people to make sub-megabyte android browsers, such as [Naked Browser](https://play.google.com/store/apps/details?id=com.fevdev.nakedbrowser https://play.google.com/store/apps/details?id=com.fevdev.nak...) and [Via](https://play.google.com/store/apps/details?id=mark.via.gp&hl=en https://play.google.com/store/apps/details?id=mark.via.gp&hl...) *correction, according to https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview they are still separate, it references android L dev preview so not the latest source tho...
- tomgaga 6y ago
  Actually, you can select which Chrome to use for the Webview in Android developer settings if you have Installed multiple versions of Chrome. Chrome stands on its own.
- tbodt 6y ago
  I measured Trichrome, which is the separate APK where the actual rendering engine is stored.
arghwhat 6y ago
So Chrome for Android is 10MB larger than the entirety of Damn Small Linux, which includes a desktop environment with three web browsers (firefox, dillo and netrik). While 60MB is still humongous, it does make sense that Google would at least care slightly on Android, as the majority of the Android market are low-to-mid-tier smartphones with reasonable performance instead of the "desktop-in-a-pocket" that are the current flagship phones. But while they care slightly on Android, they don't care at all on desktops. Remember kids: Large binaries are slow binaries.
- anthk 6y ago
  >Large binaries are slow binaries. False. Loop unrolling is always faster.
  - JoeAltmaier 6y ago
    Depends largely on the state of code caches, microcode and bus structure. Loop unrolling can be the worst thing you can do, on some architectures. See, the hardware folks have listened in on the compiler people and their problems. They've done things like identify loops and rewritten them in microcode for optimization. If a short loop can fit entirely within the CPU code buffer, speed goes way up. Unroll the loop and blow the CPU code buffer, defeat the optimization and lose all that.
  - arghwhat 6y ago
    > False. Loop unrolling is always faster. Blatantly false, which is why heuristics decide when to unroll. Large code trashes instruction caches, and cache misses are very expensive. More code, more misses. For very small loops, the unroll can pay off, but these are often too small to have significant size detriment.
- tbodt 6y ago
  Firefox on my mac is over 200MB. Is it smaller on Damn Small Linux? And yes, there is clearly only an incentive to care on Android. The automated tooling to track Chrome binary size only works on the Android build.

userbinator 6y ago

Dillo/NetSurf may be of interest to you. They fit the size requirement as well as the "lack of JS" requirement (i.e. no JS support at all). "appsites" will definitely not work in them, but the document-oriented web and things like HN are fine.

bArray 6y ago
I've used Dillo, but unfortunately most web pages are seriously malformed. Would be nice if it was possible to get some better CSS support. I would like to see better JS support, but the scope of JS is simply insane for such a small browser. It's unfortunate much of the web is completely unusable without running JS. Perhaps it's possible to first run the page through a larger browser engine and then send the processed content to the small browser (such as Dillo), that would massively widen the scope of what it could display.
- anthk 6y ago
  Use dillo from HG, it has better CSS support. >But the scope of JS is simply insane for such a small browser. Edbrowse has JS support thanks to duktape.
  - bArray 6y ago
    > Use dillo from HG, it has better CSS support. Here? https://hg.dillo.org/dillo/ https://hg.dillo.org/dillo/ Seems to be still pretty old... > Edbrowse has JS support thanks to duktape. Huh, very interesting: https://duktape.org/ https://duktape.org/ I initially assumed by ducktape you meant "barely held together"!

stjohnswarts 6y ago

what you want isn't possible with the web being like MTV and moving far beyond it's original intention. The best you can get is get one of the small browsers and live with broken pages. Some people do just that. I think you should be think in terms of relativity though. Think about how much a "10 MB" only browser took up in main memory back in the day.

bArray 6y ago
> I think you should be think in terms of relativity though. > Think about how much a "10 MB" only browser took up in main > memory back in the day. This is exactly the point, software has swelled to use the resources available to it, so with each new iteration your machine gets faster but what it runs gets slower. It doesn't feel like this is something we should settle for.