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.
Textual: Rapid Application Development framework for Python
71–80 of 112 posts
Re: Textual: Rapid Application Development framework for Python
#72I 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?
Re: Textual: Rapid Application Development framework for Python
#73Earlier 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.
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
#74I 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 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
#75Did 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!)…
Re: Textual: Rapid Application Development framework for Python
#76Earlier 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…
Re: Textual: Rapid Application Development framework for Python
#77Earlier 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.
Re: Textual: Rapid Application Development framework for Python
#78I am working on a new python project and one of the first things I added was https://github.com/Textualize/rich because of how easy it is to make things look good in the terminal.
Re: Textual: Rapid Application Development framework for Python
#79After 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…
A great example of finding a way out of clutches of a dichotomy.