5 ms·

What's incredible is how software engineers have failed over the last decade to truly advance the creation of CRUD apps. Making a CRUD app in many ways has bec

by khet 4y ago

What's incredible is how software engineers have failed over the last decade to truly advance the creation of CRUD apps. Making a CRUD app in many ways has become much more complicated than it was when I started programming 10 years ago. Today when I want to build an application, I often find myself frustrated and bemused at the state of things. Not because I find it difficult to write TailWind, or connect my Redux state to a component, but because I would have imagined the increase in the number of engineers would have led to more abstractions that would have simplified the creation of a CRUD app, which is are just glorified web forms. I wonder if ChatGPT had even stood a chance if engineers were good at engineering. But engineers are really mostly good at boiler-plating code complex enough to ensure job security. Which ChatGPT might excel at one day. What I would have liked to have seen is a world in which we were good at creating abstraction layers to solve an entire class of problems. But alas, I might have asked for too much.

emerongi 4y ago
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.
ducharmdev 4y ago
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.
- khet 4y ago
  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.”
  - ducharmdev 4y ago
    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.
darepublic 4y ago
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
DrFell 4y ago
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.
- aeonik 4y ago
  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.
  - marcosdumay 4y ago
    > 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.
    - aeonik 4y ago
      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.
ojr 4y ago
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
- hombre_fatal 4y ago
  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.
hnfong 4y ago
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.

by khet 4y ago

emerongi 4y ago

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.

ducharmdev 4y ago

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.

khet 4y ago
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.”
- ducharmdev 4y ago
  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.

darepublic 4y ago

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

DrFell 4y ago

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.

aeonik 4y ago
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.
- marcosdumay 4y ago
  > 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.
  - aeonik 4y ago
    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.

ojr 4y ago

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

hombre_fatal 4y ago
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.

hnfong 4y ago

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.