jkaplan

1. Microsoft was heavily involved in orchestrating the 95% of employees to side with Sam -- through promising them money/jobs and through PR/narrative 2. The profit incentives apply to employees too

Bigger picture, I don't think the "money/VC/MSFT/commercialization faction destroyed the safety/non-profit faction" is mutually exclusive with "the board fucked up." IMO, both are true

> was it just Helen Toner’s personal vendetta against Sam

I'm not defending the board's actions, but if anything, it sounds like it may have been the reverse? [1]

> In the email, Mr. Altman said that he had reprimanded Ms. Toner for the paper and that it was dangerous to the company... “I did not feel we’re on the same page on the damage of all this,” he wrote in the email. “Any amount of criticism from a board member carries a lot of weight." Senior OpenAI leaders, including Mr. Sutskever... later discussed whether Ms. Toner should be removed

[1] https://www.nytimes.com/2023/11/21/technology/openai-altman-...

I feel like the "safety" crowd lost the PR battle, in part, because of framing it as "safety" and over-emphasizing on existential risk. Like you say, not that many people truly take that seriously right now.

But even if those types of problems don't surface anytime soon, this wave of AI is almost certainly going to be a powerful, society-altering technology; potentially more powerful than any in decades. We've all seen what can happen when powerful tech is put in the hands of companies and a culture whose only incentives are growth, revenue, and valuation -- the results can be not great. And I'm pretty sure a lot of the general public (and open AI staff) care about THAT.

For me, the safety/existential stuff is just one facet of the general problem of trying to align tech companies + their technology with humanity-at-large better than we have been recently. And that's especially important for landscape-altering tech like AI, even if it's not literally existential (although it may be).

I think the surprising thing is seeing such cohesion around a “goal to ship” when that is very explicitly NOT the stated priorities of the company in its charter or messaging or status as a non-profit.

Probably some combination of: 1. Pressure from Microsoft and their e-team 2. Not actually caring about those stakes 3. A culture of putting growth/money above all

That’s a fair point. I guess there are contexts where pseudonymity can be useful and enable types of interactions that otherwise might not be possible. Especially in online contexts where you’re interacting with people you don’t know anyway, so using your real name doesn’t add much value in terms of trust.

I’m still skeptical that work is a context where I’d want/need this. But it’s a thought-provoking idea!

Oh for sure! I’m not saying using real names automatically creates real relationships and trust, just that it helps. I just generally want to see the internet moving toward deeper, more meaningful interactions, which, like you say, is a big challenge, and almost certainly means some form of making things “smaller.” But making things more anonymous strikes me as the wrong direction.

It’s interesting to see all these ideas built around the idea that “more anonymity is better.”

I think the opposite is usually (not always) true, and that many of the issues we see in today’s internet stem from the fact that we have completely lost a human connection to the people on the other end of our interactions. (You can even go further and connect this to the larger loss-of-community trends across modern society.) Developing a real relationship with someone increases empathy and trust; it leads to healthier, clearer, and more productive communication; and it generally is good for everyone’s mental health and happiness.

Personally, I want a less anonymous and more communal internet (and society).

This comparison feels like it's less about Node vs Rails and more just about "batteries-included framework" vs not. (Although, perhaps there isn't really a Django/Rails equivalent in Node yet? I'm not definitively sure.)

>I’ve always found it hard to climb out of the plumbing, forget about it.

This is the crux it of it, and it's true for any web project not relying on "magic" frameworks. And of course, it comes with tradeoffs. Namely, frameworks can be inflexible, and they can be difficult to understand/debug under the hood.

There is no escaping these tradeoffs, with any framework or language. More magic means less plumbing and more initial speed, but less flexibility and potential issues as complexity/scale increases. It's all about trying to choose the best tool for the job.

The sophons are here

Even completely leaving aside the language/software diversity, the point is that the vast majority of web "frontends" are really just one thing (rendering the UI and responding to inputs) whereas web "backends" are frequently not really one thing (1 or more types of storage, 1 or more types of computation, responding to requests, perhaps event processing and scheduling, etc.)

I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)

Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.)

2. At the end of the day, web backends are just a lot more varied and complex than web frontends. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. And functionally, there's a relatively large set of common things they pretty much all do (routing, serve images, etc.) Therefore, it's relatively simple to build an opinionated framework that can still cover a good number of situations.

By contrast, a "backend" is really a lot of different things (like the four you mention, plus various types of storage and caching), which can use many different languages/technologies, all working together in different ways. It's hard to conceive of a universal "backend" framework that could cover all of that complexity.

3. There are some efforts to do this kind of thing (to some extent). Google's Firebase and AWS Amplify are the two that I think are closest -- they try to give low-configuration generic backend building blocks. (I'm currently using Amplify for a project -- still too early to tell. It also works with Next.js!) There's also platform-as-a-service options like Heroku.