jpillora/debator

later a plugin system to experiement with different approaches

Atlassian's Jira does this, it's got a ton of features and modes which you can choose from. Yet there are a few core pieces which are omnipresent.

Definition sidepanel, Show a pro/con table in the sidebar, etc

I think some of these would need to be baked into v1, though definitely start sparse in beta and then make data driven feature decisions

like Google Wave

I never used Google Wave, I heard it was good though never caught on because of its unorthodoxy/complexity. I'm sure there are good lessons to be learnt from it though.

compartmentalize discussions around topics. The difficulty is they always leak into other topics

Agreed, keeping discussions focused will be really important. Some people I know diverge away from the topic of debate easily and quickly becomes unproductive. For example, two people might diverge while others have moved to a new thread. The problem is, as with many we've discussed, the only real automated solution is true AI. We'll just have to experiment with different UX solutions for this. I have a feeling user flagging will become the solution, just need to hone the heuristics.

Don't want to get into the UX weeds again though just as an idea for the future while I'm thinking of it. Maybe given some heuristic, we could convert a branch (sub-tree) into a new debate (the root of a new tree). People from the first debate would still see the converted comment as a comment, though you can no longer reply, you must follow the link to the other debate.

I don’t think there is a holy grail interface. It will be about making a trade off.

Agreed

Server-side rendering is the main thing. Makes interfaces super-snappy.

I see the benefits of this for SEO, though using standard href/a-tags with pushstate/historyapi you get crawlability. I agree load times are improved, though with resource caching (and the more extreme - appcache) and data caching (localstorage) you can reduce load times significantly (not possible with legacy browsers unfortunately though). Pure client-side rendering creates a nice separation between frontend/backend, run frontend on (www.foo.com) and backend on (api.foo.com). Allow a CDN to handle www and it'll relieve your backend from much of the superfluous traffic.

The main philosophy is that you should be able to remove a module and the app still works. And you should be able to add a feature by typing npm install my-feature and its auto wires itself into your project.

I think this a good strategy and I've dreamed of various ways to solve the Node code organisation problem. I've arrived to the opinion however the problem is Node/npm itself. The fact that we are able to monkey patch anything, place code anywhere, and load it in any way we like is the problem - this ability instant causes multiple solutions to arise, which then leads to divergence in the language, the excessive invention of DSLs and therefore never-ending list of "sub-languages" to learn. Not saying your solution is bad, only that it would be extremely difficult to make it (or any other organisation solution) mainstream Node practice.

I think this is an issue in all languages though Go (sorry about the Go bandwagon) was actively designed to prevent this kind of situation. There is exactly 1 way to format code, organise modules, organise tests, run tests, and there is an overarching philosophy that gets (sometimes harshly) drilled into users by the Go community.

now that we have Webpack...

I do like Webpack, I was using for a while in my startup to attempt to create a "single binary" (single js file) for distribution and obfuscation.