3 ms·

loosely coupled components are the way to go I disagree. Had you added "in some situations" I wouldn't. The point of the frameworks, which are heavily coupled

by rguzman 16y ago

loosely coupled components are the way to go I disagree. Had you added "in some situations" I wouldn't. The point of the frameworks, which are heavily coupled components with many constraints, conventions and hidden parts of functionality is rapid prototyping. That means that you can go from 0 to something quickly without knowing all the details. For a large class of use-cases the ability to get something out there fast is more important than the technical debt you may incur by not knowing how everything is loaded. This is the case for a lot of new products, startups and such. On the flipside, if you have a very solid spec of what you're building (for example, if you are re-writing an already-existing piece of software with a browser-level test suite as spec so that it is easier to scale) then loosely coupled components are likely the way to go. And yes, as soon as scale comes into question loosely coupled components that you understand well are the way to do it. This just isn't always the case. Secondly, it is not clear whether the frameworks get in your way that much. I remember reading a blogpost about a shop replacing django bit by bit until there was no django. That seems pretty cool. On the other hand, there is disqus, which used django from the get-go, I think, and haven't swapped it out, but just built a lot of tools around it. On the third hand, there is probably a lot of sites that start with loosely coupled components and keep refining. They are all valid approaches. At the time you are starting it is usually unclear how to go about it. In general I agree that people should try to understand how their tools work, but there are only so many hours in a day, y'know?

jgalvez 16y ago
You have a point. Let me elaborate my thoughts on Flask a bit further. Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much. I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention. I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is no surprise, of course, since it comes from the same guys who made the Sphinx documentation builder. I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.

by rguzman 16y ago

jgalvez 16y ago

You have a point. Let me elaborate my thoughts on Flask a bit further. Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much. I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention. I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is no surprise, of course, since it comes from the same guys who made the Sphinx documentation builder. I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.