>I would personally consider it less hacky to represent the comment tree as a tree of nested list elements in the HTML in the first place. I just don't get this fear of `<li>`.
Apparently pg did it in part to be "unPC" in regards to HTML. (see the linked quote in the 'inline javascript' thread[0].) It is weird that, in the name of exploratory programming, he chose the most complicated and finicky layout imaginable just to stick it to the W3c and their rules, man.
Fortunately, I think Anarki is already moving in the right direction. Table layout should be almost entirely removed (I think polls still use it) and I've been adding css classes and IDs to make the HTML more amenable to scripting. Unfortunately, this means we can't really use anything from HN without rewriting it. There's still a bit more work to do in removing old html like fontcolor, etc.
But the interesting question would be where to store state? HN appears to have endpoints that handle it (?collapse=id) so I assume there is just a list of closed ids for each user somewhere on the server. It could probably also be done with local storage but that wouldn't persist across browsers.
> But the interesting question would be where to store state? [...] It could probably also be done with local storage but that wouldn't persist across browsers.
Cool that you're working on this. Storing state on the server would also allow for it to work w/o JavaScript. (Yes, yes, I know, maybe everyone are not that much into progressive enhancement.)
I'm working on improving the HTML, I don't know when if ever I'll get around to collapsible comments.
I was just pointing out that HN's own implementation is server-side, but doesn't have to be. As with voting, the js just makes changes to the DOM that shadow the actual work on the backend. I have no idea how to do it efficiently, though, since presumably each close/open operation would also mean an http request and possibly a file write.
> I have no idea how to do it efficiently, though, since presumably each close/open operation would also mean an http request and possibly a file write.
Which is the same for voting and page generation.
ie. Right now there's a big cost on the servers because all the work is done on the servers. If you start looking at it from the perspective of not adopting that cost then you might as well say the same for voting + all the html creation and just write the whole thing in js where you only fetch data.
This is the slippery slope that lead me to writing apps in clojurescript. For me, the workload may get increased, but much of the operational costs get distributed across the users and on their hardware.
> Which is the same for voting and page generation. [...] Right now there's a big cost on the servers because all the work is done on the servers.
Yea, I don't think something like checking whether a comment is member of the list of hidden items by a user would really add workload of any significance.
> [...] you might as well say the same for voting + all the html creation and just write the whole thing in js where you only fetch data.
Does that not lead to an awful lot of traffic sometimes? (I'm imagining a version of News that would transmit all submitted content to let the client do the sorting and searching instead of doing it on the server.)
> I don't think something like checking whether a comment is member of the list of hidden items by a user would really add workload of any significance.
I don't think so either. My comment was that "all the work is done on the servers". For the whole app. That is looking at all of the cost in aggregate (every interaction requires a http request, and requires throttling, session handling, authentication, html page generation, and so on....).
> Does that not lead to an awful lot of traffic sometimes? (I'm imagining a version of News that would transmit all submitted content to let the client do the sorting and searching instead of doing it on the server.)
Sure if you fetch all data unsorted, but I wasn't suggesting (or at least thinking) anything like that. I was just suggesting the html creation and many interactions that currently represent at least half if not most of the workload the server operations are currently doing.
> Storing state on the server would also allow for it to work w/o JavaScript.
I agree for this case (surprise, surprise...). This app was/is designed to work without js (mostly). If there's much more of a departure from this design and any real dependancy on js begins, well really the whole app should get re-written.
