AshleysBrain

Would memory safe languages avoid these kinds of problems? It seems like a good example of a nightmare bug from memory corruption - 5 days to fix and the author alludes to it keeping them up at night is a pretty strong motivation to avoid memory unsafety IMO.

Does anyone know if any browsers have Ubuntu RISC-V ports? Chromium or Firefox perhaps? Might be interesting to give it a spin.

Our browser based game engine Construct (https://www.construct.net) supports rendering with both WebGL and WebGPU.

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

Agreed - the picker APIs are essential. Chrome Developers did a blog about how we use it in Construct, our browser-based game development software: https://developer.chrome.com/blog/how-construct3-uses-the-fi...

As it says - 65% of users save to local files. It's what people want.

WebM Opus is an open format that plays in all modern browsers now - including recent Safari releases. There are still some bugs though last I checked.

Are the apps actually uninstalled for real, or does the system just hide them to create the same appearance as uninstalling to satisfy legal requirements?

We make Construct 3: https://editor.construct.net

You can start with a visual block-based system and move on to JavaScript/TypeScript. We have a lot of schools using it to help teach programming concepts in a fun way. Happy to answer any questions!

We relied on Closure Compiler for years, but we're now moving off it to ESBuild + UglifyJS. Closure has the most advanced minification, but these days it's not well maintained - it's lacking support for modern JavaScript features like dynamic imports and private fields, it's not clear when or if any of that will be supported, releases have reduced to every ~6 months, and all too often if you file a bug the response is "this doesn't affect Google, tough luck". So unfortunately despite having the best minification I can't recommend it any more - it's basically a Google-internal project that happens to be on GitHub. UglifyJS looks like a better option these days.

I did a lot of coding with C++ and ended up moving to 100% JavaScript for our game creation tool Construct (www.construct.net).

I'm now a huge fan of JavaScript - I think it's a really underrated language. People often still talk about it like it's 2010. The modern language features are amazing, the performance is incredible - including the GC performance - and it's memory safe and no need to worry about allocations. If you want static typing, use TypeScript, which is also very good and is basically a static type layer over JavaScript.

My advice is look at the modern language features which now have wide cross-browser support, and be sure to use them. It can significantly change your coding style for the better. By that I mean things like modules, private class fields, nullish coalescing, optional chaining, async/await, map/set - some of which are fairly old now but are still getting new improvements worth knowing about.

As I mentioned in another comment, in short, WebCodecs and File System Access API I believe. Both pretty essential for an app designed for editing large video files from disk.

> If only it was possible to prove nothing goes back to the server

That's an interesting question, but I think it's also equally difficult to prove for non-browser software.

WebCodecs and File System Access API I believe. Both pretty essential for an app designed for editing large video files from disk.

I did mention that, but it doesn't mean it was first published then. It could have been first published years ago, and then recently edited to fix a typo.

This is a bit of a tangent but it always annoys me when content has no published date next to it. There's a tiny "last updated" date at the bottom. But how do we know if this is a new article or one from a few years back? With technology moving so fast it can significantly change the context in which you read an article.

As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own origin even when using security flaws to read any part of the address space.

I suspect the only reason Apple rebranded iOS on iPad as iPadOS a few years ago was just to be able to claim it's a separate OS for regulatory reasons, despite it obviously being the same iOS as run on iPhones but on a different form factor device. I'm glad this gambit did not fool the EU.

> That AI-generated header image is horrible...

It looks like there are rows of parked cars along the road... in ancient Rome!

I think this is more an illustration of how Apple are intentionally trying to hobble web apps so they can continue to tax all transactions on the app store, than any kind of issue with web technology itself. If Apple implemented the necessary features and fixed the bugs, it could well be a strong alternative to a native app. But they make money from preventing that and are doing everything they can to prevent other browsers from implementing quality PWA support.

Does the DMA actually require that other browsers support 'Add to home screen'?

Nope, it could still be a bug - they typically remain silent even when major bugs are causing disruption. Just one of several ways Apple make developing for Safari a nightmare.

I think it's worse than that: Apple managed to wrangle it so the new rules apply specifically to iPhone, and not iPad [1]. So the new rules apply only to iPhone devices in the EU. So then there's the absurd situation that, say, a Firefox user in the EU using the Firefox browser on both iPhone and iPad will in fact be using two entirely different browser engines. Imagine what a burden on support that will be, having to answer questions like "why do websites look/work differently between iPhone and iPad when I'm using Firefox on both?"

[1] https://9to5mac.com/2024/01/26/ios-17-app-stores-and-more-ip...

I don't think it's true that developers do nothing for Apple. If there were no third party apps for iPhone, Apple would sell many fewer phones. I suppose many could theoretically move to the web, but then the point still stands that third party apps are still making the iPhone much more worthwhile to own.

With proper competition, OS makers work hard to attract developers - think of Ballmer's "developers developers developers" clip from back in the day - as they recognise that developers add value to their platforms and help sway consumers. The trouble these days is there is no meaningful competition. No matter what Apple's rules are, developers are obliged to provide something for iPhone, and Apple can rest assured there is negligible chance of a third mobile platform gaining traction.

Apple know this and through their strict policies have imposed a cruel reversal of the situation: they claim they are doing developers a favour by deigning to allow them to access all of Apple's iPhone customers, and tax all their revenue for the service they ostensibly provide, even though developers do a lot to make iPhones worth having. It's an abuse of their market position and there's not much anyone can do about it - except as the blog says, publish to the web instead. It's not perfect but it's the only meaningful alternative to regulation, which Apple are obviously going to use every trick in the book to wriggle out of, because why willingly shut off billions of revenue from taxing app developers? Hopefully the web can gain traction as a way to avoid abusive app publishing rules.

I think you've misunderstood the point of the post. Of course bugs happen and things go wrong, including on our side. What makes it so much worse is Apple's opaqueness: no communication on bugs, no release schedule, no public plans. So we have no idea what will ship or when or whether catastrophic bugs will go to worldwide release or be fixed. For example how am I supposed to avoid booking a holiday when Safari's stable release happens, when the release date is an Apple secret right up until the very moment it begins its worldwide release? You can't blame me for messing up my planning there, because it's simply not possible, and it can result in a great deal of stress for developers like me.

All other browsers have enough communication and transparency to avoid this. Towards the end of the blog post I outline what Apple need to do - which all other browser makers already do - to make it at least vaguely tolerable to develop for Safari.

I used to think it was better to have Safari for browser engine diversity. However Apple develop Safari with such appalling negligence that it's changed my mind [1]. Having a single browser engine dominate is not a perfect situation and will have downsides. However it is still better than having to put up with Apple's negligence towards Safari.

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

We make Construct: https://www.construct.net

It has a capable block-based alternative to coding suitable for young people/beginners, and a "Behaviors" system that can get instant results (e.g. a built-in Platform movement). It's mostly 2D focused but can do some simple 3D (like retro-style FPS). If they want to go further, you can do JavaScript/TypeScript coding too!

Maybe they rushed it out originally, but it's been out for two years now, and I think it's reasonable to expect any rough edges to have been smoothed out over that time!

I've been regularly using Windows 11 for most of the time it's been out, which is about two years now. The main problem I have with it is even after two years it still feels beta quality. The number of major regressions in the main system user interface is baffling. I see obvious glitches fairly regularly, dropdown menus getting stuck and not dismissing, icons vanishing but still interacting, explorer windows appearing blank for a moment before their content appears, layout bugs (inputs extending past window edge, text labels overlapping), etc. etc. not to mention a bunch of features that went missing or became harder to access, like explorer context menu options (and others complain about moving the start menu), due to replacing the legacy UI with a completely new one that doesn't yet cover everything the old one did... but they shipped it anyway and even after a couple of years it's not back up to speed.

I've been advising others to avoid Windows 11 - stick to Windows 10 until Microsoft sort out this mess.

(Author here) Construct is completely independent of GameMaker. Key differences are it's fully browser based and built entirely on web technology, has more focus on the block-based alternative to coding, but also support for industry-standard JavaScript and TypeScript rather than a custom language (GML).

(Author here) It's useful to render things like gamepad buttons, in-game items and characters, etc. Here's an example from Nintendo: https://scirra.aha.io/attachments/7235903469701444113/token/...

Another point to note is this is rendered in to the canvas so it can be processed with effects and layered easily with other game content, which isn't so easy with HTML (although our new HTML layers feature also helps with that).