Show HN: Lona – Framework for responsive web apps in full Python without JS(lona-web.org)
lona-web.org
Show HN: Lona – Framework for responsive web apps in full Python without JS
http://lona-web.org
80 comments
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
Do you have an online demo?
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.
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.
Still waiting for this!
+1, not in docs nor in github :(
This is like Hotwire, https://hotwired.dev/ or Phoenix https://phoenixframework.org/ , but for Python
Phoenix is really cool and ergonomic, albeit a bit strongly opinionated (which makes newcomers clueless IMO).
I've always felt like I had a much, much easier time picking up strongly opinionated tools rather than open ended tools if I'm being honest.
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.
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.
I'd be interested and will check this out. I have used plotly dash and love to hear a compare and contrast
Unfortunately i don't know plotly and have no experience with dart programming.
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.
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.
There is a fork / enhanced version of Dash that does use websockets: https://github.com/richlegrand/dash_devices
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
>Streamlit provides an editor to create your app
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: https://github.com/streamlit/streamlit
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: https://github.com/streamlit/streamlit
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.
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.
@JPKab: Ah ok! Thanks for making this clear
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.
Just a thought.
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.
Just a thought.
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.
https://lona-web.org/end-user-documentation/html.html#fronte...
https://lona-web.org/end-user-documentation/html.html#fronte...
Thanks for the link. Will investigate further.
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).
[1] https://github.com/mikeabrahamsen/Flask-Meld [2] https://www.django-unicorn.com/
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).
[1] https://github.com/mikeabrahamsen/Flask-Meld [2] https://www.django-unicorn.com/
Sorry, not a web dev. What is polling in this context?
Awesome work!
How would you say it compares with similar frameworks like Plotly Dash and Streamlit which attempt to accomplish the same thing?
How would you say it compares with similar frameworks like Plotly Dash and Streamlit which attempt to accomplish the same thing?
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 :)
Ah ok! I didn't know that
Not nitpicking, but i had to reread “JavaScript based” several times before it finally clicked as “JavaScript-based” or based on Javascript (style).
Nicely done.
Nicely done.
Thanks!
Whoops! Thanks for the feedback (i am no native speaker)
This looks so tempting but each time I try to use something to avoid Javascript, I end up spending more time debugging the Javascript.
In your experience, how much time do you spend in the JS layer?
In your experience, how much time do you spend in the JS layer?
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.
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 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 agree. Typescript is much nicer than Python and doesn't suffer from the problem you describe. I think you'd be mad not to use it at this point.
TypeScript, if you use its strong points, has a much slower development pace than a language such as Python. To each their own.
How so? After having used typescript, Mypy and static languages, I could never go back.
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'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).
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).
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.).
It's annoying.
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.).
It's annoying.
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.
[0]https://www.purescript.org/
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.
[0]https://www.purescript.org/
> I get autocomplete and goto definition with dynamic languages just fine.
No you don't. See how autocomplete does with this function:
No you don't. See how autocomplete does with this function:
def foo(s):
s.
def foo(s: str):
s.Static languages are good for beginners. Like training wheels for programmers.
Does the downvote mean static languages are bad for beginners?
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?!
I guess it is just hubris.
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.
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.
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.
Well, no because static typing is ancient.
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.
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.
[0] https://htmx.org/
[0] https://htmx.org/
Thanks!
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?
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.
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
[0] https://webtoolkit.eu
[0] https://webtoolkit.eu
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!
[1] https://github.com/dddomodossola/remi [2] https://pysimplegui.readthedocs.io/en/latest/
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!
[1] https://github.com/dddomodossola/remi [2] https://pysimplegui.readthedocs.io/en/latest/
I think Apache Wicket takes a similar approach for Java? https://wicket.apache.org/
I like the approach, and it's good to see more projects in this space.
I like the approach, and it's good to see more projects in this space.
I asked this question on this thread. Thanks!
Interesting! I didn't know this project.
Thanks!
Thanks!
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.
This is pretty neat. Will check it out.
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.
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.
Kweb is in kotlin, not java, but it runs on the jvm https://github.com/kwebio/kweb-core/
Thanks!
Personally I think Rails + Hotwire nailed this. I believe there's also a Django port of Stimulus but maybe not Hotwire.
Havent you heard? If you want www devs to use it you have to graft on some hideous typesystem along with jsx.
Would be hilarious if someone read this and thought “you know I should add static types to python”
Would be hilarious if someone read this and thought “you know I should add static types to python”
This specialized protocol thing sounds like ASP.Net web forms all over again. Loved it for developing but performance usually s**ed balls
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.
I'm super happy with unpoly. Enhancing HTML to make it do things it doesn't do by default is an awesome idea.
It would be cumbersome to develop and maintain rich and complex web user interfaces its approach.
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.
Writing HTML in Python is just so bisarre to me and very messy and a bad idea.
In my experience scattering an application over python and javascript ends in very messy code most of the time.
Here are some snippets from our legacy codebase, where the exact same method is used (Django Crispy Forms):
https://walkman.cloud/s/TWmtNMjMM3ZfdZM
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.
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.
No approach is right for every problem. For the applications i develop for work this python only approach really cleaned up the code.
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
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