Live data from Hacker News

Textual: Rapid Application Development framework for Python

github.com

71–80 of 112 posts

Re: Textual: Rapid Application Development framework for Python

#71

Rapid application development is probably the wrong description. That’s already used by systems that have UI builders and code integrated, like Delphi etc and early systems like VB. I went looking for such a thing in this project and only found examples in Python scripts.

[deleted]

Re: Textual: Rapid Application Development framework for Python

#73
post #45
post #38

Earlier quoted context omitted.

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

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.

> Have you timed it?

I literally gave a timing number in my comment.

The >1 second time was for a very unusual circumstance. Unless you timed PHP startup time using straight CGI (not mod_cgi, nor FastCGI) on a Lustre file system about 15 years ago, with the appropriate set of extensions enabled for what our application needed, you can't really compare the two.

> PHP starts up from scratch on every request

Congratulations.

Now getting back to your request to "Name one", the PHP documentation at https://www.php.net/manual/en/install.unix.commandline.php gives essentially the same answer as I did:

"By default, PHP is built as both a CLI and CGI program, which can be used for CGI processing. If you are running a web server that PHP has module support for, you should generally go for that solution for performance reasons."

Re: Textual: Rapid Application Development framework for Python

#74

I was looking for a python graphical interface library and came across this, I came to the conclusion that it is way too resource greedy and anything you build with it will be heavy.

This can't be serious. The number of resources being consumed by web frameworks is absolutely insane, they are built on so many layers. .NET desktop apps the same thing. You need a full windows install, then graphics drivers, then the .NET framework stuff.

This is running in a terminal. The golang tui's are tiny by comparison to apps like office etc and can deploy in much smaller total footprints.

Re: Textual: Rapid Application Development framework for Python

#75
post #26

Did a cursory dive through, check: https://textual.textualize.io/tutorial/ and https://github.com/Textualize/textual/blob/main/docs/example... ...what have people had success with in golang-world? Anything reasonably equivalent someone could recommend? There's a fair amount of "stuff" for TUI's in golang, the thing that's very attractive about 'textualize' is it feels very "web-browser-y" and has a nice (scrollable!)…

Bubble Tea is fantastic.

Re: Textual: Rapid Application Development framework for Python

#76
post #25
post #19

Earlier quoted context omitted.

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

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

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.

Re: Textual: Rapid Application Development framework for Python

#77
post #41
post #19

Earlier quoted context omitted.

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

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.

Yeah, that was my point. You couldn't get to non https sites in a lot of situations

Re: Textual: Rapid Application Development framework for Python

#79
post #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 c…

This very insightful, thank you.

A great example of finding a way out of clutches of a dichotomy.

Post reply on HN