4 ms·

So you're running a Chrome window on top of V8/Node.js, and at the same time starting up a WSGI server just to serve your Python application in that browser win

by pikzen 11y ago

So you're running a Chrome window on top of V8/Node.js, and at the same time starting up a WSGI server just to serve your Python application in that browser window. If that doesn't sound completely batshit insane to you, you have a problem. Or you're a Node.js developer.

rpcope1 11y ago
Yeah, I agree. I think this throws a lot of the major advantages of GUI programming in Python out the window, starting with the back end really needs to be stateless with electron, where as with Tkinter/Qt/WxWidgets the interface is much simpler, and the application can be stateful (which makes life so much easier most of the time). It might be time to give Tk/Tcl a facelift, refresh PySide, or build another good GUI toolkit, but using a browser seems like a really poor solution.
- elcritch 11y ago
  I have an MS in CS and am now working in a science lab. Most scientists (much less grad students!) are not professional programmers. As such I'm working on moving my GUI code from PyQT to html5 based UI's because it simplifies what non-professionals need to learn. By capitalizing on advances in html they can learn some html/js and use it in reports, for UI's, and sharing data, instead of learning Python and QT, while trying to figure out formatting documents in latex or word, and creating their code Matlab or C or Python and then outpatient plots. Electron and html5 have a ways to go, but the synergy that can be gained will be well worth the effort, IMHO. Using a browser for quickly sharing research and making basic UI's to interact with computations actually fits rather nicely into the vision Tim Berners-Lee had when created html for browsing information at CERN. As far as statefullness, GUIs really would be better off moving away from implicit state to ReactJS functional style approaches.
  - deleted 11y ago
    [deleted]
  - rpcope1 11y ago
    I'm not sure I agree much at all, but I take issue with your last statement. Why on earth would I ever want to move to anything remotely like ReactJS when I'm building a single user application? You must carry state information, and in that case explicitly having state is both often conceptually simpler, easier to modify/debug, and require far less code than using something literally insane like using js + DOM.
    - elcritch 11y ago
      It's good to have varying opinions. I'm unsure what you're considering positive about state. Synchronizing state among multiple widgets in QT for example is a pain and quickly becomes become fragile. To help deal with this, QT 5 introduced a JavaScript based reactive programming framework before ReactJS was popular. See https://en.m.wikipedia.org/wiki/QML#Property_bindings https://en.m.wikipedia.org/wiki/QML#Property_bindings Perhaps not completely an insane idea to some :)

by pikzen 11y ago

rpcope1 11y ago

Yeah, I agree. I think this throws a lot of the major advantages of GUI programming in Python out the window, starting with the back end really needs to be stateless with electron, where as with Tkinter/Qt/WxWidgets the interface is much simpler, and the application can be stateful (which makes life so much easier most of the time). It might be time to give Tk/Tcl a facelift, refresh PySide, or build another good GUI toolkit, but using a browser seems like a really poor solution.

elcritch 11y ago
I have an MS in CS and am now working in a science lab. Most scientists (much less grad students!) are not professional programmers. As such I'm working on moving my GUI code from PyQT to html5 based UI's because it simplifies what non-professionals need to learn. By capitalizing on advances in html they can learn some html/js and use it in reports, for UI's, and sharing data, instead of learning Python and QT, while trying to figure out formatting documents in latex or word, and creating their code Matlab or C or Python and then outpatient plots. Electron and html5 have a ways to go, but the synergy that can be gained will be well worth the effort, IMHO. Using a browser for quickly sharing research and making basic UI's to interact with computations actually fits rather nicely into the vision Tim Berners-Lee had when created html for browsing information at CERN. As far as statefullness, GUIs really would be better off moving away from implicit state to ReactJS functional style approaches.
- deleted 11y ago
  [deleted]
- rpcope1 11y ago
  I'm not sure I agree much at all, but I take issue with your last statement. Why on earth would I ever want to move to anything remotely like ReactJS when I'm building a single user application? You must carry state information, and in that case explicitly having state is both often conceptually simpler, easier to modify/debug, and require far less code than using something literally insane like using js + DOM.
  - elcritch 11y ago
    It's good to have varying opinions. I'm unsure what you're considering positive about state. Synchronizing state among multiple widgets in QT for example is a pain and quickly becomes become fragile. To help deal with this, QT 5 introduced a JavaScript based reactive programming framework before ReactJS was popular. See https://en.m.wikipedia.org/wiki/QML#Property_bindings https://en.m.wikipedia.org/wiki/QML#Property_bindings Perhaps not completely an insane idea to some :)