3 ms·
It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies
by handrous 5y ago
It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
- wonnage 5y agoEspecially with graphql being the new hotness I wonder if it's time to replace JSON with a binary format like Thrift. The old argument was that REST+JSON was simple and easy to debug but that goes out the window with GQL anyway. JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
- RedShift1 5y agoIf you were sending HTML those copies and parsing would be there anyway?
- Dylan16807 5y agoEven so, if we look at gmail all the data needed for the email list is 20-100KB. The bloat is caused by bad design, not the extra copies.
- pdimitar 5y agoWhen 99% of all SPAs I ever used are that painfully slow (sometimes even on 4G) then obviously that way of work encourages people to make bad design. So we should uproot the problem and not dance around it.