5 ms·

I wrote my first web app with Django. And then Rails. These frameworks taught me how a web app should be structured (models, views, controllers, services, migra

I wrote my first web app with Django. And then Rails. These frameworks taught me how a web app should be structured (models, views, controllers, services, migrations, middleware). Now, if I wanted to, I could build my own application without Django or Rails, as long as I had something to accept incoming HTTP requests, make responses, and a library to make DB calls. But I wouldn't have gotten to this point had I not learned Django and Rails first. I think using a framework turns many "unknown unknowns" into "known unknowns". I can read my framework's documentation and learn it has built in logging, so logging is something I need to think about when building a web app. It lets you filter sensitive data from logs, so that's something I need to think about. This is why I was building a type of application I didn't build before, I would look for a framework I could use, or something like it. I'd use go kit for building a microservice for example. I don't get many of the concepts involved with building a microservice (circuit breakers, service discovery, etc) and hopefully the framework would help me learn them.

pmontra 6y ago
> But I wouldn't have gotten to this point had I not learned Django and Rails first. You would because I did. I started coding CGI scripts in C in 1994 then discovered Perl's CGI.pm Then I handcoded SQL queries and discovered marshalling / unmarshalling / SQL injections etc. Then started using some library to spare me the issues. Repeat for any piece of the stack. Am I going back to frameworkless? No, because I would end up without customers. "No sir, it takes 6 months, not one, because I have to hand code everything or use my own buggy library instead of X which a zillion other developers use."
- piranha 6y ago
  So you suggest that all libraries outside frameworks are incomplete and buggy? Can’t really agree with you!
  - toast0 6y ago
    I have yet to run into a library that wasn't incomplete and buggy! Of course, frameworks are also incomplete and buggy.
  - all_factz 6y ago
    No. They're just suggesting that in 6 months the libraries they would create to support their frameworkless application would contain some non-trivial amount of bugs. That seems 100% reasonable to me. Of course, they could plug existing libraries into their frameworkless application, which seems like a much more reliable approach.
jv22222 6y ago
I worked the opposite way round. I built my own custom PHP frameworks for each project for 15(ish) years until Laravel and then I was finally convinced it was better to use someone else’s framework than mine. I liked doing it this way round because when I did Finally use a framework I had a pretty good idea of how it was all put together and also really appreciated the elegance and design choices they had made. I’m not sure I would have appreciated it so much if I had started out with the framework and not learned all the things it takes to build one under the hood.
- todotask 6y ago
  About the same as mine, I have started writing PHP code as my first project a decade ago without any web framework and not even a PHP proficient. Until Laravel first appeared in the PHP world when MVC approach was easy to pick up for a small site. I'm no longer find MVC approach sufficient for all projects and move on to Javascript, Swift, etc, finally settled on Go just before it turns 10th. I'm really appreciate I could build without web framework today.
  - motogpjimbo 6y ago
    Laravel isn't an MVC framework. I often see people make this point and it puzzles me because even the creator of Laravel argues that it's not MVC. Laravel has a "Model" abstraction, but its models are Active Record objects, i.e. database row proxies. The M in MVC is not supposed to be in 1:1 correspondence with your database tables. Laravel's Model class is poorly named. The closest Laravel would come to being MVC would be by adding your business logic to service classes and adding them to Laravel's service container - an approach that the Laravel documentation mentions as a possibility but doesn't make a big deal of. Indeed, the documentation largely encourages the use of controllers to contain business logic.
    - PaulDavisThe1st 6y ago
      Sounds as if you prefer the Microsoft take on MVC, where they introduced the "UI Model" as an additional component. (Real) Model -> fetch -> UI Model -> build -> View ^ | v build/modify ^ | v Controller The UI Model serves as a simplified version of the "real" model that can also use the data structures/objects used by the technology used in the View. In "original" MVC (outside of the use of this term in webdev), the "M" in MVC absolutely did refer to a 1:1 correspondence with the data at the core of the application. This works too, but when using various UI toolkits, adding the UI Model can make things feel a bit more natural.
marcus_holmes 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. 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.
lowwave 6y ago
For sure. Once one built with Django or/and Rails, it is much easier to know how to structure the other more decoupled frameworks like ExpressJS. Sometimes it is much better to decouple an app into different components that we need such as ORM, layout engine, depending on the task at hand.
brightball 6y ago
People forget what life was like before Rails and Django. Everyone can build their functionality in any way they want to, but the trade off is that anyone else who works on your code then has to figure out how you structured it, documented it and make sense of everything else along the way. It’s a huge headache if anyone other than you is ever going to work on your code. But that also only works if there is a clearly dominant framework in your language (like Rails and Django). In languages that are more built for the web out of the box like PHP, JS and Go most frameworks are just putting the pieces together in different ways and that leads to a lack of a dominant structure. Anybody can strip out parts to make something fast. There’s nothing special or magical about that. Assembling a cohesive approach to solving a repetitive problem that thousands of other people can get behind is significantly more challenging. It’s an exercise in optimizing education rather than optimizing performance. Good frameworks are hard. Bad frameworks are numerous and easy. Look for languages with a single dominant framework.

pmontra 6y ago

> But I wouldn't have gotten to this point had I not learned Django and Rails first. You would because I did. I started coding CGI scripts in C in 1994 then discovered Perl's CGI.pm Then I handcoded SQL queries and discovered marshalling / unmarshalling / SQL injections etc. Then started using some library to spare me the issues. Repeat for any piece of the stack. Am I going back to frameworkless? No, because I would end up without customers. "No sir, it takes 6 months, not one, because I have to hand code everything or use my own buggy library instead of X which a zillion other developers use."

piranha 6y ago
So you suggest that all libraries outside frameworks are incomplete and buggy? Can’t really agree with you!
- toast0 6y ago
  I have yet to run into a library that wasn't incomplete and buggy! Of course, frameworks are also incomplete and buggy.
- all_factz 6y ago
  No. They're just suggesting that in 6 months the libraries they would create to support their frameworkless application would contain some non-trivial amount of bugs. That seems 100% reasonable to me. Of course, they could plug existing libraries into their frameworkless application, which seems like a much more reliable approach.

jv22222 6y ago

I worked the opposite way round. I built my own custom PHP frameworks for each project for 15(ish) years until Laravel and then I was finally convinced it was better to use someone else’s framework than mine. I liked doing it this way round because when I did Finally use a framework I had a pretty good idea of how it was all put together and also really appreciated the elegance and design choices they had made. I’m not sure I would have appreciated it so much if I had started out with the framework and not learned all the things it takes to build one under the hood.

todotask 6y ago
About the same as mine, I have started writing PHP code as my first project a decade ago without any web framework and not even a PHP proficient. Until Laravel first appeared in the PHP world when MVC approach was easy to pick up for a small site. I'm no longer find MVC approach sufficient for all projects and move on to Javascript, Swift, etc, finally settled on Go just before it turns 10th. I'm really appreciate I could build without web framework today.
- motogpjimbo 6y ago
  Laravel isn't an MVC framework. I often see people make this point and it puzzles me because even the creator of Laravel argues that it's not MVC. Laravel has a "Model" abstraction, but its models are Active Record objects, i.e. database row proxies. The M in MVC is not supposed to be in 1:1 correspondence with your database tables. Laravel's Model class is poorly named. The closest Laravel would come to being MVC would be by adding your business logic to service classes and adding them to Laravel's service container - an approach that the Laravel documentation mentions as a possibility but doesn't make a big deal of. Indeed, the documentation largely encourages the use of controllers to contain business logic.
  - PaulDavisThe1st 6y ago
    Sounds as if you prefer the Microsoft take on MVC, where they introduced the "UI Model" as an additional component. (Real) Model -> fetch -> UI Model -> build -> View ^ | v build/modify ^ | v Controller The UI Model serves as a simplified version of the "real" model that can also use the data structures/objects used by the technology used in the View. In "original" MVC (outside of the use of this term in webdev), the "M" in MVC absolutely did refer to a 1:1 correspondence with the data at the core of the application. This works too, but when using various UI toolkits, adding the UI Model can make things feel a bit more natural.

marcus_holmes 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. 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.

lowwave 6y ago

For sure. Once one built with Django or/and Rails, it is much easier to know how to structure the other more decoupled frameworks like ExpressJS. Sometimes it is much better to decouple an app into different components that we need such as ORM, layout engine, depending on the task at hand.

brightball 6y ago

People forget what life was like before Rails and Django. Everyone can build their functionality in any way they want to, but the trade off is that anyone else who works on your code then has to figure out how you structured it, documented it and make sense of everything else along the way. It’s a huge headache if anyone other than you is ever going to work on your code. But that also only works if there is a clearly dominant framework in your language (like Rails and Django). In languages that are more built for the web out of the box like PHP, JS and Go most frameworks are just putting the pieces together in different ways and that leads to a lack of a dominant structure. Anybody can strip out parts to make something fast. There’s nothing special or magical about that. Assembling a cohesive approach to solving a repetitive problem that thousands of other people can get behind is significantly more challenging. It’s an exercise in optimizing education rather than optimizing performance. Good frameworks are hard. Bad frameworks are numerous and easy. Look for languages with a single dominant framework.