Hacker News Reader

It makes me wonder: what if the solutions you have in mind do exist out there, but simply as open source projects with zero eyeballs on them? What if there are dozens upon dozens of them, each solving a class of problems but in a slightly different way?

In terms of organizing work among huge groups of people, I don't think any of the above possibilities would be feasible for an industry. We already complain about having just a handful of frameworks to choose from.

It doesn't matter if the solutions exist if engineers don't think for themselves. The last project I worked on was about a dozen or so forms and the code base was thousands of lines of react/redux boilerplate nightmare. That project didn't need to be an SPA, and it could have been built much simpler. Heck it could have been hundreds of lines with jquery & node/express.

I love this quote and I think its apt here, “Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands.”

I guess I see it more as a broader economic problem than purely one of individual responsibility. Sure, bad design choices are made by individual teams that could be avoided, but at the same time our industry incentivizes the problems you describe.

Many developers are trying to get React experience on their resume to be more hireable; they do not care whether it's the best solution for the business, only that it adequately compensates them for labor that they can use to sustain their families.

With smaller organizations I think you can better control the motivations behind design solutions, but larger orgs can become a complete mess due to the politics (e.g. tech leadership encouraging all teams to use technology X, regardless of whether it makes sense for many situations). Collectively, these decisions and the resulting norms put pressure across the industry, encouraging certain behaviors and discouraging others.

If you just need CRUD, define your models in Django and use the admin site.

Everything after the "but..." is beyond the CRUD. If you choose to use TailWind or React or whatever to write the frontend and it increases the complexity of your app, that's your (or your client's) choice.

That said, Django was around before you started programming, so yeah perhaps the landscape (including the fads) got a bit more complicated in the past decade. But... I was there during the PHP4 era and writing a CRUD app with forms back then was much more painful than it is now... You either have to invent your own web framework or copy&paste a lot of hand crafted HTML and SQL. I tried both.

Practical CRUD app architectures still exist like always. You just wouldn't know it anymore from social media. The engineers who understand it got exhausted of explaining the obvious over and over again. Just let the beguiled play with their insane contraptions. It's of no concern.

I feel like this is part of the problem, we keep trying to find the right abstractions, but it seems to me the ones that generalize well enough are tend to be very difficult for most to understand.

I've been down a rabbit hole for the last five years researching this, and I am converging on Clojure. I don't understand why transducers aren't used everywhere, they seem to solve a gigantic class of problems that I see everywhere.

I'm also getting the feeling that Haskell folks have really done a lot of great work, and plan to learn more about their typing system next. Monads seem to be a fundamental building block.

If I try to bring this up with engineering teams, I don't get any traction because nobody wants to learn any of this stuff. It takes too much time to ramp developers up, and management is skeptical because there aren't enough large-scale communities or companies built around the concepts from their perspective. Bottom line is, it takes too much investment for too much risk.

Instead we get a lot of half-baked and wrong abstractions incrementally invented for the latest pain point instead.

> Monads seem to be a fundamental building block.

Sorry, but no. If that or transducers are the things you think about on this context, you are going on the wrong direction.

Not that those aren't useful. Whatever software solves the OP's problem will certainly make plenty of usage of interpreters and lambdas (what monads and transducers are), and any developers should be able to use both of those. But those are completely removed from the problem, they aren't an attempt to solve it.

The apps that I write pull data, process it, and write it to another sink.

There are many different sources and sinks, but the processing pipelines tend to be the same.

Based on my research these abstractions are designed for this. Feel free to elaborate why I'm incorrect, or better abstractions.

I brought it up in the discussion relating to CRUD, because it's very similar to the code I used to write for straight CRUD. In fact both ends of the processing pipelines are identical to CRUD.

> Based on my research these abstractions are designed for this.

Those two are general purpose abstractions aimed at organizing code. They can certainly be used for this, just like they can be used for anything.

I'm somewhat into FP concepts, and here is how I de-jargon these terms:

> transducers

Just a function composition operator. Notes: is aware of iterators like `reduce`, and merges multiple consecutive of such loops into one. (should optimizing compilers not strive to do this anyway?)

> monads

Literally just an "interface". For instance, you will be able to .map() it.

> algebraic effects

Resumable exceptions (you can go back to the "throw" with the corrected data)

There's definitely a movement towards simplicity, adjacent to the movement towards complexity. For example Phoenix LiveView, which provides a SPA-like experience to the user while keeping the logic server-side. Making a beautiful, rich web application is definitely simpler than ever, as long as you pick your tools correctly. On the other hand, working in a company with hundreds of engineers, the job is probably harder than ever, as there is a lot of over-engineering going on and you need a ton of knowledge about so many different tools.

Large teams tend towards complexity and it's understandable and frustrating at the same time.

For spa web applications I would say things are better now than 10 years ago. I do think crud apps have suffered from a lot of churn with not a lot to show though. And I do think a world where we make these type of apps increasingly with ai seems feasible for the next 10 years

graphql and react is better than what we were doing 10 years ago and is way easier than rolling your own custom backend and frontend abstractions because react and graphql have a large ecosystem of resources of people using these technologies to build a variety of different apps, with tons of example code available on Github

People who complain about CRUD should also describe what they think they want. It seems to either cash out into zero boilerplate (no code) or something else that we seem to already have but just isn’t so compelling that it becomes ubiquitous.

CRUD is easier than ever and frankly not the pain point of software. Banishing boilerplate also isn’t a goal without trade offs, so it’s not a good litmus test to how good our tools are.