I think his website could use a framework and some off-the-shelf templates to make it easier to read :)
Using a framework will harm the maintenance of your software
61–70 of 550 posts
Re: Using a framework will harm the maintenance of your software
#62Without a framework whats the alternative? Roll your own everything...?
Re: Using a framework will harm the maintenance of your software
#63Since last year I've been working on a framework for making media processors (audio, etc): https://github.com/celtera/avendish
Every year I have 2/3 internship students. This year I put them on this framework as a baseline, compared to the previous years where the students would have to do things more manually through libraries. They all got at least 5 times as much done as the students of the previous years in the same 3-4 months span of time.
Re: Using a framework will harm the maintenance of your software
#64I'd think most things would be bad if you failed to follow that advice about them, and the frameworks I'm most familiar with (aspnet core, ef core) seem to be pretty good about making it easy to follow.
Re: Using a framework will harm the maintenance of your software
#65Frameworks come and go. What is trendy today will be deemed obsolete a few years later. By the time when the community no longer interested in said framework, it will feel like the rug got pulled leaving many projects stranded.
13 years into my professional career I'm still seeing Spring everywhere.
Spring: June 2003
Rails: August 2004
Django: July 2005
Symfony: October 2005
Re: Using a framework will harm the maintenance of your software
#66From the author’s About page: “I mostly work with Ruby on Rails. A professional, Open Source platform which powers enormous (e.g. Twitter.com) and tiny applications.”
Is your implication here that he's a hypocrite, or that he knows what he's talking about from experience?
It can give you a solid respect for the dangers of letting a framework grow far beyond a simple focus.
Re: Using a framework will harm the maintenance of your software
#67Earlier quoted context omitted.
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole: > The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
I think an easy example of that is what frustrates me the most in JS-land: everything has it's own CLI. Why? Quick start: `npm run nouveau-framework create@app 365 --with-voodoo`. I don't want that. I want (maybe, at my discretion!) to add your framework as a dependency, read some API docs, and just start plugging it in where necessary. But they all focus on greenfield projects, they all think the whole project is ab…
Then again when I'm greenfielding having the option to be up and running in 2 minutes is rather nice.
Re: Using a framework will harm the maintenance of your software
#68Re: Using a framework will harm the maintenance of your software
#69(formatting edited)
1) I'd like to see real data behind this claim. (feels very anecdata and I have reversely correlated anecdata)
2) Companies that have large codebases or large developer populations and don't have any of these things are often headed for disaster.
Re: Using a framework will harm the maintenance of your software
#701. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in…
Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the configuration).
What dictates program flow is when you use HTTP with Django (What its primary use case is) but that is dictated by the request/response nature of HTTP not by Django.
You can use as little or as much of Django as you want. Naturally, the more of it you use, the more it does for you.