IDOM – It's React, but in Python
rmorshea.github.io
IDOM – It's React, but in Python
1–10 of 13 posts
Re: IDOM – It's React, but in Python
#2Wow. This seems awesome. Has anyone tried replacing Dash apps with this yet?
Re: IDOM – It's React, but in Python
#3This was much needed for python.
Re: IDOM – It's React, but in Python
#4Apologies, but why?
Re: IDOM – It's React, but in Python
#5Apologies, but why?
The article has a section that addresses this.
Re: IDOM – It's React, but in Python
#6Apologies, but why?
If you have went thru the article by now you must've also thought, why Blazor(c#) and phoenix(erlang) frameworks are required.
Re: IDOM – It's React, but in Python
#7This was much needed for python.
Actually back in the ActiveX glory days, ActiveState had browser plugins for Perl, Tcl and Python as scripting languages.
That is why script has a language attribute, but we ended up being stuck with JavaScript.
Re: IDOM – It's React, but in Python
#8The is interesting to me because I want to do frontend and I don't know javascript.
At first glance, it seems there is a big problem: _every_ event means a clientserver round trip! I tried this with their basic examples, when I cut the server the client becomes static. It seems to me a lot of the logic could be kept client side. Am I missing anything here?
Re: IDOM – It's React, but in Python
#9The is interesting to me because I want to do frontend and I don't know javascript. At first glance, it seems there is a big problem: _every_ event means a client server round trip! I tried this with their basic examples, when I cut the server the client becomes static. It seems to me a lot of the logic could be kept client side. Am I missing anything here?
Although they have live versions in the documentation, are these widgets being served by a dedicated server or is it all client side?
Re: IDOM – It's React, but in Python
#10As a Python dev this code is extremely difficult to follow. If I take off my Python glasses it kinda makes sense reading the examples.
Take a look at ‘toggle_1()’ function, which is called by a lambda, and takes no arguments. On top of that, it refers to ‘toggle_state()’ which also doesn’t take any arguments. That function calls ‘set_state()’ and is fed a lambda which toggles a Boolean input and somehow all that switches the value of ‘input_1‘.
That boggles my Python mind.
Wouldn’t everything be a lot less magical if it was oop? Then you’d go ‘input_1.toggle_state’ and it is pretty clear to everyone which variable is being toggled.
I know this library is mirroring another framework in another language, but this is the first time I’ve read a piece of code and thought “maybe oop is the better option”.
My point is not to try and argue that this is a poor framework. I have no right to such an opinion and I get that this code generates a JavaScript/html application which will eventually get executed and therefore everything happens one extra step detached from the Python code.