Any time something is adopted as broadly as JavaScript it's going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin' mess.
Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place!
Or would it?
We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!
> Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.
This such a complete and utter lie and I'm surprised people in 2022 still believe it.
You do know what's happening when you run Docker on your Macbook, right? Right?
Your frontend team needs an API call that retrieves only friend requests with user names/avatars because the current API call is too heavy.
Normally they'd go to the back-end team and ask them to add an endpoint or modify an existing endpoint to give them the exact data they need. The problem with that is global API surface area becomes more complicated. Complexity is bad because more mistakes are made.
With this model your front-end team can implement the endpoint themselves in the BFF and model the response data exactly as they need it.
They also don't need to deal with that one zealot on the back-end team that gives everyone a hard time about tiny irrelevant issues.
Not really. When you turn off recommendations, the app icons are hidden but the space for recommendations stays there! Yes, just a big ol' block of whitespace with a prompt to turn recommendations back on. It takes up like 30%+ of the start menu.
Right, I was just pointing out the flaw in the parent commenter's statement. You can't do "code version is tied to your database version" - that's just not a thing.
Which didn't answer my question at all. Adding more structure to the AST with @param/@return/whatever doesn't make for better documentation. It's useless crap in a real world scenario.
This is why I said it's hard to succinctly explain. Non-programmers and bad programmers can't tell the difference between Go and Python (for example) in this context. The actual difference is very very significant.
You may be right, but... and maybe I'm being naive here... if HN can do it, why can't local social networks? The amount of people in the network is even smaller than HN. I suppose the problem is finding good moderators that keep to an ethical standard and that ethical standard is different everywhere. Well I think I answered my own question lol
> The best way would be exporting docs from your codebase, and have all documentation related artifacts expressed alongside the code
I LOVE Golang's approach to this [1]:
- Documentation generation from code is built in to the language toolkit
- There is a standard for writing the comments so all of them look the same across every project
- It even supports code examples which are visible as a REPL in the generated docs
When people ask "what's so great about Go?". It's stuff like that which is hard to succinctly describe but makes a huge difference in overall quality of Go code in the wild.
Sure. We could also not use a container registry. Or resource management. Or liveness/readiness probes. For the database we could use RDS and take the latency/$$$ overhead. For file storage set up a separate EBS volume or whatever. But... why?
so there's that