Looking at it more broadly, you never have to worry about the TCP/IP stacks you're running on top of anymore. You never have to worry about the Windows API or the POSIX API anymore, as a web developer. For the vast majority of developers, those concepts have been "compressed" to nearly nothing. If you believe what he's saying in the keynote, the problems isn't that this compression doesn't happen, it's that it's not mature for the web development space. In fact, for user facing application developers, I don't think it will ever happen. The end user application will always get pushed higher and higher with the development stack growing underneath them. Today, TCP/IP is pretty much fully abstracted away for all webapp developers. Tomorrow, databases may reach that point.
Looking at it more broadly, you never have to worry about the TCP/IP stacks you're running on top of anymore.
Well, I do worry about TCP/IP in system design. But sure, when writing code I reach for an HTTP client library, not a TCP/IP library. Although to be fair, HTTP is an open protocol. Frameworks are not protocols. And even then, when the protocol goes wrong you will be struggling if you don't understand the underlying TCP/IP stack. I have had to resort to wireshark traces (and explaining how a 3-way handshake works) to prove to a vendor that a simple HTTP integration with their service was failing on their end.
Well that's kind of his point, throw the TCP/IP stuff to the proverbial Aaron to deal with. It's just that if you're doing the system design, you're playing the role of the proverbial Aaron.
But in other case I mentioned, I wasn't "Aaron" (and not every place has an Aaron). I was just a dev trying to use HTTP(S) to call another service. The vendor said it was a problem on our end, and if I didn't learn TCP/IP it would have been hard to prove otherwise. Regular devs still need to eventually learn how it works in order to fix it when things go wrong.
At the end of the day, customers will not accept "it's not my fault, but the framework" as an answer. They simply want it to work. The customer still holds the dev team responsible for the product, including everything their chosen framework does, good and bad. That's why I prefer libraries, because they can ideally be understood in isolation of the rest of the system. It is harder to do this with frameworks which mix many concerns.
I don't think we actually disagree in principle, but in degree of abstraction.
I'd agree with you there. Libraries, and anything that's that modular, are much easier to deal with than frameworks. I don't think platforms have that problem as much as frameworks do, since you're pretty much only dealing with things in the layer under you instead of other things in the same layer or even in the layer above you.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Looking at it more broadly, you never have to worry about the TCP/IP stacks you're running on top of anymore. You never have to worry about the Windows API or the POSIX API anymore, as a web developer. For the vast majority of developers, those concepts have been "compressed" to nearly nothing. If you believe what he's saying in the keynote, the problems isn't that this compression doesn't happen, it's that it's not mature for the web development space. In fact, for user facing application developers, I don't think it will ever happen. The end user application will always get pushed higher and higher with the development stack growing underneath them. Today, TCP/IP is pretty much fully abstracted away for all webapp developers. Tomorrow, databases may reach that point.
Well, I do worry about TCP/IP in system design. But sure, when writing code I reach for an HTTP client library, not a TCP/IP library. Although to be fair, HTTP is an open protocol. Frameworks are not protocols. And even then, when the protocol goes wrong you will be struggling if you don't understand the underlying TCP/IP stack. I have had to resort to wireshark traces (and explaining how a 3-way handshake works) to prove to a vendor that a simple HTTP integration with their service was failing on their end.
Well that's kind of his point, throw the TCP/IP stuff to the proverbial Aaron to deal with. It's just that if you're doing the system design, you're playing the role of the proverbial Aaron.
But in other case I mentioned, I wasn't "Aaron" (and not every place has an Aaron). I was just a dev trying to use HTTP(S) to call another service. The vendor said it was a problem on our end, and if I didn't learn TCP/IP it would have been hard to prove otherwise. Regular devs still need to eventually learn how it works in order to fix it when things go wrong.
At the end of the day, customers will not accept "it's not my fault, but the framework" as an answer. They simply want it to work. The customer still holds the dev team responsible for the product, including everything their chosen framework does, good and bad. That's why I prefer libraries, because they can ideally be understood in isolation of the rest of the system. It is harder to do this with frameworks which mix many concerns.
I don't think we actually disagree in principle, but in degree of abstraction.
I'd agree with you there. Libraries, and anything that's that modular, are much easier to deal with than frameworks. I don't think platforms have that problem as much as frameworks do, since you're pretty much only dealing with things in the layer under you instead of other things in the same layer or even in the layer above you.