In other words, with default styling you have to calculate natural widths of every cell in the whole table before you can begjn layout out even the first cell of the table.

There are style settings you can use which change this, and allow layout of early cells or rows to complete without depending on later cells.

(Also the height of each row can depend on the height of the content of every cell in the row. But that's local to each row so it's a relatively small dependency.)

There’s a ridiculous number of Japan-centric things that make it to the front page compared to any other culture. Tech has always had a Japan obsession.

But is there a ridiculous number of Japan-centric things that make it to the front page compared to any other community? Are Japan-centric things discussed on HN more than Reddit, Tumblr, Imgur? Because that was my point; Japan is popular in general, not just popular on HN to the point it’s even worth singling out.

But attaching the Japan label suddenly makes it more appealing as it invokes many distorted (and misinformed) aspects of Japan.

It's the same annoying vibe that Koreans get when they come across a foreigner who is into Kpop. Most Koreans do not care for Kpop as do most Japanese do not care for Anime.

Yet these exports create a parasocial relationship with a foreign country that when broken turn them into passive aggressive bigots.

The more you covet the harsher the rejection. Japanese and Korean society simply has no place for outsiders. Having a Japanese passport doesn't make you Japanese as it will not change your ancestral history, having your gender changed on your drivers license doesn't change the biological history and so on.

I think you're mostly right on the money on that, but I'll also say it doesn't have to be all fetishization. A lot of US Americans legitimately do live in places where you don't have access to cozy nightlife like that because it's not what the market provides, and if it's to your tastes, I can understand desiring it.

I lived and worked in South Korea for a number of years, and I really enjoyed some of the laid-back wine bars and whiskey bars there, made for working-age couples and small groups in their 20s to lounge around and talk with a drink. That kind of atmosphere is very commonly available there, but fairly hard to find in Berlin (where I live now), where bars more typically are tacky, sticky, and play terrible music so loud you have to yell at each other. I also miss the late-night coffeeshops a lot, where I spent many a night with the laptop doing FOSS stuff - your typical Berlin café closes no later than 7pm. There are exceptions to these rules but the sort of places I like are generally a lot harder to find.

Note I e.g. get the same opinion from Catalan friends in & about Berlin, who really miss their chill bars and street-side places from back home in Barcelona and similar. So this is again more of a "I like this foreign thing I can't have here as much" than it is about Japan.

Everything else they would rather see devs stay on their platforms, see the official tier 1 scenarios on swift.org.

And for the few that aren’t okay with feeling out of place, the devs of those apps will now have to contend with shipping more macOS specific styles and workarounds.

I’m not looking to discuss Electron performance/etc so please ditch that discussion before it starts. I just find it interesting how comparatively tricky this particular UI styling might end up being for cross-platform developers.

And they're rational to do it this way. These companies shipping apps to millions of people all came to the conclusion that investing in native Mac software is not worthwhile to their business. Users don't avoid Electron-based products, and building native Mac apps slows you down. It's easier both technologically and organizationally to ship your web site as an Electron app. It costs less and you don't lose any users.

So I would be surprised to see _any_ popular Electron app get design updates to accommodate these changes.

As a user it makes me sad, but I find myself blaming Apple for losing this fight, not the hundreds of successful companies that all somehow make the same choice. If building native were an advantage, people would take it.

It's rational for businesses to do things that make them money, and to not do things that don't make them money or make them lose money. SaaS business believe that spending R&D budgets on growth hackers and web product engineers is a better return than spending those same budgets on macOS engineers. I suspect they are right.

It doesn't matter to these businesses that you personally avoid Electron apps. They don't care, and Apple has made it easy and rewarding for them not to care.

Electron apps are not all B2B or associated with a service. This restriction is odd.

> Or, what purchasing decisions have you made on behalf of your company that took Electron-ness into account?

Password manager. PDF software. REST client. Other developer tools.

You're taking the boring argument track here. Yes, they use their own design system language, but they still roughly fit in with an OS that's not random transparency/glass effects everywhere.

They clearly will not fit in with the new UI styling without significant thought and work.

It's not going to matter, most Electron apps look out of place on the Mac already. The developers are not going to care and probably most users are not going to care either (I used to be staunchly against Electron for this reason, but gave up, and now I choose just enjoy apps looking the same between platforms).

Apple neglected the desktop from ~2016-2020 and made two frameworks that are unpopular among developers (Catalyst and SwiftUI) after that. Outside some indie devs, the native Mac app ship has sailed. Even developers that had their roots in macOS (e.g. AgileBits) have given up and switched to Electron.

AFAIK, most people do most things on the Web. So, no, Electron Apps will feel like what most people use most of the time. It's native apps that will feel out of place.

The design language of native controls is usually much quieter and more subdued than the garishness that is allowed in the name of branding.

Consistency with native app/style had never been an issue, ever. It's stylistic choice. while I get that someone would like to have the same theme everywhere it does not prevent anything.

Every single webpage is different that the other and yet everybody browse the web.

There's plenty of pragmatic reasons not to build a native app. The concerning thing IMO is the hegemony of opinion here. After all, nothing says "hacker" quite like following all the rules properly and always doing the sensible thing. :)

IMO the jury is out on how much they are.

> why are none of these gains being used to get back towards native app development?

because the different platforms are still radically different in a way an LLM can't easily and simply paper over. How do I specify a UI in a way that an LLM can competently implement it in HTML, SwiftUI and whatever Windows is using these days?

One argument might be that, like with any LLM output, you still do need to know it well enough to know if it's good or not implementation-wise. You still need that knowledge to understand if your performance for rendering in some scenarios is going to fall off a cliff.

Web (via browsers or Electron/etc) are mostly one train of thought. When you're doing native application development using host OS frameworks, you have to actually know the framework. LLMs don't really save you from that; i.e, I could have an LLM spit out whatever flavor of Windows-specific UI I need. I have zero way of knowing whether it's correct or not.

- I read once, although I have no idea how accurate this is, that a company could classify maintenance expenses (i.e., paying SREs and some SWEs to keep the service running and fix bugs) as non-R&D and therefore be able to amortize. That's another advantage to mature services over new services.