Hi! I am fscherf on GitHub and started Lona as side project when covid related home office started in germany (march 2020). I am a full time python web developer and searched for a way to code entire web applications in python without javascript. I came up with a Javascript based rendering mechanism that speaks a specialized protocol over websockets in order to give the python based backend full control over the frontend. My project reached 1.0 a few days ago and i am searching for feedback
It's great to have more and more of these projects, especially since frontend dev is such a huge time sink (if you're not doing it 100%).
There are also some similar projects, for example flask-meld [1] for flask (also via websockets but falls back to polling if not available) and django-unicorn [2] (afaik only polling).
depends on the nature of the opinionated tool I think. If it's opinionated in the sense of boiling down well known concepts to their essence it aids in learning, say Clojure to me is like this.
On the other hand if it's opinionated in an esoteric way it can be quite hard. I remember a HN post about some decentralized chat app that had a language called 'Hoon' I think and it read like someone had reinvented Malbolge.
Ok, so you should definitely look at Plotly Dash and Streamlit. They are both frameworks that have essentially accomplished the same goal.
Plotly Dash doesn't use websockets though, at least not since I was deep in a project to build a Tableau-like viz creator on top of it a couple of years ago.
I'd like to see your thoughts and how this compares.
Ok. Plotly: if i read the docs correctly, Plotly converts python scripts to a web application and they can host the app for you. Lona is meant to be self hosted and runs the python directly. Streamlit: Streamlit provides an editor to create your app, and infrastructure to run it. Lona has no editor and runs on your infrastructure. I would say Lona has the smallest software stack of the three, and you have full control over it
That's actually not the case. Streamlit is an open-source python package to generate frontend components for data-focused apps. You can host it on whatever infrastructure you like.
It's essentially for data engineers who don't even want to think about front end. Streamlit's narrow use-case doesn't seem to compete with Lona, which seems more general and flexible.
Dash (by Plotly) doesn't "convert" Python scripts, no, it works in a similar way to Lona: there is a Javascript frontend that communicates with the Python backend and the Python functions (callbacks) are executed directly.
Both Plotly and Streamlit can be self-hosted. I've hosted prod apps in both frameworks. However, I understand why you thought that, because both companies seek to monetize their open source software via offering ultra-simple, semi-automated hosting for apps built in their respective frameworks. Plotly Dash is just a Flask app with a whole lot of other things wired in and a sophisticated front-end operating on a DAG structure provided by the server that is dynamically generated from the Python code. It's got it's issues, but it's interesting nonetheless.
I'm not trying to be some pedantic know-it-all or anything, I'm just correcting you on this because I'm very curious on the deltas between your very interesting looking framework and those. I love these kinds of projects and I'm excited to take a deeper look at yours once I'm done with my current sprint. Very glad to see you made awesome use of your time during the lockdowns.
Lona needs no cloud services because its meant to run on your infrastructure. It runs your code directly, no translation layer like in Plotly and all of its features are open source. No pricing whatsoever
Dash also can be hosted on local infrastructure and in fact does no "translation", it's also using a complex Javascript front-end that abstracts away the HTTP conversation from the Python end :)
First thing I wanted as well. I want to see how this thing feels. Can you see the joins? Is it a normal webapp at first glance or some clunky monstrosity?
Unfortunately not, but i will have some at lona-web.org/demos soon. There is a ready to use, barebones project linked in the docs. You have only to clone and run "make server" to fiddle around with it.
Just to let you know a few people are still waiting for the demo. The project looks cool but we would like to see it work without having to download and install stuff. It may sound petty but there are many projects out there and practically speaking installing all interesting ones would take ages, so we need to be picky and choose carefully. I bookmarked your page and am visiting it regularly, but the demo is still not there. Thank you very much for your work and I hope a demo appears soon!
I am sorry that you are still waiting. Currently i am very busy fixing bugs and helping people who started Lona projects in the last days. I only work on Lona at night because this is a side project.
The hosting infrastructure behind lona-web.org is very lightweight and Lona makes heavy use of multithreading. I plan on providing "demos" in Form of an code example next to a gif or video of me using it.
I released Lona 1.2 which has a much smaller package size and now can run from a single python script. So there is no need anymore to install much stuff to try it out til then.
OK, I'll give you some feedback. I want a way to write Python-only in apps that look native on iOS, Android, and desktop , and can also be used on the web.
There's React, which has React Native for iOS and Android, and there are even Windows and Mac versions of React Native. However, React Native isn't really complete for desktop yet as far as I can see. For one thing, most of the Mac interface, which comes from Microsoft, was undocumented last time I looked, which was recent.
Flutter (based on the Dart language from Google) seems like it may be very good for iOS, Android, and desktop. But it kind of sucks for the Web. Dart web apps just don't feel like normal web apps, and either the user has to download a 2MB framework or put up with an HTML-only renderer which reportedly has problems with font spacing.
Recently I ran across Framework7, an HTML5 framework that has themes for iOS, Android, and desktop (the latter theme is called Aurora). While there aren't themes specifically for Windows and Mac, I suspect Aurora would be good enough in a context like nw.js or electron, where one of those is used to interact with the native menu and notification systems.
Framework7 supports React, Vue, and Svelte; all excellent Javascript based frameworks. You can also use it with plain JS.
However, I'm a long-time Python programmer, not a JS programmer, and would prefer to use Python.
What I would LOVE to see is a Python-only application framework that worked with Framework7's JS interface, which would provide good iOS and Android themes, as well as an decent one for desktop and web.
It could be served from PyQt or PySide for desktop-native interfacing and Cordova for mobile, and run on the web too.
While nw.js or electron can be used to get the same effect for JS apps, the solution I am pointing toward seems like it would get that effect equally well for Python.
Maybe there are few problems or difficulties using Lona with Framework7 as things stand already. But it would be great if a developer didn't have to even know javascript at all in order to use Framework7 from Python, and that can't be the case since all Framework7's docs and interfaces are aimed at JS folks.
I'm learning JS now and expect to use Framework7 for an upcoming project. Once I've learned JS, I may not care so much about whether or not I can use Python, because the fact is that modern JS is a very nice language, which has taken things like generators from Python and other things from other languages. It now has standard OO abilities, etc.
But I'd still rather not do that; it would be great if there really was a pure python solution for mobile, desktop, and web that allowed most of the same source to run in all those contexts. Something like BeeWare has that ambition, but it seems like they are too far away from fully implementing it to be usable anytime soon. But leveraging something like Framework7 seems to offer the possibility of solving the problem much more quickly.
It does seem that using the approaches embodied in Lona, Dash, JustPy, etc., that it would be possible.
I never used Framework7 but at first glance there it should be no problem to use it in a Lona project. Lona has a contrib module that supports Bootstrap3 and Chart.js at the moment. Pretty much all frameworks that require common web technologies like HTML, CSS and JS can be integrated.
Same here...i don't know about others, but over the years, the reason i have tried avoiding javascript is that the browsers/targets differ enough that its annoying...whereas it *feels* like coding in python (or other languages) seems to achieve more of the "write once, run everywhere" consistency concept...whereas javascript forces me to know about, and code for all those tiny, little browser differences. Ugh! Or, maybe i'm the only one who thinks this? Maybe it is my brain definitively telling me that i should just stick to the backend? (I'll admit that i code alot less nowadays.)
If you're not using features on the bleeding edge, you won't have to worry about browser differences nowadays.
And even if you want to use those features, you could just use (even automatic!) polyfilling or a library that abstracts any differences away.
No application I've got my hands in nowadays (and there are some with a total of more than 100k LOC) contains a single line like "if (isMicrosoftEdge) { ... }". If you're doing that, you're not writing idiomatic JavaScript.
Of course you can do things that aren't portable, but writing open("/tmp/mytempfile.txt", "a") in python isn't portable either. Avoiding that is just knowing your job.
I can't remember the last time I had to deal with browser inconsistencies wrt JavaScript. That's only ever a recurring problem with CSS in my experience, and even then it would be a stretch to call it a consistent problem in my experience.
I think one 20% of the total development time was spent on the javascript client. The client is not very complex. It pretty much makes DOM manipulation API's usable for the backend only
I've started with static languages and I prefer dynamic ones over static. Code is a liability and static typing can create incentives for adding more and more boilerplate that brings little value to the table.
I'm preferring dynamic languages and lots of tracing and rollback capabilities in production in 2021.
I've found this to be a common mindset among people who started out with Java/C#/C++/etc.
Modern statically-typed languages are a totally different beast. Type inference is widespread and powerful, and you end up writing very little additional boilerplate. On top of that, guarantees like the prevention of null values greatly increase the value you get from having static types.
If you haven't tried one in a few years, I recommend revisiting them. TypeScript is a great place to start.
PS: It's totally possible, but also totally unnecessary, to write TypeScript like you would Java or C# (lots of classes, nullable-everything, explicit types for everything). To get the most out of it you honestly have to do the exact opposite of that (turn on strict null checks, use plain types, leverage type inference as much as possible).
My last experience was with Go. Awesome language. I use it when I need extraordinary performance. For everything else, it's Python or vanilla JavaScript.
Even "old" statically typed languages like Java and C++ are streets better than dynamically typed languages like Python (without type hints).
I don't think people have that view because they haven't experienced modern static typing systems. I think they have that view because they aren't willing to admit that they make the kinds of mistakes that static types help with, and they aren't willing to admit that they benefit from the kinds of assistance that static types provide (autocomplete, go to definition, etc.).
I get autocomplete and goto definition with dynamic languages just fine. And I make mistakes that static typing could have helped, but then again they are not frequent enough to justify the bureaucracy (and they don't break production).
Of course, there is no general rule. This is true for the type of projects that I've been recently working on, which are small-scale distributed web systems.
If a new project demands a rigorous type system, I would probably go to something like PureScript[0] before going to C# clones like TypeScript. It seems that the compiler would help me a lot more in a language like that.
No it means that statically typed languages are good for everyone. They aren't "training wheels" that you'd want to remove at any point.
A lot of misguided programmers think they don't write bugs and they don't need any help from autocomplete or linting or whatever. It's not just inexperienced programmers! A lot of experienced ones mistakenly think that they don't write bugs and therefore don't need to use anything that helps them detect bugs. How very dare you suggest that I might make a typo?!
Weird that you’re talking in English without injecting a bunch of literal “noun” “adjective” “adverb” in your sentences. I mean why not really commit to it, ya know? Are programming languages for the human or the computer anyways? Typescript is definitely popular right now. So is McDonalds.
Of course for many advanced things you are forced to use types. Like shader languages. But thats not because the advancement there is in the domain of programming languages.
And your boos mean nothing. I’ve seen what makes you cheer.
English is not a programming language. And anyway English does have a load of extra stuff to indicate the "types" of things. For example proper nouns are capitalised, plurals get different quantifiers, adverbs get a "ly" suffix.
I think Latin is even more of a "typed" language.
But anyway that is really irrelevant because it's not programming.
> But thats not because the advancement there is in the domain of programming languages.
This looks very nice, congratulations! I've been using HTMX [0], and I think having frameworks that let you have interactivity without having to write Javascript are very powerful.
I don't really understand the appeal. I guess if you're primarily a python programmer it's nice to be able to write the front and back in the same language; potentially sharing code for utilities , etc. Just like using node with a JS front-end... But, the front-end is always a JS frontend, I don't see how layering extra abstractions on top of it could ever result in better performance; and also, I imagine you can't do everything you can do with JS with this tool as well; why take power away?
Your example code @ https://lona-web.org/#what-is-lona imperatively builds a web-page... you still are writing the same amount of code but you're adding another step. When you write the html it's declared and it's done, there is no extra processing like there is when you write a program to produce another program.
This is cool though, clearly it has some real utility for you, I'm curious though; how does it improve the web development experience? How does it make you more efficient?
Thats a very good question! I am a full stack developer and have no problems writing big applications in python, javascript, html, css and juggling multiple frameworks at once. Also i am very experienced with async code and asyncio. But at work i am the only one with this skill set. The most of the other developers only have application specific domain knowledge and can write python code.
One of our biggest internal projects at work is our web based accounting system. If there is a bug that is not a technical issue but an accounting issue, i cant do anything (i have no clue about accounting). If the bug touches multiple layers of the software (backend and frontend) our application developers are sometimes busy for days. Thats slows down development and is expensive.
With Lona, and the Lona widgets i created for our accounting system, i can give them a very simple, abstract and pythonic API for common tasks like "show an table and then update it", "show a progressbar with an abort button" or "show a popup with 3 buttons".
The code is more readable for everyone involved, and the application developers can now solve most of their problems on their own.
Performance: Yes you are right, you have to sacrifice performance for this approach to web, but performance is in this kind of applications no problem. CPU time is cheap these days, developer time is expensive. We are a small team.
This is what Wt[0] does, but for C++. You can write the whole web application in C++ without writing any Javascript. The homepage of Wt itself is written in Wt. And there is some impressive widgets showcase page at https://www.webtoolkit.eu/widgets
Awesome work! I also developed a similar project called PyWebIO (https://github.com/pywebio/PyWebIO) last year. It provides less control to HTML element but provides a straightforward way to make input and output. Hope we can learn from each other's project.
I'd like to point to the excellent REMI [1] library that provides similar capabilities to Lona. You can create web apps by only writing Python. They can also be executed as GUI programs. You can even choose REMI to be the output backend of PySimpleGUI [2].
Not sure what the differences are, but good to know there are similar approaches :) Maybe every project can learn from each other. Thanks for sharing!
How well does this work in a high network lentency environment? If I understand correctly, it requires every user interaction to have a round-trip between client and server.
Actually i don't know it exactly because i have no tooling in place to benchmark something like this. The Lona client has hooks which are called when the server needs to long to respond. Until now this was never a problem, neither in development setups or production.
Its a trade-of. Most of my projects are services for <100 concurrent users on semi recent hardware. CPU time is cheap this days, developer time is expensive.
Why do you think that? In fact i do exactly that for my company since beginning of the year and the code looks and runs better than everything we had before.
This is NOT the right solution to the problem you mentioned. If developers don't know what they are doing, they can leave an even bigger mess with this.
