5 ms·

After a few decades of developing applications, I am convinced that frameworks are the wrong approach. You gain development speed in the beginning, but you los

After a few decades of developing applications, I am convinced that frameworks are the wrong approach. You gain development speed in the beginning, but you lose it later on when the framework introduces breaking changes and you have to keep working around a changing stack. Or the framework gets abandoned and it would be too much work to maintain it. Because it has so much bells and whistles you don't need. This one for example contains 1298 files without dependencies. Both, coding everything yourself or using lean libraries are better. There are very few lean libraries unfortunately. Keeping code elegant and simple is a rare skill. When there is a lean, well done library for my use case, I use it. Because if shit hits the fan, I can maintain the library myself.

anonzzzies 3y ago
> There are very few lean libraries unfortunately. Keeping code elegant and simple is a rare skill. So... You are saying 'you should write everything yourself with libraries that basically don't exist'? I agree with you somewhat, but it's not very realistic; it's so much faster to use something that gets you 80% of the way with minimum work. And you know it'll break in a bit but that's life. Also, frameworks like Django or ASP.NET have been pretty stable for a very long time. We have large Django projects from 10 years and updating those was a breeze.
- TekMol 3y ago
  it's not very realistic It is totally realistic. I have multiple projects running that do not use any external code. With millions of users. Those projects are PHP though. PHP has a lot of bells and whistles on board. Unfortunately with PHP 8, they started introducing a lot of breaking changes. So they lost my trust and I will use Python for new projects. Not sure yet if I will use Django (As you said, it seems pretty stable) or do the good old CGI approach. If I do the latter, I will probably write a new CGI library for it, because in the Python ecosystem it is all about long running processes nowadays and I think that is the wrong approach.
  - VectorLock 3y ago
    There are some good reasons that everything, PHP and Python included, moved away from CGI to long-running processes.
    - TekMol 3y ago
      Name one.
      - eesmith 3y ago
        In general, startup takes time - import dependencies, read config files, make a database connection, and so on. That time can be noticeable. Years ago I had to deploy on a network file system which was very slow for file stats. (It was designed for HPC and bandwidth.) Python startup (by default) requires a large number of stat calls. It took our CGI app over a second just to start. I was able to improve it by packaging the Python std lib as a zipfile, and our app as another, since zipimports avoid a lot of stat calls. TurboGears had just come out. I did a prototype using it. Its was so much faster! For organizational reasons were were not able to switch. IT took over and, after several years, replaced it all with a Java version.
        TekMol 3y ago
        What is your problem with startup time? Have you timed it? How long does it take? PHP starts up from scratch on every request, yet it blows Python out of the water performance wise.
        Thews 3y ago
        It's been a while since I've seen anyone brag about PHP's speed. PHP is quite slow at encoding and decoding JSON, very slow at any kind of tree data structure, and has among the highest memory usage of any language at printing a string of text to a console or otherwise. Python is faster at all of those things and it's quite slow. Those are kind of web related tasks, and the web benchmarks for say django vs laravel don't show that PHP is any kind of winner.
haswell 3y ago
I think this really depends on the kind of applications you’re developing, and how you use frameworks during the development process. Frameworks really shine at quickly proving out concepts. They enable prototypes that would have otherwise been too costly to produce, which is often the difference between a project moving forward or not. The problem is often what comes next: teams fall for the productivity boost and carry the rapid design forward expecting similar gains throughout the rest of the project. I use frameworks when I want to get ideas out of my head. I tend to throw framework code away if I take the project further, and I’m in a better position to implement from scratch knowing what I’d do differently. YMMV, the environment you work in makes a big difference, the kind of thing you’re building makes a big difference, etc.
- kbrannigan 3y ago
  this is developer's gospel for me So I don't have to always to use the framework's feature all the time ??!!! When I face an issue with the framework, I tend to question my ability as a programmer, even though i could code it myself. Like a non trivial django form, I could have just manually coded the form, then just pass the data to the view, validate it manually. Instead of fighting
- DenisM 3y ago
  This very insightful, thank you. A great example of finding a way out of clutches of a dichotomy.
