There are also some similar projects, for example flask-meld  for flask (also via websockets but falls back to polling if not available) and django-unicorn  (afaik only polling).
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.
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.
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.
See the code examples here:
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.
How would you say it compares with similar frameworks like Plotly Dash and Streamlit which attempt to accomplish the same thing?
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.
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.
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.
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.
Just a thought.
In your experience, how much time do you spend in the JS layer?
And even if you want to use those features, you could just use (even automatic!) polyfilling or a library that abstracts any differences away.
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'm preferring dynamic languages and lots of tracing and rollback capabilities in production in 2021.
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).
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.).
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 before going to C# clones like TypeScript. It seems that the compiler would help me a lot more in a language like that.
No you don't. See how autocomplete does with this function:
def foo(s: str):
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?!
I guess it is just hubris.
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.
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.
Well, no because static typing is ancient.
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?
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.
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!
I like the approach, and it's good to see more projects in this space.
I was wondering if there is any similar lightweight options for Java? The only ones I know of are very big libraries, i.e. GWT, Vaadin etc.
Would be hilarious if someone read this and thought “you know I should add static types to python”
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.
Lona can encapsulate html and its functionality into widgets (https://lona-web.org/end-user-documentation/html.html#widget...). The most views then just use a few abstract widgets and maybe around 10 html nodes