Of course it's not required but when you start pushing the boundaries of a language with the goal of achieving a clean interface, obscure features you wouldn't normally resort to become appealing. I dislike all of the magic around Laravel's Eloquent ORM - model relationships, query builder, abuse of ForwardsCalls trait, etc, but at the same time I can appreciate how "clean" it all looks once it's put together.

> what used to be a complex blob of floats is now a simple grid layout.

And what used to be relatively simple static layouts designed for a 4:3 screen are now layouts that must accommodate a screen of any arbitrary aspect ratio and physical size. This means that most of your components will now have at least 2 layout states, one for desktop and one for mobile, usually horizontal and vertical respectively, accomplished by switching random layout related properties on and off. Arguably anything related to CSS layout comes with a ton of quirks and flex/grid are no exception. It's those quirks that put most people off CSS, because they're sometimes far from intuitive, hard to debug, and are just things you have to know.

> And what used to be relatively simple static layouts designed for a 4:3 screen are now layouts that must accommodate a screen of any arbitrary aspect ratio and physical size.

You should, yeah – it’s not inherent to CSS, though. For example on Android, your app can be ran on phone or tablet. I’d argue that the tools CSS provides for this are pretty easy to use.

> accomplished by switching random layout related properties on and off

You don’t have to, but it’s easier to understand usually.

For example, you can make a sidebar layout without @media (or @container) queries but you have to understand flexbox pretty well: https://every-layout.dev/layouts/sidebar/

(Personally, I’d just use an @container query here.)

> Declaratively describe your UI, React paints it. That's it. No app state management.

"that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.

> Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.

That's literally the point of React Compiler

No, you don't. React does.

I think I get what GP means. Without very judicious use of useMemo, you can't move a piece of state into an outer component without causing the rest of its children to also be re-rendered when the state is changed. I recall having to fiddle around with useRef at least a few times due to this, to avoid lots and lots of useMemo churn.

But that's the whole point of react compiler, which is the whole point of the post we're talking under

Have you tried wrapping component exports with memo? That basically solved everything for me. It’s the equivalent of functional components from before hooks.

> export default memo(ExampleComponent)

> the matchmaker shuffles the queue to avoid the same players being matched together repeatedly

This is actually something I hate about multiplayer games with matchmaking nowadays. I made the majority of my childhood friends only because we stayed on the same server and played together for hours on end. I don't think it's a stretch to say that a key reason for why we play multiplayer rather than single player games is to socialize. This has become increasingly more difficult when you just get a new set of people every 10-30 minutes.

This is why smaller AA games still keep this alive - to build community. For instance: Squad, a 80-100 player multiplayer game which primarily depends upon privately hosted servers ran by communities that actually care about the community and game. You'll still run into jerks like any online game, but it's a world of difference to the one-match/single-serving strangers you usually play with in other games.

This is something I really like about Rocket League’s matchmaking. Competitive is random, but Casual play allows you to keep the same lobby. You can even vote to rematch to keep the same teams. I’ve had numerous runs of 3-4 or more matches with the same people. It’s fun to get into a back and forth, especially if you rematch and the other team wins one - then you’ve _gotta_ have a tie breaker!

Yeah, way back when I used to play Counter-Strike, I eventually landed on one server I really liked and kept going to. It would be interesting to see who was on it at different times of the day, and eventually I got to be friendly with most of the regulars that showed up, and they knew me.

Turns out several lived near the server's location, in Texas, and at one point my friends and I just happened to be going there to visit a friend who was stationed at the nearby military base, and so I ended up meeting up with them for lunch. Nice guys.

> Turns out several lived near the server's location, in Texas, and at one point my friends

Also ended up in a similar situation multiple times (bunch of randoms found some server we liked, sticked around for matches across weeks, eventually became regulars and eventually figured out we lived nearby). Sometimes we'd bump into each other on other servers too.

After a couple of times of hanging out we've found out why (probably at least) we came across each other, we all default to sorting the server list based on ping (latency), and since we were all geographically close, we tended to end up on the same servers.

Texas wasn't that close to me (I was in Illinois), but the server was hosted within a data center, and had pretty low latency for me anyway.

Also it was very consistently up and low latency compared to other servers, so that's why I kept going there at first. Later on I kept showing up because I got to know people on the server.

Can't you make a group with people you like ? There a feature like that in rocket league.

Getting grouped with the same bad team mates repeatedly would just make me quit the game.

You can queue with people you already know, and some games do have a 'stay as a team in the next queue' option, but there's no real opportunity to actually get familiar with anyone, let alone a community, and play with them more in the same way that you get with community servers

Group with the same team until the magic runs out in 3 games then everyone quits lol

can't you queue with people

As someone who's struggled with starting projects from scratch multiple times over and not releasing anything for many years because it was never good enough, half-assing is not the mindset that helped me start shipping things. Rather, it was gaining an understanding about which parts of my code don't need to be perfect right now and also realizing that practically nothing is perfect the first time you do it.

