AshleysBrain

This is probably an unpopular opinion but I think that if all this effort went in to improving Firefox, or a fork of Firefox if the goal is to totally de-Google it, then that wouldn't be such a problem and it would overall be healthier for the web. I don't really understand the purpose of this titanic software engineering effort just to avoid... a default search engine setting?

I think you misunderstood: the point was sometimes project corruption is due to a defect in our software, in which case it is definitely our fault and we race to fix it. But most reports of corruption are bad zip files, which aren't our software (unless you think the widely used and battle-tested library zip.js is writing bad zip files, which I don't think is the case). My best guess is it's faulty hardware or system-level issues.

Author here: we write zip files with the widely-used library zip.js [1], so if that's writing bad zip files, the problem is going to be widespread across many web apps. But I'd argue that zip.js is thoroughly battle-tested (current open issue count: 0) and not the cause of the problem.

[1] https://gildas-lormeau.github.io/zip.js/

If the exact words we choose when writing matter so much, then why use a non-deterministic LLM that produces slightly different output on every run?

It's not an error, it's just saying the project exceeds the free edition limits, which means you can look around and preview it but not make edits to it.

Shameless plug but if you like small file size overheads, our browser based game engine Construct[1] exports an empty web project with about 300 KB overhead for a fully-featured engine. We achieve this by going all-in on the web platform so we don't have to ship a heavyweight runtime with it, and using a modular approach where only the components you use get exported.

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

Is this not a good example of how generative AI does copyright laundering? Suppose the image was AI generated and it did a bad copy of the source image that was in the training data, which seems likely with such a widely disseminated image. When using generative AI to produce anything else, how do you know it's not just doing a bad quality copy-paste of someone else's work? Are you going to scour the internet for the source? Will the AI tell you? What if code generation is copy-pasting GPL-licensed code in to your proprietary codebase? The likelihood of this, the lack of a way to easily know it's happening, and the risks it causes, seems to me to be being overlooked amidst all the AI hype. And generative AI is a lot less impressive if it often works as a bad quality copy paste tool rather than the galaxy brain intelligence some like to portray it as.

It sounds like they were testing with iOS 12? In practice that has fallen out of use and doesn't need to be supported any more. Yes, a bunch of problems are to do with Safari specifically, but if you target relatively modern versions only (iOS 16+ is pretty reasonable IMO) it'll save a lot of pain.

I read through this guide a while back and it is great. However it's fairly old now being from 2011 - are there any updated guides or explanations of what's changed since then?

That was from an AI hallucinating HN 10 years from now: https://news.ycombinator.com/item?id=46205632

Perhaps someone with good with reverse engineering skills could figure out what went wrong here - it might be amusing...

I think the article is slightly misleading: it says "Google has resumed work on JPEG XL", but I don't think they have - their announcement only says they "would welcome contributions" to implement JPEG XL support. In other words, Google won't do it themselves, but their new position is they're now willing to allow someone else to do the work.

It's easy to say "XYZ is dead, time to replace it with something better". Another example is the Win32 APIs are hideous (look up everything SetWindowPos does) and need replacing.

In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.

So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.

This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1".

If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making.

[1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...

IIRC JPEG2000 was never supported by any browser other than Safari, and even Safari recently gave up and removed support (around the same time they added support for JPEG XL). As to why other browsers never supported it, I'm not sure.

WebP seems pretty widely supported to me - on Windows at least, Explorer shows thumbnails for them, Paint can open them, other editors like Paint.NET have built-in support... I haven't come across software that doesn't support WebP for a while.

They were referring to some apps ignoring your default browser preference and opening Microsoft Edge whenever you click any link in the app. That's not a niche case, it's an everyday interaction.

Perfect blog post for HN IMO - any blog title involving "in too much detail" will probably do well! Great job with the post, the visualizations are fantastic.

Wish they said what they actually did to get these improvements!

I'm sure there's a time and a place for "vibe coding", but a related point is with larger software projects, most work is maintenance (shameless plug: see my blog post on the subject[1]). It should be obvious that if there's a problem in a serious project, "just work around it or ask for random changes until it goes away" is probably not going to get you very far. I suspect perhaps "vibe coding" was just pointed out with the attitude of "hey this is kinda cool", but hype is blowing it out of proportion.

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

I'd say that our JS game engine codebase is generally idiomatic, maintainable JS. We don't really do anything too esoteric to get maximum performance - modern JS engines are phenomenal at optimizing idiomatic code. The best JS performance advice is to basically treat it like a statically typed language (no dynamically-shaped objects etc) - and TS takes care of that for you. I suppose a compiler is a very different use case and may do things like lean on the GC more, but modern JS GCs are also amazing.

Basically I'd be interested to know what the bottlenecks in tsc are, whether there's much low-hanging fruit, and if not why not.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS/JS codebase?

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

Just to be clear, you can still access your projects without a subscription - it's only editing that a subscription unlocks. We also have a full asset store here: https://www.construct.net/en/game-assets

I think a few comparable development tools have sprung up, including ours, Construct [1], which is very much web-first.

I think the reason people say nothing replaced Flash is because now there are lots of tools instead of just one, as anyone can target HTML5, so the market has fragmented; and the market has changed, as people develop for app stores and platforms like Steam, so the web isn't as big a focus as it used to be (although it's still important).

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

It's nice to throw around ideas like this sometimes, but the reality is if a new browser is not compatible with 99.9% of existing web content, nobody will use it.

Mozilla have a positive view of the API [1], but it doesn't look like development has started [2].

[1] https://github.com/mozilla/standards-positions/issues/1053

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1923880

Previously if you moved an element anywhere else in the DOM for any reason - such as reordering elements, sorting a list, etc. - lots of kinds of elements would be reset: iframes reloaded, transitions/animations are cancelled, video playback is reset, focus is lost, even the scroll position is reset to the top. Some could be worked around (like saving the scroll position and restoring it), but others could not (like iframes being reloaded). Now with moveBefore() all these moves can be done while preserving the element state, which can dramatically simplify the usage of the DOM in some cases.

Is the ability to move elements preserving DOM state really the key to such attacks? Previously you could do the same but the iframe would reload - but if it's a small simple page, it could load very quickly, in which case it doesn't seem all that different to moving the iframe with its existing content.

Shameless plug, but I'd just like to point out this was actually made in our game creation software Construct 3! (https://www.construct.net)

It's mainly focused on 2D, but we have been adding some 3D features over the years that can handle retro-style content like this, although I'd speculate this is based on some kind of raycasting technique rather than true 3D.

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.