[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]

/operate/ - 8chan Operation & Discussion

This board is for reaching the global administrators and volunteers. General 8chan Meta discussion is also allowed.

Catalog

Email
Comment *
Verification *
File
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options
Password (For file and post deletion.)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf, swf, pdf
Max filesize is 8 MB.
Max image dimensions are 10000 x 10000.
You may upload 5 per post.


Please check the stickies before making a new thread.
Please email admin@8chan.co for reporting illegal content or reporting security issues with 8chan.
Remember: All boards on 8chan are operated independently by individual board owners.
8chan bug tracker (Github) | 8chan FAQ (how to post, etc) | 8chan status blog (Twitter)
/operate/s 2ch version | 2channel bulletin board | pink channel
...
Recommended Boards (?)
8chan Newspaper Bunbunmaru | Imageboard Culture | 8chan Directory | 8chan Boards
Featured Boards (?)
Cyberpunk & Science Fiction | alternatif_kanal | snoutposting lair | Vidya Game Lounge | Music Production

File: 1453877503388.jpg (29.42 KB, 400x300, 4:3, javascript_hipster.jpg)

f5a4b9 No.46222

Has an idea like this been looked into to solve some of 8ch's problems?

- Use Redis patch, or similar in-memory cache

- Threads and posts only exist as JSON.

- Don't build pages ever again. API endpoints are the replacement.

- Turn frontend into a semi-SPA. Starting off, it can just be a really shitty document.write() mess where a giant string containing HTML is built up from the JSON. This will give it 1-to-1 parity with existing 8ch, and will also be quite fast, though not very maintainable. Can be improved later, perhaps to use a hipster library like Vue or Mithril or React.

- localStorage, maybe Web SQL, is used to locally cache thread JSON, and is updated when the API reports a new post or index/catalog change

- Server's job is to manage cache and respond with updates when there are any

- Could serve only the new posts, or re-serve the entire JSON document for a thread. Not sure which would be faster/better.

Downsides:

- Have to add a fair bit more code to handle caching and make sure cache expiry and refresh is done sanely

- Have to write a bit more JS

- Large threads may load a little more slowly for users since clients will be loading them dynamically, especially on mobile and old devices

- Doesn't really fix other fundamental issues with vichan, but those can be fixed at a more relaxed pace in the future once scalability is improved

- Trading disk IO for frequent cache refresh polling and more concurrent connections (if written in nginx config language or Lua, this can be done insanely fast)

- Tinfoil hatters who refuse to enable Javascript or whitelist it here won't be able to use the site. Maybe the old HTML file building could be a fallback here.

Upsides:

- Scaling should be far easier and cheaper. No more 5 trillion .html files lying around. No more Twig, except for the mod pages and a few minor things.

- Can lead to a much nicer UI once the SPA features are fleshed out

For additional performance, you could bypass PHP and have nginx do most or all of the cache management and API response for you.

I don't know if this is the best option. I think a full rewrite or switching to Lynxchan would be a big mistake. I think a rewrite is maybe not a bad idea for the distant future, but PHP and Laravel weren't the right choices. vichan's internals suck, but in terms of features it's the most mature software out there, and the code isn't so abhorrent that it can't be hacked on (unlike Kusaba X or something).

I posted these suggestions during Infinity Next's announcement thread a while back and said it seemed like a bad idea, but was largely ignored.

I'd be willing to help with a patch to add some of these features if HW shows serious interest in the idea.

f5a4b9 No.46223

test.


d33314 No.46282

feels like it's going to need way more cpu power from the end-user, which is a bad thing.


f5a4b9 No.46284

>>46282

It wouldn't. Rendering some basic shit with Javascript isn't that performance-consuming, as long as some massive framework isn't used.

However, Javascript is still required, which many users wouldn't agree with. So the plan probably isn't tenable.


f0f2aa No.46447

>>46222

Yup, sounds like FutaBilly




[Return][Go to top][Catalog][Post a Reply]
[]
[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]