4 ms·

> But I hope you agree that this would be really nice. Black boxes with tons of magic are great if you need to do exactly that one thing that creators had in m

> But I hope you agree that this would be really nice. Black boxes with tons of magic are great if you need to do exactly that one thing that creators had in mind. When you need it to work a little bit different you're usually either just out of luck, or the added flexibility makes whole api very complex (and usually buggy, as it goes hand in hand). It's just super hard to make things very high-level and simple, while still flexible enough. Having a number of simpler functionalities that you're free to compose any way you like is for me preferred approach anytime. Most of the things that you mention can be solved with fairly simple wrapper libs doing just one thing (tracking state of connection, tracking errors, batching requests, etc.). Perhaps not in a perfectly reusable way, but good enough to allow easy recycling from project to project, and it's way easier to use and debug and adjust than if we had one huge built-in service object to handle it all.

Garlef 6y ago
> Black boxes There are a few black boxes most people are very happy not to peek into; Having these black boxes is a huge productivity win: * Compilers * Garbage Collection * OS Kernels * File systems * Docker * App Stores / package managers * Infrastructure as code frameworks (i.e. terraform) * JS Frontend frameworks I think there's three things at work here: 1. Familarity with treating item X as a black box (High for compilers, low for infrastructure as code). 2. Maturity of the interfaces (High for compilers, low for infrastructure as code). 3. Relevance of the details for your use case / business context. > Having a number of simpler functionalities that you're free to compose any way you like is for me preferred approach anytime. Most of the things that you mention can be solved with fairly simple wrapper libs doing just one thing I totally agree: That's how I imagine how the magic functions are defined. > Black boxes with tons of magic are great if you need to do exactly that one thing that creators had in mind. This totally depends what your business context is. For most companies, dealing with CORS in HTTP requests is very far from their business domain. Still, developers spend a lot of time configuring and building endpoints, API clients, etc. at a low level of abstraction.

Garlef 6y ago

> Black boxes There are a few black boxes most people are very happy not to peek into; Having these black boxes is a huge productivity win: * Compilers * Garbage Collection * OS Kernels * File systems * Docker * App Stores / package managers * Infrastructure as code frameworks (i.e. terraform) * JS Frontend frameworks I think there's three things at work here: 1. Familarity with treating item X as a black box (High for compilers, low for infrastructure as code). 2. Maturity of the interfaces (High for compilers, low for infrastructure as code). 3. Relevance of the details for your use case / business context. > Having a number of simpler functionalities that you're free to compose any way you like is for me preferred approach anytime. Most of the things that you mention can be solved with fairly simple wrapper libs doing just one thing I totally agree: That's how I imagine how the magic functions are defined. > Black boxes with tons of magic are great if you need to do exactly that one thing that creators had in mind. This totally depends what your business context is. For most companies, dealing with CORS in HTTP requests is very far from their business domain. Still, developers spend a lot of time configuring and building endpoints, API clients, etc. at a low level of abstraction.