31–40 of 112 posts
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 f…
I would love to find a way to get some sort of emulation layer to get Textual apps running in the browser. Does anyone know of any projects that might aid in this silly goal?
This looks very cool. For the web browser version which is coming soon, will the “DirectoryTree” feature be supported? Any idea when the web view will be in beta/launch?
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 f…
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.
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 f…
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 c…
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
Earlier quoted context omitted.
There are some good reasons that everything, PHP and Python included, moved away from CGI to long-running processes.
Name one.
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.
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 f…
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 f…
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.