PurpleRamen 3y ago
Frameworks exist, because you can't code everything yourself. And libs are pointless if you need interconnected gears, which UIs are very heavy users of. Frameworks exist, and remain to exist, because there is demand and they solve problems. But yes, not every framework is good.
dclowd9901 3y ago
I’m inclined to agree. Unless the framework implements a lot of opinionated behavior that aligns with your product goals, you almost invariably end up fighting it. And on a long enough time line, that tends to happen anyway. But that’s not why we adopt frameworks. We do it so that engineers are fungible commodities. It makes it easier to find, hire and onboard additional resources. Also requires fewer resources since you don’t need folks on your team dedicated to maintaining your house-built framework. So, while I agree that building something in house is better for getting exactly what you want from a framework, it isn’t very practical from a business standpoint.
mrits 3y ago
If your app lives in a vacuum I don't see why you'd ever need to upgrade the framework. If it doesn't then the code you wrote yourself will eventually break as the rest of the world advances their APIs and standards. Even a website written in pure HTML and put up on a small linux server a decade ago would have rendering issues as well as probably not allowed past browsers or corporate firewalls due to older SSL libraries.
- unoti 3y ago
  > If your app lives in a vacuum I don't see why you'd ever need to upgrade the framework. Unfortunately the only apps that live in a vacuum are embedded apps not connected to the internet. We should all be monitoring our dependencies for security upgrades. Eventually even a stable framework like Django goes out of long term support. I wrote a Django app in 2008 that is still in heavy use today and at some point had to go through and upgrade to a new major version. It wasn’t a breeze, it took me a few weeks. To leave the app live on that 10 year old version would have been irresponsible for security reasons. The only apps that live in a vacuum are embedded apps, like the one in a vacuum cleaner.
  - mrits 3y ago
    The vacuum gets power from an electrical network that is also fully capable of transferring structured digital information as well. My point is that your own code will also break if you don't keep it maintained for all practical purposes.
- dalke 3y ago
  My static pure HTML+CSS site is nearly 20 years old and renders just fine in modern browsers. It's so old it has no https interface. I do depend on my hosting provider to keep Apache and FreeBSD up to date, if only for security reasons.
  - mrits 3y ago
    Yeah, that was my point. You couldn't get to non https sites in a lot of situations
ye-olde-sysrq 3y ago
You could also just use some known, boring technology. I was using Java Swing in 2016. It was rock-solid and unchanging. It will outlive me. Nobody is going to touch it again (all the churn is now in JavaFX). And yet! It even got HiDPI support somewhere around Java 8 or 9 (or at least, whatever they did, Swing apps now respect display scaling when at one point they definitely did not).
VectorLock 3y ago
Compare and contrast your operating system, and how many files and breaking updates that gets.
paulddraper 3y ago
> I am convinced that frameworks are the wrong approach Frameworks are always eventually the wrong approach. But so many projects need a 1.0 without breaking the bank.
miahwilde 3y ago
Do you perchance maintain a short list of clean and lean libraries?
IKantRead 3y ago
I really want to agree with this, but the trouble is that an unstated prerequisite is that you need a team of developers that have a strong sense of software design. A sensibility I've come to believe is drastically in decline in more junior software engineers (though don't mistake this for a statement that the quality of these devs appears any less). Just take Ruby on Rails, which is probably a great example of a framework that runs into the problems you're describing. My experience with more contemporary, generally more junior, dev teams is that the "Rails" part of the framework is essential for these developers to maintain any loose semblance of adherence to any kind of architecture or design principles. Earlier in my career I remember, even junior devs, spending a fair amount of time thinking about about the abstractions they were using, making design decisions, and often times being more guilty than not of over thinking abstractions. Today I've seen so many very bright and talented engineers whose sole view of good software is minimizing the time from request to PR (and code reviews that strong favor minimizing the time from PR -> prod). If you have a bunch of senior engineers (not SV "senior", but truly experienced), and they're the type that still pick up SICP form time to time, or spend a Saturday reading a section of TAOCP, then sure I think the framework-free approach is best. But you also don't need to tell that to a team of engineers like that. Otherwise, frameworks and even languages that do the most handholding when it comes to design decisions are going to remain essential.
- kanbara 3y ago
  what’s with the jab about SV “senior”? where i am, senior engineers are properly senior. and nobody even knows what levels and titles people have. ¯\_(ツ)_/¯
pbreit 3y ago
Any suggestions for lean Python libraries besides Flask?
- datadrivenangel 3y ago
  Fast API is very lightweight.
billowycoat 3y ago
For a TUI though? A plain old terminal gives you next to nothing. Not even buttons or scroll bars. A lean library will turn in to a framework if you decide to build anything more than a minimally complex app. The widgets are conditional imports. If you don’t use the tree widget, it is never imported.
codegeek 3y ago
Most code is written to make money. Frameworks make it easy to not only start a project but run it for a long time with fast time to market. I agree that if it was just about writing nice code, libraries are good but if you want to make money writing code, frameworks help do it much faster. You could argue that you can make money writing without frameworks but at what cost and how many teams can successfully do that ? Framework gives any team (even average ones) the headstart they need to continue to actually do something that makes money.
- baq 3y ago
  Nail on the head. Too many devs care way too much about having a pretty solution instead of a cost-efficient one. The solutions space usually has a middle ground somewhere (affectionately called 'horrible hack' every once in a while). It's what makes a difference between a software engineer and a programmer. To paraphrase, anyone can build good software, but it takes an engineer to build good software quickly.
