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 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!
I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows.
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.
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.
Potentially using the git hash as a seed would make sense, so for a given snapshot of code it is always going to be deterministic. When the git hash changes (i.e. your code) then that would result in a different set of test inputs running.
Just as an anecdotal experience. It doesn't necessarily go without saying.
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 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"...
Wiz seems to only be about 4 years old, as per wikipedia. That valuation in such a short amount of time surely must be some kind of record? Or am I missing something?
All great points. I try to de-google mostly from a personal perspective (though still haven't gotten off Maps or Android). I use loads of Google products at work though because I'm not the decision maker there.
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 really like the idea of Ecosia and Steward Owned companies, but as somebody who wants out of the Ad game completely, uses uBlock Origin religiously and pays for services like email and search. I haven't actually used Ecosia, but am interested in others experiences with it. But I imagine in the HN crowd a lot of other people fit the same profile as myself.
One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.