Looking Forward (open discussion)

[zixaphir]

The more I use Appchan X, the more I realize the inherent limitations of 4chan X as it is now. Although @MayhemYDG X V3 solved many of the complaints I originally had with 4chan X's code (some of which I had fixed myself in the code currently use in Appchan X 1.2.6), it misses the point (not to say my code isn't currently missing the point)

Yes, now we preparse everything and save it all in convenient global objects that we constantly have access to. I appreciate that, yes I do. But we're still sitting in Web 1.0 mentalities, especially in regards to how individual threads are handled.

Why, when a user opens a thread, do we have to load the entire HTML of the thread? We have JSON, we have a JSON post parser, we have several conveniently named containers that we put individual threads and the entire board in that we could simply clear and replace with JSON posts that are preparsed, preprocessed, and ready to present to the user without the overhead associated with loading the entire DOM, collecting every god-forsaken post, and inserting features one-by-one while the document is live. Why are we stuck in the mentality that we need to load the thread's entire page?

Unfortunately, this worldview completely breaks 4chan X. Why? Because 4chan X is written with the explicit expectation that when content switches focus (IE, from a board view to a thread view), the page must be reloaded to load new features, kill old ones, kill and refresh the current configuration, and reload a completely new set of Thread, Post, and various other object variables the script works on. The unnecessary overhead is built into 4chan X at its core, and will need to be rewritten from a paradigm of seamlessness to allow for these changes.

This particular issue would also become a lot simpler to solve with this in mind: https://github.com/zixaphir/appchan-x/issues/122

@seaweedchan @aeosynth @ahodesuka

plz add anyone I missed, I'm bad with remember which people actually care about this stuff.

[zixaphir]

Things that would need to be implemented to allow for seamless browsing:

• [x] Garbage Collection: clearing or pruning posts, threads, and other variables that are aged past a point where they are probably no longer relevant to the current DOM
• [x] Safe unloading of features: We don't want a thread updater on the main page when we switch to the main page from a thread.
• [x] JSON for the board's front page: Although the user will likely initially get to the board page from a direct link, in the case of switching boards or returning to the board page from a thread, we should load the board from JSON.

Also, this would give us a considerable edge over the inline extension by virtue of bandwidth savings, raw performance, and user experience.

[zixaphir]

Also some funny things we could add to help with user experience:

• [x] Breadcrumb: A nice, four or five link history of how the user got to the page they're currently on.
• [x] Throttling: Not all posts need to be parsed and added to the DOM at the same time. By throttling them, we could prevent browser lockup and allow the user experience to be smoother and more consistent, especially in larger threads.
• [ ] Load Last ... Posts: Just load the most recent posts, ala 7chan and the like.
• [x] Endless Pages: Auto-pager, load more threads as we scroll... idk?

[zixaphir]

And just reserving this post for anything that I may have forgotten to add. Any recommendations for things that would need to be done to do this or could be done easier as a result of this would be appreciated.

[vendethiel]

related qqueue/c4#5

[Yttrium-tYcLief]

Another feature I'd like, though it sounds pretty crazy, would be multiple threads on one page.

[zixaphir]

Another feature I'd like, though it sounds pretty crazy, would be multiple threads on one page.

ehhh, possible, but I don't think it would work with the current implementation of the thread updater, and I'm not sure I want it to. It just doesn't seem convenient to me. Maybe you could draw a mockup that could show how this makes sense from an interface perspective?

[zixaphir]

@Nami-Doc: Actually, that clears up a lot of my own concerns with doing this. I mean with URL rewriting and everything.

[Yttrium-tYcLief]

Maybe you could draw a mockup that could show how this makes sense from an interface perspective?

Sure thing, give me a few minutes.

[Yttrium-tYcLief]

Something like this? Post box has two sessions that can be viewed by focusing on each pane. You need to click one to be able to interact with it - not clicking or hovering, but for keyboard bindings and changing the post form viewed.

[zixaphir]

Originally appchan was built on something like that -- that is to say, the thread was focused and scrolled independently of the actual page body. Idk, though, it feels very hacky and probably would break features. I do feel browser tabs accomplish that task a lot better and the only real enhancement over just cascading your windows is the independent post form.

[Yttrium-tYcLief]

My issue with browser tabs is I have too many of them when I have multiple small threads up.

[zixaphir]

I'm just saying, in my experience, it doesn't work very well.

[vendethiel]

why don't you remove inline html from appchan-x ? I find it bad in 4chan-x (I only care about the code; I'm not a 4channer). PS: I love jade, for its syntax et al.

[zixaphir]

@Nami-Doc, I don't understand

[vendethiel]

