Comments URL: https://news.ycombinator.com/item?id=42921639

Points: 4

# Comments: 0

    The world needs a browser that puts people first, contributes to open standards using a brand new engine, and is free from advertising's influence.
     
    This is why I've co-founded the Ladybird Browser Initiative with Andreas and my family has pledged $1M to support Ladybird's development. I believe in Ladybird and I believe in Andreas' vision, and I hope you'll help us support an open, independent browser that supports you.
     
    Chris Wanstrath
    GitHub Founder & former CEO

Comments URL: https://news.ycombinator.com/item?id=37837327

Points: 75

# Comments: 4

And then incremental rebuilds (when I go and pull the latest changes once in a while to see what's new) take anywhere between 1-10 minutes, depending on what changed exactly. YMMV.

For an entire operating system, it's pretty cool already! I wonder if C++20 modules will take it down some more, it's been mentioned a few times as something to investigate.

I don't know much about the subject to be fair.

I believe his rationale is that other languages are generally awkward at talking about technical stuff, and SerenityOS is addressed at technical users anyway. In my own experience as a French native speaker, I do tend to prefer all my software to be in English rather than getting the awkwardly-translated-in-French version.

As far as accessibility goes, like anything in the project, it's up to someone passionate to step up and work on it.

The monthly progress videos are also nice in that regard.

I'm just one of many but I'm guessing his sincerity combined with his technical abilities make it all very compelling to watch and contribute with money or code, even though the system isn't at a point where you would want to use it.

Basically: it's a fun, open, ambitious project whose story is being told mainly through videos, with a kind and interesting person behind it.

Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able to make their own game servers).

When a player wants to join a server, they POST a request to the switchboard, which gives them back a token that they can send to the game server after establishing a WebSocket connection to it. The game server checks the token with the switchboard and gets back public user account info if it's valid.

Each game server's logic is currently single-threaded. I guess we might end up offloading some work to WebWorkers later on.

A server can publish some state info through the switchboard that will be broadcasted to other servers from the same user. This is used to show player counts in game rooms from a lobby, things like that.

I run the whole thing on a couple cheap Scaleway servers, with Cloudflare in front (no AWS nor containers or anything of the sort). My previous platform, built with Node.js (https://jklm.fun) is able to sustain at least 2000 concurrent players like that, though admittedly those are board-like games which are not very demanding, unlike the games for Sparks.land which will be more fully-fledged... so we'll see how that holds up!

If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.

> I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?

Not that I can tell. But if we need to, we can always do a minified bundle in production later on. So far it's just nice to not have to even think about it!

I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.

The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.

[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land