https://www.reddit.com/r/factorio/comments/16ja44x/friday_fa...

Well, assuming they haven't changed their plans in the year since, and won't in the next few months.

But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.

A better case for infinite scrolling would be chat history, where you'd want an entirely separate UI widget for "jump to date", with bidirectional infinite scroll that unloads distant content, and a way to grab permalinks. Missing any one of those features, or the fact that messages will never be re-ordered for marketing purposes, infinite scrolling becomes a hinderance.

But only the big sites like google have enough users to birthday-paradox their way into a meaningful ID graph, so you're safe from that tiny ad startup that also happens to be threatening google's business model...

IMO much of that could be fixed with a JSON derivative that allows optional type identifiers before values. While you're there, guarantee support for comments and trailing commas, because despite design ideals, humans will write JSON manually, even using JSON for configuration files that are expected to be hand-modified!

No, I used to be a notepad user (on personal projects, not shared work) (you can kinda see it in the use of indentation to help convey information that IDEs would use font or colour to emphasize), and these days use tabs but longingly wish Eclipse, etc. had more options in their already-massive formatting configuration dialogues.

Thing is, few if any IDEs support the concept, so if I want to have half-indents, I must use spaces. Unfortunately, these days that means giving up and using a more common indent style most of the time, as the extra bit of readability generally isn't worth losing automatic formatting or multi-line indent changes.

When you look into it, while ESR says he's using JSON, he's really using a custom format that is readable by typical JSON libraries, but his format has very strict limitations, and his implementation is designed to error out early, rather than parsing an entire 10MB object tree before handing anything back to the application. He does not acknowledge this inconsistency in the article, only mentioning it late in the comment section.

Extensibility is valuable, but does that mean the format should support '"position": {"x":5,"y":[7.2,"XXIV"],"font-face":"Comic Sans"}', where every single object can have arbitrarily-many unrelated fields inserted? HTTP is better, with a flat key-value list, but if you build on top of HTTP itself, you now do not know if any of the systems on the network or libraries used might respond strangely to some obscure old header.

Personally, I think transmitting integers as text is at best rude, and somewhat comparable to Java allowing any reference to be null: Every client now has to handle an extra error condition on every parse. With binary integers, every bit pattern is valid, so you can perform a single range check to handle every type of bad input. Use 0x1234 as a magic number somewhere, and endianness errors are trivially debugged from a single sample packet.