Comment by Nextgrid
5 hours ago
> maybe it's also our fault and we can do better?
Part of it is absolutely our fault; part of it is the industry.
In the electronics world, when you need <common functionality>, you can find an off-the-shelf part that fits your requirements, fit that part in and it'll work. When you need logic in a hardware device, nobody's rolling their own CPU from discrete parts - they just take the cheapest microcontroller fitting the requirements.
In the software world we don't seem to have this concept of building blocks for common functionality even decades into the industry. Most software projects are some flavor of CRUD app with custom logic operating on the CRUDed objects. You'd think all the complexity would be in the custom logic, but actually it's at best 50-50 and at worst most of the complexity is in the whole CRUD bullshit and not what happens to the object once it's CRUD'ed.
How come in 2026 there's still no way to have an off-the-shelf component I can buy to do "I have a table of objects on the server, and I want to expose this as a UI to the client"? Why do I still see people writing this by hand in React/$JS-framework-of-the-day and messing around with things like OpenAPI and/or writing serializers/deserializers by hand? I swear most of the work I see in the web development space is the minutia between client/server communication.
I think there are several reasons:
* overengineering/resume-driven-development: even if there was to be an off-the-shelf component to do the task, people would probably avoid it and prefer to bullshit around reimplementing a (worse) solution. That's already the case where people are using React/SPAs/etc for views that do no need any interactivity and could just be an HTML form.
* political choices influencing tech selection: more often than not some tech or service provider is selected based on political reasons and not technical, and then the engineering challenge becomes as to how to shoehorn this ill-fitting part into our solution.
* aversion to paid software: hardware engineers are expected and allowed to select parts that cost money. I've never been on a software project where we had an explicit budget for licensing software. Reaching for paid software became the least resort option I'd have to fight for and burn political points, while spending 10x the cost building a (shittier) replica in-house was considered fine.
Due to the last point there's also little incentive for software providers to build and sell such components, so the market is quite small and not competitive, with the (very few) competitors having their own dealbreakers. Firebase will give you the instant database and UI, but then you're forever tied to paying them rent. You can't just license the server component and install it in-house like you can buy an FPGA.
No comments yet
Contribute on Hacker News ↗