AshleysBrain

The CEO did step down already: https://techcrunch.com/2023/10/09/john-riccitiello-steps-dow...

Yep, we've ended up on the same idea - we make a best effort to keep it working and if we can't we advise to switch to another browser. But tough luck on iOS, as other browser engines are banned...

I previously blogged about how Apple treat web developers with negligence when it comes to Safari [1]. This makes it looks like Apple treat other developers with negligence as well, which is unsurprising, frankly.

[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...

We are building a full game engine and editor fully in JavaScript [1], and we've got WebGPU support too [2].

[1] https://www.construct.net

[2] https://www.construct.net/en/blogs/construct-official-blog-1...

What I'm saying is in an ideal world web content should be able to detect whether some codecs are not hardware-accelerated, and so such workarounds should not be necessary. Of course, lots of naive web content might just check if it's supported and use it anyway... but surely the big sites like YouTube get this right?

Software decode has its uses - if you just want a small GIF-style looping clip, hardware support doesn't matter much, and it's nice to have one codec that can be relied upon to work everywhere.

Doesn't the Media Capabilities API [1] provide a way to determine if a codec is "power efficient" (presumably meaning hardware supported)? So then you can switch to another codec if AV1 isn't hardware-supported.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...

Huh, I didn't know that, good point! Even weirder though. Hopefully it's a prelude to built-in support.

Microsoft Edge does support AV1, but weirdly only through a Microsoft Store extension [1], even though Chrome has support built-in. This actually really sucks because in practice hardly any normal consumers would bother to install a strangely named extension, and so web developers have to assume it's largely unsupported in Edge. Safari ties support to a hardware decoder, which I suppose is understandable to avoid accidental battery drain from using a software codec, and means eventually in some year's time support can generally be relied upon when enough new hardware is in use. But that won't happen with Edge as things stand!

I think it's high time the web had a single audio and video codec choice that is both open and widely supported, which is why I've proposed support for AV1 and Opus for the Interop 2024 effort [2] [3].

[1] https://apps.microsoft.com/detail/av1-video-extension/9MVZQV...

[2] https://github.com/web-platform-tests/interop/issues/485

[3] https://github.com/web-platform-tests/interop/issues/484

We build a full game creation IDE and game engine which is entirely browser-based and almost entirely written in JavaScript (including all the performance-sensitive stuff), and the performance is ridiculously good[1]. You don't need WASM for good performance[2].

[1] https://www.construct.net/en/blogs/construct-official-blog-1...

[2] https://surma.dev/things/js-to-asc/

It looks like a well executed product, but I believe the future is to move towards running in the browser only, rather than browser wrappers for the desktop. For example, isn't just visiting a URL in your browser so much more easy and convenient than having to have an installer? Isn't it nice to use the already-installed browser rather than ship a full browser engine with the app?

We put our money where our mouth is as we develop Construct[1], a fully browser-based game development editor. It's only available in the browser. You can install it in Chrome and Edge so it looks much like a locally installed app. We actually used to have an NW.js wrapper for things like file system access, but browsers now support enough features (including the File System Access API in Chrome/Edge) that we retired the NW.js wrapper and just do everything 100% in the browser now. It works great for us and I think it will only get better.

[1] https://www.construct.net

I thought there were specific assembly instructions for this kind of thing, such as MAXSS in x86 [1], plus vector variants like SSE4 PMAXSD. Presumably it's possible the CPU can handle those with special branchless logic, depending on the compiler and CPU implementation. I guess you'd have to know about the CPU internals to know if the instruction is truly branchless, but it is branchless in the sense there is no conditional jump made in the assembly instructions.

[1] https://stackoverflow.com/questions/40196817/what-is-the-ins...

Most languages have a `max` function, so the core of the loop could be written with just something like: `maxV = max(maxV, v)`

That could be entirely branchless, right?

I remember finding a similar thing while working on minifying JavaScript. If you have code like

func("hello world");

func("hello world");

Then naively it seems that can be optimized to this:

let s = "hello world";

func(s);

func(s);

However once compressed, the second result is usually larger! It's basically because the second example adds the `let s =` part which is new unique content it has to store.

So if you want to minify JavaScript to a shorter version uncompressed, it's good to transform the first to the second. However if you want to minify JavaScript to the smallest compressed size, it's actually better to do the reverse transform and turn the second case in to the first! But then you get in to tradeoffs with parse time with a longer input, especially with very long strings - so I'm not sure any of today's minifiers actually do that. (Edit - turns out Closure Compiler does: https://github.com/google/closure-compiler/wiki/FAQ#closure-...)

contenteditable may have its flaws, but I'm not sure if it's fair to call it "abandoned" as browser vendors do still maintain it - for example this very week Firefox 115 came out and the release notes[1] refer to updates to how contenteditable works.

[1] https://www.mozilla.org/en-US/firefox/115.0/releasenotes/

It seems to me that Apple invented their own proprietary graphics technology (Metal), never supported a cross-platform one (Vulkan), then found not enough games ever supported Metal, so they added a translation layer for another proprietary graphics technology (DX12).

Wouldn't they have been better off just supporting Vulkan?

Someone I know pulled off some pretty big career changes: from a sound engineer working in windowless rooms, to a professional gardener, then to a software engineer. After several years working full time mainly outdoors as a gardener - including through the winters - they were looking forwards to working indoors again. And the pay was much better in software. So while some of us stuck in the office might gaze out the window on a sunny day and daydream about having a job out there in the fresh air, it can go the other way too.

There's several people here commenting that physical work can be refreshing and rewarding compared to office jobs, but often that's only in a part-time or volunteer capacity. I can attest to it being a nice change, but only ever as a part-time project. I would guess anything you do full time long-term will some time or another feel a bit of a grind. Manual work in particular can take a serious physical toll over the years, and being mostly sat down indoors for your job can end up being tempting too. I also know a couple of musicians who are perpetually on the road, and it's not always a glamorous globetrotting lifestyle - one said they mostly see highways and airports. But then there are great gigs too.

I think there's probably no such thing as a perfect job. That's not to say a change can't be refreshing or worthwhile though! Perhaps it's just that after many years most people eventually get a bit tired of whatever they're doing, and then the grass can look greener on the other side.

Why bring that up with respects to a technology that was collaboratively designed between all major browser vendors?

It would be great if browser makers published their own statistics on this kind of thing. They presumably have the real data. But they don't share it, so the next best thing is for a community of interested developers to try to collect it themselves. Of course that's not as good as the real data that the browser makers have, but what better option is there if you need data like this?

Firefox is working on implementing WebGPU support too.

That idea usually works, but doesn't apply to WebGPU, as it has some specific hardware and software requirements to be supported.

We make Construct Animate which can do Flash-style animation right in the browser: https://www.construct.net/en/animation-software

Waiting doesn't work when Apple do things like ship a working and spec-compliant WebAssembly API which works great so you start using it, then they completely break it in a subsequent update, and leave it both enabled and broken for months. No amount of foresight or caution will save you in that case. It's ultimately the browser maker's responsibility to make sure APIs work.

We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.

I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.

That means avoiding features that can enhance your software, improve performance, and help get ahead of competitors.

Browser makers, including Apple, always say to use feature detection - i.e. to use features when they appear to be available. The alternative is user-agent sniffing, which they advise against.

That Chromium dashboard is amazing for planning and exactly the kind of thing we need for Safari.

Browser makers always recommend feature detection (i.e. use a feature if it's available) over hacks like user-agent sniffing to selectively enable features. Web developers can't look in to a crystal ball and pre-emptively code around APIs with unexpected issues.

I credited the Apple developers with doing a good job in the blog. The point is Apple's policies end up turning what should be a routine bug fix in to a total nightmare.

I've filed dozens of issues with Apple and many of them go in to great detail. However when you're pushed for time and dealing with multiple potential emergencies, you can't always manage much more than a "heads up, this looks wrong" type issue. In the case of the first bug, it was indeed a real problem with Safari and it was Apple's responsibility to fix it. Given that Apple are a trillion-dollar company with thousands of employees, and we have a handful of people in an office in south-west London, I think it's reasonable that Apple does more of the heavy lifting investigating Safari issues anyway. Ultimately it's up to Apple to make Safari a high-quality browser, not us, although we still do our bit with bug reports where we can.

I credited the Apple developers with doing a good job in the blog. The problem is Apple's policies end up turning a routine bug fix in to a total nightmare.