> Bulletin board system gains nothing from "single page application" style architecture, it is a collection of documents, stick with it.

Real-time updates, differential updates, cacheable partials, free distributed rendering, to name a few.

Specifically in the realm of cacheable partials, every single site out there that repeats elements between pages could benefit as a well-architected SPA. It's analagous to h.264 vs GIF: you can compress/cache the similar chunks and only update the deltas and save bandwidth, making your platform more scalable. Sure, GIF can compress each individual frame, but h.264 improves on that dramatically by compressing in another dimension. The essence, in my mind, of the SPA is keeping your HTTP requests DRY.

I agree on the benefits of SPA, but there is a dealbreaker when it comes to forums - you want it to be searchable, and that currently means using server generated templates for SEO purposes (or a setup using PhantomJS to pre-render the pages each time, but that is even more suboptimal, especially for a potentially fast moving BB).

NodeBB's engine supports both cold-loads from server-side and ajax-loaded pages. So if you browse NodeBB via JS-disabled browser for example, it will still work (read-only)

You can try SnapSearch https://snapsearch.io/ which uses Firefox to render SPA sites.

> Bulletin board system gains nothing from "single page application" style architecture, it is a collection of documents, stick with it.

I'd have to say the Discourse project (http://discourse.org) provides a fantastic counter example to this. It shows what can be achieved when SPAs embrace the URL and a lot of thought is put into how the modern browser features can be used to improve the user experience rather than just jumping on the bandwagon.

Example forums:

http://meta.discourse.org http://discuss.atom.io http://discuss.emberjs.org

Discourse emulates the normal behaviour really well, good for them. After a quick look looks like they do not suffer from the issues I mentioned before.

I just do not see any benefits going SPA style when working with data that is essentially collection of documents.

Single-page applications can change pages faster.

Sure about that? Try browsing http://forum.dlang.org/

Especially if you're in Europe (I get a ping time of 24 msec from Switzerland), the pages load nearly instantly. It's actually the sort of thing that you notice and go "whoa" it's so fast.

Yet there's nothing special about it. It's just a regular web server, written in D, that serves pages really fast (probably out of cache).

If you use HTTP caching and compression appropriately, and keep your design light, there's no particular reason you need to use Javascript to speed things up.

I'm not saying non-single-page-apps are slow, but that single-page apps can be faster in certain circumstances. When I click a link in your example I still get that slight delay, which could be eliminated with a single-page application.

not convinced discourse UX is that good either,in fact NodeBB copies a lot from discourse.

neither am I, there's a good reason people are willing to pay for older BB systems like IPBoard and vBulletin, they work and they are iteratively improved upon instead of 'UX-rebooted' like Discourse and NodeBB. I personally don't think any of the systems are perfect but the the older forums work fine as long as they are popular enough that resources are dedicated to policing them.. so I personally feel proper inter-forum karma integration should be top priority, more-so than new UXs!

This is why I prefer https://github.com/radar/forem by the "Ruby hero" Ryan Bigg. It's also for Rails but without the bells and whistles from Discourse. A.k.a. "The best Rails forum engine. Ever.", it's perfect if you want to build something unique from the ground up.

I would associate Discourse more strongly with Javascript or Ember than Rails.

You can see my app too: http://PlaysZone.com uses the same single page concept with server side rendering for the first loaded page. The other pages loads some json with ajax.

> EDIT: Also, when using infinite scroll, do not put anything in the page footer. Now when the pages have copyright info and couple links in there, I can see those only for a split of a second before new content appears. Makes me go crazy.

This sort of design element occurs way too often. I call them Tantalus footers, because they're always just out of reach. It also makes me wonder if the people who designed these things actually tried using them under real-life conditions.

I was just about to complain about overriding the scroll behaviour. The homepage doesn't work properly because I have Chrome at a weird size, so I'm unable to see all of the features list, if I scroll slightly it takes me to the next section.

> Bulletin board system gains nothing from "single page application" style architecture, it is a collection of documents, stick with it.

Saying Nothing is to be gained is going a bit far. This is an interesting experiment, with some novelty, that will be iterated upon. I presume that the bugs will also be fixed.

Yes, I was a bit too harsh. My point is that discussion forum is almost completly just a collection of documents. Traditional web pages serve that structure really well.

I agree although I can see value in a pjax style approach to get faster page reloads. As long as you preserve normal behaviour and url structure, this is usually a win-win.

EDIT - just checked and it does a moderately good job without javascript: "Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode."

This is probably an acceptable compromise. Just to clarify - I'm not arguing that everything should work with js disabled - just that it's a good litmus test for whether a website is fairly robust with regard to normal HTTP behaviour.

Discourse in general loads a lot faster than traditional bbs when you click links or try to view a specific post. So what's being gained is better user experience. I'm not sure I see the relevance of the underlying data structure... isn't email just a collection of documents too? Why is gmail a SPA?

I don't know if I would call a fully working product with pricing details and everything an experiment.

>Kinetic scrolling on Firefox for Android is broken. Do not fiddle with scrolling when doing web development, ever. I guarantee that you will fail.

What do you mean? I've tried on Firefox (Beta) and Chrome on my Nexus 5 and it seems to work fine for me.

>Do not fiddle with scrolling when doing web development, ever.

This should be carved into the desk of every webdev on earth.