It's a bit sad that most of the comments here are negative. Most of them seem to be some variation of, "Nobody needs a tool like this, all you have to do is simply dedicate yourself to multiple years of writing corporate CRUD apps in both vanilla soul-crushing Javascript and web frameworks. You know, like I did."
So, I am the target audience of this. I have a LOT of experience writing tools and automation and that is where most of my Python knowledge comes from. I am not an expert Python programmer, but I am competent.
But sometimes, I have an idea for writing a web application that would greatly improve my day-to-day life in some way. I know exactly what I want it to do, I know exactly what I want it to look like. I have already designed the API in my head, and could probably write the bulk of the Flask code in under an hour. Maybe a couple of hours if you want tests. But what I DON'T have is the time to learn is the vagaries of HTML+CSS layout and internalize the Great Lessons of the last 20 years of JS development history.
I have consciously stayed away from (non-trivial) web development because the tooling and patterns change almost daily. But the old stuff is not replaced, it is simply bolted on top of. And you have to know the WHOLE stack in order to troubleshoot most any part of it. Waking up one morning and saying, "I know a fair amount about computers, I want to write a web application," is just about as fanciful as saying, "I know a fair amount about airplanes, I want to design a jet engine."
Rio devs, thank you for releasing this as open source. I look forward to checking it out. Even if it doesn't pan out for me, I appreciate that you took a crack at it.
I agree frameworks like this are great to see. I wonder how it compares with https://nicegui.io which is something I've used to build several small web applications in pure python (and wrap one up with their included pyinstaller based packer into an executable).. Either way, also glad to see competition in the space.
Coming off yesterday's Qt discussion (summary: it's fucked up and there are no usable alternatives in embedded), I was dreading the possibility of having to learn Node/React to make anything usable on future projects.
This may have come along at exactly the right time. I'm kind of interested.
Ok that's great. I guess I'm just skeptical you won't have to either
A. Settle for premade layouts
B. Learn some CSS like specification of custom styles. And that is where you get sucked into the rabbit hole
On the css side, I can tell you that rio (that is by no means the first library of its kind) actually does not require any knowledge of css to be used. It does not use the same concepts. While the simplification costs you some levels of customization, it is not something that would truly matter in a lot if not most of its use cases.
The simplified layout system comes with its own inspection tool built into the dev version of your app so you get productive in an hour or so. They really got that part right in my opinion. As soon as they make custom components done I’m gonna discuss adopting it for our internal tooling.
It is very useful to me, even though I know some webdev. For projects where you need to expose majorly python functionality on the web, and don't want to add whole other dimension and toolkits to your python code, this is brilliant.
> "I know a fair amount about computers, I want to write a web application," is just about as fanciful as saying, "I know a fair amount about airplanes, I want to design a jet engine."
I do back end web development, but need to be able to build and run the whole thing locally. I've been through webpack, and grunt, and.. um.. something before that. And throughout it all, I have a make file that has targets for 'clean', 'build', 'NOTEST=true' (to prevent tests from running), etc... specifically because I find it super frustrating when we need to move from one build system to another, and trying to remember which one _this_ project is on, and how that one does each thing, etc.
So every time we add (switch to, but really add) a new build system, I update the Makefile to be able to build with that system, and then just use make to build everything and completely ignore what's doing the actual build :)
These frameworks are cute, and I understand the desire to avoid the modern SPA JavaScript build systems, but it always seems like so much more work than just writing HTML.
I swear, HTML/CSS + Flask + HTMX gets you so far these days. Then, you can throw in some AlpineJS for any inter-element interaction you need and build a responsive SPA without almost any JavaScript.
Alpine is great for your blog, but it's not even a little bit tempting for real world professional projects. Looking back at every project I've worked on there's no shot I would ever select Alpine for any of them.
These type of condescending comments really scream "I'm not even a web developer but here's my strong opinion as someone who only makes toy front ends to demo my data work"
Back in the day we did plenty of "real world professional projects" with jQuery.
I don't see why you couldn't with Alpine.
Yeah at some point you may need a more sophisticated solution but plenty of projects don't need React. This very forum you're using is just a very simple vanilla js file.
>Back in the day we did plenty of "real world professional projects" with jQuery.
And they were terribly unperformant, bug ridden, messes of spaghetti that I wouldn't wish on anyone in the year 2024. Things evolved past that for a reason.
Also 0 chance. Well maybe under some specific unrealistic constraints.
But I am a fan of alternative approaches to the typical stuff just for the fun and learning aspect of it. I'd never come on here and be like "oh well that's cute, but it's useless, why can't we just x".
For example I think Imba is pretty cool and I've used it for a couple throwaway personal projects just to give a spin, but I'd not use it at work.
And you don't even need build systems for modern SPAs. You can write web components in plain JS, load JS and CSS with standard module imports. Use bare import specifiers with import maps. Things have gotten much simpler.
Rio Dev here. I can see where you're coming from. Seeing an experience web-dev work can be mindblowingly fast. But there's two sides to each story - there's tons of developers that are experts in their own fields but that aren't familiar with web technologies. That's where frameworks like Rio, streamlit, reflex, etc. come in.
We've been getting a lot of reactions from people being surprised how quickly they can create Rio apps after just a few hours, when previously creating UIs was always a major roadblock for them. Seeing these reactions has been extremely rewarding.
You need to spend time learning how it works, what are it's limitations and what not.
The newer it is, the fewer components, help and support you have at your dispose.
I don't like these frameworks because it tempts people to learn something that isn't going to get mainstream adoption.
We already have to be careful when choosing a framework like React, vue, svelte etc...
Are you building a side project? You probably should just do it with what you already know, it's gonna be faster and probably better.
Not saying we shouldn't try new things or build new ways of doing stuff, but in this case you are not really running your python code on the web, your running compiled js,html and css...
I much rather choose something that allows me to write vanilla js with some extra features like signals.
What would solve these issues is backwards compatibility. I want to be able to write a full JS/HTML app, a full "framework specific" solution, and anything in between.
Let me migrate my current project into the new framework and see what the experience is like. Let me hack some stuff together for fun, only then I'll consider the framework.
const f = (x, y) => {
const z = x + y;
const w = z * 2;
return z - w + x;
};
In Python, you cannot do this:
f = (
lambda x, y:
z = x + y;
w = z * 2;
return z - w + x;
)
Instead, you need to pull it out into a def:
def f(x, y):
z = x + y;
w = z * 2;
return z - w + x;
Sometimes, this is no big deal. But other times, it's damn annoying; the language forces you to lay out your code in a less intuitive way for no obvious benefit.
Actually you can. If you really want a multi-line lambda with your example...
```f = lambda x, y: [
z := x + y,
w := z 2,
z - w + x,
][-1]```
* That version does look strange, as it uses a list in order to get that last calculation. But I often use lambdas to check results in parametrized tests, and they naturally spread to multiple lines without the list hack since they're chains of comparisons.
Using a list combined with the walrus operator is a clever hack, but it's nice to not be limited to expressions. In JS you can define the equivalent of a multi-line lambda function with any number of statements (which is helpful when you're passing a function as a callback e.g. in a React hook).
It may be nice in the moment, but there's usually regret a few weeks/months down the line when trying to read that code, or angst for the next developer. There isn't that much more effort to just create a normal def to hold that increase in complexity suggested by the need for multiple statements. That's why functions were invented in the first place.
If a callback function gets really unwieldy then you should probably extract it from the call site and define it elsewhere, but that should happen because you decided to, not because the language's limitations coerced you into doing it. The lambda restrictions in Python are probably due to the complexities of parsing indentation based languages, and the clean code argument is just a helpful rationalization. I've never woken up in angst over the fact that I wrote a callback function with two statements in it.
From the blog post you linked: "But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level."
He's saying exactly what I said: that parsing (or more precisely lexing) makes the problem complex, because Python uses indentation semantically. He then rationalizes avoiding the implementation complexity with a gut feeling: "But none of that takes away my gut feeling".
You see it as a rationalization, while I see it as good sense. After all he also mentioned the "puzzles solvers" who solved the "puzzle", and some would likely have happily provided an implementation if he had given the go-ahead. But he outright refused specifically because "... a user interface can handle only so much complexity or it becomes unusable". You don't need to try putting words in his mouth after he specifically stated that maintaining a simple user interface is higher priority.
And the really ironic thing is that we wouldn't even be having this discussion now if not for this focus, because Python wouldn't have gained such popularity to the point it's also attracting more folk who would destroy what makes it so popular in the first place.
Interesting. I see HN has mangled my code block onto 1 line and replaced a couple stars, but the fixup should be obvious...
Yes, it is, it should, and that's exactly the point. It'd look janky even without the `[-1]`, and this is what the core devs are trying to protect against. Lambdas are anonymous functions meant only to be used in places where expressions are valid, such as function parameters and return values. There's even a linter warning if you assign one to a variable. All to help reduce the creation of janky-looking code, and that's a huge benefit for most developers.
I feel like there is something missing here. What's stopping you from using a normal def? Aside from the definition itself not being usable inline, there is nothing lambda does that def doesn't. And if you really want a definition close to the calling site, just define it there and then put the name where you want to pass it.
At the end of the day though there's really nothing to prevent you from creating janky code. Heck I saw a wild hack a couple weeks ago that allows for the creation of arbitrary custom syntax with pure Python, so you could create a multi-line lambda if you really want to that badly. But the widely adopted conventions exist for a reason.
def outer(a):
def inner(b):
return a * b
return inner
Though slightly longer, for most developers, it's still more grokkable (and related stack traces better) than:
def outer(a):
return lambda b: a * b
A very large part of Python's design is to emphasize readability for the majority. I still remember how long it took me to wrap my head around this "lambda thing" that I'd see pop up ever so often, even after a couple years of using Python. I eventually got fed up and took some time to really get to understand it. This shouldn't have to be the case for everyone reading random code.
Python is a primarily OOP-based language with functional aspects. And the design decisions that went into it are what makes it so popular today. It's not Haskell or Lisp or any of the other many that the majority avoid due to language complexity. Don't try to make it into one.
Rio components are classes, so you could create a named class method and reference it. Obviously not the same thing as multi-line lambdas but it'd be the pythonic approach imho.
The primary advantage is that the built in set of components is pretty powerful (e.g. a real table view), everything runs server side, the Python can be JIT compiled, and from the user's POV it still feels like a web app (e.g. zoom is respected). You can "shell out" to Javascript if needed, you can use Java libraries. The JPro website is itself a JavaFX app running as a web app. Also there's a visual UI builder that's decent (and free).
Primary downside beyond just the obscurity of the stack (same problem as for Rio), is just that JPro is a commercial solution. But then you get commercial support and bug fixes in case you need something special or hit an obscure rendering case.
I should caution that the jpro.one home page has some pretty obvious screen reader accessibility issues. Assuming the website is rendered with the framework itself, I wouldn't be comfortable using that framework in a real application unless someone did a comprehensive accessibility audit first.
I love Python, but I also love building web apps in the native language of JS/HTML/CSS. Often times these "build the web in X" solutions are amalgamating that language into code that looks almost like HTML or JS, just with a Python flavor. I would love to hear from someone who used to do full-stack and now has moved mostly into a solution like Rio?
Nice, I guess a more established framework for writing webapps in Python is Streamlit, which is pretty good - minimal syntax can create quite an advanced, "reactive", GUI. It's very quick to throw together functional / relatively complex stuff with. But it's also very opinionated, so all Streamlit apps tend to have a similar look. Also it's more aimed at ML demos, for a few, non-persistent users, rather than for large apps with persistant users, etc. Wonder how this compares.
I agree with your sentiment. There's so many non-JS/TS frontend webapp frameworks (using either Kotlin, Go, Python, etc. - not even talking about the WASM ones) - but they all come to a halt once they actually need to use those frameworks besides writing a simple blog site, HN reader, etc.
I'm excited to see more projects like Rio exploring the full-stack python web dev space. There are definitely categories of users for which the approach makes sense.
---
For me personally -- and I'm guessing for a bunch of other HNers -- writing full-stack web apps strictly in python is a non-goal.
I've settled on a comfortable (for me) stack for smaller projects that need python on the backend that combines:
1. Litestar (or another lightweight HTTP framework of choice like flask, etc.)
2. HTMX
3. htpy.dev (an in-python HTML builder)
4. Custom web components implemented in a plain-old JavaScript ES6 module loaded directly by the browser
A typical project only needs a handful of components. HTMX and htpy.dev both play very nicely with web components.
When I want zero build steps, I write plain JavaScript + JSDoc comments. JSDoc is... okay-ish, but it ain't no typescript.
If I need a database, I'll grab SQLAlchemy. I wish there were a mature lightweight solution here; maybe Tortoise ORM will get there soon?
There's nothing in this stack that couldn't strictly be done in javascript-land. JSX syntax with HTMX is pretty great and much better than any in-python HTML builder. But often my projects have other requirements (like ML) where python is, at least today, inevitable.
Rio dev here. I 100% agree with you. We aren't expecting for JS developers to flock to rio en-masse. Instead, we're targeting the many, many Python devs that have been completely left out in the web revolution and are still stuck construcing user-interfaces using tkinter and similar.
Hopefully JSX can be more mainstream, that is, I can use it directly in js/html/css projects without all the extra tools pre-installed and pre-configured, making jsx part of the 'vanilla' development will be really nice(no react, no vuejs etc).
I agree about the JSX part - but the thing about real dev is that you have to use all the tools you can, so you don't have to reinvent the wheel. Nobody's still making Windows-only GUI apps using the Win32 API - it's easier and all, but there's so much stuff you have to code yourself that it's simpler to learn a GUI library/framework and Just Use That. I had a quick glance at HTMX - and it seems to just be going backwards (similar to Go - the language is so simple that it's actually hard to code real stuff in it). Why should I make an API that's essentially web only (because you have to send back HTML from the server using HTMX) if I can just use JSON/Protobuf/etc. and with just a few build tools I can automatically generate functions that I can call directly in JS. Sure, it's easier to build a website with plain JS (and by that HTMX, which is glorified plain JS) but this is the real world.
I may be the wrong person to answer, alas. I nearly entirely avoid the machinery of web components.
With the stack above, I typically write small classes that derive from HTMLElement and implement a couple key callbacks (usually, connectedCallback and disconnectedCallback). In those, I typically (a) initialize state by reading attributes from the DOM and (b) configure event handlers. Pretty simple.
That's... about it. I'm templating elsewhere, so I avoid using web component templates. And the less I think about the shadow DOM, the better.
For this, the MDN documentation on custom components is enough.
Storing state in-memory is usually not a good idea for web apps, most use databases with persistence. I got curious and found the example code for implementing password-based authentication on SQLite. I don't think it's very compelling when the alternatives include Django.
I feel like you’re getting a lot of pushback on this and I’m going to go out and say this is cool and I’m glad people continue to try to innovate on the webdev experience.
The way I see it is building apps somewhat similarly to SwiftUI is actually a pretty good idea. If you have established rules for how each container expands or fills its content you can build a great web app development experience without getting down into css and html explicitly. Just Vbox container Hbox container text container etc. I can certainly see a niche for this as it is a different style of UI development.
I’ve never been great as a UI designer so doing it in the traditional web stack has always been even harder but I’ve found that with SwiftUI I can usually get 90% of a good look very quickly.
I spend 95% of my work time doing backend python microservices for internal tools, 5% on terraform for the infrastructure, and 0.0001% of my time building frontends for these tools (I just use plain html and JS, and only add a frontend when absolutely necessary). I've build a react app for fun in the past just to learn how that works but if I had to do it again for work I would basically have to go through the entire learning process again.
So, something like this where I'm writing pure python for my web components could really save me a lot of that churn time, not to mention that many of my coworkers have absolutely no JS experience. I have an upcoming task to build a new frontend and am going to add in a couple days to try this out to see if it meets our needs.
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 engineering effort.
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 :)
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.
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.
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.
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.
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
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.
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”.
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.
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?
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.
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.
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
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.
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...
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.
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.
You'd need to re-invent the wheel on so many things.
Flexbox layout? CSS animations? Some custom npm library that I need to use to provide social logins, SDKs to integrate payment gateways? etc etc
If all you want is just a set of UI components, sure. We already have plenty of UI libraries out there.
These days there are many better ways to write low-JS, low-boilerplate code.
HTMX for interactivity, UnoCSS for generated CSS on the fly. It's even possible not to bundle your ES6 modules these days, with <script type="importmap">.
Local apps run inside of a webview. Think of it like electron but for Python. Even though this _should_ be cross platform, we've unfortunately found a lot of subtle issues with pywebview. That's why we're still considering this to be experimental.
In my experience webview works great on Windows, but struggles on Linux. For examples Videos don't play reliably when using the GTK backend.
We're looking into other ways to run a browser - my favorite would be to just find one already installed and just start it without UI - but that's some way off.
Python is not perfect—no language is—but it arguably has the lowest barrier to entry for new programmers, with far fewer "wats" than languages of its kind and era (certainly less than JS). Sure, its reference implementation is not the most performant, but it easily interoperates with C/C++, and alternative implementations like PyPy are also relatively easy to switch to, so it can be performant when it needs to. Dynamic typing is not great for maintaining large codebases, but with the advent of gradual typing, this shouldn't be a major hindrance anymore. It has a great standard library, and a huge ecosystem. My only major gripe with it is the packaging and the insane amount of tooling around it, which I doubt will ever be resolved at this point. But Python is not so bad overall.
"Dynamic typing is not great for maintaining large codebases" - when your language has an option to not use types, most SWEs will NOT use them - I experienced this firsthand (Angular TS codebases littered with "any" types - direct equivalent analogy to Python in this case). I heard the saying, "you can only burn yourself so many times" - but this seems to be untrue in this case - it's as infinite as human stupidity is.
Ecosystem is great - and probably the greatest thing Python has to offer after the aforementioned low barrier to entry. No language comes close if one wants to get up & going and try out AI/ML - whether using an API or using some packages to make models of one's own - it has everything one can ever need.
To be fair a lot of small startups could benefit from forgoing custom CSS styles for very straightforward frontend dev. So much money wasted on react devs imho (including myself)
When building a full fledged web app I prefer JavaScript - when I do want to do more in Python I find Streamlit is a perfect fit for Python native, low code, but not trying to do too much
Looks cool! But I'm wondering who the target audience is. Most web devs prefer javascript. Are you hoping to target data scientists to build data apps, for example?
Exactly! We've seen from personal experience just how many people are currently working on AI/datascience projects and would love to create UIs for them, but just can't. That's exactly who Rio is for - people who are experts in one field, and don't want to invest hours and hours into other languages just to create interfaces for what they're working on.
That’s really smart. I was previously a data scientist who only knew python and made the transition last year to become a full stack web dev and I honestly had no idea what I was in for. I probably won’t use your tool, but I’ll happily recommend other data scientists check it out so they don’t have to go through what I did.
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"
Java is the new COBOL in many places, thanks God it is not part of the browser. Such a terrible development of language, terribly slow for anything desktop, terribly slow as DX. We would have 100x more people complaining if there weren't a script attached to that Java.
Most people just can't objectively do the "Counterfactual Thinking" of what if only Java had ever existed and JavaScript never did.
Any developer who has loved JS all their lives would've also loved Java if that's what was available to them all their life. It's largely just what you're used to.
Running JS on the server side is just a mess, and has only been popular to do since NodeJS was invented. Imagine if it was always the SAME code on both client and server starting since 1995. That would've definitely been a better world by far.
I wrote lots of Applets too. My parenthetical "(Applets)" in that post was misleading, sorry.
Java and Applets pre-existed JavaScript, and purely due to a 10 day timing constraint put on him by Netscape management (right after their deal with Sun Microsystems), Brendan Eich, wanting a Java-syntax, but not having enough time to do it right, cobbled together JavaScript instead.
> and purely due to a 10 day timing constraint put on him by Netscape management (right after their deal with Sun Microsystems), Brendan Eich, wanting a Java-syntax, but not having enough time to do it right, cobbled together JavaScript instead.
Stop spreading FUD. You have no idea what you’re talking about.
Stuff that people hate wasn’t even part of the original demo.
Built-in components do as much work as possible directly on the client. Any Python code however runs on the server. This makes it dead-simple to e.g. connect to your database and also gives you the full power of real CPython, not just a cut-down WASM/transpiled version.
I have always been using Gradio, and it still comes short when it comes to slick UI, even with themes.
So it is nice to see solutions like this that has a slicker UI.
https://reflex.dev/ is all made in Reflex and has raised a seed round! There are also a few YC companies using Reflex that have raised seed rounds too.
The VC bit is the entire reason I would not use something like this.
Just waiting for them to want their money out and then I am stuck deep in a product fast headed for enshitifaction or abandonment when it fails to make a billion dollars in 2 years.
I am often in need of building internal tools, dashboards - simple apps with simple UI that doesn't need to be unique, drive engagement, or whatever. It needs to get the job done and let me move on.
Streamlit is close but the peculiar approach they take (rerun the script) makes it unwieldly for more complex apps (say, a few related pages, a few dozen components each).
I've been looking for a way to just let me do "GUI app in Python" that get delivered over HTTP and rendered in browser, and Rio is exactly what I was hoping for.
Yeah, no chance Meta will rewrite FB frontend to use Rio. Also pretty sure that I won't be doing any fancy websites in it. But if I can skip dealing with React/Vue/HTMX/whatever on the frontend for some internal thingy.
I only tried doing some simple stuff but so far I really like what I see!
It's amazing how much you can build without resorting to those fancy frameworks if you dedicate some time to learning Django and how its views work. You do not need a SPA, you need a working app that looks good.
In general I'm not convinced that these "no Javacript" frameworks will last, and to some extend you going to have to re-learn a lot. That's not to say that the idea isn't interesting.
While I have no idea how this would work, I think it would be more useful to have tools like this as a sort of template language for something like Django or Flask. So you get the mature frameworks on the backend and something like Rio to generate the backend, within the context of Django/Flask/Bottle/whatever.
Some modern web applications do need VueJS, React, something like that. CRUD apps mostly don't, but we are way past CRUD apps for a lot of thing. You can maybe get away with calling Asana and Jira CRUD apps, but you can't do Figma with just Django.
Rio dev here. You're right in that all Rio components use Material Design, but there is still room for configuration. I can't post pictures here, but if you check our discord, somebody has made a full-retro website that doesn't look material-y at all.
In addition to high-level components there's also some very basic building blocks, like a humble Rectangle. By combining these in clever ways you can get more styles than you might originally expect - just like everything on the web is ultimately colored boxes.
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 enough
the view code compiles to elixir code, it just uses html as a familiar syntax. it's written inline as functions in the source code though so I tend to think of it as closer to a "pure elixir" solution.
It's a bit sad that most of the comments here are negative. Most of them seem to be some variation of, "Nobody needs a tool like this, all you have to do is simply dedicate yourself to multiple years of writing corporate CRUD apps in both vanilla soul-crushing Javascript and web frameworks. You know, like I did."
So, I am the target audience of this. I have a LOT of experience writing tools and automation and that is where most of my Python knowledge comes from. I am not an expert Python programmer, but I am competent.
But sometimes, I have an idea for writing a web application that would greatly improve my day-to-day life in some way. I know exactly what I want it to do, I know exactly what I want it to look like. I have already designed the API in my head, and could probably write the bulk of the Flask code in under an hour. Maybe a couple of hours if you want tests. But what I DON'T have is the time to learn is the vagaries of HTML+CSS layout and internalize the Great Lessons of the last 20 years of JS development history.
I have consciously stayed away from (non-trivial) web development because the tooling and patterns change almost daily. But the old stuff is not replaced, it is simply bolted on top of. And you have to know the WHOLE stack in order to troubleshoot most any part of it. Waking up one morning and saying, "I know a fair amount about computers, I want to write a web application," is just about as fanciful as saying, "I know a fair amount about airplanes, I want to design a jet engine."
Rio devs, thank you for releasing this as open source. I look forward to checking it out. Even if it doesn't pan out for me, I appreciate that you took a crack at it.
I agree frameworks like this are great to see. I wonder how it compares with https://nicegui.io which is something I've used to build several small web applications in pure python (and wrap one up with their included pyinstaller based packer into an executable).. Either way, also glad to see competition in the space.
Coming off yesterday's Qt discussion (summary: it's fucked up and there are no usable alternatives in embedded), I was dreading the possibility of having to learn Node/React to make anything usable on future projects.
This may have come along at exactly the right time. I'm kind of interested.
Ok that's great. I guess I'm just skeptical you won't have to either A. Settle for premade layouts B. Learn some CSS like specification of custom styles. And that is where you get sucked into the rabbit hole
On the css side, I can tell you that rio (that is by no means the first library of its kind) actually does not require any knowledge of css to be used. It does not use the same concepts. While the simplification costs you some levels of customization, it is not something that would truly matter in a lot if not most of its use cases.
The simplified layout system comes with its own inspection tool built into the dev version of your app so you get productive in an hour or so. They really got that part right in my opinion. As soon as they make custom components done I’m gonna discuss adopting it for our internal tooling.
I am not affiliated with them btw.
> Settle for premade layouts
Just think of how many man years we could have saved if we did this.
And think of how many man centuries we could have saved if we were okay with a page refresh
We will save man-years, because an LLM will do that.
Nope! No premade layouts, and not a single line CSS. Give it a shot :)
It is very useful to me, even though I know some webdev. For projects where you need to expose majorly python functionality on the web, and don't want to add whole other dimension and toolkits to your python code, this is brilliant.
> because the tooling and patterns change almost daily.
That is just plain wrong. And that comes from someone who stayed from web dev for the same reason. Nowadays it’s vite/esbuild and you’re good to go.
And you don’t need any web framework to come up with basic ui.
touch index.html; touch styles.css; python3 -m http.server
And you’re good to go.
> "I know a fair amount about computers, I want to write a web application," is just about as fanciful as saying, "I know a fair amount about airplanes, I want to design a jet engine."
This analogy makes no sense.
Last time I (kinda halfway / didn't) learned frontend it was react-create-app. Before that webpack. And before that grunt.
You do not need a framework if you really know CSS and HTML5 well, but that is exactly "knowing the whole stack" - which was the parents point.
> Before that webpack. And before that grunt.
I do back end web development, but need to be able to build and run the whole thing locally. I've been through webpack, and grunt, and.. um.. something before that. And throughout it all, I have a make file that has targets for 'clean', 'build', 'NOTEST=true' (to prevent tests from running), etc... specifically because I find it super frustrating when we need to move from one build system to another, and trying to remember which one _this_ project is on, and how that one does each thing, etc.
So every time we add (switch to, but really add) a new build system, I update the Makefile to be able to build with that system, and then just use make to build everything and completely ignore what's doing the actual build :)
> Last time I (kinda halfway / didn't) learned frontend it was react-create-app. Before that webpack. And before that grunt.
You’re describing more than 10 years of evolution here. That’s hardly daily.
These days it’s npx vite build, what’s there to learn?
Well, both of those things were hyperbole, not really to be taken quite so literally.
Thank you so much for the kind words! It's always great to read messages like this.
I can't wait to hear your feedback
These frameworks are cute, and I understand the desire to avoid the modern SPA JavaScript build systems, but it always seems like so much more work than just writing HTML.
I swear, HTML/CSS + Flask + HTMX gets you so far these days. Then, you can throw in some AlpineJS for any inter-element interaction you need and build a responsive SPA without almost any JavaScript.
Alpine is great for your blog, but it's not even a little bit tempting for real world professional projects. Looking back at every project I've worked on there's no shot I would ever select Alpine for any of them.
These type of condescending comments really scream "I'm not even a web developer but here's my strong opinion as someone who only makes toy front ends to demo my data work"
Back in the day we did plenty of "real world professional projects" with jQuery.
I don't see why you couldn't with Alpine.
Yeah at some point you may need a more sophisticated solution but plenty of projects don't need React. This very forum you're using is just a very simple vanilla js file.
> Back in the day we did plenty of "real world professional projects" with jQuery.
I was there, it sucked
>Back in the day we did plenty of "real world professional projects" with jQuery.
And they were terribly unperformant, bug ridden, messes of spaghetti that I wouldn't wish on anyone in the year 2024. Things evolved past that for a reason.
Bold of you to assume that modern web dev isn’t also a terribly unperformant, bug-ridden mess of spaghetti.
An undesired level of condescendence for a message against it, no? My first impression...
would you use one of these python-to-web frameworks like rio though? I think gp was just saying alpine was a good alternative to that.
Also 0 chance. Well maybe under some specific unrealistic constraints.
But I am a fan of alternative approaches to the typical stuff just for the fun and learning aspect of it. I'd never come on here and be like "oh well that's cute, but it's useless, why can't we just x".
For example I think Imba is pretty cool and I've used it for a couple throwaway personal projects just to give a spin, but I'd not use it at work.
And you don't even need build systems for modern SPAs. You can write web components in plain JS, load JS and CSS with standard module imports. Use bare import specifiers with import maps. Things have gotten much simpler.
Rio Dev here. I can see where you're coming from. Seeing an experience web-dev work can be mindblowingly fast. But there's two sides to each story - there's tons of developers that are experts in their own fields but that aren't familiar with web technologies. That's where frameworks like Rio, streamlit, reflex, etc. come in.
We've been getting a lot of reactions from people being surprised how quickly they can create Rio apps after just a few hours, when previously creating UIs was always a major roadblock for them. Seeing these reactions has been extremely rewarding.
Flask + HTMX + AlpineJS always seem like so much more work than just writing JavaScript.
All of it is so much more work compared to PHP + HTML + CSS (and no JS).
Is it? Why spend so much time learning PHP when you can just use JS?
Every framework, requires a learning curve.
You need to spend time learning how it works, what are it's limitations and what not.
The newer it is, the fewer components, help and support you have at your dispose.
I don't like these frameworks because it tempts people to learn something that isn't going to get mainstream adoption.
We already have to be careful when choosing a framework like React, vue, svelte etc...
Are you building a side project? You probably should just do it with what you already know, it's gonna be faster and probably better.
Not saying we shouldn't try new things or build new ways of doing stuff, but in this case you are not really running your python code on the web, your running compiled js,html and css...
I much rather choose something that allows me to write vanilla js with some extra features like signals.
What would solve these issues is backwards compatibility. I want to be able to write a full JS/HTML app, a full "framework specific" solution, and anything in between.
Let me migrate my current project into the new framework and see what the experience is like. Let me hack some stuff together for fun, only then I'll consider the framework.
I've enjoyed working with Reflex (https://reflex.dev) as a pure Python wrapper over React.
react license applies then to products made with this stack? i.e. no product that meta thinks of as a competitor is allowed?
React is fully OSS as far as I know: https://github.com/facebook/react/blob/main/LICENSE
I think the term you mentioned was there at the start but has since been removed and React is licensed pure MIT since 2017.
React used to be licensed as BSD + recovable patents: https://engineering.fb.com/2017/08/18/open-source/explaining...
+1 for Reflex. Truly amazing.
How is it writing React without multi-line lambdas?
They are everywhere in JavaScript and I couldn't imagine my day-to-day without them!
I think my answer: I have no idea what multi-line lambdas are, probably explains why I find Reflex (or Rio/Streamlit, etc) amazing, haha
For a person with zero front-end knowledge, it's a game changer.
In JavaScript you can do this:
In Python, you cannot do this: Instead, you need to pull it out into a def: Sometimes, this is no big deal. But other times, it's damn annoying; the language forces you to lay out your code in a less intuitive way for no obvious benefit.Actually you can. If you really want a multi-line lambda with your example...
```f = lambda x, y: [ z := x + y, w := z 2, z - w + x, ][-1]```
* That version does look strange, as it uses a list in order to get that last calculation. But I often use lambdas to check results in parametrized tests, and they naturally spread to multiple lines without the list hack since they're chains of comparisons.
Using a list combined with the walrus operator is a clever hack, but it's nice to not be limited to expressions. In JS you can define the equivalent of a multi-line lambda function with any number of statements (which is helpful when you're passing a function as a callback e.g. in a React hook).
It may be nice in the moment, but there's usually regret a few weeks/months down the line when trying to read that code, or angst for the next developer. There isn't that much more effort to just create a normal def to hold that increase in complexity suggested by the need for multiple statements. That's why functions were invented in the first place.
If a callback function gets really unwieldy then you should probably extract it from the call site and define it elsewhere, but that should happen because you decided to, not because the language's limitations coerced you into doing it. The lambda restrictions in Python are probably due to the complexities of parsing indentation based languages, and the clean code argument is just a helpful rationalization. I've never woken up in angst over the fact that I wrote a callback function with two statements in it.
There may be a few restrictions due to complexity, but lambdas isn't one. This is about decent and sane design choice[0] for readability.
[0] https://www.artima.com/weblogs/viewpost.jsp?thread=147358
From the blog post you linked: "But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level."
He's saying exactly what I said: that parsing (or more precisely lexing) makes the problem complex, because Python uses indentation semantically. He then rationalizes avoiding the implementation complexity with a gut feeling: "But none of that takes away my gut feeling".
You see it as a rationalization, while I see it as good sense. After all he also mentioned the "puzzles solvers" who solved the "puzzle", and some would likely have happily provided an implementation if he had given the go-ahead. But he outright refused specifically because "... a user interface can handle only so much complexity or it becomes unusable". You don't need to try putting words in his mouth after he specifically stated that maintaining a simple user interface is higher priority.
And the really ironic thing is that we wouldn't even be having this discussion now if not for this focus, because Python wouldn't have gained such popularity to the point it's also attracting more folk who would destroy what makes it so popular in the first place.
That's pretty janky - I don't think it would pass review in many places!
Interesting. I see HN has mangled my code block onto 1 line and replaced a couple stars, but the fixup should be obvious...
Yes, it is, it should, and that's exactly the point. It'd look janky even without the `[-1]`, and this is what the core devs are trying to protect against. Lambdas are anonymous functions meant only to be used in places where expressions are valid, such as function parameters and return values. There's even a linter warning if you assign one to a variable. All to help reduce the creation of janky-looking code, and that's a huge benefit for most developers.
But what if I want to use lambdas for more things?
Imperative programming only gets you so far.
Maybe this is a sign that people are using Python for grander things than it was designed for?
I feel like there is something missing here. What's stopping you from using a normal def? Aside from the definition itself not being usable inline, there is nothing lambda does that def doesn't. And if you really want a definition close to the calling site, just define it there and then put the name where you want to pass it.
At the end of the day though there's really nothing to prevent you from creating janky code. Heck I saw a wild hack a couple weeks ago that allows for the creation of arbitrary custom syntax with pure Python, so you could create a multi-line lambda if you really want to that badly. But the widely adopted conventions exist for a reason.
> Aside from the definition itself not being usable inline, there is nothing lambda does that def doesn't
Being unable to position it inline is the problem.
You might not see the benefit, but many do. It prevents Python from being a good functional programming, for one thing.
There's 0 problem with doing:
Though slightly longer, for most developers, it's still more grokkable (and related stack traces better) than: A very large part of Python's design is to emphasize readability for the majority. I still remember how long it took me to wrap my head around this "lambda thing" that I'd see pop up ever so often, even after a couple years of using Python. I eventually got fed up and took some time to really get to understand it. This shouldn't have to be the case for everyone reading random code.Python is a primarily OOP-based language with functional aspects. And the design decisions that went into it are what makes it so popular today. It's not Haskell or Lisp or any of the other many that the majority avoid due to language complexity. Don't try to make it into one.
Ah I see! Thanks for elaborating! :)
Rio components are classes, so you could create a named class method and reference it. Obviously not the same thing as multi-line lambdas but it'd be the pythonic approach imho.
Either name them, or squeeze multiple expressions into a tuple. More can be done, now with walrus.
> They are everywhere in any proper programming language
FTFY.
Another rather unconventional way to do this, though it can be powerful, is to combine GraalPython, JavaFX and jpro.one:
https://www.jpro.one
The primary advantage is that the built in set of components is pretty powerful (e.g. a real table view), everything runs server side, the Python can be JIT compiled, and from the user's POV it still feels like a web app (e.g. zoom is respected). You can "shell out" to Javascript if needed, you can use Java libraries. The JPro website is itself a JavaFX app running as a web app. Also there's a visual UI builder that's decent (and free).
Primary downside beyond just the obscurity of the stack (same problem as for Rio), is just that JPro is a commercial solution. But then you get commercial support and bug fixes in case you need something special or hit an obscure rendering case.
I should caution that the jpro.one home page has some pretty obvious screen reader accessibility issues. Assuming the website is rendered with the framework itself, I wouldn't be comfortable using that framework in a real application unless someone did a comprehensive accessibility audit first.
I love Python, but I also love building web apps in the native language of JS/HTML/CSS. Often times these "build the web in X" solutions are amalgamating that language into code that looks almost like HTML or JS, just with a Python flavor. I would love to hear from someone who used to do full-stack and now has moved mostly into a solution like Rio?
Nice, I guess a more established framework for writing webapps in Python is Streamlit, which is pretty good - minimal syntax can create quite an advanced, "reactive", GUI. It's very quick to throw together functional / relatively complex stuff with. But it's also very opinionated, so all Streamlit apps tend to have a similar look. Also it's more aimed at ML demos, for a few, non-persistent users, rather than for large apps with persistant users, etc. Wonder how this compares.
How difficult is it to add authentication in this framework? How many lines of code? How secure?
None of the python->web projects have this.
I agree with your sentiment. There's so many non-JS/TS frontend webapp frameworks (using either Kotlin, Go, Python, etc. - not even talking about the WASM ones) - but they all come to a halt once they actually need to use those frameworks besides writing a simple blog site, HN reader, etc.
I'm excited to see more projects like Rio exploring the full-stack python web dev space. There are definitely categories of users for which the approach makes sense.
---
For me personally -- and I'm guessing for a bunch of other HNers -- writing full-stack web apps strictly in python is a non-goal.
I've settled on a comfortable (for me) stack for smaller projects that need python on the backend that combines:
1. Litestar (or another lightweight HTTP framework of choice like flask, etc.)
2. HTMX
3. htpy.dev (an in-python HTML builder)
4. Custom web components implemented in a plain-old JavaScript ES6 module loaded directly by the browser
A typical project only needs a handful of components. HTMX and htpy.dev both play very nicely with web components.
When I want zero build steps, I write plain JavaScript + JSDoc comments. JSDoc is... okay-ish, but it ain't no typescript.
If I need a database, I'll grab SQLAlchemy. I wish there were a mature lightweight solution here; maybe Tortoise ORM will get there soon?
There's nothing in this stack that couldn't strictly be done in javascript-land. JSX syntax with HTMX is pretty great and much better than any in-python HTML builder. But often my projects have other requirements (like ML) where python is, at least today, inevitable.
Rio dev here. I 100% agree with you. We aren't expecting for JS developers to flock to rio en-masse. Instead, we're targeting the many, many Python devs that have been completely left out in the web revolution and are still stuck construcing user-interfaces using tkinter and similar.
Hopefully JSX can be more mainstream, that is, I can use it directly in js/html/css projects without all the extra tools pre-installed and pre-configured, making jsx part of the 'vanilla' development will be really nice(no react, no vuejs etc).
I agree about the JSX part - but the thing about real dev is that you have to use all the tools you can, so you don't have to reinvent the wheel. Nobody's still making Windows-only GUI apps using the Win32 API - it's easier and all, but there's so much stuff you have to code yourself that it's simpler to learn a GUI library/framework and Just Use That. I had a quick glance at HTMX - and it seems to just be going backwards (similar to Go - the language is so simple that it's actually hard to code real stuff in it). Why should I make an API that's essentially web only (because you have to send back HTML from the server using HTMX) if I can just use JSON/Protobuf/etc. and with just a few build tools I can automatically generate functions that I can call directly in JS. Sure, it's easier to build a website with plain JS (and by that HTMX, which is glorified plain JS) but this is the real world.
https://htmx.org/essays/splitting-your-apis/
https://htmx.org/essays/mvc/
> If I need a database, I'll grab SQLAlchemy. I wish there were a mature lightweight solution here; maybe Tortoise ORM will get there soon?
[Peewee ORM](https://docs.peewee-orm.com/)
Peewee never quite got there IMO, and it hasn't kept up with the times (modern asyncio, etc.)
Is there really an “etc”? Beyond asyncio, I haven’t found anything that SQLAlchemy can do that Peewee can’t even more easily.
Where’s a good place to learn about the web components aspect? I’ve tried a few times (and the shoelace docs) but it doesn’t stick.
I may be the wrong person to answer, alas. I nearly entirely avoid the machinery of web components.
With the stack above, I typically write small classes that derive from HTMLElement and implement a couple key callbacks (usually, connectedCallback and disconnectedCallback). In those, I typically (a) initialize state by reading attributes from the DOM and (b) configure event handlers. Pretty simple.
That's... about it. I'm templating elsewhere, so I avoid using web component templates. And the less I think about the shadow DOM, the better.
For this, the MDN documentation on custom components is enough.
Looks like htpy, but with some components and a different syntax?
https://htpy.dev/
Unlike Htpy, this one has callbacks and state in Python.
Storing state in-memory is usually not a good idea for web apps, most use databases with persistence. I got curious and found the example code for implementing password-based authentication on SQLite. I don't think it's very compelling when the alternatives include Django.
https://github.com/rio-labs/rio/blob/41a6bb828c2e20eb7fdc5c6...
This is just programmers being lazy and essentially reinventing PHP sessions, throwing away years of progress.
+1 for htpy. Awesome library.
I feel like you’re getting a lot of pushback on this and I’m going to go out and say this is cool and I’m glad people continue to try to innovate on the webdev experience.
The way I see it is building apps somewhat similarly to SwiftUI is actually a pretty good idea. If you have established rules for how each container expands or fills its content you can build a great web app development experience without getting down into css and html explicitly. Just Vbox container Hbox container text container etc. I can certainly see a niche for this as it is a different style of UI development.
I’ve never been great as a UI designer so doing it in the traditional web stack has always been even harder but I’ve found that with SwiftUI I can usually get 90% of a good look very quickly.
I spend 95% of my work time doing backend python microservices for internal tools, 5% on terraform for the infrastructure, and 0.0001% of my time building frontends for these tools (I just use plain html and JS, and only add a frontend when absolutely necessary). I've build a react app for fun in the past just to learn how that works but if I had to do it again for work I would basically have to go through the entire learning process again.
So, something like this where I'm writing pure python for my web components could really save me a lot of that churn time, not to mention that many of my coworkers have absolutely no JS experience. I have an upcoming task to build a new frontend and am going to add in a couple days to try this out to see if it meets our needs.
Nice! How does it compare to https://fastht.ml/
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 engineering effort.
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.
Becomes: I'd prefer: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...
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.
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.
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”.
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.
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.
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?
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.
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.
> 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.
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.
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
> We need something like that for the web.
It’s called HTML/CSS/JS.
They should be, but the default browser styling is terrible.
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
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.
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.
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.
Remember GWT? I sure do.
Going from GWT at my first internship to regular HTML/CSS/JavaScript at the next (before even TypeScript) was such a fresh experience.
Vaadin is still around.
Apache Wicket
With tailwind people aren't writing CSS anyway (technically)
Streamlit seems to be doing ok.
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.
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.
You'd need to re-invent the wheel on so many things.
Flexbox layout? CSS animations? Some custom npm library that I need to use to provide social logins, SDKs to integrate payment gateways? etc etc
If all you want is just a set of UI components, sure. We already have plenty of UI libraries out there.
These days there are many better ways to write low-JS, low-boilerplate code. HTMX for interactivity, UnoCSS for generated CSS on the fly. It's even possible not to bundle your ES6 modules these days, with <script type="importmap">.
I would hesitate to label anything Python as “type-safe” per the README - maybe type-conscious or just “typed Python”
there are maybe 50 web framework / app builder in python
just like there are new frameworks everyday in javascript
Is it the run_in_window() method cross platform? Can you talk a bit more about the implementation?
afaict it uses https://github.com/r0x0r/pywebview under the hood (so yes, cross-platform)
Nailed it! We use pywebview. (Rio Dev here.)
Local apps run inside of a webview. Think of it like electron but for Python. Even though this _should_ be cross platform, we've unfortunately found a lot of subtle issues with pywebview. That's why we're still considering this to be experimental.
In my experience webview works great on Windows, but struggles on Linux. For examples Videos don't play reliably when using the GTK backend.
We're looking into other ways to run a browser - my favorite would be to just find one already installed and just start it without UI - but that's some way off.
While I'm not certain if the world needs more Javascript,
I am certain it does not need more Python.
That's overly harsh IMO.
Python is not perfect—no language is—but it arguably has the lowest barrier to entry for new programmers, with far fewer "wats" than languages of its kind and era (certainly less than JS). Sure, its reference implementation is not the most performant, but it easily interoperates with C/C++, and alternative implementations like PyPy are also relatively easy to switch to, so it can be performant when it needs to. Dynamic typing is not great for maintaining large codebases, but with the advent of gradual typing, this shouldn't be a major hindrance anymore. It has a great standard library, and a huge ecosystem. My only major gripe with it is the packaging and the insane amount of tooling around it, which I doubt will ever be resolved at this point. But Python is not so bad overall.
I don't know if its overly harsh, but ill give you harsh.
The thing is Python deserves all the hate JS gets and more.
1. The foot guns are real and mean (look up Mutable Default Arguments)
2. The language pushes beginners towards some bad habits (Deep inheritance) and away from good ones (Functional)
3. The performance is very poor (both single and multi threaded)
4. There are no real safe guards, and unexpected type behaviour
5. The packaging story is archaic with no fix in site. (There exist no standard out of the box way to guarantee deterministic builds)
Sure its good at Data, but that is a cultural accident, not by design.
"Dynamic typing is not great for maintaining large codebases" - when your language has an option to not use types, most SWEs will NOT use them - I experienced this firsthand (Angular TS codebases littered with "any" types - direct equivalent analogy to Python in this case). I heard the saying, "you can only burn yourself so many times" - but this seems to be untrue in this case - it's as infinite as human stupidity is.
Ecosystem is great - and probably the greatest thing Python has to offer after the aforementioned low barrier to entry. No language comes close if one wants to get up & going and try out AI/ML - whether using an API or using some packages to make models of one's own - it has everything one can ever need.
I probably don't want to know about the performance implications
To be fair a lot of small startups could benefit from forgoing custom CSS styles for very straightforward frontend dev. So much money wasted on react devs imho (including myself)
Don't hire a React dev, hire a web dev.
When building a full fledged web app I prefer JavaScript - when I do want to do more in Python I find Streamlit is a perfect fit for Python native, low code, but not trying to do too much
Looks cool! But I'm wondering who the target audience is. Most web devs prefer javascript. Are you hoping to target data scientists to build data apps, for example?
Exactly! We've seen from personal experience just how many people are currently working on AI/datascience projects and would love to create UIs for them, but just can't. That's exactly who Rio is for - people who are experts in one field, and don't want to invest hours and hours into other languages just to create interfaces for what they're working on.
That’s really smart. I was previously a data scientist who only knew python and made the transition last year to become a full stack web dev and I honestly had no idea what I was in for. I probably won’t use your tool, but I’ll happily recommend other data scientists check it out so they don’t have to go through what I did.
This looks almost identical to Dash. Any meaningful difference here? https://dash.plotly.com/
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"
Java is the new COBOL in many places, thanks God it is not part of the browser. Such a terrible development of language, terribly slow for anything desktop, terribly slow as DX. We would have 100x more people complaining if there weren't a script attached to that Java.
Most people just can't objectively do the "Counterfactual Thinking" of what if only Java had ever existed and JavaScript never did.
Any developer who has loved JS all their lives would've also loved Java if that's what was available to them all their life. It's largely just what you're used to.
Running JS on the server side is just a mess, and has only been popular to do since NodeJS was invented. Imagine if it was always the SAME code on both client and server starting since 1995. That would've definitely been a better world by far.
Applets did run in the browser, I wrote a couple.
I wrote lots of Applets too. My parenthetical "(Applets)" in that post was misleading, sorry.
Java and Applets pre-existed JavaScript, and purely due to a 10 day timing constraint put on him by Netscape management (right after their deal with Sun Microsystems), Brendan Eich, wanting a Java-syntax, but not having enough time to do it right, cobbled together JavaScript instead.
> and purely due to a 10 day timing constraint put on him by Netscape management (right after their deal with Sun Microsystems), Brendan Eich, wanting a Java-syntax, but not having enough time to do it right, cobbled together JavaScript instead.
Stop spreading FUD. You have no idea what you’re talking about.
Stuff that people hate wasn’t even part of the original demo.
https://buttondown.com/hillelwayne/archive/did-brendan-eich-...
I read that whole blog post and nothing in there disagrees with what I said.
Did you?
> Most of JavaScript's modern flaws are arguably not due to the short development time
[flagged]
I don't appear to be the one who's angry.
[flagged]
Curious to know what you're using under the hood for the python! I've download the repo and a quick search with "pyodide" didn't return anything.
Is python actually executed in the browser or is there a cpython process running on the backend?
No, it needs a server to run. This can be a python process or nginx or anything that FastAPI supports, since this seems to be build on top of FastAPI
You nailed it.
Built-in components do as much work as possible directly on the client. Any Python code however runs on the server. This makes it dead-simple to e.g. connect to your database and also gives you the full power of real CPython, not just a cut-down WASM/transpiled version.
I have always been using Gradio, and it still comes short when it comes to slick UI, even with themes. So it is nice to see solutions like this that has a slicker UI.
I love a framework that replaces JS with Python. I'm less certain about replacing HTML/CSS with Python?
Me too, but I’m curious where this could lead!
I will start using this once a startup raises millions in VC funding and their whole app is built with this.
https://reflex.dev/ is all made in Reflex and has raised a seed round! There are also a few YC companies using Reflex that have raised seed rounds too.
The VC bit is the entire reason I would not use something like this.
Just waiting for them to want their money out and then I am stuck deep in a product fast headed for enshitifaction or abandonment when it fails to make a billion dollars in 2 years.
I am definitely target audience for this.
I am often in need of building internal tools, dashboards - simple apps with simple UI that doesn't need to be unique, drive engagement, or whatever. It needs to get the job done and let me move on.
Streamlit is close but the peculiar approach they take (rerun the script) makes it unwieldly for more complex apps (say, a few related pages, a few dozen components each).
I've been looking for a way to just let me do "GUI app in Python" that get delivered over HTTP and rendered in browser, and Rio is exactly what I was hoping for.
Yeah, no chance Meta will rewrite FB frontend to use Rio. Also pretty sure that I won't be doing any fancy websites in it. But if I can skip dealing with React/Vue/HTMX/whatever on the frontend for some internal thingy.
I only tried doing some simple stuff but so far I really like what I see!
Is the rio.dev website built with Rio?
"Once your components are ready, you can mix and match them to create entire web applications. Even this entire website is written in Rio."
how does this compare to streamlit ?
Nice work! Joined the discord
It's amazing how much you can build without resorting to those fancy frameworks if you dedicate some time to learning Django and how its views work. You do not need a SPA, you need a working app that looks good.
In general I'm not convinced that these "no Javacript" frameworks will last, and to some extend you going to have to re-learn a lot. That's not to say that the idea isn't interesting.
While I have no idea how this would work, I think it would be more useful to have tools like this as a sort of template language for something like Django or Flask. So you get the mature frameworks on the backend and something like Rio to generate the backend, within the context of Django/Flask/Bottle/whatever.
Some modern web applications do need VueJS, React, something like that. CRUD apps mostly don't, but we are way past CRUD apps for a lot of thing. You can maybe get away with calling Asana and Jira CRUD apps, but you can't do Figma with just Django.
Agreed. There are legitimate cases for using SPAs, but often CRUD will suffice.
Why would I want to dedicate time to learning Django when I can just use a simple React framework?
Why the name Rio? Couldn't find in the docs
Good for python developers without JavaScript knowledge, but your app will be attached to a fixed same graphic style.
Rio dev here. You're right in that all Rio components use Material Design, but there is still room for configuration. I can't post pictures here, but if you check our discord, somebody has made a full-retro website that doesn't look material-y at all.
In addition to high-level components there's also some very basic building blocks, like a humble Rectangle. By combining these in clever ways you can get more styles than you might originally expect - just like everything on the web is ultimately colored boxes.
Are there any other frameworks that have similar ideas, perhaps using a functional language?
If you choose to use Common Lisp as a functional language, CLOG is available: https://github.com/rabbibotton/clog
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 enough
slint is more declarative, supports Rust and Python
I prefer less declarative
elixir's liveview is perhaps the best known and arguably inspired a lot of the ones in other languages
yes but doesn't that expect view code that looks a lot like HTML and is usually styled with Tailwind?
the view code compiles to elixir code, it just uses html as a familiar syntax. it's written inline as functions in the source code though so I tend to think of it as closer to a "pure elixir" solution.
so, uh, how does this work?
liveview kinda deal? python to js compiler? something else?
it drives me nuts when this isn’t in the readme, or from what i can find the docs
this is a major implementation detail that will determine the usecases for apps written in rio