Frontend dev here. I think it’s important to remember that there’s not necessarily one use case to rule them all when it comes to the web. If this helps a smaller project that is Python-first get their work in front of a wider audience, is that a bad thing? I’m inclined to think it’s just fine to have lots of approaches available.

Hey, Rio dev here. Love to see us on Hackernews <3

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 MyRoot. Due to align_x being set, the Button only takes up the minimum amount of space necessary and is centered in the available space.

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.

That's why they said "vice versa".

It would be a lot easier if they didn't rename things. 'Text' becomes 'span' and 'justify' becomes 'text-align'. Unless there's more I'm missing, it looks like they've just added a layer of indirection.

    rio.Text(self.name, justify="left"),

Becomes:

   <span style="[...] text-align: left;">Dataset 1</span>

I'd prefer:

    rio.Span(self.name, text_align="left")

Using the term "justify" is very common outside of web. It's been used for decades in print ("left justify / right justify / center justify"). This is indeed a web project though, so I hear what you're saying.

The term "justify" is used in modern CSS too: https://developer.mozilla.org/en-US/docs/Web/CSS/justify-con...

    justify-content: center;
    justify-content: start;
    justify-content: end;
    justify-content: flex-start;
    justify-content: flex-end;
    justify-content: left;
    justify-content: right;

We don't see ourselves as Python bindings for the web, but instead as a pythonic way to create apps. I understand that "span" has become a well known name amongst web developers, that's just not something most new developers understand.

Think of it like how Python has renamed a lot of things. What other languages call arrays, Python calls lists. HashTables are dicts, and so on. Python has faced a lot of resistance here from people that got used to the more technical names, but I think the popularity of the language speaks for itself. Easy to understand, meaningful names are a plus, not a downside :D

> that's just not something most new developers understand.

That is just false if you ask me. Eventually you reach the limits of the API defined by a framework and users will have to reach out to HTML and CSS. And now is there not only a level of indirection, but also all of the existing documentation from the Web Platform cannot be applied.

I think there is validity for having a Python based system (instead of JS) that runs on the client to render standard HTML and CSS, but this goes beyond that and will just become an immense scope creep.

What connection do you think span has to text? To me, span is just the grouping element that defaults to display: inline. This can be used for text, but it can be used for about a million other things too. To me this looks like a fast path to a lot of docs that say “We aren’t actually putting any text in this element, but for legacy reasons it’s called Text. Version N+1 will rename it to Inline”.

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.

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.

A list is not an array. Each item is a pointer to what could be any type. There’s an array module if that’s what is needed.

Yeah, that's gonna be annoying when you want to read HTML & CSS documentation and translate it to Python. How do you differentiate text-align, justify-content, justify-items, and justify-self?

Their goal is for their target developers not to have to learn html and css. Text and justify make a lot more sense to those whose layouting experience is mostly based on MS Word then span and text_align do.

Also, let's not pretend that html/css is particularly well designed or easy too learn. It's the backwards compatible result of decades of experimentation, where the initial design did not even remotely consider building interactive apps with it.

Modern web app dev requires learning way to much (archaic) stuff, just to create something that ought to be simple. Rio at least seems to be trying hard to address that.

I find these projects very interesting as ideas but never ever suitable for any serious purpose. Not even for my personal website or blog. As soon as you approach the boundary of what the project provides, you are completely on your own. Also, unlike "established" projects, they may stop being maintained at any point. That's the reality.

Not sure I agree. What makes the presentation layer of HTML/JS/CSS so different from Win32 of yore, which had VB? VB enabled a LOT of bespoke monstrosities, but it let you do things quickly and easily. We need something like that for the web.

There will always be essential complexity in dealing with the client/server nature of web apps. But there's still a lot of incidental complexity that can be burned off.

> What makes the presentation layer of HTML/JS/CSS so different from Win32 of yore, which had VB?

From my experience: besides both Win32 and VB being from the same entity (Microsoft), which helps a lot, what we had basically were VB bindings for the underlying Win32 library.

This Rio project seems more analogous to a library that tries to do an abstraction on top of Win32, like wxWidgets or Java's AWT. They work but the end results always seem a bit "off".

And unlike Win32, web technologies are moving targets and any assumptions one makes may be wrong some browser updates down the line... and there's where the nightmare comes

Because of the rendering features provided by HTML, CSS and JavaScript semantics.

That is why Flash became so loved by Web designers, allowing them to target a rendering surface, completely bypassing the browser.

Also why we are now having Flash's revenge with WebGL/WebGPU/WebAssembly.

However the "until you have to debug it" still applies, unless you ship the browser with the application, but that isn't something people usually do. /s

> We need something like that for the web.

It’s called HTML/CSS/JS.

They should be, but the default browser styling is terrible.

At yes lets use a screwdriver to do something which a hammer was meant for and call it progress.

That is what I read when I read the title. People should think about what a language's purpose is before planning to interate a technological design around it. Python is very good for many things just not this...

What exactly makes Python (the language) not good for this? Keep in mind we now also have PyScript.

It fails flat when you want to go beyond to scope of the framework. But for teaching programming or quick prototyping or some raspberry project, these are pretty great.

Now, python having some experimentation like this is quite nice to see.

I agree with some of what you’re saying and it made me think of how common this is or not.

It appears this renders html using python syntax.

Just like any html avoidant libraries of JavaScript that need to be debugged.

React can have debugging too to output html.

Maybe less so but still the case for Rails for Ruby.

Remember GWT? I sure do.

Vaadin is still around.

Going from GWT at my first internship to regular HTML/CSS/JavaScript at the next (before even TypeScript) was such a fresh experience.

Apache Wicket

I would argue that it depends on your skill as a developer, the stacks that you're familiar with, etc. As an example I work with a lot of scientific developers who are familiar with python and R but don't know anything about the website needing to make a web application. They're also not trying to optimize for thousands of users or have the cleanest interface. Technologies like Dash, Bokeh, Stream lot, and Shiny for Python and R all help these types of people make a functional web application for a small set of users without having to go down the rabbit hole of web technologies.

Back when I started programming, building programs with GUI was a breeze. Whether it was using Delphi, VB and WinForms, later .NET, or whatever - it was so easy that even complete beginners could get the hang of it.

At least for me, there's some nostalgia involved. The longing of "simple" - at least for smaller apps / software. Being able to slap together some simple app in 15 minutes.

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

What about text rendering?

Apart from native a11y, hackability/"DX" and affordances like text selection, I feel that text rendering is a big moat of classic web technologies.

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

That would be one of the entries in the "unholy nightmare" bullet list.

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.

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.

> And by all in I mean your "web page" is nothing but a <canvas> tag and your non-web framework is handling basically everything

What a huge step back for the web.

Streamlit seems to be doing ok.

With tailwind people aren't writing CSS anyway (technically)