MCArth

If you've used both you know the OpenAI plans don't compare to Anthropic plans _at all_. Claude code subscriptions are probably worth 4x as much in API spend compared to the same OpenAI subscription tier.

This is completely out of touch with my worldview. I've lived in and around London my whole life and, while "see it say it sorted" is a common joke, I've never once heard someone say they dislike them

Google analytics numbers don't include users with adblock

Yup, but developer productivity with web library (e.g. react) > no library vanilla dom manipulation > canvas

no need to roll your own solution. If you want to ship a game, go high level :D

For web native rendering pixijs is good for 2d (and phaser is good also a good entry level). For 3d theres threejs/babylonjs.

There's also unity, which some browser games use but it has downsides on web (large build sizes for one)

None of the networking solutions will give you unreal engine netcode developer productivity (and that includes ones for unity). I use colyseus, it doesnt solve everything but will save you some work

Re saturation, it definitely depends on the genre, web is its own market. What type of game are you thinking of making?

As long as you don't read your writes and use transform for animations it won't cost you more than 0.5ms to 1ms per frame (could it be better? Sure. But developer productivity is important.)

I use react in my game platform bloxd.io - which I work full time on - and I couldn't be happier

Tbh when making a web game you'd be better served using standard web UI in tandem with your game even if canvas text wasn't blurry.

Web libraries (react, etc) are very advanced and it'd be incredibly hard for a js game engine to match them for UI

article says fungible raised $300 million (_not_ at a $300 million valuation)

This isn't true! I've encountered many bugs in safari (fullscreen pointer lock not working on most html elements comes to mind), and they certainly do not value quality.

That's like saying we should be writing all our applications in assembly.

No. Developer productivity is important, and it does impact the end user in quality and amount of features.

This just isn't true! There are so many features that have not been supported long after other browsers implemented them (webgl 2 comes to mind, though that is finally available - 4% of global web users still don't have support due to this, though!)

It's not just regex, it's a long list of features and bugs. The OP was simply giving an example. I've encountered many time-wasting bugs on safari in the past, which have simply been open for several years.

Amazing!

Music to my ears - from my own experience, safari is a pain to deal with. I've run into many bugs that haven't been fixed for years, and they've lagged behind in implementing standards like WebGL 2.

Hopefully this will force them to invest more resources into safari and webkit

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern.

It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful.

Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!

I've spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads

It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem

I'm not sure what the solution is, but I no longer use any packages which export only an es module.

I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads

It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem

I'm not sure what the solution is, but I no longer use any packages which export only an es module.