[HN Gopher] Show HN: Minimal, no-JS web forum software
___________________________________________________________________
Show HN: Minimal, no-JS web forum software
Hello HN! I've found my SQL knowledge to be lacking, so I made a
project that uses SQLite as a backend. As it is intended for self-
hosting I aim to make it easy to set up and maintain. Getting it up
& running takes no more than a few commands (bar setting up a proxy
such as nginx, which is out of scope). I've set up a "demo" site
at https://forum.agreper.com/ if you want to try out the UI.
Author : demindiro
Score : 232 points
Date : 2022-10-10 16:09 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sh4nks wrote:
| Nice! I built one with Flask as well :-)
| tiffanyh wrote:
| I commend you for hand rolling it all and not using JS.
|
| I miss the days of good ole forum software (e.g. FluxBB/PunBB)
| before it was superseded with massive JS bloat/clunky forum
| software like Discourse, Flarum, etc.
| onlyrealcuzzo wrote:
| The point of no-js is mainly to avoid client-side tracking,
| right?
|
| Can't you do a lot of that with CSS?
| INTPenis wrote:
| I loved PunBB. 18 years ago at my first IT job I actually stole
| PunBBs design to make the control panel for our web hosting
| company. Nobody knew because even then punbb was kinda
| esoteric.
| fuzzy2 wrote:
| I actually believe vBulletin 3 is where it's at!
|
| With modern forums, it's mostly the UX that sucks. PWAs that
| never recover from errors, endless scrolling, stuff like that.
| Also
|
| * Falsehoods forum developers believe about network reliability
| - did you know the network can be down? Then up again?
|
| * Falsehoods forum developers believe about time - did you know
| that time can jump forward, by huge amounts, because the page
| was suspended for whatever reason?
|
| Turns out, if you try to do the browser's job, that's a lot of
| work! Just don't.
|
| Performance is usually good enough for me, even with all the JS
| and whatnot.
| snek_case wrote:
| Why do people hate endless scrolling so much?
| quickthrower2 wrote:
| Terrible user experience. If it infinitely scrolls I can be
| sure some gesture on the phone will lose my spot and it
| will take ages to find where I was. Also they rarely play
| nice with the back button. There is usually a better way to
| present data.
|
| For reading, do you prefer books or ancient scrolls?
| gcanyon wrote:
| Apollo (reddit client on iOS) solves this by having the
| same gesture undo itself -- tap at the top to scroll to
| the top of the reddit post, tap again to return to where
| you were.
|
| I'm not saying your complaint is invalid, just that there
| are ways of mitigating the issue. And that said, I can't
| imagine how reddit threads would work if paginated.
| NoraCodes wrote:
| > I can't imagine how reddit threads would work if
| paginated.
|
| Presumably similarly to HackerNews threads, which are
| paginated.
| quickthrower2 wrote:
| Yes. Pagination can be bad if the URL indexes by 1-10,
| 11-20 etc. But I think HN paginates using the post ID, so
| that the links are permanent (?) which is a better way to
| do it. Basically the novel idea here is to treat the
| browser like a REST client.
|
| This also means you need a predictable, deterministic
| algorithm, like "ORDER BY DATE DESC", but Reddit does
| have order by popularity, so that will not be idempotent.
| But now being super picky as order by popularity is
| pretty useful. Although I think date should be the
| default. And order by [what cambridge analytica-likes
| know about me] should be off.
| quickthrower2 wrote:
| Sounds reasonable. I am complaining about infinite scroll
| on the web. But inside a native app it might be better
| since there is more precise control of that experience.
| Assuming the app creator has done a good job.
| skilled wrote:
| And you love it, _so much_? It 's probably the stupidest
| thing ever invented as far as UX goes.
| diab0lic wrote:
| It is possible the gp post just feels neutral about it.
| There are a whole range of emotions between love and
| hate.
| snek_case wrote:
| I do feel neutral/indifferent about it. I was just
| wondering why I see so much negative sentiment towards
| it.
| protomikron wrote:
| It often breaks the builtin Browser-Search.
| kitsunesoba wrote:
| Which is often followed by attempts to replace browser
| native Find in Page with a custom implementation that
| doesn't work as well.
| paulryanrogers wrote:
| Impossible to jump pages, know how much there is, often
| breaks native scrolling in awkward ways without recourse.
| luispauloml wrote:
| Someone posted this on HN last month and I think it
| summarizes very well what people dislike the most about
| infinite scrolling:
| https://news.ycombinator.com/item?id=32789617
| chillfox wrote:
| It makes it impossible to get to the footer.
| whartung wrote:
| Because it's like swimming across a large lake finding
| yourself exhausted in the middle with little alternative to
| swimming back.
|
| Now on my phone it's relatively easy to jump to the top of
| the page. It's also almost done impossible to jump to the
| bottom.
|
| On a desktop I can at least mash the END key or play silly
| reindeer games with the scrollbar thumb.
|
| On mobile it's very hard to Leap or Surge or Jump.
|
| If I'm madly fanning the page with my thumb or, worse, my
| fingers because I'm tired with my thumb, I pretty much just
| give up at that point.
|
| I also like having non-endless scrolling because I can use
| the scroll bar as a gauge of how much is left of the
| article.
|
| Being constantly fed is just a bad experience.
| ratww wrote:
| Well, first, it's not reliable. If the network goes down
| and it doesn't have some form of recovery, you gotta start
| from scratch. Second, it's not bookmarkable (except for the
| odd case), so you can't send specific pages to anyone, you
| often can't start navigating in it one day and continue on
| other, or in another device. Third, you lose navigation and
| exploration features, like navigating to the first page and
| seeing the oldest stuff, or going into the middle.
|
| But the biggest reason people hate as a matter principle is
| because it is in 99% of cases done without any UX research
| and without any care from developers, and that's in the
| best case. The worst case is to cause doomscrolling, which
| is nefarious in its own.
|
| It is disrespectful to users. If you don't want people
| seeing old content just fucking delete it.
| tiffanyh wrote:
| > I actually believe vBulletin 3 is where it's at!
|
| Curious, what about vBulletin v4 and v5 do you not like?
| Ralfp wrote:
| Developers of vB 3 left the company and started new forum
| software named XenForo. They were then sued by Internet
| Brands (vB owners) for IP theft - IB claimed XenForo was
| next vBulletin. In court hearings we've learned that IB
| plan for vBulletin development was to fire all but lead
| dev, and have this lead dev only delegate and review work
| to outsourced devs in Asia. We've also heard that ,,only
| developers care about quality of code" and trying to keep
| code good is ,,waste of time".
|
| And then vB 4 landed and turned out to be insanely poor
| launch - forum index was plugin based, but it was very easy
| to end with index page that did 700 mysql queries, which
| took forever to execute without relying on full page cache
| like varnish.
|
| Today its supposedly much better, but Internet Brands uses
| internal version of vBulletin 3 (3.8) to run their sites
| instead of v4 or v5.
| fuzzy2 wrote:
| It's just the feeling! :-)
|
| vBulletin 4 was also okay in the end, but I always thought
| vBulletin 5 was trying to be too many things at once. It's
| just too modern! I understand, of course, that the online
| community landscape has changed since back then and
| vBulletin has to adapt to remain competitive.
| LinuxBender wrote:
| For what it's worth, phpBB still _sortof_ supports having
| javascript disabled [1] but it is nowhere near as lightweight
| as the example here created by demindiro.
|
| I also commend demindiro on not requiring JS. It is refreshing
| to see simple yet useful applications.
|
| [1] - https://www.phpbb.com/community/viewtopic.php?t=2106245
| FunnyLookinHat wrote:
| I also miss the days of good ole server-side rendered
| applications. I'm not sure the author's history or work
| experience, but, if I built something like this, I'd likely
| find it extremely cathartic compared to most tech stacks
| nowadays. :-)
| gosukiwi wrote:
| PHPBB
| skilled wrote:
| For that era, FluxBB/PunBB weren't even that great. I think
| phpBB/vBulletin took the cake (as was evident by the number of
| forums run by the said software), and of course, IPB was also
| nice but came with a steep price by comparison.
| make_me_rich wrote:
| Ohh I miss the good old days of forums in general. I find all
| this new software, where conversions* are "threaded" stupidly
| hard to read. Even worse, when the software is trying to
| recommend to you, what to read. Back in the day you had a
| thread, every post to that thread was chronologically added to
| that thread and in case you wanted to reply to someone, you
| quoted them... _sigh_
|
| EDITED: *conversations
| Semaphor wrote:
| I actually love threaded discussions... On HN and Old Reddit.
| But anything is better than whatever XDA uses, and almost
| everything is better than discourse.
| ratww wrote:
| > Old Reddit
|
| Important distinction.
|
| New Reddit also fell prey to bad development practices and
| is without exaggeration unusable for me. It often "crashes"
| and the whole page goes dark-grey on my browser, and this
| has been happening for at least a year. After reloading I
| can't see all messages without navigating away, and middle
| click messes with the scrolling. At this point I will
| assume they either don't care or are fucking with me.
| ngrilly wrote:
| I also prefer reading threaded discussions, but are you
| aware of a good way of keeping track of new messages?
| That's my main issue with threaded discussions, for example
| here on HN.
| halikular wrote:
| Notifications and sorting for new like reddit has.
| asddubs wrote:
| that only really works for responses to your comments and
| top level comment chains though.
| busymom0 wrote:
| I am the developer of HACK, an iOS, android, MacOS client
| app which provides push notifications for HN when someone
| replies to your comment or post.
| com2kid wrote:
| I miss the good old days of BBSes, the late 90s were a
| serious step back in forum usability.
|
| Until JS came along, reading online forums on a broadband
| internet connection was a worse user experience than using
| BBS forum software on a dial up modem.
|
| Every single action, full page reload. And until cloud
| computing came along, even the best of website forums had
| servers that took forever to respond.
|
| Somehow a BBS written for a 386 16mhz in 1992 was faster than
| a forum written in 1999 or even 2005. Oh wait, the 1992 forum
| was likely written in C, or even assembly! (And it only had 1
| user at a time, that helped!)
| dmitriid wrote:
| Threaded conversations are really good because you can have
| branching discussions that don't interfere with each other.
|
| But the only forum I know of that realised how to properly do
| it is this old Russian software forum [1] You need a mail
| client-like interface so that you can see your place in the
| discussion.
|
| Triple quoting someone and trying to read the actual thread
| in a flat forum sucked then and sucks now.
|
| [1] Example link http://rsdn.org/?forum/philosophy/8357952
| mostlysimilar wrote:
| vBulletin 3.x/4.x and IPB 2.x/3.x had threaded view as an
| option alongside flat.
|
| Forum software of old actually gave users the power to
| choose the interface they want. We've really gone backwards
| with software interfaces.
|
| Also, themes. These days all we get are "Dark Mode" and
| "Light Mode". Boring.
| IshKebab wrote:
| Check out the D language forums. Easily the best forum
| software I've seen.
| jonnycomputer wrote:
| I find HN's approach very easy to read and follow. But then,
| each submission does not keep getting commented on
| indefinitely. Could get unwieldy then.
| asddubs wrote:
| it works if you want to read a thread exactly once and then
| never come back to it. if it's an ongoing discussion that
| you want to visit even just two times, you'll just end up
| reading all the same comments again and struggle to find
| anything new
| cygx wrote:
| _Ohh I miss the good old days of forums in general. I find
| all this new software, where conversions are "threaded"
| stupidly hard to read._
|
| A 'classical' web _forum_ is threaded, contrasting with an
| unthreaded (bulletin) _board_ - at least that 's how the
| terminology was used in the German webdev scene of the late
| 90s/early 2000s, possibly due to the prominence of SELFHTML
| and its forum.
| dspillett wrote:
| _> find all this new software, where conversions are
| "threaded" stupidly hard to read._
|
| This is not new, it just isn't applied to web based forums as
| much as I (someone who likes threaded discussions like that)
| would like. For small discussions it make little difference,
| for large branching threads it can help greatly when you
| don't care to follow all the sub-threads. It was not uncommon
| in Usenet clients back in the day. Of course it needs to be
| coupled with good UI for collapsing branches and otherwise
| navigating the tree, and perhaps a chronological view option
| for issue who prefer that (or a tree-view with posts spaced
| by arrival order for the best of both of you do it right - I
| had a reader that did that but can't currently remember it's
| name).
| IshKebab wrote:
| I too miss the good old days where the information you wanted
| was buried somewhere in a 100 page phpBB thread and you had
| to manually search through it 1 page at a time, with each
| one-line comment taking up half the page with avatars and
| signatures.
|
| Good times. Sad that things have moved on to systems that
| don't suck quite so much but that's progress for you.
| moffkalast wrote:
| I do still wonder why the fast and responsive software can't
| invest a little bit into design in order to not look like
| complete shit.
|
| Sure something like phpBB is light, but the UX is also barely
| usable. Give me something like Reddit or Discourse over that
| any day. Why can't we have the best of both worlds?
|
| Hackernews on the other hand manages to lack both (in some
| speculations intentionally), with neither usable design nor
| speed.
| bulatb wrote:
| FOSS tends to treat aesthetics like developers complain
| executives treat software quality: This doesn't help me. Why
| does it matter? Why should I care? I see no difference.
|
| Improving either is an uphill battle when decision makers
| don't value the work, at best, or at worst are committed to
| resistance. And you don't even get paid.
| alxlaz wrote:
| There is a considerable cultural overlap between "people who
| think no-JS, fast and responsive software is cool" and
| "people who think the design of Reddit or Discourse is really
| awful". (Man, especially Reddit, I swear the day they retire
| old.reddit.com will be the day I stop using it). They
| probably _are_ investing a little bit into design, just not
| the one you like.
| lsbehe wrote:
| Very nice work.
| rexreed wrote:
| It feels very retro - back to the earlier days of the web circa
| what Craigslist still looks like. Are you doing this just for
| development experience / fun or to make it something bigger? I
| still find no-JS back-end forums such as PHPBB and similar to
| still be useful. People are still running vBulletin. These
| systems are all very robust and handle moderation and many other
| forum-related must haves. Are you looking to build those as well?
|
| It definitely feels like we're going full circle with the Web and
| back to its earlier, decentralized, stripped-down past.
| aimor wrote:
| Thanks for sharing this. I've been writing my own simple websites
| for a couple years now and I really like seeing what other people
| have done. Sometimes I learn better ways to do things, and
| sometimes I realize what I did was perfectly acceptable.
| 93po wrote:
| Very fast. Really like it.
| l-portet wrote:
| Cool project, is there a theme feature?
| Xeoncross wrote:
| That reminded me of the 1KB forum:
| https://nerdparadise.com/programming/phpforum
|
| I actually shortened it, expanded it to add bot detection and
| published the update also under 1KB:
| https://gist.github.com/Xeoncross/1503594
|
| Such abuse PHP could handle back then.
| leviathan wrote:
| Holy sql injection Batman
| [deleted]
| m00dy wrote:
| is it missing captcha ?
| benbristow wrote:
| Has a CAPTCHA but it can be solved pretty easily (paste into
| Dev Tools console)... const input =
| document.querySelector('body > main > form > table > tbody >
| tr:nth-child(3) > td:nth-child(2) > input'); const
| challenge = document.querySelector('body > main > form > table
| > tbody > tr:nth-child(3) > td:nth-
| child(1)').innerText.split('=')[0]; input.value =
| eval(challenge);
| bmacho wrote:
| Teddit works like a charm with disabled javascript, it supports
| css based thread collapsing, and cookie based information for
| logged out users as well (you can store which subreddits you
| follow).
| ratww wrote:
| _> it supports css based thread collapsing_
|
| I didn't knew but I love it... I wish more developers took
| interest in such things.
| bmacho wrote:
| .. actually it uses the summary/details html tags, but the
| same thing is totally doable with css checkboxes and
| visibility too.
| derekzhouzhen wrote:
| What innovation do you have to make a moderator's job easier?
|
| I ask because I believe this is the hardest part of a forum
| software; The one thing that make or break a community is whether
| there is timely and fair moderation so contents are fresh and
| relevant.
| forgotpwd16 wrote:
| Love the HN-like design. How do you handle big threads and many
| nested replies?
| robertlagrant wrote:
| I thought for a minute this was going to link to
| news.ycombinator.com!
| cxr wrote:
| HN is not "no-JS web forum software".
| Kiro wrote:
| HN uses JS.
| MarcellusDrum wrote:
| Optionally. The site works just fine with JS disabled.
| ms123 wrote:
| Love it! I built one using go (https://git.sr.ht/~m15o/vpub) and
| it powers https://forum.status.cafe/
|
| Thanks for sharing it :)
| lsbehe wrote:
| It's not caching the stylesheet. If you plan on updating it a
| lot you should still enable caching and e.g. increment a url
| parameter every time you change it (like style.css?v=3).
| lcfcjs wrote:
| barefeg wrote:
| Out of curiously, does HN use JS heavily? It feels quite
| lightweight, and it's sort of a forum
| lifthrasiir wrote:
| Very sparingly: https://news.ycombinator.com/hn.js
|
| I'm pretty okay with that, my only complaint is that when you
| vote a comment or story it creates an invisible image with a
| voting URL, which may be loaded much later so the click may not
| register from time to time.
| donio wrote:
| And all of it is optional. You can do all operations
| (readinig, posting, commenting, voting, flagging) with JS
| disabled, you just get page loads rather than dynamic
| updates.
| zhte415 wrote:
| Looks great. If you wanted to extend it with JS, HTMX or
| lightweight functions easily added to Flask, which is imho the
| _right way_ for CRUD.
|
| And specifically, looks great - clearly outlined, threaded,
| indented, flow of conversation.
| ad404b8a372f2b9 wrote:
| I love it. And it's telling of modern practices that it's one of
| the fastest forum I've used in the past few years, you click and
| the page instantly appears!
|
| Do you intend to extend it and keep working on it or was it just
| a one off project?
| lolinder wrote:
| > And it's telling of modern practices that it's one of the
| fastest forum I've used in the past few years, you click and
| the page instantly appears!
|
| "Modern practices make for slow apps" is a common trope on HN,
| but it's important to note that it's not just modern
| _practices_ that make modern web apps feel slow; modern
| _feature sets_ are the larger culprit.
|
| This app could be a React SPA and it would still be faster than
| most forums you've used because it intentionally has a minimal
| feature set.
| ad404b8a372f2b9 wrote:
| I don't buy that for a second to be honest.
|
| Modern forums haven't innovated all that much, you have
| infinite scrolls, notifications and live updates, that's all
| that I can think of, off the top of my head. If you go on the
| main page of a modern forum and a Phpbb one they'll be
| functionally equivalent for the end user.
|
| And even if they had innovated, you can put as big a feature
| set as you want on the backend and not send 20Mb of
| JavaScript along with a single request per post and your page
| will load instantly.
|
| And that's not even going into all the websites which are
| entirely featureless, I regularly see SAAS landing pages that
| take over a minute to fully load, that's just to display text
| and images.
|
| Maybe the stack is capable of being fast and light
| theoretically but it never is in practice.
| lolinder wrote:
| > Modern forums haven't innovated all that much...
|
| I'm not comparing modern forums to older forums, I'm
| comparing both types of forum to OP's minimal forum.
|
| > And even if they had innovated, you can put as big a
| feature set as you want on the backend and not send 20Mb of
| JavaScript along with a single request per post and your
| page will load instantly.
|
| You have to distinguish between initial page loads and
| subsequent interactions. Forums are not typically one-page-
| and-done websites: you spend a lot of time navigating
| around the different views.
|
| For this use case, phpBB forums were and are _very_ slow.
|
| I tested out the phpBB demo [0] and compared it with the
| Discourse demo [1]. The Discourse demo has a slow initial
| load, but it's quite snappy after you've downloaded the
| 6.23mb (not 20mb!) of JS and CSS. The phpBB demo seems
| faster on the initial page load, but it gets pretty painful
| to navigate as you click around into different sub-forums.
|
| The reason why the OP's no-JS forum can outperform both
| phpBB and Discourse is primarily that it doesn't do very
| much work on each user action, not that its stack is
| inherently superior. The biggest bottleneck in a forum will
| be the speed of each request-response cycle, not whether
| the requests return JSON or HTML.
|
| [0] http://www.try-phpbb.com/33x/index.php
|
| [1] https://try.discourse.org/
| GoblinSlayer wrote:
| Feature set is absolutely design practice.
| nathias wrote:
| very cool forum
| jamesmccann wrote:
| This is a cool project! One small suggestion: the native blue
| links for the author name, "thread", and "reply" make the content
| hard to focus on as the UI is quite intrusive. HN solves this
| quite well with a colour scheme that has the comment content as
| the most prominent element in a thread.
| sirsinsalot wrote:
| It's absolutely beautiful. Within a fraction of a second, I knew
| what it was and how to use it and how much value it has.
| throwaway81523 wrote:
| It's always nice to hear about someone writing a cool program
| just because they felt like doing so. Every time I think about
| writing a forum server, I find I return to the thought that
| Usenet was better, and that if I wanted a web forum, I'd consider
| putting a web front end on an NNTP server. That would among other
| things let people keep using NNTP clients (I like gnus.el) if
| they don't want to use a browser. There are a bunch of NNTP web
| clients already, but afaict they all needlessly suck.
|
| You might take a look at Fossil (fossil-scm.org) which is not a
| forum, but is an all-in-one source control system, bug tracker,
| wiki, and web backend, all implemented as an SQLite client
| written in C. Its blurb says a scripting language might sound
| more attractive than C superficially, but in Fossil, SQLite does
| all the heavy lifting that would otherwise have been done with
| scripts. On my bottomless todo list I want to study its
| implementation sometime, since I think it would be a good example
| of "advanced" uses of SQL and SQLite. That is completely
| independent of Fossil's purpose as a VCS application. I'm ok at
| basic SQL but not so clueful about sophisticated uses.
|
| One thing to watch out for is that since SQLite is an embedded
| DB, when you make an SQlite query, the overhead is basically a
| local subroutine call rather than the network traffic that a
| client/server DB would incur. That in a way changes the
| asymptotics of an application: particularly, the "N+1 queries"
| antipattern of some client/server DB apps is a perfectly ok
| design strategy for SQLite. I believe Fossil may rely on this in
| some way.
| chatterhead wrote:
| Wonderful job!
| Aperocky wrote:
| May I recommend an ORM for any such project? hand rolling SQL
| statement aren't going to scale.
|
| Here's my shameless plug: `pip install sqlitedao`:
| https://github.com/Aperocky/sqlitedao
| tonetheman wrote:
| My experience is the exact opposite.
|
| ORM's never scale and you end up with hand written SQL long
| term. Unless it is really just a CRUD app then ORM's really
| work fairly well.
| Aperocky wrote:
| On a personal and professional level it has been the opposite
| case for me.
| bityard wrote:
| I get the impression that OP's project is not aiming for scale.
| softfalcon wrote:
| Not trying to bash your ORM as it could have a great
| translation layer to make optimal queries.
|
| my experience optimizing SQL has been removing the ORM layer
| via hand rolling SQL queries.
|
| Most of my peers also seem to agree that ORM is great for
| knocking a feature out, but you'll inevitably run into
| performance concerns at scale and need to write your own
| optimized queries yourself.
|
| I feel like with SQLite having limited resources, you'd likely
| want to optimize your queries as best you can without an ORM?
| Is that not the case?
| Aperocky wrote:
| A well thought out ORM would consider for performance,
| obviously if you're just retrieving a particular string then
| manual SQL might have a few times speed lead.
|
| The fundamental issue with both handrolled SQL and ORM is
| inefficient queries leading to linearly increasing time
| consumption. for instance usage of `LIMIT` and accidentally
| querying on non-indexed fields. But I don't see how this
| differentiate the 2 as I have seen it happen in both
| situations professionally.
|
| A good ORM enforces certain behaviors, specifically querying
| by index and constant time pagination. This guards against
| accidental querying behaviors.
| egberts1 wrote:
| i worry about spammers coming across my soon-to-be-hosted forum.
| What mechanism can one do to prevent fraudulent signups?
| genericacct wrote:
| IMHO one of the best features a modern web forum sw can provide
| is browser notifications
| foofoo4u wrote:
| This is great. I want to see more of the web to be like this.
| Simple, direct, light, and functional. I've came to learn on this
| thread alone that other projects such as teddit and nitter exist,
| which capture this same spirit. I'd like to know if other
| projects for popular sites exist as well. Someone should make an
| aggregation of sites and open source libraries like
| https://github.com/Demindiro/agreper that exist.
| ftth_finland wrote:
| I dislike forums which indent successive replies.
|
| I hate forums which indent replies _and_ don't support collapsing
| sub-threads.
|
| The proper way of handling replies is to post them under each
| other and support quoting.
| [deleted]
| demindiro wrote:
| > I hate forums which indent replies and don't support
| collapsing sub-threads.
|
| [-] should collapse subthreads. Caveat is that the browser
| doesn't remember which subthreads were collapsed due to no-JS.
| have_faith wrote:
| Not if each "collapse" link reloads the page and at the same
| time stores the preference in the backend against your
| username so that subsequent page loads know what to hide (:
| XCSme wrote:
| Can't you redirect/store the information in the URL and
| then somehow read the URL data in CSS?
| veidr wrote:
| LOL you are so right... so much was lost when we started
| accepting that page reloads are expensive (T_T)
| have_faith wrote:
| It was a tongue-in-cheek suggestion but page reloads are
| pretty fast these days with http/2. Maybe there's ways of
| submitting a form in the background for the same effect,
| no reload needed! now we're surfing.
| com2kid wrote:
| For 20 years page reloads were expensive.
|
| In 1999 I had a cable modem connection that could pull
| down 2 megabytes per second and ping up and down the west
| cost well under 50ms.
|
| But forum servers were _slow_. Like, really really slow.
| When Sites like Reddit finally came to, 15 or so years
| later, with inline replies, they were a breath of fresh
| air.
|
| Back in 99 Slashdot had massive resources put into making
| it responsive, lots of servers thrown at it, and it was
| still laggy and slow compared to Reddit now days.
|
| Everyone arguing about "time to first draw being under
| 100ms" forgets that just a short time ago, web servers
| took more than 100ms to _respond to a connection_.
| veidr wrote:
| Yeah you're not wrong. But I wouldn't consider that
| 100ms, or even 500ms, "expensive".
|
| In 1999 I would have been jealous of your internet
| connection -- I still had a 256kbps ISDN line, and there
| were fast forums even then (but mostly not). I think it
| mainly depended on whether the sites rendered HTML on the
| fly (with like maybe Perl? to render database content)
| or... just served static HTML.
|
| Page reloads only got expensive when we decided that they
| would do a bunch of other shit besides that.
| com2kid wrote:
| > Yeah you're not wrong. But I wouldn't consider that
| 100ms, or even 500ms, "expensive".
|
| 100ms is noticeable, 500ms is bad.
|
| The old dial up BBSs may have been slow enough that you
| could watch character appear, but they were responsive!
| Those characters started printing right after your
| keypress happened. Of course it helped that it was likely
| a local phone call.
|
| I imagine HN ever had a 500ms response rate, the
| engineers behind it would consider it a failure!
|
| (Even reddit is under 500ms for many operations, and it
| is super heavyweight)
|
| > I think it mainly depended on whether the sites
| rendered HTML on the fly (with like maybe Perl? to render
| database content) or... just served static HTML.
|
| Yeah Perl didn't help the 90s web at all. It made stuff
| possible, but wow, the performance was bad.
|
| Then again web server software design back then was also
| a long ways away from what we know to do now.
| Nextgrid wrote:
| > just a short time ago, web servers took more than 100ms
| to respond to a connection
|
| And yet, once you wait that 100ms or however long it
| takes for the server to respond, your page is fully
| loaded and interactive. During the loading process, your
| browser remains responsive and your CPU is not loaded.
|
| Nowadays, we still wait the same amount of time for the
| initial load, but now your CPU is at 100% parsing
| megabytes of shitty Javascript, and once the initial load
| completes, you're still not guaranteed the page won't
| slow down/overload your CPU again because some stuff can
| be asynchronously loaded (supposedly for performance
| reasons, even though doing it on the backend as part of
| the initial load would be faster in the vast majority of
| cases).
| com2kid wrote:
| > Nowadays, we still wait the same amount of time for the
| initial load, but now your CPU is at 100% parsing
| megabytes of shitty Javascript, and once the initial load
| completes, you're still not guaranteed the page won't
| slow down/overload your CPU again because some stuff can
| be asynchronously loaded (supposedly for performance
| reasons, even though doing it on the backend as part of
| the initial load would be faster in the vast majority of
| cases).
|
| The new reddit site is _fast_. Yes initial load time is
| like 2 seconds, but after that, everything else is
| instant. Click comments, escape out, go back to feed,
| load comments of a different story, it is _quick_.
|
| Yes crappy JS abounds everywhere, NYT is an offender
| recently (they used to be good!), lots of sites suck in
| this regard, but when modern web dev is done well, it
| works _really_ well.
|
| Though having read the Reddit engineering blog posts,
| they throw a ton of resources at ensuring Reddit is fast.
|
| Meanwhile, Ars Technica loads things almost instantly,
| but for the last year or two (!!) their article pages
| have leaked memory and CPU, eventually taking up all my
| CPU and gigs of memory.
|
| Not sure how even. Great load times, responsive site,
| keep that background tab open and watch the CPU start to
| melt down.
| ftth_finland wrote:
| I stand corrected.
|
| I did not recognize the [-] as it looks like some weird emoji
| on my mobile browser due to the too small and uncentered
| background.
| MetaWhirledPeas wrote:
| That's just, like, your opinion man. I prefer HN's indented
| approach to a typical forum listing where it's just a firehose
| with quotes. But the best approach is to allow the view to be
| switched as desired.
| eterm wrote:
| HN's model is bad for high volume. Sometimes on HN you only
| get _one_ top level reply on the whole page because once it
| puts the top top-level reply it then puts _all_ the replies
| to that above the next top-level reply.
|
| So you get a vast amount of low quality replies above the
| next high-quality reply.
|
| For low volume it works okay because you can manually
| collapse but for high volume once it starts paging it breaks
| down and you just get further into the top level comment
| without properly being able to escape.
|
| Reddit's model of auto-collapsing so you get a mix of threads
| and top-level replies is much better for picking out the
| better responses.
| httpete wrote:
| I made a reddit-like comment system for HN if you are
| curious: https://www.hackernewz.com/item/33153152 (link to
| your comment: https://www.hackernewz.com/item/33153152?comm
| entId=33155112)
| rakoo wrote:
| The style is very neat. Mind sharing the source ?
___________________________________________________________________
(page generated 2022-10-10 23:00 UTC)