3 ms·

Thanks for the detailed response! I think I should've added more detail in my original post explaining that I'm very much pro-removing code, my gripes were dir

Thanks for the detailed response! I think I should've added more detail in my original post explaining that I'm very much pro-removing code, my gripes were directed at packages that have optional modules that aren't included by default because maintainers claim "users want small binaries". I'm of the opinion that most packages should include their optional add-ons in their default distributions, and offer a separate "minimal" version without any add-ons for the users with low-resource requirements. (See my response to the other comment above too)

franciscop 7y ago
I see, I totally agree! I want to rewrite https://serverjs.io/ https://serverjs.io/ at some point, and I'm thinking about what functionality to add. e.g., CORS will probably be a config toggle instead of having to add custom middleware. But what about things where it is purely an option? There's a slippery slope there IMHO. Database connection? For a server library, no way. Key Value store? Also no way... no, wait, those are used for sessions, now you have to either do no sessions by default, have in-memory sessions which are super tricky (because they "work", until there's tricky production issues) or add Redis/similar connection. Same for rendering templates, I added the 3-4 most common but not others and feels really "meh". It's also A LOT of work to add the top 3-4 options, even without documentation.
- nikisweeting 7y ago
  Those decisions seem pretty reasonable from the perspective of a mostly-Django dev! Do you think >30% of users would want to install those things every time they use serverjs.io? If not it seems fine to leave them out. I think Django supports db-backed/cache-backed/file-backed sessions out of the box, but I think Flask doesn't have native sessions at all, it's only addable with additional libraries, but I could be wrong.

franciscop 7y ago

I see, I totally agree! I want to rewrite https://serverjs.io/ https://serverjs.io/ at some point, and I'm thinking about what functionality to add. e.g., CORS will probably be a config toggle instead of having to add custom middleware. But what about things where it is purely an option? There's a slippery slope there IMHO. Database connection? For a server library, no way. Key Value store? Also no way... no, wait, those are used for sessions, now you have to either do no sessions by default, have in-memory sessions which are super tricky (because they "work", until there's tricky production issues) or add Redis/similar connection. Same for rendering templates, I added the 3-4 most common but not others and feels really "meh". It's also A LOT of work to add the top 3-4 options, even without documentation.

nikisweeting 7y ago
Those decisions seem pretty reasonable from the perspective of a mostly-Django dev! Do you think >30% of users would want to install those things every time they use serverjs.io? If not it seems fine to leave them out. I think Django supports db-backed/cache-backed/file-backed sessions out of the box, but I think Flask doesn't have native sessions at all, it's only addable with additional libraries, but I could be wrong.