Rikki

There'll be more details soon, but it's very flexible. We have over 15 different rules built-in right now, for common actions across the community. Most can be limited by quantity and/or location.
Here's a look at configuring a "Award points when a user posts 1000 topics" rule:

 
Some rules can award different users too - for example, we have an action that fires when someone votes on a poll, but you can choose to award the voter and/or the poll author. I think this sort of flexibility will open up some really interesting engagement possibilities!

We aren't sure if this will make it into 4.6 or be a later release, but it shouldn't be too long until it's available in any case 🙂 

Any further details how points can be obtained? Is it going to be through regular content creation - i.e. number of posts, articles, images, etc.? Or it will be more flexible, for example based on where the topic is located (post in professional category might be worth more than one in humor section), or based on word count or number of attachments? Even better if we can set the weight of points ourselves 🙂

There'll be more details soon, but it's very flexible. We have over 15 different rules built-in right now, for common actions across the community. Most can be limited by quantity and/or location.
Here's a look at configuring a "Award points when a user posts 1000 topics" rule:

 
Some rules can award different users too - for example, we have an action that fires when someone votes on a poll, but you can choose to award the voter and/or the poll author. I think this sort of flexibility will open up some really interesting engagement possibilities!

There'll be more details soon, but it's very flexible. We have over 15 different rules built-in right now, for common actions across the community. Most can be limited by quantity and/or location.
Here's a look at configuring a "Award points when a user posts 1000 topics" rule:

 
Some rules can award different users too - for example, we have an action that fires when someone votes on a poll, but you can choose to award the voter and/or the poll author. I think this sort of flexibility will open up some really interesting engagement possibilities!

I love the look of the new hover card too! Super sexy. Good job @Rikki

Oh god I hope this will replace the current reputation ranking system as that looks baller as heck and I don't use the word baller lightly.

We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂 

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

As JS continues to modernize and become more usable as a core scripting language, I feel like we'll see jQuery at the very least become superseded by something lighter and more powerful.
But there's never likely a time where we'll move to just raw JS for complex applications. Some type of library will always be needed for the reasons Matt said.
Those libraries will likely become lighter and faster, but they'll still exist.

jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll.
So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that".
Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.

I cannot presume to speak for everyone, but it has been my personal experience whenever seeking out photos to share; all the website's I pull from as a casual user are already using WEBP. That is to say, my members, when posting images, are already frustrated that all the cool photos they wish to share seem to be incompatible with the site. To put that into context, imagine visiting a forum that was incompatible with JPEG. At this point, general web compliance and practiced user engagement should be enough to justify adaptation, in my opinion.
From a technical standing point, I recently updated a static website, which was heavily image-related. One of the last modification was converting my PNG's to WEBP. I noticed a full 4-second speed difference as a notable improvement. 

Hi Charles,
Firstly, thanks for spending the time sharing your thoughts. The impression I get from your posts in this topic is you feel your way of moderating is the correct way and that our platform isn't fit for purpose if it doesn't facilitate that approach. Forgive me if I've misinterpreted, but I wanted to share our perspective: we've been powering thousands of diverse communities for nearly 20 years. A lot of those communities are in industries that would typically be considered ripe for toxicity (e.g. gaming, sports), and have many millions of posts (50+ million in some cases). Many of these communities are run by brands that care deeply about their public image and simply would not allow the perception of toxicity to exist in their name. Moderation is one of the key priorities for these sorts of communities.
We therefore have a pretty well-tested understanding of the needs of sites when it comes to moderation, toxicity, guidelines and so forth. It's what we work with customers on every single day.
Put simply, manually reviewing every post made in a community in a 'just in time' fashion isn't sustainable or scalable. On a very small community with a couple thousand posts and a few users active at any one time, it may be an approach that can work, but it simply wouldn't be viable on communities that receive thousands of posts an hour and have hundreds of members online at any one time. Some of our customers have entire salaried community moderation teams and even they don't have the resources to attempt that.
The implication that unless every post is reviewed by a moderator, a community will inevitably descend to chaos and toxicity, is wrong. Moderation is a much more holistic endeavor than simply reading every single post. 
You are absolutely right that users want to see their post immediately, so pre-moderating content usually isn't the best approach. We tend to suggest a reactive approach instead, where content is posted freely but problems are identified and then acted upon.
We have a very robust warning system that can head off many problems, or put troublemakers in a timeout so they can't cause further issues. We have automatic moderation tools that can take actions on content depending on how other users interact with it. We have a very powerful permissions system that allows you to gradually (and automatically) grant more access to users once they've proven themselves. We have a built-in spam service that can prevent many spammy registrations before they even make it to your community. All of these tools have been developed with the lessons we have learned over the years. Obviously, there is always room for improvement and we take ideas and problems on board to figure out what to do next.
I am certainly not suggesting your approach is wrong. If you've made it work for you, then all the more power to you. However, it is not an approach that in our experience would be useful to most communities. It seems to me that the custom app approach is going to be the best fit for you, and I hope it works out.

On this site we use the system font stack, which means Windows/Mac+iOS/Android use different fonts. That can make the resulting content look slightly different across devices.

On this site we use the system font stack, which means Windows/Mac+iOS/Android use different fonts. That can make the resulting content look slightly different across devices.

I can see good reasons to want to only provide a preview, but nothing would make me go find another web site on the internet to find whatever it was I was looking for instead. I may be in the minority, but this "Experts Exchange" mode of teasing the content away and trying to force a registration is nails on a chalkboard, and unless you're the only game in town, I'd avoid doing this. This might not apply to highly motivated consumers for image content (i.e. adult content).
You can eliminate the bandwidth issue by going with a CDN like Cloudflare or Cloudfront. You can encourage registration by becoming the defacto source for whatever it is your community provides. You can protect resources by doing things like using feature images to show a snippet of a screenshot of what might be downloadable, and turning off attachments for guests altogether.
I'd venture to say that this is something that might backfire on you, and you'd not realize it until it was too late. Yet, caching multiple copies (guest & members) is how I'd engineer this. If this were a feature important to me, the extra cache space would be more than worth it.

We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂 

The fix for disabling email notifications I mentioned will be in our next release, but I don't know when that will be. We are continuing to discuss the other issues brought up here, particularly separating some of the notification types.

The fix for disabling email notifications I mentioned will be in our next release, but I don't know when that will be. We are continuing to discuss the other issues brought up here, particularly separating some of the notification types.

We have some ideas on making blocks and pages more flexible, though they are in their early stages. As things stand right now, custom templates are your best approach, but I certainly hope we can provide something more intuitive and robust in future.