Blog

Originally published April 2023. The argument hasn’t changed. The platforms have only made it more urgent.

Every community has behaviour that is legal but corrosive: the committee member who treats the organisation’s money as their own, the volunteer who bullies newcomers until they leave, the member who harasses others and dares anyone to prove it. No law covers most of it, and no law should. For most of history it was handled by something more powerful than law: reputation. People cared what their community thought of them, and behaved accordingly.

I made this argument in 2000, in The thin veil of civilisation. Social norms, enforced by approval and disapproval, are the real glue of a society. Laws are the backstop.

That glue is weakening. Communities are larger, more anonymous and more transient. Someone can behave badly in one organisation and turn up fresh in the next, with a clean slate and a new set of targets. The tools communities now run on make it worse. Facebook groups and WhatsApp chats give organisers no memory and no standing: complaints vanish in a scroll, and the platform’s rules, not the community’s, decide what can be said.

Privacy matters

I take privacy seriously. People should control their own data, decide what is shared, and never be exposed on a whim. That principle is why I build member-owned infrastructure in the first place.

But privacy protects people from strangers, corporations and the state. It was never meant to protect people from the consequences of how they treat others. Privacy that means no one may ever say “this person did this, and it isn’t acceptable” is not privacy. It is impunity.

Accountability done properly

Naming has to be done carefully or it becomes a mob. The rules that make it legitimate:

• Conduct, not character. What someone did, not who they are.
• Decided by those accountable, through a known process, not by whoever shouts loudest.
• A right of reply before anything is published.
• Proportionate and time-limited. Records expire. People can change.

Whether to go further and name people publicly is each community’s call. I would, and I do. A community’s duty doesn’t end at its own boundary: if bad actors are quietly shown the door, they simply move on to the next organisation, which gets no warning. Keeping it private protects the offender, not the next victim. But I understand why others stop short of that, and a fair internal record is still far better than none.

Whichever you choose, the truth matters. Publish only what you can stand behind. Anyone named falsely has the law of defamation on their side, which is exactly as it should be.

Communities should own this

The point is not shaming for its own sake. It’s that a community should be able to set its own standards and enforce them, on infrastructure it controls, under rules it writes. When the platform belongs to someone else, you get their rules and their priorities, and usually their silence. When it belongs to you, you can build accountability that is fair, transparent and answerable to members.

It’s how I run Princes Park Touch, whose Hall of Shame is public, and it’s what LocalHero is built to let any community do, publicly or not.

I am a member of the advanced WordPress facebook group and its seems every few days someone posts and article on there waxing lyrical about the latest javacsript only theme they have built using the latest JavaScript framework and the rest api.

Dont get me wrong, I love javscript, and I think the rest api is one of the best things to happen to WordPress but every time I read about someone usea front end framework to build a theme I shake my head.

A wise man once said,

just because you can doesn’t mean you should

This applies to so many things, especially JavaScript when used to output content.  In order to explain we all need to be reminded of the way the web is traditionally designed namely:

• HTML for con­tent
• Css for pre­sen­ta­tion
• Javascript for func­tion­al­ity

This combination might seem old hat but it was created by smart people with good reasons.

When done properly it has three major strengths

1. It conveys meaning
2. It is robust
3. It has a clear separation of concerns

However it can be slow so today many advocate using JavaScript to interract with apis to replace this traditional paradigm. This has  major advantage in that can be substantially faster as the client side javascript can request only the information that it needs. However it also means that javascript is now the creating the content as well as the providing the functionality

However lets just compare how this compares to the traditional approach. Namely:

Conveying meaning.  Yes javascript can convey an experience that may be indistunguishable to the eye BUT the web is not just a visual medium for humans. Machine like search engines, and screen readers are important and in most cases a javascript front end is invisible to these agents

Being robust. Javascript is a not a fully standardized lanaguage and is notorious for conflicts and errors, and being browser depe3ndent. So an error on a javascript front end usually means the whole site falls over. In contrast a traditional semantic html front end degrades gracefully

Separating concerns. In a JavaScript front end you are tightly coupling functionality with content and potentially presentation as well. This actually if you change the api or you change your javascript the whole thing falls over. In contrast html is html and if the JavaScript stops working you still have the html.

Javascript is important but its not a replacement for html. Its future is in rproviing functionality, both in enhancing the reading experience and in making the eually important area of creating, updating and deleting content on the web.

Finally I’d like to urge you that is you need speed work on the basics like http caching, or look to modern technologies like http/2 and service workers.