This. It is resume-driven development. Especially at startups where the engineers aren't compensated well enough or don't believe the produce can succeed.

As someone who doesn't use React, there is React Native (for iOS & Android), and React (and that can be server-rendered or client-rendered).

There's also React Native Web

I'm sorry what

I find it is a good idea, it allows developers to cleanly define how to structure elements without random divs sneaking in.

It requires a strong design system and it probably makes it harder to use some web APIs but those can be reasonable tradeoffs

In case you want to use React to make Web sites as well.

They should make a version of that runs as an app on a phone

They have one, it's called React Native Web Native

Twitter is built in React Native Web

There was also react vr

In my career I've seen startups "shut down" and lay off the NA team.

I've seen venture capital acquire startups for essentially nothing laying off the entire product team aside from one DevOps engineer to keep everything running. I've seen startups go public and have their shares plummet to zero before the rank-and-file employees could sell any shares (but of course the executives were able to cash out immediately). I've seen startups acquired for essentially nothing from the lead investor.

In none of these scenarios did any of the Engineers receive anything for their shares.

Yet every day people negotiate comp where shares are valued as anything more than funny money.

The only reason I paid my yearly JetBrains subscription this year was to keep my lower price locked-in. I've been using VS Code all year. I won't renew my JetBrains subscription that I've had since 2009. Sad.

How is that relevant?

I thought you would just use another computer in your house for the flows?

My development flow takes a lot of RAM (and yes I can run it minimally editing in the terminal with language servers turned off), so I wouldn't consider running the local LLM on the same computer.

It's not about which of your computers you run it on, it's about the relative capability of any system you're likely to own vs. what a cloud provider can do. The difference is hilarious - probably 100x. Knowing that, unless you have good reasons (and experimenting/playing around IS a good reason) - not many people would choose to actually base their everyday workflow on an all-local setup.

It's sort of like doing all your work on an 80386. Can it be made to work? Probably. Are you going to learn a whole lot making it work? Without a doubt! Are you going to be the fastest dev on the team? No.

> Another old person thinking they figured out life

I didn't get this impression at all.

It isn't "sovereign" if the parent organization is controlled by a foreign company.

Yeah weird, I thought the company called OpenAI is all about naming things in a way that accurately represents their real status.

I know less than ten people with foldable phones, but without fail they all claim that the screen is durable, but I have yet to see any foldable phone without a cracked screen after a few years.

A lot of people crack their normal smartphone screens too. Every mall's got a guy making a living off of fixing them.

> The standard answer is scale. “Small programs don’t need types,” the reasoning goes, “but large programs become unmaintainable without them.”

This is not accepted wisdom at all.

If the argument is that even small programs benefit from types, then I'd agree. In the context of Typescript for example, leaving types out is hiding vital information needed for reading the code. Without it, you must infer that information on reading it, and you very well may infer wrong, incorrectly spotting a place where a function that appears to take a number is passed a string. To know if that's a bug, you must read the called function explicitly for the case to determine if an optional conversion is applied. And of course the inverse is even worse, because you may come to assume that all the functions taking numbers are also taking care to convert strings should they appear, when in fact no such assumption can be made.

I'm of the mind that the modern resurgence of typed programming languages is mainly the revelation that you can build your contracts directly into the structure of the code without necessarily needing additional (imperative, runtime!) assertions or physically separated unit tests to validate those assumptions as the software evolves. It's just inlining a certain kind of assertion or test directly into the declarations of the code.

He's even more wrong when the Python typing system allows us to catch bugs in small scripts.

All the dev servers I've used over the past 10 years come with warnings that they're not security hardened, so I'd be wary of using `tailscale funnel` even though it is awesome to share like that so easily.