Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Textual: Rapid Application Development framework for Python

github.com

Post reply on HN
Print view View original

61–70 of 112 posts

Re: Textual: Rapid Application Development framework for Python

#61

Post by aidos »

TekMol wrote: post #45
eesmith wrote: 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.

By the time everything is imported and running you can be into the territory of really not wanting to do it on every request. I’ve not timed it in my case for a while but you’re definitely looking at 100s or 1000s of ms.

Re: Textual: Rapid Application Development framework for Python

#62

Post by VectorLock »

Thews wrote: post #58
TekMol wrote: post #45

Earlier quoted context omitted.

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.

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

If he think's CGI startup time is acceptable then I guess maybe PHP seems fast then?

Re: Textual: Rapid Application Development framework for Python

#63

Post by thewataccount »

TekMol wrote: post #29
VectorLock wrote: post #24

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.

Long running processes only need to load their imports, configuration, database connections, etc. once, and don't incur overhead for each request. On top of this, things like imports get to be cached, and there's less need for a database connection pooler to broker connections.

Particularly async runtimes have become more popular - where you can have a single process handling concurrent requests and awaiting/yielding in between their api/db calls. Instead of having many processes that don't share resources that might be waiting 10ms/100ms for api/db calls.

For applications that make large numbers of api/db calls - especially slower ones, may prefer async runtimes over individual processes per request.

I'm not at all saying CGI is a bad option, just that there are real benefits to reusing, pooling and caching resources.

Re: Textual: Rapid Application Development framework for Python

#65

Post by Thews »

VectorLock wrote: post #62
Thews wrote: post #58

Earlier quoted context omitted.

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

If he think's CGI startup time is acceptable then I guess maybe PHP seems fast then?

My bigger issue with the CGI model is the lack of handling connections as streaming. You can't parse a file while it's still being uploaded, and that can eat up a lot of memory on larger files.

I know startup times can take a toll like establishing db connections, cache checking (like redis), file imports, etc. If you are using something that starts up for every request, then you have to be aware of those kinds of things and design around them.

Re: Textual: Rapid Application Development framework for Python

#66

Post by [deleted] »

JonathanBeuys wrote: post #6

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…

[deleted]

Re: Textual: Rapid Application Development framework for Python

#67

Post by benrutter »

jdoss wrote: post #12

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

I love building command line tools and as much as I like the look of Textual I've tried it a few times and it's a little too heavy/inflexible for me. Rich on the other hand is immense and I makes development so smooth- it's great to be able to have a nice api for bold/color/emoji/tables etc straight out the box!

Re: Textual: Rapid Application Development framework for Python

#68

Post by [deleted] »

ramses0 wrote: 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!)…

[deleted]

Re: Textual: Rapid Application Development framework for Python

#69

Post by [deleted] »

darkstar999 wrote: post #2

I tried this a while back but was put off by the fake "css". They say "The dialect of CSS used in Textual is greatly simplified over web based CSS and much easier to learn." But I immediately ran into issues trying to use css that I'm familiar with (and it wasn’t even fancy). They should have called it something else and used different syntax.

[deleted]
Post reply on HN