I now leave a bunch of TODOs in my code as a reminder to myself that yes, this isn't the best it can be, I'll come back and make it better when it becomes a bottleneck, but for the time being 80% of something is better than 100% of nothing. This way I'm able to move on and continue doing meaningful work rather than wasting time obsessing over minute details that almost nobody else would care about.

I've been using Go's html/template for the last couple of months and all I can say is that it's still very much a toy. It's fine for basic loops and conditionals but anything beyond that is extremely limited and having proper reusable components is a constant fight against limitations, specifically because of the lack of being able to pass multiple arguments to a template. I wish the Go team had gone with something more akin to PugJS[1], which in contrast is very rich in features, flexible and dare I say fun to build components and pages with.

[1] https://pugjs.org/api/getting-started.html

> because of the lack of being able to pass multiple arguments to a template

I'm not sure if this I understand the issue correctly, but one can pass multiple arguments, by wrapping them e.g. into a hash (https://go.dev/play/p/89gP42K8XRb):

  package main
  
  import (
      "log"
      "os"
      "text/template"
  )
  
  func main() {
      err := template.Must(
          template.New("").Parse("{{ .greeting }}, {{ .user.name }}!"),
      ).Execute(os.Stdout, map[string]any{
          "user": map[string]any{
              "name": "earthling",
          },
          "greeting": "hello",
      })
      if err != nil {
          log.Fatal(err)
      }
  }

In my experience, the module is far from a toy, but it's not always obvious how to use it properly, at first.

> Also, VSCode is built on Electron

That's not the point. The point is that it doesn't use a framework like React, Vue, etc., it instead directly creates and manipulates DOM elements, somewhat like Puter.

> when pieces fit together nice or can be refactored cleanly

This is a trade-off that makes sense to embrace in some contexts, and I do believe that web is one of them. The more nicely your pieces fit together the harder it'll be to break them apart. You can only refactor cleanly once you are aware of all the requirements, but those requirements are usually constantly changing in the context of web and so your pieces fitting together a little too nicely means that you now have to refactor a lot more code.

This might be one of those things like monitor refresh rate where you can only really tell the difference if you've experienced the better version for a while, but I haven't ever felt slowed down by the speed of VS Code.

I do think it's something like that. Things can quickly get to the speed that feels "fast enough" that they don't feel subjectively slow, but can still be sped up by a couple orders of magnitude. If you Ctrl-F something and it takes a few hundred ms, you probably don't feel like it was slow, but in reality the "speed-of-light" for this operation was probably orders of magnitude faster than it happened on your device. Once you experience something close to the theoretical speed, it's really hard to go back to something you thought was perfectly fine before. And you start noticing that everything feels slower than it "should"..

I think of something like grep, where if I tried to grep a large hierarchy it'd be really slow and I'd sorta reason to myself "well yeah it's a lot of files in a large tree, of course it'll be slow!". Then I installed ripgrep and suddenly what I thought was a reasonable speed was shown to be unreasonably slow!

Every now and then I switch back to Apple's Terminal app, and I'm blown away at how much faster it is at just typing than iTerm it is, and how much nicer that is.

I switched to iTerm2 a few years ago due to blurry fonts on zoom with Terminal.app . Wonder if that's still a problem?

A few months ago I switched to WezTerm and, after some config wrestling, I've been very happy using it (https://github.com/bbkane/dotfiles/tree/master/wezterm).

it is actually faster and snappier to use on a beefy M2 max, on the same hardware zed starts up in half the time. the difference is very noticeable. of course it is much less configurable and doesn't work with a lot of things VS Code can do easily.

edit: see this comment for a much better explanation than mine of what I originally meant https://news.ycombinator.com/item?id=39409763

Startup would have to be terrible for me to bother.

VS Code starts in under a couple of seconds, and I have it open all day long; once open, other windows open even faster than that.

If it took any longer than a couple of seconds, I'd start blaming the extensions other editors won't have.

> Startup would have to be terrible for me to bother.

that's just the first noticeable difference.

but there have been instances lately where opening, editing and saving the file took me less time with zed than just open it in VS Code and waiting for it to be ready for inputs

> VS Code starts in under a couple of seconds

I am talking about relative speed differences. Imagine you open the same code base and the editor is ready in half a second. going back to the "slower" one would be unbearable.

now admittedly zed is no way near to the extensibility of VS Code so it is probably doing less and that's where probably much of the speed difference comes from, but it can't really be overlooked once you experienced it.

In a perfect world startup times would be indistinguishable from instantaneous.

And for an image previewer I'd care.

If I'm opening a codebase with thousands of files, I don't mind to wait a couple of seconds, as long as it's responsive afterwards.

I have. I have some huge Markdown documents I've needed to load and VSCode cannot render them without becoming super slow. In contrast, vim gets it done.

> It's a PHP project. It shouldn't have typing, that's for playing make-belief of writing in Java for the framework-oo-enterprise world.

At least types are enforced at runtime. Wait until you learn about TypeScript.