I find this (among others) pretty horrible :[. that does not belong in the .coffee file

[zixaphir]

innerHTML is faster to generate and easier to read than generating each DOM node individually in most circumstances.

[vendethiel]

Am not talking about DOM manips, that's awful. I'm proposing to put them in their own files. And maybe use an engine, like jade. This is what I meant by "inline html". inline in the code

[zixaphir]

Oh, I see what you mean. Like what we're currently doing with CSS in Mayhem X3 and Av2

[vendethiel]

yep. I'm going a bit further, I use this structure for my userscript :

• src
  • {module name}
  • styles
    • {feature}.styl
  • templates
    • {feature}.jade
  • {feature}.coffee

[zixaphir]

I don't think I want a template engine (coffeescript makes it fairly easy to do most of the things I like to do and I don't want more node dependencies right now), but I do agree that the inline HTML was getting... uhm... ugly. I'll start working on pruning it after I get Av2 stable. (I don't want to delay it too much more than I already have)

[vendethiel]

oh yeah uh, that wasn't my point. Just that it getting some love would be better

[seaweedchan]

Something I'd like would be replacing the catalog toggle link's functionality with loading the board's catalog on the current page, and of course replacing Fappe Tyme with a Gallery Mode.

[zixaphir]

gallery mode

Pretty much

for thumb in $$('.thumb', doc)
  galThumb = thumb.clone true
  $.add container, galThumb
  $.on galThumb, 'click', ImageExpand.cb.gallery

or something, with a container or something and appropriate CSS, and a previous and next button.

Probably not that hard.

[aeosynth]

i've got a gallery mode app at aeosynth/iv, currently blocked b/c fucking keyboard events madness

[aeosynth]

what sort of features are you willing / able to implement from scratch?

[zixaphir]

@aeosynth: whatever I need to to move forward with it.

[zixaphir]

More for me than for anybody else. Not an accurate list by any means, just what I see at a glance.

Features that will need significant work:

• [x] Unread Count - Pretty much need to be able to dynamically kill and revive it
• [x] Thread Updater - same as above
• [x] Index Features - Write them to not depend on 'index' view, be able to temporarily clear a thread and bring it back so we can search the index mid-thread
• [x] Main - uhh... yeah just werkz
• [x] QR (Pretty much need to be able to wipe its state and bring it back every time we navigate

Moderate amount of work:

• [x] Filter? Appears to just werk.
• [x] Thread Hiding Also appears to just werk
• [x] FavIcons
• [x] Comment Expansion? - Since the Index Features happened, we might be able to delete this? Just removing this feature. It isn't even used anymore.
• [x] Expand Thread
• [x] Keybinds? just werk
• [x] Thread Exerpt? - hopefully just disable it on view change?
• [x] Thread Stats? - same as above
• [x] Quote Threading - same as above

(hopefully) Little to no work:

• [x] Header - Seems we just need to change the current board link if we switch boards, probably.
• [x] Navlinks
• [x] Relative Dates - looks like just adding its "flush" method on view change just werkz

Beautifully, most features aren't too heavily reliant on the current view to be functional, and check it as they run, rather than beforehand.

Features that will have to be written:

• [x] Pull the board title / subtitle from JSON and change it on navigation.
• [x] Permalink - I mean, since we're probably not going to be using window.location to navigate anymore. I was wrong, we can use window.location with history.pushState.

I'll update this as I make progress or find more things that need progress.

[seaweedchan]

Filter?

Could be a reason to do https://github.com/seaweedchan/4chan-x/issues/207

Header - Seems we just need to change the current board link if we switch boards, probably.

Not sure what you mean by that exactly but maybe this falls into that? My problem with it now is that when using the custom board list and open up a board that's not on that list, it's not indicated in the custom board list unless you add the current-board-title thing, which seems redundant on boards that ARE on your list.

I dunno how I'd treat that, though. Maybe adding a current-board-title alternative that only shows up when .current isn't found.

I also think there must be a better way we can do the full board list, it's a bit... I dunno, messy the way it is now, at least when toggling it on. I feel like some kind of organized dropdown or something might be better.

[zixaphir]

Yeah, I could poke around the filter code and add an option for that, probably.

Header

I've already got the header code mostly working by regenerating it on Main.navigate (which is the function I've written and am using for most of the management of the new JSON features) when we switch boards.

The current-board-title thing can be mitigated with .current ~ .current { display: none; }

[zixaphir]

More of a note for me than anyone else: still need to figure out how to handle URL hashes so that we can scroll to posts after loading a thread.

[seaweedchan]

Since everything is jsonified anyway, what about a split view feature to have both the index and a thread or two side by side

Oh wait I guess that was basically suggested already

Also would searching in all posts be possible with an option or something?

Also complaints I see so far like in http://boards.4chan.org/g/res/39455805 are that it's noticeably slow for those on slower connections, and that even on unmodified settings (Paged layout, sort by bump) we toss out the original HTML to generate it again.

[zixaphir]

According to Mayhem's comments:

        $.replace board, Index.root
        # Hacks:
        # - When removing an element from the document during page load,
        #   its ancestors will still be correctly created inside of it.
        # - Creating loadable elements inside of an origin-less document
        #   will not download them.
        # - Combine the two and you get a download canceller!
        #   Does not work on Firefox unfortunately. bugzil.la/939713
        d.implementation.createDocument(null, null, null).appendChild board

[zixaphir]

Note to self: backlinks seem to be doubling up for no reason now.

[zixaphir]

And backlinks problem resolved.

It was nothing like I thought it was. D: