Ironically, I usually find abstractions with "concept compression" (aka frameworks) to be easy to get started. But in the long term create a much higher mental load than I would have with a library approach. I can't even count the times I've had to research framework internals because it was not behaving how I thought it should. So not only do I need to solve my problem, but now I need to understand how the framework operates to do so. That's far more mental load than a library, where a library only handles a specific piece like template rendering.
I find nearly everything the speaker says in this video just to be a narrative to support his own efforts, but is far removed from my experience with frameworks (aside from easy to get started). I've used a lot of different frameworks over the years, but not rails specifically. I should also note that I still live with software I wrote (terribly) 10+ years ago. So that certainly colors my experience, and "easy to get started" is not nearly as much of priority for me as easy to maintain. I find that frameworks generally conflict with the latter as timescale increases.
The comparison with Javascript seems a bit different from the video. Javascript's problem is more of an ecosystem/tooling mess. But a lot of platforms aside from rails have opinionated, prescribed solutions... especially for back-end.
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.
Ironically, I usually find abstractions with "concept compression" (aka frameworks) to be easy to get started. But in the long term create a much higher mental load than I would have with a library approach. I can't even count the times I've had to research framework internals because it was not behaving how I thought it should. So not only do I need to solve my problem, but now I need to understand how the framework operates to do so. That's far more mental load than a library, where a library only handles a specific piece like template rendering.
I find nearly everything the speaker says in this video just to be a narrative to support his own efforts, but is far removed from my experience with frameworks (aside from easy to get started). I've used a lot of different frameworks over the years, but not rails specifically. I should also note that I still live with software I wrote (terribly) 10+ years ago. So that certainly colors my experience, and "easy to get started" is not nearly as much of priority for me as easy to maintain. I find that frameworks generally conflict with the latter as timescale increases.
The comparison with Javascript seems a bit different from the video. Javascript's problem is more of an ecosystem/tooling mess. But a lot of platforms aside from rails have opinionated, prescribed solutions... especially for back-end.
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.