deleted 3y ago
[deleted]
sharts 3y ago
Nothing is stopping one from versioning and packaging their dependencies. Then there is no work to maintain anything and you can address any other changes with your own code if you like. Libraries can change as well. Frameworks are just that, a bunch of libraries.

anonzzzies 3y ago

> There are very few lean libraries unfortunately. Keeping code elegant and simple is a rare skill. So... You are saying 'you should write everything yourself with libraries that basically don't exist'? I agree with you somewhat, but it's not very realistic; it's so much faster to use something that gets you 80% of the way with minimum work. And you know it'll break in a bit but that's life. Also, frameworks like Django or ASP.NET have been pretty stable for a very long time. We have large Django projects from 10 years and updating those was a breeze.

TekMol 3y ago
it's not very realistic It is totally realistic. I have multiple projects running that do not use any external code. With millions of users. Those projects are PHP though. PHP has a lot of bells and whistles on board. Unfortunately with PHP 8, they started introducing a lot of breaking changes. So they lost my trust and I will use Python for new projects. Not sure yet if I will use Django (As you said, it seems pretty stable) or do the good old CGI approach. If I do the latter, I will probably write a new CGI library for it, because in the Python ecosystem it is all about long running processes nowadays and I think that is the wrong approach.
- VectorLock 3y ago
  There are some good reasons that everything, PHP and Python included, moved away from CGI to long-running processes.
  - TekMol 3y ago
    Name one.
    - eesmith 3y ago
      In general, startup takes time - import dependencies, read config files, make a database connection, and so on. That time can be noticeable. Years ago I had to deploy on a network file system which was very slow for file stats. (It was designed for HPC and bandwidth.) Python startup (by default) requires a large number of stat calls. It took our CGI app over a second just to start. I was able to improve it by packaging the Python std lib as a zipfile, and our app as another, since zipimports avoid a lot of stat calls. TurboGears had just come out. I did a prototype using it. Its was so much faster! For organizational reasons were were not able to switch. IT took over and, after several years, replaced it all with a Java version.
      - TekMol 3y ago
        What is your problem with startup time? Have you timed it? How long does it take? PHP starts up from scratch on every request, yet it blows Python out of the water performance wise.
        Thews 3y ago
        It's been a while since I've seen anyone brag about PHP's speed. PHP is quite slow at encoding and decoding JSON, very slow at any kind of tree data structure, and has among the highest memory usage of any language at printing a string of text to a console or otherwise. Python is faster at all of those things and it's quite slow. Those are kind of web related tasks, and the web benchmarks for say django vs laravel don't show that PHP is any kind of winner.

haswell 3y ago

I think this really depends on the kind of applications you’re developing, and how you use frameworks during the development process. Frameworks really shine at quickly proving out concepts. They enable prototypes that would have otherwise been too costly to produce, which is often the difference between a project moving forward or not. The problem is often what comes next: teams fall for the productivity boost and carry the rapid design forward expecting similar gains throughout the rest of the project. I use frameworks when I want to get ideas out of my head. I tend to throw framework code away if I take the project further, and I’m in a better position to implement from scratch knowing what I’d do differently. YMMV, the environment you work in makes a big difference, the kind of thing you’re building makes a big difference, etc.

kbrannigan 3y ago
this is developer's gospel for me So I don't have to always to use the framework's feature all the time ??!!! When I face an issue with the framework, I tend to question my ability as a programmer, even though i could code it myself. Like a non trivial django form, I could have just manually coded the form, then just pass the data to the view, validate it manually. Instead of fighting
DenisM 3y ago
This very insightful, thank you. A great example of finding a way out of clutches of a dichotomy.

PurpleRamen 3y ago

Frameworks exist, because you can't code everything yourself. And libs are pointless if you need interconnected gears, which UIs are very heavy users of. Frameworks exist, and remain to exist, because there is demand and they solve problems. But yes, not every framework is good.

dclowd9901 3y ago

I’m inclined to agree. Unless the framework implements a lot of opinionated behavior that aligns with your product goals, you almost invariably end up fighting it. And on a long enough time line, that tends to happen anyway. But that’s not why we adopt frameworks. We do it so that engineers are fungible commodities. It makes it easier to find, hire and onboard additional resources. Also requires fewer resources since you don’t need folks on your team dedicated to maintaining your house-built framework. So, while I agree that building something in house is better for getting exactly what you want from a framework, it isn’t very practical from a business standpoint.

mrits 3y ago

If your app lives in a vacuum I don't see why you'd ever need to upgrade the framework. If it doesn't then the code you wrote yourself will eventually break as the rest of the world advances their APIs and standards. Even a website written in pure HTML and put up on a small linux server a decade ago would have rendering issues as well as probably not allowed past browsers or corporate firewalls due to older SSL libraries.

