Just because at some point they did GitHub releases doesn't mean they still do, especially when the installation instructions only mention other channels.
We (at repl.it) discovered remi when we were looking for a native GUI alternative. Found remi and was able to write a TicTacToe game in 30 minutes, it felt natural and the app is fast enough to not notice it's remote. Take a look (source code there too):
The reason we started looking into it is that we have a lot of users wanting[1] to write GUI apps and although we support all the major Python web frameworks[2], users, especially novices, still find it easier to write native GUIs. And I can't blame them, after you've learned a bit of Python, learning to write web apps is a whole new ballgame (HTML and CSS are a different style of code altogether that warps people's minds at first).
Hey -- Just want to give a shout-out and big thanks to the folks at repl.it!!! I love it! I'm teaching college kids who have never written code and repl.it is my platform of choice for quick examples while in the middle of a lecture. At the end, I just save it, and the kids can come revisit the in-class examples whenever they want. It's a great teaching tool! Thanks!!!
How does this compare to Dash by plotly and also Jupyter Dashboards?
At first glance the use cases seem different (applications vs dashboards) but they both provide widgets and GUI elements. Are there things that would be much simpler/quicker in one vs the other?
correct, they seems different but you can achieve "same results" with both. dash is really powerful for look n feel and for plots. but I see it a bit confusional for callbacks and object oriented development. I never used it, so maybe I'm not the right person to ask for a comparison.
Seems great! I used https://github.com/miyakogi/wdom a few times but it wasn't satisfying because you have to get your hands dirty with js when you want to customize things (not in js libs but with the widgets).
good question, comparison beyween projects is a good investigation method. they are really similar projects. flexx has more modularity and depends from powerful libraries like Tornado. Remi has its own webserver and has zero dependencies, not necessarily a good choice but however a notable difference.
I don't quite understand your answer. As the readme says:
> Remi should be intended as a standard desktop gui framework. The library itself doesn't implement security strategies, and so it is advised to not expose its access to unsafe public networks.
So if listening on localhost to provide a GUI on the users desktop, is it not meant to be protected from attacks from the web?
you are right, it requires further explanation. it is intended to be used on localhost and also on the web, preferably on safe networks like VPN. it implements ssl encription and a basic http authentication. technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. I consider it unsafe because I never spent enough time to test the framework penetration resistance.
That's scary. Listening on localhost or serving a LAN/VPN behind a firewall does not make your web app secure from attackers on the Internet unless you air gapped. HTTP Basic Auth and HTTPS doesn't change that. Please do read up on CSRF.
This has been an issue for decades and just recently been in the news due to massive attacks against home routers (web apps listening on the LAN) and desktop apps (both web apps and web APIs listening on localhost). I get the impression that this has not been considered.
thank you so much for the advice.
however, as previously mentioned:
technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions.
this means that the attacker have to know the ID of an object instance, in the actual running instance to point to a defined function.
however, the safety of an application is up to the developer, that can leave opened also the door of a safe atomic bunker
Am I correct to interpret this as it's up to the app developer not to put any features that do anything of any importance in the web interface, because one should operate under the assumption that it's not only the logged on user in front of the computer (even when address='127.0.0.1') that can press the buttons?
Unless I'm completely misunderstanding I don't agree that is at all comparable with the security model expected of a "standard desktop gui framework" nor safe.
Though indeed if there are large, random and unpredictable IDs required to perform actions it may defeat or make the attack difficult.
you are correct it could be theoretically pressed by someone else, but it should be really difficult because of the unpredictability of IDs. It should be simpler to attack flask or django based webinterfaces. doesn't it?
thank you for the advice. it should be pretty simple to protect an app from that kind of attacks. however this doesn't mean that remi is a safe web framework. personally I feel like @nicolaslem (look at his comment).
I'm building an app using Bottle as the framework and getting HTTPS to work properly (with a proper certificate) has been a nightmare. I think I fixed it after a full day of research and tinkering yesterday.
This app is super small... maybe 5 users simultaneously, so I don't need the overkill of Django or integrating with something on Apache or Nginx.
REMI looks pretty straightforward and lightweight; even without HTTPS it looks useful... I'll give it a whirl and keep it in my bag of tricks!
yes, https is supported. you have to config 3 parameters in the "start" function call:
certfile: ssl certificale filename
keyfile: ssl key file
ssl_version: authentication version (i.e. ssl.PROTOCOL_TLSv1_2). If None, disables ssl encription
Awesome! That's great news! I may try to rewrite some parts of my app and see if REMI is a good fit.
Bottle is great if you have a simple use case... but getting HTTPS going was horrible. I can't count how many back-end engines I tried (cherrypi, paste, cheroot, gevent, waitress, etc.). Finally got it working on gunicorn.
I'd love to find a framework that abstracts all this away so I don't have to think about it...
Just my two cents, but there are good reasons why Python web frameworks are encouraged to sit behind a reverse proxy:
- Security, most WSGI servers are not designed to handle bad actors like intentionally slow clients. It is usually trivial for a client to DoS your application.
- Separation of concerns, letting your framework focus on its core job rather than pilling features related to crypto and certificate renewal.
The fact that you struggled getting HTTPS to work probably means that you were heading the wrong direction. I suggest to take a look at Caddy[0]. It is a small, handles HTTPS automatically and is super easy to put in front of a Python application.
I have worked with it and it's great. Any thoughts on using an established css framework (i.e. bootstrap)? Because manually sizing all controls for different monitors and complicated layouts are cumbersome.
there are some additional container widgets than in the past that allows auto sizing and positioning. these are VBox HBox (for flex layouting) and GridBox. however someone successfully integrated bootstrap in his application using remi. personally I see it an unuseful complication. thaks to its lightweight infrastructure, a remi page occupy only few kilobytes.
I'm not sure if author know about Shiny, it's basically same concept, write html GUI in R, serve with a web server. Shiny is quite mature, and I feel they have some good parts that can be inspring:
It's good to only code GUI in one language, but it's kind of unavoidable that you still need to learn html and css (even javascript) if you want to more control and customization.
- Shiny have some html tag functions to make it really flexible to construct html.
- You can customize css by adding your own.
- Shiny support adminLTE dashboard and bootstrap styles, DataTables js library, interaction with plot and DataTables.
Similar to Shiny is Bokeh for python, which appears to be trying to replicate the Shiny experience. While you can only get so much control without resorting to JS injections, it's pretty good for [select options -> search -> visualize result] type of problems.
49 comments
[ 2.7 ms ] story [ 136 ms ] threadI wish it was easier to find the signal on, "is this project abandonned?" "Does it still work?"
We see Davide helping people on our forums and fixing bugs as they come.
https://repl.it/talk/ask/Python-GUI/6924
Just because at some point they did GitHub releases doesn't mean they still do, especially when the installation instructions only mention other channels.
https://github.com/dddomodossola/remi/releases/tag/v1.2.2
https://repl.it/talk/share/Python-GUI-Tic-Tac-Toe/6145 (might not take the HN load tho)
The reason we started looking into it is that we have a lot of users wanting[1] to write GUI apps and although we support all the major Python web frameworks[2], users, especially novices, still find it easier to write native GUIs. And I can't blame them, after you've learned a bit of Python, learning to write web apps is a whole new ballgame (HTML and CSS are a different style of code altogether that warps people's minds at first).
Here is a basic demo that renders a plot (using matplotlib) if you want to fork and play around with it: https://repl.it/@amasad/remi-repl-demo
[1]: https://repl.it/talk/ask/does-tkinter-work/6685
[2]: https://repl.it/languages/django
At first glance the use cases seem different (applications vs dashboards) but they both provide widgets and GUI elements. Are there things that would be much simpler/quicker in one vs the other?
How does remi compare to https://github.com/flexxui/flexx?
For example, flexx can translate parts of the app to JS to have a more reactive experience.
I have seen some applications like this, but they fail to check the origin header.
So if listening on localhost to provide a GUI on the users desktop, is it not meant to be protected from attacks from the web?
This has been an issue for decades and just recently been in the news due to massive attacks against home routers (web apps listening on the LAN) and desktop apps (both web apps and web APIs listening on localhost). I get the impression that this has not been considered.
https://en.wikipedia.org/wiki/Cross-site_request_forgery
however, the safety of an application is up to the developer, that can leave opened also the door of a safe atomic bunker
Unless I'm completely misunderstanding I don't agree that is at all comparable with the security model expected of a "standard desktop gui framework" nor safe.
Though indeed if there are large, random and unpredictable IDs required to perform actions it may defeat or make the attack difficult.
https://docs.djangoproject.com/en/stable/ref/csrf/
https://flask-wtf.readthedocs.io/en/stable/csrf.html
My recommendation is you read up on the subject and I'll leave it at that. You have been given everything needed to search for more information.
I'm building an app using Bottle as the framework and getting HTTPS to work properly (with a proper certificate) has been a nightmare. I think I fixed it after a full day of research and tinkering yesterday.
This app is super small... maybe 5 users simultaneously, so I don't need the overkill of Django or integrating with something on Apache or Nginx.
REMI looks pretty straightforward and lightweight; even without HTTPS it looks useful... I'll give it a whirl and keep it in my bag of tricks!
Bottle is great if you have a simple use case... but getting HTTPS going was horrible. I can't count how many back-end engines I tried (cherrypi, paste, cheroot, gevent, waitress, etc.). Finally got it working on gunicorn.
I'd love to find a framework that abstracts all this away so I don't have to think about it...
- Security, most WSGI servers are not designed to handle bad actors like intentionally slow clients. It is usually trivial for a client to DoS your application.
- Separation of concerns, letting your framework focus on its core job rather than pilling features related to crypto and certificate renewal.
The fact that you struggled getting HTTPS to work probably means that you were heading the wrong direction. I suggest to take a look at Caddy[0]. It is a small, handles HTTPS automatically and is super easy to put in front of a Python application.
[0] https://caddyserver.com/docs/proxy
It's good to only code GUI in one language, but it's kind of unavoidable that you still need to learn html and css (even javascript) if you want to more control and customization.
- Shiny have some html tag functions to make it really flexible to construct html.
- You can customize css by adding your own.
- Shiny support adminLTE dashboard and bootstrap styles, DataTables js library, interaction with plot and DataTables.