[HN Gopher] Rio: Web apps in pure Python
___________________________________________________________________
Rio: Web apps in pure Python
Author : doppp
Score : 159 points
Date : 2024-09-17 14:05 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| adrianpluis wrote:
| Nice work! Joined the discord
| miso2024 wrote:
| 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.
| atum47 wrote:
| Is it the run_in_window() method cross platform? Can you talk a
| bit more about the implementation?
| Retr0id wrote:
| afaict it uses https://github.com/r0x0r/pywebview under the
| hood (so yes, cross-platform)
| Sn3llius wrote:
| 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.
| 3l3ktr4 wrote:
| 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.
| KeplerBoy wrote:
| Is python actually executed in the browser or is there a
| cpython process running on the backend?
| dncornholio wrote:
| 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
| Sn3llius wrote:
| 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.
| 8organicbits wrote:
| Looks like htpy, but with some components and a different syntax?
|
| https://htpy.dev/
| mlboss wrote:
| +1 for htpy. Awesome library.
| aitchnyu wrote:
| Unlike Htpy, this one has callbacks and state in Python.
| 8organicbits wrote:
| 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...
| DannyPage wrote:
| 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?
| babyyoda wrote:
| 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
| Sai_Praneeth wrote:
| Nice! How does it compare to https://fastht.ml/
| gmaster1440 wrote:
| I've enjoyed working with Reflex (https://reflex.dev) as a pure
| Python wrapper over React.
| vishnudeva wrote:
| +1 for Reflex. Truly amazing.
| greener_grass wrote:
| 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!
| Retr0id wrote:
| 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.
| vishnudeva wrote:
| 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.
| greener_grass wrote:
| In JavaScript you can do this: 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.
| vishnudeva wrote:
| Ah I see! Thanks for elaborating! :)
| mixmastamyk wrote:
| Either name them, or squeeze multiple expressions into a
| tuple. More can be done, now with walrus.
| wiseowise wrote:
| > They are everywhere in any proper programming language
|
| FTFY.
| a3w wrote:
| react license applies then to products made with this stack?
| i.e. no product that meta thinks of as a competitor is allowed?
| pjmlp wrote:
| 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.
| dncornholio wrote:
| 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.
| mattgreenrocks wrote:
| 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.
| worewood wrote:
| > 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
| pjmlp wrote:
| 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
| wiseowise wrote:
| > We need something like that for the web.
|
| It's called HTML/CSS/JS.
| mattgreenrocks wrote:
| They should be, but the default browser styling is
| terrible.
| rty32 wrote:
| 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.
| Sn3llius wrote:
| 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.
| eigilsagafos wrote:
| 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 :)
| animal_spirits wrote:
| This kind of framework isn't targeted towards frontend devs
| though. It is targeted towards backend devs who want to
| make frontends easier.
| testermelon wrote:
| That's why they said "vice versa".
| 8organicbits wrote:
| 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")
| Sn3llius wrote:
| 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
| jonkoops wrote:
| > 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.
| dumbo-octopus wrote:
| 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".
| bee_rider wrote:
| 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.
| Phrodo_00 wrote:
| 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
| Sn3llius wrote:
| List access is O(1), which effectively makes them arrays
| :)
| Phrodo_00 wrote:
| 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.
| Sn3llius wrote:
| 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.
| pjmlp wrote:
| C++ has them on the standard library, I would make a
| clear split with C in this regard.
| mixmastamyk wrote:
| 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.
| positus wrote:
| 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.
| simonw wrote:
| 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;
| magnio wrote:
| 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?
| Sparkyte wrote:
| 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...
| zdragnar wrote:
| Remember GWT? I sure do.
| pjmlp wrote:
| Vaadin is still around.
| davidsgk wrote:
| Going from GWT at my first internship to regular
| HTML/CSS/JavaScript at the next (before even TypeScript) was
| such a fresh experience.
| ashconnor wrote:
| Apache Wicket
| j45 wrote:
| 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.
| jtr1 wrote:
| 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.
| Onawa wrote:
| 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.
| TrackerFF wrote:
| 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.
| afavour wrote:
| 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.
| moffkalast wrote:
| 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.
| pjmlp wrote:
| Welcome to what made Flash took off in first place.
| afavour wrote:
| I'm old enough to remember making admins with Adobe Flex. I
| unironically kind of miss it.
| Sn3llius wrote:
| 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.
| moritzwarhier wrote:
| 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.
| bobbylarrybobby wrote:
| How does a screen reader interact with one of these canvas
| pages?
| afavour wrote:
| That would be one of the entries in the "unholy nightmare"
| bullet list.
| wiseowise wrote:
| > 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.
| explorigin wrote:
| Streamlit seems to be doing ok.
| manojlds wrote:
| With tailwind people aren't writing CSS anyway (technically)
| pmarreck wrote:
| Are there any other frameworks that have similar ideas, perhaps
| using a functional language?
| airstrike wrote:
| 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
| kitkat_new wrote:
| slint is more declarative, supports Rust and Python
| patrickmay wrote:
| If you choose to use Common Lisp as a functional language, CLOG
| is available: https://github.com/rabbibotton/clog
| zem wrote:
| elixir's liveview is perhaps the best known and arguably
| inspired a lot of the ones in other languages
| tambourine_man wrote:
| Why the name Rio? Couldn't find in the docs
| red_hare wrote:
| 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.
| Sn3llius wrote:
| 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.
| spankalee wrote:
| 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.
| fkyoureadthedoc wrote:
| 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"
| zem wrote:
| 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.
| fkyoureadthedoc wrote:
| 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.
| rmbyrro wrote:
| An undesired level of condescendence for a message against
| it, no? My first impression...
| pier25 wrote:
| 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.
| ramesh31 wrote:
| >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.
| fkyoureadthedoc wrote:
| > Back in the day we did plenty of "real world professional
| projects" with jQuery.
|
| I was there, it sucked
| robertoandred wrote:
| Flask + HTMX + AlpineJS always seem like so much more work than
| just writing JavaScript.
| beretguy wrote:
| All of it is so much more work compared to PHP + HTML + CSS
| (and no JS).
| robertoandred wrote:
| Is it? Why spend so much time learning PHP when you can
| just use JS?
| mike_hearn wrote:
| 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.
| montebicyclelo wrote:
| 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.
| maipen wrote:
| 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.
| ramon156 wrote:
| 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.
| igtztorrero wrote:
| Good for python developers without JavaScript knowledge, but your
| app will be attached to a fixed same graphic style.
| Sn3llius wrote:
| 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.
| meehai wrote:
| how does this compare to streamlit ?
| bnchrch wrote:
| While I'm not certain if the world needs more Javascript,
|
| I am certain it does not need more Python.
| imiric wrote:
| 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.
| ZeroCool2u wrote:
| This looks almost identical to Dash. Any meaningful difference
| here? https://dash.plotly.com/
| weakfish wrote:
| I would hesitate to label anything Python as "type-safe" per the
| README - maybe type-conscious or just "typed Python"
| insane_dreamer wrote:
| I love a framework that replaces JS with Python. I'm less certain
| about replacing HTML/CSS with Python?
| joshdavham wrote:
| Me too, but I'm curious where this could lead!
| surfingdino wrote:
| 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.
| robertoandred wrote:
| Why would I want to dedicate time to learning Django when I can
| just use a simple React framework?
| mrweasel wrote:
| 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.
| fmnxl wrote:
| 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">.
| fsndz wrote:
| I will start using this once a startup raises millions in VC
| funding and their whole app is built with this.
| apetuskey wrote:
| 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.
| ag_rin wrote:
| 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.
| jhot wrote:
| 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.
| davepeck wrote:
| 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.
| synergy20 wrote:
| 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).
| mixmastamyk wrote:
| 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.
| davepeck wrote:
| 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.
| nomdep wrote:
| > 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/)
| davepeck wrote:
| Peewee never quite got there IMO, and it hasn't kept up with
| the times (modern asyncio, etc.)
| Sn3llius wrote:
| 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.
| bityard wrote:
| 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.
| darepublic wrote:
| 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
| thunky wrote:
| > Settle for premade layouts
|
| Just think of how many man years we could have saved if we
| did this.
| DrillShopper wrote:
| And think of how many man centuries we could have saved if
| we were okay with a page refresh
| amelius wrote:
| We will save man-years, because an LLM will do that.
| Sn3llius wrote:
| Nope! No premade layouts, and not a single line CSS. Give it
| a shot :)
| thegiogi wrote:
| 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.
| Sn3llius wrote:
| 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
| wiseowise wrote:
| > 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.
| jononor wrote:
| 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.
| wiseowise wrote:
| > 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?
| bityard wrote:
| Well, both of those things were hyperbole, not really to be
| taken quite so literally.
| joezydeco wrote:
| 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.
| darepublic wrote:
| 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)
| robertoandred wrote:
| Don't hire a React dev, hire a web dev.
| joshdavham wrote:
| 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?
| Sn3llius wrote:
| 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.
| joshdavham wrote:
| 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.
| kitkat_new wrote:
| I probably don't want to know about the performance implications
| quantadev wrote:
| 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"
| mixmastamyk wrote:
| Applets did run in the browser, I wrote a couple.
| quantadev wrote:
| 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.
| wiseowise wrote:
| > 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-...
| quantadev wrote:
| I read that whole blog post and nothing in there
| disagrees with what I said.
| wiseowise wrote:
| > 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.
|
| Jesus, when will this stupid meme die already?
|
| Programming boomers are as obnoxious as real world boomers.
|
| Modern JS is good, and with TS it's even delightful. Stop
| yelling at cloud, old man.
| meiraleal wrote:
| 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.
| chirau wrote:
| Is the rio.dev website built with Rio?
| senko wrote:
| 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!
| abdullahkhalids wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-17 23:01 UTC)