I've been looking around online at compatibility for HTML5 browser streaming. It looks like straight up AV1 in a MP4 container is becoming absolutely fine for browser playback on devices.

Is anyone using this on webpages yet? The sooner we move to AV1, the sooner we can have high quality video stored at smaller file sizes, which is a massive bonus.

Right now my company video hosting is purely in MP4 with H264, moov atom to the front as per the requirement, and it plays back on everything with no fallback in a straight HTML5 video container. What's the chance of switching to AV1 and not having to worry about the fallback for the most part?

Edit: I should have used a better title. I used FFMpeg for MP4 and AV1 creation/encoding. This is more about HTML5 video container code and direct AV1 file playback.

Web devs: what's up with this trend? For enterprise apps, I get it…single sign-on needs to detect what your email domain is to send you to your identity provider. For consumers, I feel like it's gotta be one of these reasons:

• Users don't know about the tab key being able to move to other fields on a page
• Mobile users don't really have a tab key, despite there being "previous/next field" arrows on the stock iOS keyboard since its inception (Android users, help me out please)
• Users tend to hit Enter after typing in their username, leading to a form submission with a blank password
• Security, maybe? In the past I have sent a link and a password in separate emails or separate communication methods entirely. Are you hashing/salting these separately for better MITM mitigation?

Did your UX team make a decision? Are my password managers forever doomed to need a "keyboard combo" value for every entry from now on?

Non-devs: do you prefer one method over the other? If so, why?

Tildes maintainers: selfishly, thanks for keeping these together :)

The more I think about it, the more I'm convinced of it.

The biggest selling point of Node folks has been the "single threaded, event driven" model, right? Unlike JavaScript, other languages work on a "blocking" basis i.e. you run a statement or command and the program "waits" until the I/O is complete. For example, you issue open('xyz.txt', 'rb').read() in python and the program waits or blocks until the underlying driver is able to read that whole text file (which could take arguably long time if said file is too large in size).

But with the Nodejs equivalent, you just issue the statement and then pass the "event handler" so that your program is never in the "waiting state". The whole premise of Node/JS event-callback is that "you don't call us, we will call you".

This is all nice in theory but if this were indeed true then Nodejs scripts should be blazing fast compared to Python and even Java considering that most programs we write are I/O heavy and 99% of time, they're just waiting for an input from a File/URI/User? If this event callback model indeed worked as effectively as claimed, Node would have been the numero one and only language being used today?

I think I'm starting to understand why that isn't the case. This whole "single threaded, event driven" thing is just a farce. You can also replicate the same thing that Node.js is doing in your Java or Python too by applying multi-threading (i.e. one thread just "waits" for the I/O in the background while the other keeps doing its job). All you've done here is just handed or delegated that complexity of multi-threading to Node.js?

Realistically, it's impossible to wait or block an I/O request while at the same time also letting the other part of the code engage in other tasks, that's the very definition of multi-threading. Doing "async" is impossible without multiple threads in that sense. Node must have a thread pool of sorts where one of them is engaged in the wait/block while another is running your JS code further. When the wait is over, the control is then passed to the "event handler" function it was bound to in that other thread.

What Node is selling as "single threaded" applies to application or business logic we are writing, node itself can't be single threaded. I feel it's better to just implement multi-threading in your own code (as needed) instead of using something convoluted and confusing like Node.js. What say you?

This is more focused towards those that use custom domains for their email. My current plan is up at Zoho for my team in a month, and even though I've used them for the past few years its been hit-or-miss (especially when using third-party apps or programs).

Who do you use? Who do you not trust? Who would you never go back to?

Sidenote: I hope this might eventually kick off a ~privacy group, one day.