6 ms·

This has nothing to do with bloat. While unimpressive not to be able to open files larger than 2MB, it's easy to see how and why such a limit came about, and as

This has nothing to do with bloat. While unimpressive not to be able to open files larger than 2MB, it's easy to see how and why such a limit came about, and as Atom seems to be styled as a text editor for programming, not really unreasonable, as very few human-created text documents get anywhere near 2MB.

nightski 11y ago
Sorry, it's not obvious at all how the limit came about. That is pretty terrible.
- manigandham 11y ago
  Atom is a desktop/native wrapper around browser-like internals. The stuff inside is all just HTML/javascript/css running on node. There are some neat advantages, as well as just seeing how far a web interface for a desktop app can go. The limit came about because trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. It was just a hard problem to solve, having an HTML-based editor deal with so much text at once.
  - rplnt 11y ago
    > trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. I'd love to test that. Anyone willing to privide an example file? HTML with css perhaps, no js. Should be pretty small when zipped.
    - icebraining 11y ago
      Assuming you don't need anything complex, it's pretty easy to generate it. Here's a 100MB HTML file (compressed to 300KB): https://curl.io/get/yt7zbmfq/0eb1564f570236acf1d9f304855a7c79d4346fa9 https://curl.io/get/yt7zbmfq/0eb1564f570236acf1d9f304855a7c7... As a side note, VIM opens it in an instant /troll
  - userbinator 11y ago
    The limit came about because trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. I remember opening HTML files in that size range (they were logs) in IE6 around a decade or more ago, on a machine with <1GB of RAM, and it handled them just fine - there was a noticeable delay, but it wasn't unusable. Even searching for strings worked.
- mseebach 11y ago
  It is obvious to me: I think they chose to load, parse, prettify, colour etc. and keep the entire file into an in-memory data structure, which is easy to reason about, and totally reasonable for "human sized" data. However, for arbitrary sized files, you need a mechanism for leaving most of the file in a raw state - that's harder (but not impossible, obviously). So, it makes sense to me that they would assume only "human sized" data (and expect users to use another tool for looking at large files, "do one thing well" and all that) and opt for a slightly simpler programming model. Apparently, they decided that the assumption was wrong, and so changed the model.
dagw 11y ago
very few human-created text documents get anywhere near 2MB. True, but as a programmer i very often generate and need to view files greater than 2MB.
- errtnsd 11y ago
  This. Not to mention log files which commonly consume megabytes.
  - bradleyland 11y ago
    Nitpick inbound. You shouldn't open log files with an editor unless your intent is to edit the file. There are a whole host of tools (grep, less, awk, sed, etc) useful for parsing and exploring log files.
- mseebach 11y ago
  You also very often do X, but that doesn't mean your programming text editor is the correct tool for doing X. Insisting on all tools having an X because X is a useful thing is how you get the very bloat the GP is talking about.
  - lolhackernews 11y ago
    On the other hand, virtually every other editor is the correct tool to do that task, yet this one is not. Are we supposed to accept that?
andrewchambers 11y ago
2MB is 0.025 percent of my ram, I shudder to think how much ram is actually being used by atom... At least the html looks pretty.
userbinator 11y ago
The biggest problem I see is that this is an artificial, arbitrary hard-coded limit: https://github.com/atom/atom/commit/ec65a71d6dc8c3c44cb1b77a6cff09e9da39ccac https://github.com/atom/atom/commit/ec65a71d6dc8c3c44cb1b77a... If I have 64GB of RAM, I expect my applications to be able to use all of it when asked to, and not just give up completely. It's fine to slow down, and giving a warning "Opening large files may be slow. Do you want to continue?" would be nice, but working with a 2097151-byte file and giving up if it's 2097152 bytes is really unpleasant.

nightski 11y ago

Sorry, it's not obvious at all how the limit came about. That is pretty terrible.

manigandham 11y ago
Atom is a desktop/native wrapper around browser-like internals. The stuff inside is all just HTML/javascript/css running on node. There are some neat advantages, as well as just seeing how far a web interface for a desktop app can go. The limit came about because trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. It was just a hard problem to solve, having an HTML-based editor deal with so much text at once.
- rplnt 11y ago
  > trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. I'd love to test that. Anyone willing to privide an example file? HTML with css perhaps, no js. Should be pretty small when zipped.
  - icebraining 11y ago
    Assuming you don't need anything complex, it's pretty easy to generate it. Here's a 100MB HTML file (compressed to 300KB): https://curl.io/get/yt7zbmfq/0eb1564f570236acf1d9f304855a7c79d4346fa9 https://curl.io/get/yt7zbmfq/0eb1564f570236acf1d9f304855a7c7... As a side note, VIM opens it in an instant /troll
- userbinator 11y ago
  The limit came about because trying to open a 100MB file as an html page (even without all the extra styling and interactive options) will break any browser. I remember opening HTML files in that size range (they were logs) in IE6 around a decade or more ago, on a machine with <1GB of RAM, and it handled them just fine - there was a noticeable delay, but it wasn't unusable. Even searching for strings worked.
mseebach 11y ago
It is obvious to me: I think they chose to load, parse, prettify, colour etc. and keep the entire file into an in-memory data structure, which is easy to reason about, and totally reasonable for "human sized" data. However, for arbitrary sized files, you need a mechanism for leaving most of the file in a raw state - that's harder (but not impossible, obviously). So, it makes sense to me that they would assume only "human sized" data (and expect users to use another tool for looking at large files, "do one thing well" and all that) and opt for a slightly simpler programming model. Apparently, they decided that the assumption was wrong, and so changed the model.

dagw 11y ago

very few human-created text documents get anywhere near 2MB. True, but as a programmer i very often generate and need to view files greater than 2MB.

errtnsd 11y ago
This. Not to mention log files which commonly consume megabytes.
- bradleyland 11y ago
  Nitpick inbound. You shouldn't open log files with an editor unless your intent is to edit the file. There are a whole host of tools (grep, less, awk, sed, etc) useful for parsing and exploring log files.
mseebach 11y ago
You also very often do X, but that doesn't mean your programming text editor is the correct tool for doing X. Insisting on all tools having an X because X is a useful thing is how you get the very bloat the GP is talking about.
- lolhackernews 11y ago
  On the other hand, virtually every other editor is the correct tool to do that task, yet this one is not. Are we supposed to accept that?

andrewchambers 11y ago

2MB is 0.025 percent of my ram, I shudder to think how much ram is actually being used by atom... At least the html looks pretty.

userbinator 11y ago

The biggest problem I see is that this is an artificial, arbitrary hard-coded limit: https://github.com/atom/atom/commit/ec65a71d6dc8c3c44cb1b77a6cff09e9da39ccac https://github.com/atom/atom/commit/ec65a71d6dc8c3c44cb1b77a... If I have 64GB of RAM, I expect my applications to be able to use all of it when asked to, and not just give up completely. It's fine to slow down, and giving a warning "Opening large files may be slow. Do you want to continue?" would be nice, but working with a 2097151-byte file and giving up if it's 2097152 bytes is really unpleasant.