Surely the argument is just to have an LLM stressing for vulnerabilities during the build pipeline before merging to main? Resulting in better security from LLMs.
One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.
While there is nothing inherently wrong with this. It does have vibes of Mayers and the Yahoo logo. The ship is going down but we have a fresh new look!
Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative.
I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
My personal experience is Remix has all kinds of problems akin to the issues in the blog post, including the mess that is remix -> react router v7. When I worked with Remix a year ago logging and middlewares were also a disaster. For example it didn't have middlewares, and had no way to create a LocalContext from the host (e.g. Express or whatever you use) that first starts handling the request down through the remix app.
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.
It's clear to me that the frontend conversation space is broken. Not even just the ecosystem being a mess.
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.
While I enjoyed the discussion as an exercise in stripping back positions to underlying principles. I find it a great irony that the overarching reason why they diverge on what is "good practice" is not discussed.
John sounds like he is about to start building a new type of database, and Bob sounds like he's knee deep in a 20 year old code base for a logistics company. Both of their positions are reasonable, and both optimized for specific contexts.
I found Bob's responses more measured (which I value a lot), with John's at times being more compelling. I do agree that over-composition is a real problem that Bob is on the wrong side of the line on. But to be fair, Bob and Clean Code comes from a time where it was the opposite and his position on this feels like a philosophy that has an over-correction (albeit - not necessarily a flaw) at it's core.
One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.