AshleysBrain

I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches.

If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure, you can end up in a situation where 90% of your work is maintenance, but you made that tradeoff - these should be things you consciously weigh up and decide, not just do automatically.

I think this is a good point - pure JavaScript code is indeed exceptionally fast. DOM calls do have relatively high overhead, and if the change kicks off CSS recalculation or layout, then that can be even more costly. However that's not representative of the performance of the JavaScript language itself.

The upcoming JavaScript Shadow Realms proposal looks like it solves a similar problem: https://github.com/tc39/proposal-shadowrealm/blob/main/expla...

Genuine question: what would it take for a lot of indie mobile developers to move to the web? It seems app stores are pretty punishing with their capricious rules and high fees, and the web avoids that with greater freedom, better backwards compatibility, and lower fees. Some of the tech was flaky 10 years ago, but a lot of web tech is impressive now, and still advancing (e.g. WebGPU and CSS container queries).

I guess discoverability and monetization are key points, but what about free art projects or small games built as side-projects and such? It seems to me they wouldn't have much to lose and a lot to gain by moving to the web.

Blogs are still an underrated goldmine of knowledge, especially in tech. I find academic papers often too abstract or opaque, textbooks are good but generalized, and documentation is reference-like. Stumbling across a tech blog where someone explains some fairly specific and difficult problem they had, and an interesting solution they found, can be exactly what you needed to solve a problem.

The web has its problems for sure, but don't forget there are still gems out there which the web has made possible. I'd love to see a comeback of blogging culture, but I guess a lot of that has been sucked in to social networks now.

The blog says "Should You Turn it On? Yes. Seriously. Turn it on when you have a supported OS and don’t look back." If that becomes the general advice, I imagine it will end up getting more broad use - even if most of the people who turn it on don't really need the extra security.

Disabling WebGL will block a lot of HTML5 games. I think there will be a lot of "WebGL not supported" or "browser out of date" messages that will need updating to include "please turn off lockdown mode"...

We're building one: https://www.construct.net

Apple do appear to be trying a bit harder with Safari - since the regulatory heat has turned up, they've started releasing Safari more regularly since v15, and adding more new web platform features. Safari still does have its problems but I don't think it's fair to say Apple are letting WebKit stagnate.

I think it's very unlikely that the web will end up Chromium-only.

macOS-specific browser share numbers are hard to come by, but on our own moderately sized website we see about 60% of macOS users choosing Safari. Even if iOS allows other browser engines, presumably a similarly large number of iOS users would also choose Safari, either because it's the default or because they like it. So regardless of what happens with iOS regulation, it seems likely there will always be significant Safari usage on the web.

So then the only way we end up with a Chromium-only web is firstly assuming a worst-case scenario for Firefox essentially falling out of use, but its usage on desktop appears to have stabilised around 7-8%. Secondly Apple would then need to decide to ditch WebKit for Chromium. I can't imagine they'll ever do that. Apple have a strong desire to do things their own way and keep full control over how their browser works. So I think we're a long way from a Chromium-only web.

I scored 29/30, only missing one because there were so many machine generated ones I started to just click the machine button repeatedly. Then I checked more closely and got all the rest right.

The machine generated ones are usually easy to spot if you look closely, because parts of the image are just nonsense (e.g. weird patterns, things out of place, odd focus). Machine generated images clearly have no actual understanding of the real world.

We are building Construct, an entire game development IDE in the browser: https://editor.construct.net

Their promise-based error handling seems to skip over a major gotcha: if the first `save` call throws an exception, it does not get handled in the `.catch()` callback! It would require its own try-catch to handle. That is an overlooked benefit of try-catch in async functions: it handles everything, both normal exceptions and promise rejections.

I think Le Hoang Quyen[1] deserves a shout-out for writing the initial implementation of ANGLE's Metal backend, which is now used to power WebGL in Safari. Impressive work! It looks like they got some recognition from Google already[2], which is nice to see.

[1] https://github.com/kakashidinho

[2] https://lehoangquyenblog.wordpress.com/2020/09/30/google-ope...

It's not really a server but you can do some interesting stuff with intercepting fetches in Service Workers, e.g. https://servefolder.dev - a little side project of mine.

There doesn't appear to be any clear proposals put forward. The goals under "Our campaign" are vague and high-level. How exactly can E2E encryption be done without putting children at risk, as they put it? This page at least appears to be silent on the matter. So it's hard not to come away thinking that this is just a "think of the children" attack on E2E encryption as a whole.

