3 ms·

I respectfully disagree with one of the points you made: in my experience, micro frameworks like Sinatra or Flask work best for large projects while the more fu

I respectfully disagree with one of the points you made: in my experience, micro frameworks like Sinatra or Flask work best for large projects while the more full fledged ones like Rails or Django work best in small projects. The reason is that micro frameworks give you more flexibility and in large projects this is gold since you have to deal with so many requirements and multiple stakeholders. In large projects having to do more things "manually" is actually a good thing for this reason. It is likely that you have a large team so in terms of work required it's not going to impact you that much. You can still use libraries for the various things the framework lacks, e.g. it's not like you have to build authentication from scratch, but at least being modular gives you freedom to swap one library for another. On the other hand whenever I worked in small teams or solo I have been highly appreciative of frameworks like Django that have "batteries included" and let me get things done quickly and efficiently. It's true what you say "A field of infinite possibilities seems like a great idea, but you quickly realize it's actually a sea of infinite decisions." but this is more of a problem if you are working solo or in a small team, whereas if you have a large team you can put different minds onto different problems/features... (Edit: grammar)

lhorie 5y ago
It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard was that people doing willy-nilly things cause setbacks to efforts to make project-wide improvements. One example was that build times were very slow and there was an effort to implement incremental builds along some interface boundaries, but then teams would disrespect agreements to not violate constraints for that boundary (because immediate deadlines trump long term large efforts) A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. A project can be very very large, but be entirely CRUD forms, and Rails could fit like a glove. But on the other hand, a project could have predominantly "curveball" features (maybe it simultaneously has a real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).
- mastazi 5y ago
  > A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.
- midrus 5y ago
  > real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc). All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.
deleted 5y ago
[deleted]
midrus 5y ago
> The reason is that micro frameworks give you more flexibility and in large projects this is gold since you have to deal with so many requirements and multiple stakeholders Not my experience at all. The "new requirements" you mention are always about business, not technical. Frameworks like Rails, Django and Laravel solve a pretty good bunch of the technical challenges which, in my experience, are common to the 90% of everything we build in most web based companies. I've seen this argument of let's use flask/sinatra/express/fastapi because I need the flexibility/it is just a simple service too many times. And every single one ended up in a frankestein mix and match of 10s of other libraries that some developer ( now gone, of course) decided at the time was the best thing in the world until he got bored. Also, you're not forced to use everything in these frameworks. If you think your application just needs routing, you can also use them and call it a day. If it happens 3 years down the line that you need an ORM, then you have it right there waiting for you.
- mastazi 5y ago
  > are common to the 90% of everything we build in most web based companies. Imagine that you had to build something where you need to use 90 nails and 10 screws: it's not a good idea to do the job with just a hammer, you should probably have a screwdriver as well.
  - midrus 5y ago
    Fortunately I'm in the web development business and not in the construction one.
    - mastazi 5y ago
      Based on what you said in your previous comments I thought you were interested in magic :-p

lhorie 5y ago

It can go both ways. At work, I periodically get in contact with an extremely large codebase that is actively worked on by multiple teams. One complaint I heard was that people doing willy-nilly things cause setbacks to efforts to make project-wide improvements. One example was that build times were very slow and there was an effort to implement incremental builds along some interface boundaries, but then teams would disrespect agreements to not violate constraints for that boundary (because immediate deadlines trump long term large efforts) A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. A project can be very very large, but be entirely CRUD forms, and Rails could fit like a glove. But on the other hand, a project could have predominantly "curveball" features (maybe it simultaneously has a real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).

mastazi 5y ago
> A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is. This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.
midrus 5y ago
> real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc). All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.

deleted 5y ago

[deleted]

midrus 5y ago

> The reason is that micro frameworks give you more flexibility and in large projects this is gold since you have to deal with so many requirements and multiple stakeholders Not my experience at all. The "new requirements" you mention are always about business, not technical. Frameworks like Rails, Django and Laravel solve a pretty good bunch of the technical challenges which, in my experience, are common to the 90% of everything we build in most web based companies. I've seen this argument of let's use flask/sinatra/express/fastapi because I need the flexibility/it is just a simple service too many times. And every single one ended up in a frankestein mix and match of 10s of other libraries that some developer ( now gone, of course) decided at the time was the best thing in the world until he got bored. Also, you're not forced to use everything in these frameworks. If you think your application just needs routing, you can also use them and call it a day. If it happens 3 years down the line that you need an ORM, then you have it right there waiting for you.

mastazi 5y ago
> are common to the 90% of everything we build in most web based companies. Imagine that you had to build something where you need to use 90 nails and 10 screws: it's not a good idea to do the job with just a hammer, you should probably have a screwdriver as well.
- midrus 5y ago
  Fortunately I'm in the web development business and not in the construction one.
  - mastazi 5y ago
    Based on what you said in your previous comments I thought you were interested in magic :-p