One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.

I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.

I also had the impression they would probably follow the Vercel style, framework as a business model, with it being sold to Shopify.I don't really know where it's all going, but it is not the sort of thing I would tie myself to.

Python in practice: there is more ways of doing it than in any other programming language.

Oh Python, how I love and hate you.

It certainly reflects the process I've gone during some difficult conversations, at least when I did them well. And I've certainly done the other approach where I just dug my trench and they dug theirs; oh lord, is it a terrible approach!

At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed.

This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.

Boiling down the conversation I see in the article, it just seems to be: the browser as a HMI vs the browser as a an application runtime. Depending on what you want to do one might be a better fit than the other. But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".

It's difficult to articulate the source of just how broken the discussion space is; nor have I made a particularly strong argument myself. But I think it's important to keep pushing back on conversations that position framework's like they are brands winning hearts and minds. Ala the fashion industry.

Allowing reproducibility for a given change set.

The most memorable discussion I had around PBT was with a colleague (a skip report) who saw "true" randomness as a net benefit and that reproducibility was not a critical characteristic of the test suite (I guess the reasoning was then it could catch things at a later date?). To be honest, it scared the hell out of me and I pushed back pretty hard on them and the broader team.

I have no issue with a psuedo-random set of test cases that are declaratively generated. That makes sense if that is what is meant by PBT. Since it is just a more efficient way of testing (and you would assume this would allow you to cast a wider net).

The SSR game is peak frontend fashion.

The players in this space sell hosting solutions and getting you onto their platform and spending money is their primary goal (i.e. increasing the amount of server side compute and ancillary "services" needed to deliver a frontend solution). Regardless even if you go SSR the backend elements should just be used for SSR, and potentially things like auth, but otherwise just go with a data API as normal that provides the SSR backend with data. Rule of thumb, the SSR solution should never be considered "backend" even if it is running on a server and not the client.

SSR means it is way more difficult to open the network tab in developer tools and understand how your frontend is driving your API. I don't think I fully appreciated looking at the JSON sent over the wire in this tab until I did some SSR work.

If you go with SSR expect ridiculous churn in your technology space.

In the end I have latched onto vanilla React (e.g. no framework like Next) SPA that lazy loads components so you don't have a huge download on the first page load. I use wouter for routing and am pretty much trying to minimize all other deps where possible. I've gone with Preact but am questioning that a little now since it feels like I'm going off-road a bit on my simple setup.

I'm no expert on the frontend but thought I'd share my experience walking down this same path over the last 3 months or so.

Edit: how ironic that I'm calling React "my simple setup"...

My personal experience with this model boils down to: you make a company and a charity. Where the charity owns special share categories in the company.

You can then have other share types for founders and investors. These share types can essentially be bought out (e.g. an investor share can be bought for 5x of it's initial value, say, allowing for investment with a 5x cap). Essentially allowing the charity to gain full shareholding at a certain point. But there is no requirement to have these other share types - but they are useful drivers to get the company off the ground.

Obviously this type of investment isn't something traditional VCs care for; other more philanthropic oriented sources are required.

I think Mozilla has been a good example of that but the perception has been that resilience has been crumbling for years. Without an independent business model they have been in a really terrible position from the get-go.