Ah, 2015 has came, and with it certain two pradigm shifts to Misago 0.6.

Those keeping up with project's github can guess one of shifts that occured, but for those who didn't know it yet:

Misago UI is being moved into Ember.JS

This means Misago became de-facto two apps. Django REST server exposing API's, and Ember.js application that handles frontend. The reason for this change origins from growing complexity of existing JS code, which while working nicely, was getting dangerously close to becoming JS framework on its own.

I didn't want that, so I've decided to offload this burden on 3rd party vendor. Ember.js went long way since its "debut" in Discourse and Django Rest Framework 3 is around for some time now.

The other shift shouldn't come as suprise either, considered there's thread discussing it on those forums:

Misago is becoming flatty

Yep, Misago 0.6 will introduce option to switch board index between showing categories and threads. Thread relation with category will too no longer be absolute, meaning that threads posted within subcategories will be displayed within parent categories, providing greater visibility and optional selectivity.

And ofcourse, other view will still be available trough link in navbar.

Finally, don't worry that Misago will become next Discourse. Dependencies needed to run Misago are still purely python and can be installed via single pip install command with no extra configuration necessary.

Those with JS off will get content via noscript tags, so it shouldn't be a problem.

Also how is forum really different for Google from other apps? Its very simple data hierachy and there isn't much magic in going around it.

Every page will have simplier version served by Django within noscript tags, so you don't even need JavaScript to consume forum content. Its only required for participation.

@moon, I don't think you understand the nature of Ember.JS apps. :)

When you are building Ember.js app, you are ultimately working with JS data structures (Either POJO's or Ember.Model instances), and JSON as intermediary to Django/Python data structures (models.Model or dicts).

In "vanilla" application if user wishes to follow other user, he clicks the button, button submits form to a view that only checks CSRF, then pulls out the DB user model, and sees if relation to request.user already exists. If it does not, view creates it.

In Ember.js application, pressing button results in API call, sending JSON representing current user to api/users/1231/followers/. Then API endpoint that is aware of followers/ meaning would again turn this JSON into data structure, this time Django model. If action succeeded, API would then reply with 200 code and JSON with "current" state of user we followed. Ember.js receives response and updates data state, which in turn updates UI state. Now because there's already single point for changing site users, I don't need to write all additional Django forms and views for that.

This contrasts with jQuery that left you with a lot of freedom in deciding on how you will achieve asynchrony in your APP. With it, you could "just" take over form submission event, already update UI, then send POST from form asynchronously to same view that would also handle non-js submit. Only difference would be deciding between setting flash message and returning redirect, or sending back JSON with same message instead if request.is_ajax() was true.

This means that for graceful fallback with Ember.js, in addition to developing API, you would need to develop static UI and Django views that would use forms for changing app state.

Well, to use those endpoints your views would have to muck with HttpRequest object.

Hey, tell me your use-case and lets see if its really unsuitable for you. :)

Point that Ember.js is slow on old devices is only one that I'all agree isn't subjective one.

Now, if somebody cripples his own experience, it is his choice, not mine, and there will always be people with agenda against something. I've seen how decade of "oh, we must cater for those who can't" philosophy took webdev. Those times are gone now however. And look now, out of those 3-5% of clients that don't support js, tiny percent are acient devices and extreme majority are bots and scrapers.

And If you are paranoiac, install plugin that blocks referers and async requests to spies, don't disable JS that more and more web comes to depend on.

To be honest, I hoped for links to site and some details about what it uses are seeking in it. Is it something superniche? Is it located somewhere remotely where market adoption of new devices is superslow or aimed directly at certain democraphic?

Eh, I dyslike this general php bashing. phpBB3, while they did some annoying design decisions that they are now spending great deal of time fixing, had rock solid implementation and security record.