3 ms·

> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware). Well, that's how they could be

> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware). Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too. Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time. > I don't get many of the concepts involved with building a microservice (circuit breakers, service discovery, etc) This is because you haven't really learned how to think about solving a problem with code, but have instead learned to apply a framework to any problem. If you try solving the actual problem you have first, which involves really understanding it, then you'll probably find that the framework solution is vastly overspecced for your particular situation. Because the framework has to cater for a much wider range of situations than yours. If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution.

rswail 6y ago
> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution. It will be more appropriate for right now. Whether it's smaller, tighter, or faster (or any other qualifier) is dependent on the code quality. As the manifesto says, using a framework involves tradeoffs. One of those is trading that direct current appropriateness for future expandability, reliability (bug repairs etc) and other advantages of using someone else's code that covers more use cases than your specific, current needs.
- marcus_holmes 6y ago
  I've seen this more often go the other way - that adopting a framework appropriate for the problem right now then turned out to be a massive restriction on the system as it grew, because the framework turned out to be inappropriate as the system developed. At least with homebew code, you can adapt it however you like. With framework code you're at the mercy of the maintainers, or you have to spend massively more effort adapting it to your needs, with the risk that a future update to the framework could break your code.
  - heavenlyblue 6y ago
    That system would never be exist if not for the framework. Also good luck hiring developers who want to work on your half-arsed system (or rather who would run away as soon as they realise that their experience is barely transferable to another business). With homebrew code you end up with a few really old developers whom you pay a lot because no one else exists in the universe to support your system. Everybody else comes and leaves while never saying that, to be fair - you really need to rethink your approach to software development.
    - marcus_holmes 6y ago
      Your experience does not match with mine.
davidbanham 6y ago
> Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time. Your application doesn’t need logging until _right before_ you have a problem that is solved by logging. I don’t use frameworks these days. I’m glad I was exposed to their ideas in the past. I’m glad that exposure shaped my current approach. A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.
- tlarkworthy 6y ago
  Logging is a weird one because now platforms (e.g. k8s) often offer that and it's a PITA getting your framework to stop persisting logs.
- dreamcompiler 6y ago
  > A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones. This. If you could hire a team of brilliant developers you wouldn't need a framework. Frameworks capture the design requirements of brilliant developers...but they're not your developers and they may not be your design requirements. The trick is to know when the framework's design requirements differ from yours so much that it's a better business decision to roll your own code than to change your requirements to match the framework. I kinda think far too many businesses change their requirements for reasons of short-term MVP and then paint themselves into a framework corner.
JeanMarcS 6y ago
I’ll add that when you write your own solution, it is suited for what you need it to do, and not all of other things. When using a framework (or a library) it can come with a lot of options you don’t need and can bloat your app. For example, we’ve made parsers that where waayyyy faster than what existed. But only because we knew exactly what was coming in and didn’t have to test a whole bunch of edge cases a standard library have to test. Same for a framework. To be useful it has to come with a lot of possibility that you probably won’t use for your special case, but that slows down the whole.
jasim 6y ago
It is necessary to have a fundamental understanding, and often frameworks, as you said, can cast us to a single shape, making it difficult to see how else the problem could be solved. But life is too short to always start at first-principles and rebuild civilization brick by brick. Frameworks have three things: the code artifact: a Rails or a React, then the reified knowledge it abstracts: like how to structure a web application, and the community and their cultural knowledge. Sometimes it makes sense to forego all of them and make it your own - especially when that layer of abstraction is core to the value you're creating and you want complete creative control over it. But often times they can be the difference between business success and failure.
eitland 6y ago
> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution. Only if you know what you are doing. I have read smart people admit that at some point they realized that the compiler had outsmarted their clever inline assembly hacks and I fully expect this to be true in a frameworks vs homebuilt scenario as well. Also: The number of people who knows my or your brilliant solution will always be dwarfed by the number of people who knows Rails, Django, Laravel or Spring, meaning as soon as you need to hire you are at a significant disadvantage. (I've seen brilliant people running frameworkless also, but I wouldn't necessarily recommend it for more ordinary people like me ;-)
- marcus_holmes 6y ago
  I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude. But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for. But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code. And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?
  - mcherm 6y ago
    > I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude. I don't think that's the actual message. I think the real message is more like "framework maintainers have significantly more total time invested than you do..." (especially when you add up over all the maintainers and bug reporters over the entire life of the framework) "...so they are more likely to have correctly handled some particular rare bug or special case than if you try to do it all yourself."
  - heavenlyblue 6y ago
harlanji 6y ago
>> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware). > Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too. IIS on Win 2k-ish and PHP were a sweet balance. Save file, reload page, file is seen with directives executed. Very much like JS now, sans live reloading. Rails and Django and Nuke and Drupal etc. were a good step toward including a lot of good patterns beyond the point of the required “common.php” getting too long and also CI reports became fancy with common frameworks out of the box, and other operational benefits.

rswail 6y ago

> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution. It will be more appropriate for right now. Whether it's smaller, tighter, or faster (or any other qualifier) is dependent on the code quality. As the manifesto says, using a framework involves tradeoffs. One of those is trading that direct current appropriateness for future expandability, reliability (bug repairs etc) and other advantages of using someone else's code that covers more use cases than your specific, current needs.

marcus_holmes 6y ago
I've seen this more often go the other way - that adopting a framework appropriate for the problem right now then turned out to be a massive restriction on the system as it grew, because the framework turned out to be inappropriate as the system developed. At least with homebew code, you can adapt it however you like. With framework code you're at the mercy of the maintainers, or you have to spend massively more effort adapting it to your needs, with the risk that a future update to the framework could break your code.
- heavenlyblue 6y ago
  That system would never be exist if not for the framework. Also good luck hiring developers who want to work on your half-arsed system (or rather who would run away as soon as they realise that their experience is barely transferable to another business). With homebrew code you end up with a few really old developers whom you pay a lot because no one else exists in the universe to support your system. Everybody else comes and leaves while never saying that, to be fair - you really need to rethink your approach to software development.
  - marcus_holmes 6y ago
    Your experience does not match with mine.

davidbanham 6y ago

> Your application doesn't need logging until you have a problem that is solved by logging. It's possible that you never have such a problem. If that's so, then building a logging subsystem is a waste of time. Your application doesn’t need logging until _right before_ you have a problem that is solved by logging. I don’t use frameworks these days. I’m glad I was exposed to their ideas in the past. I’m glad that exposure shaped my current approach. A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.

tlarkworthy 6y ago
Logging is a weird one because now platforms (e.g. k8s) often offer that and it's a PITA getting your framework to stop persisting logs.
dreamcompiler 6y ago
> A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones. This. If you could hire a team of brilliant developers you wouldn't need a framework. Frameworks capture the design requirements of brilliant developers...but they're not your developers and they may not be your design requirements. The trick is to know when the framework's design requirements differ from yours so much that it's a better business decision to roll your own code than to change your requirements to match the framework. I kinda think far too many businesses change their requirements for reasons of short-term MVP and then paint themselves into a framework corner.

JeanMarcS 6y ago

I’ll add that when you write your own solution, it is suited for what you need it to do, and not all of other things. When using a framework (or a library) it can come with a lot of options you don’t need and can bloat your app. For example, we’ve made parsers that where waayyyy faster than what existed. But only because we knew exactly what was coming in and didn’t have to test a whole bunch of edge cases a standard library have to test. Same for a framework. To be useful it has to come with a lot of possibility that you probably won’t use for your special case, but that slows down the whole.

jasim 6y ago

It is necessary to have a fundamental understanding, and often frameworks, as you said, can cast us to a single shape, making it difficult to see how else the problem could be solved. But life is too short to always start at first-principles and rebuild civilization brick by brick. Frameworks have three things: the code artifact: a Rails or a React, then the reified knowledge it abstracts: like how to structure a web application, and the community and their cultural knowledge. Sometimes it makes sense to forego all of them and make it your own - especially when that layer of abstraction is core to the value you're creating and you want complete creative control over it. But often times they can be the difference between business success and failure.

eitland 6y ago

> If you write your own solution to the problem, it will (almost by definition, and assuming you write decent code) be a smaller, tighter, faster and more appropriate solution than the framework solution. Only if you know what you are doing. I have read smart people admit that at some point they realized that the compiler had outsmarted their clever inline assembly hacks and I fully expect this to be true in a frameworks vs homebuilt scenario as well. Also: The number of people who knows my or your brilliant solution will always be dwarfed by the number of people who knows Rails, Django, Laravel or Spring, meaning as soon as you need to hire you are at a significant disadvantage. (I've seen brilliant people running frameworkless also, but I wouldn't necessarily recommend it for more ordinary people like me ;-)

marcus_holmes 6y ago
I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude. But the framework maintainers aren't looking at your specific situation. I mean sure, if you're writing yet another CRUD system for yet another SaaS product, then fine, use Rails, that's what it was designed for. But if you're not building Basecamp, then your application is eventually going to want to do something that Rails wasn't intended to do. And then you're going to have to write your own code. And if you're not confident that you can write that code, because you don't think you can write good enough code for this... then... why are you doing this?
- mcherm 6y ago
  > I kinda get this, the "framework maintainers are superhumans who write amazing code and nothing I could write could get close to that" attitude. I don't think that's the actual message. I think the real message is more like "framework maintainers have significantly more total time invested than you do..." (especially when you add up over all the maintainers and bug reporters over the entire life of the framework) "...so they are more likely to have correctly handled some particular rare bug or special case than if you try to do it all yourself."
- heavenlyblue 6y ago

harlanji 6y ago

>> These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware). > Well, that's how they could be structured. There are many other ways. MVC is only one option among many, and it has its drawbacks too. IIS on Win 2k-ish and PHP were a sweet balance. Save file, reload page, file is seen with directives executed. Very much like JS now, sans live reloading. Rails and Django and Nuke and Drupal etc. were a good step toward including a lot of good patterns beyond the point of the required “common.php” getting too long and also CI reports became fancy with common frameworks out of the box, and other operational benefits.