HN user
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.
Another 2014 batch member here. Hard to believe it is over 10 years I've been contributing to Watsi.
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!
The article image is literally the USA with a jetpack and Europe with a ball and chain. So it seems self evident why somebody might reference the US.
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.
The Zen of Python: there should be one obvious way to do things.
Python in practice: there is more ways of doing it than in any other programming language.
Oh Python, how I love and hate you.
Great template.
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.
Allowing reproducibility for a given change set.
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).
My 2 cents
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"...
I just assumed they were bots since they seem to be clicking at the rate limit.
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.
The model they use is relatively well known: https://en.wikipedia.org/wiki/Steward-ownership
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.
Fastmail and Kagi. And I'm very happy with both.
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.
I guess the quality here is resilience more so than immunity. I guess you can say opensource is much more resilient to enshittification.
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.
I guess, because the problem they are addressing is acute.
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.
And they have updated their status page now
In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on.
From experience, this goes from many little piles of hell to sprawling piles of hell. Obviously the current situation isn't good, but the "collection of interdependent composable SQL builders" will turn into an insane system if you roll things on 5 years. Everybody will yolo whatever they want into the collection, things in the collection will almost match a use cases but not quite and you'll get 90% similar components.
Obviously that is just one persons experience. But I'd take a single crazy sql file any day of the year because it's insanity is scoped to that file (hopefully).
But I'd agree the random string are no good. Maybe refactoring them into an enum either in the code or in the DB would be a good step forward.
I see a lot of push back against this approach. And since it is something I've been experimenting with recently, this is pretty interesting stuff. Clearly it has issues with query planning getting messed up, which is not something I had been aware of since my DB size I've been experimenting with is still only in the 10s of thousands of rows. But...
Using raw SQL file addresses:
1. Very difficult for devs to expose SQL injection vulnerabilities because you need to use parameters.
2. Having all available filtering dimensions on a query makes it very clear what the type of filtering is for that particular query.
3. Easy debugging where you can just throw your query into an SQL client and play around with the parameters.
4. Very clear what the total query footprint of you application is (e.g. files all neatly listed in a dir).
5. Super readable and editable.
6. Code for running the SQL is pretty much: here is my query, here are my params, execute.
7. Etc?
So an open question to anybody who is more familiar with DBs (and postgres in particular) than myself. Is there a reliable way to address the issue with this approach to querying that you all are flagging as problematic here. Because beyond the query planning issues, raw SQL files (with no building/templating) just seems to me like such a better approach to developing a db access layer.
I once used Team City and Octopus Deploy in a company. And ever since then, dealing with Gitlab Pipelines and Github Actions, I find them so much poorer as a toolkit.
We are very much in the part of the platform cycle where best-in-breed is losing out to all-in-one. Hopefully we see things swing in the other direction in the next few years where composable best-in-breed solutions recapture the hearts and minds of the community.
Just from personal experience. This is a great way to avoid blogging and instead work on your blog. It totally works for some people though.
If you are saying his experience (which is bad) is the best experience you can get. Rather than playing devils advocate, I think you are supporting his argument.
If we were to play devils advocate, I think the best argument is that in an early technology cycle (which arguably smart phones still are). There is a reasonable expectation that the phone will move into obsolescence before the hardware expires.
How you square the concept of sustainable/long-lived products and technological advancement is of course the predicament we find ourselves in. The answer is of course modularity and repairability. So companies like Framework or Fair Phone is who you should be buying from (both with their own foibles). Whereas if you look at the philosophy of Apple you shouldn't ever think they value agency of the user/owner.
100% agree with how confusing it all feels. Smudging data and code back together feels like a massive step backwards. I can't but be reminded of the disaster that was ASP.NET Webforms.
It took me a while to grok that in SSR frameworks, you shouldn't treat the SSR backend as a data backend. The best mental model is that the "SPA" just now has a client-server boundary in the middle of it. You should have a normal data API servicing the SSR backend.
With this approach, this does mean that client-server auth can now either live in the SSR backend or as normal on the data api. Arguably doing it on the SSR backend makes the most sense since that is now your server boundary. In this context the resurgence of auth in the SSR space make sense.