4 ms·

Sure? I mean any framework will constrain you to what it provides. These frameworks usually include some set of functionalities: - an underlying service to l

Sure? I mean any framework will constrain you to what it provides. These frameworks usually include some set of functionalities: - an underlying service to listen for http/https requests (eg: "web server") - easily map inputs to code/services ("routing"); often also providing helper functionality to extract data from paths, map and convert JSON (etc) to domain objects - some way to inject your data into a return "view" (json, html, xml, ???). Might also include reusable view code snippets (eg: "partials"), and/or some "design pattern" (eg: "layouts") system - an ORM or other db-layer abstraction - some background job processing abstraction That's about all you need; the extent to which the framework simplifies doing those things is akin to the amount of constraints. Everything else is gravy. Do note that "big" frameworks that provide ALL of that plus more can often be harder to work with since you might be forced to learn more than you need, and it's overwhelming. There's also the concern of modularity... if I don't like their ORM, can I use my own? How hard is it to add functionality not provided, etc.

fuzztester 3y ago
>Sure? I mean any framework will constrain you to what it provides. By definition, almost, compared to the bunch of libraries approach, whch is more flexible and composable.
andrewoneone 3y ago
Totally agree. The modularity and the amount of “batteries included” can eventually become a negative. The last thing I want is for someone to reinvent RxJava yet it seems to happen in every one of the more bloated frameworks. “Are you familiar with reactive programming? Oh cool - but are you familiar with mixing RxJava and Spring’s reactor? That’s what we now have and it’s a real treat sometimes.” This is just one sad and possibly poorly outdated example as I haven’t worked with spring in some years now.
- michaelcampbell 3y ago
  I worked in a place using Django, with dozens of additional plugins and enhancements. And my PR's were routinely flagged for writing 3-5 lines of idiomatic python that any python programmer (indeed, any PROGRAMMER) would have understood instead of spending half a day to try and find the "Django way" (or worse, the "whatever 5000 line plugin we installed to save the programmer from having to repeat 2 lines of idiomatic python 10-12 times") way to do it. Their (IMO insane) adherence to the common, but misunderstood idea of DRY was insanely unproductive. These frameworks become "languages" in themselves, and unless you're in it all day every day, it's _harder_ to get things done due to their incredibly large attack surface.
  - ahmedfromtunis 3y ago
    Can you give an example of this "Django way" code vs pythonic code dichotomy? I'm very curious to see how that may look like. I've been using Django for years now and was never faced with such choice.
    - michaelcampbell 3y ago
      It was over 3 years ago so sadly I can't. If I recall correctly a number of things I was forced to put into some sort of serializer. I'm also trying to remember what the plugin/enhancement was involved; "Django Rest", maybe?

fuzztester 3y ago

>Sure? I mean any framework will constrain you to what it provides. By definition, almost, compared to the bunch of libraries approach, whch is more flexible and composable.

andrewoneone 3y ago

Totally agree. The modularity and the amount of “batteries included” can eventually become a negative. The last thing I want is for someone to reinvent RxJava yet it seems to happen in every one of the more bloated frameworks. “Are you familiar with reactive programming? Oh cool - but are you familiar with mixing RxJava and Spring’s reactor? That’s what we now have and it’s a real treat sometimes.” This is just one sad and possibly poorly outdated example as I haven’t worked with spring in some years now.

michaelcampbell 3y ago
I worked in a place using Django, with dozens of additional plugins and enhancements. And my PR's were routinely flagged for writing 3-5 lines of idiomatic python that any python programmer (indeed, any PROGRAMMER) would have understood instead of spending half a day to try and find the "Django way" (or worse, the "whatever 5000 line plugin we installed to save the programmer from having to repeat 2 lines of idiomatic python 10-12 times") way to do it. Their (IMO insane) adherence to the common, but misunderstood idea of DRY was insanely unproductive. These frameworks become "languages" in themselves, and unless you're in it all day every day, it's _harder_ to get things done due to their incredibly large attack surface.
- ahmedfromtunis 3y ago
  Can you give an example of this "Django way" code vs pythonic code dichotomy? I'm very curious to see how that may look like. I've been using Django for years now and was never faced with such choice.
  - michaelcampbell 3y ago
    It was over 3 years ago so sadly I can't. If I recall correctly a number of things I was forced to put into some sort of serializer. I'm also trying to remember what the plugin/enhancement was involved; "Django Rest", maybe?