Live data from Hacker News

Textual: Rapid Application Development framework for Python

github.com

11–20 of 112 posts

Re: Textual: Rapid Application Development framework for Python

#11

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 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.

Re: Textual: Rapid Application Development framework for Python

#14

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…

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.

Re: Textual: Rapid Application Development framework for Python

#15

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…

> 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 Dja…

    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.

Re: Textual: Rapid Application Development framework for Python

#16

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’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.

Re: Textual: Rapid Application Development framework for Python

#17
post #4

I know textualize/rich are HN darling projects, but do we really want full-color mouse driven gui applications full with superfluous animations in our terminals?

We? No. Me? No. Some people? Sure?

I've been using textual a couple of months for live-system-analysis GUI and while the big flashy things with animation/mouse/gigantic whitespace borders are what they show off, you don't have to use any of that; It does take a lot of the complexity out of bigger-than-screen/scrollable windows/mouse interaction/layout details away.

It also has a nice selection of Widgets, including the DataTable, which either works for you, or works as an example of how to build things.

Re: Textual: Rapid Application Development framework for Python

#19

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…

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.

Re: Textual: Rapid Application Development framework for Python

#20

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…

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).
Post reply on HN