Live data from Hacker News

Rio: Web apps in pure Python

github.com

101–110 of 205 posts

Re: Rio: Web apps in pure Python

#101

Earlier quoted context omitted.

Yeah and no? Python Lists indeed don't make any sort of array-like guarantee, but they're implemented as a vector/autogrowing-array of python object references (but these objects are not guaranteed to be cache-local). The implementation defines the underlying data structure as PyObject *ob_item

List access is O(1), which effectively makes them arrays :)

Maybe if you don't consider CPU architecture, but most would expect to be able to do loops over Arrays that don't incur in a lot of cache misses, and Python Lists don't do that, since they're actually arrays of pointers to heap memory.

Re: Rio: Web apps in pure Python

#102
post #80
post #12

This kind "you don't need JavaScript, HTML and CSS" approach always fails flat. We already went down this route several times since the first dotcom wave and all the frameworks that tried to target the browser as if we don't need to know "JavaScript, HTML and CSS". Until we need to debug the application, or why it isn't rendering as it should. It is also why I am not a big fan of Blazor, even though I admire its engi…

IMO you either need to go all in or not at all. And by all in I mean your "web page" is nothing but a tag and your non-web framework is handling basically everything. It's an unholy nightmare for many reasons but it would at least allow you to make a reliable self-contained system. "We'll take your native constructs and jimmy them into some bastardized HTML" is almost always full of razor-sharp edge cases.

Well that but with WebGPU just might work without turning your app into lagtown central, in a year or five when it's widely supported anyway.

Re: Rio: Web apps in pure Python

#103
post #80
post #12

This kind "you don't need JavaScript, HTML and CSS" approach always fails flat. We already went down this route several times since the first dotcom wave and all the frameworks that tried to target the browser as if we don't need to know "JavaScript, HTML and CSS". Until we need to debug the application, or why it isn't rendering as it should. It is also why I am not a big fan of Blazor, even though I admire its engi…

IMO you either need to go all in or not at all. And by all in I mean your "web page" is nothing but a tag and your non-web framework is handling basically everything. It's an unholy nightmare for many reasons but it would at least allow you to make a reliable self-contained system. "We'll take your native constructs and jimmy them into some bastardized HTML" is almost always full of razor-sharp edge cases.

Welcome to what made Flash took off in first place.

Re: Rio: Web apps in pure Python

#104

Earlier quoted context omitted.

Python lists aren’t arrays, right? They are the closest thing in Python to an array maybe, but they do a ton of stuff under the hood, like grow when needed. Calling them arrays would be very confusing to everybody who expects a typical array: a pointer with some empty space after it.

Most languages have arrays that grow automatically. I'd say C/C++ is the exception there. When I said array, I specifically meant O(1) access, which is in contrast to linked lists, which the name "list" would seem to imply.

C++ has them on the standard library, I would make a clear split with C in this regard.

Re: Rio: Web apps in pure Python

#105
post #103
post #80

Earlier quoted context omitted.

IMO you either need to go all in or not at all. And by all in I mean your "web page" is nothing but a tag and your non-web framework is handling basically everything. It's an unholy nightmare for many reasons but it would at least allow you to make a reliable self-contained system. "We'll take your native constructs and jimmy them into some bastardized HTML" is almost always full of razor-sharp edge cases.

Welcome to what made Flash took off in first place.

I'm old enough to remember making admins with Adobe Flex. I unironically kind of miss it.

Re: Rio: Web apps in pure Python

#106
post #80
post #12

This kind "you don't need JavaScript, HTML and CSS" approach always fails flat. We already went down this route several times since the first dotcom wave and all the frameworks that tried to target the browser as if we don't need to know "JavaScript, HTML and CSS". Until we need to debug the application, or why it isn't rendering as it should. It is also why I am not a big fan of Blazor, even though I admire its engi…

IMO you either need to go all in or not at all. And by all in I mean your "web page" is nothing but a tag and your non-web framework is handling basically everything. It's an unholy nightmare for many reasons but it would at least allow you to make a reliable self-contained system. "We'll take your native constructs and jimmy them into some bastardized HTML" is almost always full of razor-sharp edge cases.

Agreed! And indeed we are still considering switching Rio to a Canvas + WebGL/WebGPU. The reason we've decided against it for now is accessibility, and weird edge cases such as Copy & Pasting.

Re: Rio: Web apps in pure Python

#107

Are there any other frameworks that have similar ideas, perhaps using a functional language?

If you count Rust as a "functional language", my personal favorite is iced, which is bloody brilliant and blazing fast https://github.com/iced-rs/iced It's desktop-first but compiles to WASM It's honestly "just Rust", so I guess if you're looking for a DSL-type declarative, it doesn't quite fit the bill... but there are design reasons for why it's "just rust" and honestly I much prefer it. It still feels declarative…

slint is more declarative, supports Rust and Python

Re: Rio: Web apps in pure Python

#108
post #80
post #12

This kind "you don't need JavaScript, HTML and CSS" approach always fails flat. We already went down this route several times since the first dotcom wave and all the frameworks that tried to target the browser as if we don't need to know "JavaScript, HTML and CSS". Until we need to debug the application, or why it isn't rendering as it should. It is also why I am not a big fan of Blazor, even though I admire its engi…

IMO you either need to go all in or not at all. And by all in I mean your "web page" is nothing but a tag and your non-web framework is handling basically everything. It's an unholy nightmare for many reasons but it would at least allow you to make a reliable self-contained system. "We'll take your native constructs and jimmy them into some bastardized HTML" is almost always full of razor-sharp edge cases.

How does a screen reader interact with one of these canvas pages?

Re: Rio: Web apps in pure Python

#109
The biggest tragedy in the history of software engineering was back in the mid 1990s when they failed to get Java (Applets) to run in the browser so they had to invent JavaScript, which was purely nothing but a hack put together over a weekend by one guy and it "stuck" like napalm onto humanity and has been burning us ever since. I would say at least one billion man hours (100 billion? Trillion?) has been wasted trying to contend with all the ugliness that ensued. Even the most popular language today on the web TypeScript only has one reason for existing: To try to continue to work around this napalm fire, in some semblance of a tolerable way.

Sure I love TypeScript, and use it every day, because it's the best solution to the current dumpster fire, but I'd like to get away from dumpsters some day. So it's really refreshing to see something good being done to replace this mess we call "Web Development"

Re: Rio: Web apps in pure Python

#110

Earlier quoted context omitted.

Hey, Rio dev here. Love to see us on Hackernews Rio comes with its own set of debug tools, so I don't see debugging as a problem. Our components even explain their entire layouting flow, so I'd argue debugging Rio layout is much easer than CSS :P For example, here's an excerpt of what the built-in dev-tools have to say about a button in one of my apps: > The component was allocated a width of 104.0 by its parent MyRo…

As developers/engineers we love to solve problems. Too many times though we mislabel "friction" as "problem" and then start trying to solve the friction based on our current skill set or viewpoint. So frontend devs feel friction working backend and vice versa leading to all sorts of efforts like this that mostly fail. Good luck though :)

This kind of framework isn’t targeted towards frontend devs though. It is targeted towards backend devs who want to make frontends easier.
Post reply on HN