It looks like a cool project, but... why not use lightweight webviews (WebView2/WKWebView)? Or even the heavyweight Electron/NW.js? These brings you full web API compatibility, extensibility points, and webviews have a small footprint too. What does this project aim to do differently? I don't mean to criticise a hobby project if that's what this is, it's all well and good, I'm just wondering what the thinking is.

Just this week I had a submission hit the front page and end up with ~80 votes, but I only got ~40 karma, so I think this is still true.

Sorry about the formatting at the top. An unexpected problem with the blog system on our website! The rest of it looks OK though.

Unfortunately the HTML spec hasn't yet clearly defined how TextMetrics work, so you can end up with different text alignment and measurements between browsers. See this spec issue: https://github.com/whatwg/html/issues/6731

It's for games (not sure if that's what you meant) but our startup makes Construct 3, a NoCode platform for developing games: https://www.construct.net

Shameless plug: our game creation tool Construct 3 is free to use with the full features for the duration of Ludum Dare 49: https://www.construct.net/en/blogs/construct-official-blog-1...

As cool as copilot may look, it does seem like a fundamental problem could be: if people widely use bad practices, and only a small amount of code uses good practices, an AI model will probably suggest bad practices. The AI doesn't know what's good practice, just what people tend to do. Similarly it will probably tend to suggest legacy/outdated code, since less code will be using the newer modern alternatives. I'd guess that's what happened here, and it's a bit embarrassing that their headline marketing demo does exactly that. It may be difficult to mitigate as well, as this will be rife throughout the training data.

This blog says what I've always thought - that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code - not just DOM calls. If your pure JS code already is designed to eliminate redundant calls, then you already get the minimal DOM calls from JavaScript too. That's the best case, and VDOM can only be slower as it adds diffing overhead on top.

There might be other good reasons to use a VDOM (including cases like using the DOM in a web worker). But I don't think performance is one of them.

It seems to be a recurring problem with open-source/pay-what-you-want services that donations are hard to come by. I think that if you don't have to pay, than about 90% of potential customers who would have paid just won't. Sometimes it's because they think "hey, it's free". But I think in some cases there's even a desire to pay, but the organisation isn't geared for it. For example maybe the company's payment process is just too arduous to go through if you don't have to. Or maybe someone proposes it and is countered with "what's the business case?", which is hard to answer if it's free.

I think the answer is just make some kind of optional paid service that some of your bigger customers will need. It might be an anathema to open source folks, but having an optional proprietary add-on, or some kind of paid maintenance service or something like that, may well solve the problem.

A couple of years ago I spent a while researching issue trackers and could never find one that had everything I wanted. We settled on GitHub issues, which has a nice design, public access, labels, assignment, and new issue templates. But it's still missing private issues in public repos, and issues that are blocked on/depends on other issues. It's also clearly designed around repos rather than specific to issue tracking. We make do anyway.

I always thought that for a project this size, a 6 week release cycle was already super aggressive. We came from pretty much annual releases back in the IE days, so it made a huge difference to go to rapid releases. Does trimming another 2 weeks off really make a big difference to how quickly features arrive? I feel kind of sceptical that it's a meaningful difference. I would also guess a risk is that with less time on the pre-stable channels for testing, there might actually be more bugs and issues as a result. I'd be interested to hear the arguments in favour, which the blog post doesn't seem to go in to any real detail about.

I think there's a gap in the market for a tool like Electron/NW.js, but using the system webview, bundled resources, and just a few choice polyfills for desktop-specifics (e.g. reading the command line). Libraries like this are interesting as they look like they cover the webview piece of the puzzle, but with bundled resources and a couple of extra capabilities, you could actually start distributing lightweight standalone web apps for desktop. There's no need to distribute a full browser engine, it shares the system browser engine keeping memory usage down, and it auto-updates - fixing several common criticisms of Electron/NW.js apps. Maybe an opportunity for an enterprising developer...

Honest question: why does it matter if it's one file or not? For example if you're deploying to a web server, it doesn't seem a big deal if you're uploading one file or several... so why the issue?

There are actually a number of tools that allow easy HTML5 authorship for non-technical users. We make one too - Construct 3 [1].

I think one reason Flash had such prominence was their effective monopoly. Remember when you had to install a browser plugin to get Flash? They reached ubiquity, but it was basically an impossible job for anyone else to achieve. So if you wanted Flash-like content, Flash was your only real option.

Since HTML5 is based on open technologies, there are lots of competing tools on the market doing exactly what some people apparently lament are no longer available. They're out there if you look, and arguably it's a healthier marketplace since there's real competition - although the choice is more complicated now, since there isn't that one option everyone uses.

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