unoti 3y ago
> If your app lives in a vacuum I don't see why you'd ever need to upgrade the framework. Unfortunately the only apps that live in a vacuum are embedded apps not connected to the internet. We should all be monitoring our dependencies for security upgrades. Eventually even a stable framework like Django goes out of long term support. I wrote a Django app in 2008 that is still in heavy use today and at some point had to go through and upgrade to a new major version. It wasn’t a breeze, it took me a few weeks. To leave the app live on that 10 year old version would have been irresponsible for security reasons. The only apps that live in a vacuum are embedded apps, like the one in a vacuum cleaner.
- mrits 3y ago
  The vacuum gets power from an electrical network that is also fully capable of transferring structured digital information as well. My point is that your own code will also break if you don't keep it maintained for all practical purposes.
dalke 3y ago
My static pure HTML+CSS site is nearly 20 years old and renders just fine in modern browsers. It's so old it has no https interface. I do depend on my hosting provider to keep Apache and FreeBSD up to date, if only for security reasons.
- mrits 3y ago
  Yeah, that was my point. You couldn't get to non https sites in a lot of situations

ye-olde-sysrq 3y ago

You could also just use some known, boring technology. I was using Java Swing in 2016. It was rock-solid and unchanging. It will outlive me. Nobody is going to touch it again (all the churn is now in JavaFX). And yet! It even got HiDPI support somewhere around Java 8 or 9 (or at least, whatever they did, Swing apps now respect display scaling when at one point they definitely did not).

VectorLock 3y ago

Compare and contrast your operating system, and how many files and breaking updates that gets.

paulddraper 3y ago

> I am convinced that frameworks are the wrong approach Frameworks are always eventually the wrong approach. But so many projects need a 1.0 without breaking the bank.

miahwilde 3y ago

Do you perchance maintain a short list of clean and lean libraries?

IKantRead 3y ago

I really want to agree with this, but the trouble is that an unstated prerequisite is that you need a team of developers that have a strong sense of software design. A sensibility I've come to believe is drastically in decline in more junior software engineers (though don't mistake this for a statement that the quality of these devs appears any less). Just take Ruby on Rails, which is probably a great example of a framework that runs into the problems you're describing. My experience with more contemporary, generally more junior, dev teams is that the "Rails" part of the framework is essential for these developers to maintain any loose semblance of adherence to any kind of architecture or design principles. Earlier in my career I remember, even junior devs, spending a fair amount of time thinking about about the abstractions they were using, making design decisions, and often times being more guilty than not of over thinking abstractions. Today I've seen so many very bright and talented engineers whose sole view of good software is minimizing the time from request to PR (and code reviews that strong favor minimizing the time from PR -> prod). If you have a bunch of senior engineers (not SV "senior", but truly experienced), and they're the type that still pick up SICP form time to time, or spend a Saturday reading a section of TAOCP, then sure I think the framework-free approach is best. But you also don't need to tell that to a team of engineers like that. Otherwise, frameworks and even languages that do the most handholding when it comes to design decisions are going to remain essential.

kanbara 3y ago
what’s with the jab about SV “senior”? where i am, senior engineers are properly senior. and nobody even knows what levels and titles people have. ¯\_(ツ)_/¯

pbreit 3y ago

Any suggestions for lean Python libraries besides Flask?

datadrivenangel 3y ago
Fast API is very lightweight.

billowycoat 3y ago

For a TUI though? A plain old terminal gives you next to nothing. Not even buttons or scroll bars. A lean library will turn in to a framework if you decide to build anything more than a minimally complex app. The widgets are conditional imports. If you don’t use the tree widget, it is never imported.

codegeek 3y ago

Most code is written to make money. Frameworks make it easy to not only start a project but run it for a long time with fast time to market. I agree that if it was just about writing nice code, libraries are good but if you want to make money writing code, frameworks help do it much faster. You could argue that you can make money writing without frameworks but at what cost and how many teams can successfully do that ? Framework gives any team (even average ones) the headstart they need to continue to actually do something that makes money.

baq 3y ago
Nail on the head. Too many devs care way too much about having a pretty solution instead of a cost-efficient one. The solutions space usually has a middle ground somewhere (affectionately called 'horrible hack' every once in a while). It's what makes a difference between a software engineer and a programmer. To paraphrase, anyone can build good software, but it takes an engineer to build good software quickly.

deleted 3y ago

[deleted]

sharts 3y ago

Nothing is stopping one from versioning and packaging their dependencies. Then there is no work to maintain anything and you can address any other changes with your own code if you like. Libraries can change as well. Frameworks are just that, a bunch of libraries.