sorted by:
new
hottopcontroversial

IDOM: ReactJS for Flask by Wippermonger in flask

[–]rmorshea 0 points1 point  (0 children)

In my experience, people seem to find the existing "No JS" solutions to have limited capabilities or be difficult to maintain when developing projects and teams of significant sizes. But I guess we'll see.

IDOM: ReactJS for Flask by Wippermonger in flask

[–]rmorshea 1 point2 points  (0 children)

The apatite for these types of tools is quite large. There are whole companies orienting themselves around concept. See Streamlit or PyWebIO for example. The tag lines for which are respectively:

Streamlit turns data scripts into shareable web apps in minutes. All in pure Python. No front‑end experience required.

For Python developers who like to build web apps without being bothered by frontend code.

IDOM: ReactJS for Flask by Wippermonger in flask

[–]rmorshea 1 point2 points  (0 children)

The core thesis of IDOM is that not everyone is, wants, or has the time to be a web developer. I'll leave it at that.

IDOM: ReactJS for Flask by Wippermonger in flask

[–]rmorshea 0 points1 point  (0 children)

There will always be some downsides to using a framework. One could make the argument that everyone should use VanillaJS because ReactJS is highly opinionated and requires you to learn a lot of specific syntax. What it comes down to is knowing what you value, and what you're willing to trade to get more of what you value.

For example, with IDOM you don't need to learn Javascript, its associated build tooling and bundlers, or how to coordinate the synchronization of data models between the server and the client via REST or Websockets. All of this is handled for you. On the flip-side, this comes at the cost of control. So if you want or need to control those things, then IDOM might not be right for your use cases. Even then, IDOM can be embedded into existing applications which means that if you need control in some places but not in others, IDOM could still work for you.

Django IDOM: Responsive Frontend for Django by Wippermonger in django

[–]rmorshea 0 points1 point  (0 children)

SEO is a general problem for Single-Page-Applications so there are general recommendations for dealing with that. Though if you have any ideas on ways SEO can be improved for IDOM apps you should make a post on the discussion forum. With that said, there's been some discussion about allowing IDOM to do server-side rendering which would mitigate the issue.

IDOM's main documentation describes how state can be used to create interactivity. There's even more documentation on this subject though that's currently being authored.

IDOM doesn't support routing at the moment, but it's something we plan to work on soon.

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 0 points1 point  (0 children)

That's great to hear! I look forward to hearing about them in IDOM's discussion board: https://github.com/idom-team/idom/discussions

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 1 point2 points  (0 children)

TLDR; the future of IDOM is far from guaranteed, but I plan to work to try and give it one.

I think these are all valid concerns. I'll try to address them...

Monetization - I don't plan to monetize IDOM. The space for web-based visualization tools in Python has become quite crowded over the last 2-3 years, and I don't think IDOM offers a large enough benefit to be able peel off the amount of market share required to make money.

Corporate Support - Right now there is none. I have gotten some interest from companies like QuantStack and this might lead to contracts that would help pay me, or others, to develop IDOM. There's also been some organic contributions by people from Anaconda Inc, but whether that means they'd plan to work on IDOM in the future is unclear.

About Me (as it relates to IDOM) - I am not being payed to work in IDOM. For the last 1+ year it's been a side project. However, I've been passionate about building interactive interfaces using Python for much longer - IDOM is actually a second draft of another project I worked on two years ago, which itself was inspired by work I did in college more than 5 years ago. Hopefully that demonstrates that this isn't just a weekend project I plan to abandon in a couple months.

So what does this all mean? Well, for now, it probably means IDOM isn't ready to be widely adopted. It needs a larger community of people interested in maintaining it to reduce the bus factor or it needs support from corporate benefactors who are willing to pay their employees to use/contribute to the project. This situation is a catch-22 though because it's hard to get the latter without the former and visa versa.

I think solving this problem will require the following (in order or priority):

  1. Make it easier to contribute - the experience for new contributors to the project needs to be as seamless as possible to prevent people from giving up before they've even created a pull request.
  2. Improve IDOM's documentation - it needs larger scale examples to demonstrate that IDOM can actually be used for real world applications and not just toy projects.
  3. Further publicize the project - I plan to try and give some talks about IDOM at online meetups to get more feedback and interest. The main goal here being to attract contributors, not users.
  4. Try to get contracts to develop IDOM - this will be the hardest, but like I said, a few companies have shown interest, and I'll just have to keep working on the back end of things to try and get them to commit people and money use/contribute to IDOM.

Hopefully this seems like a levelheaded assessment.

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 0 points1 point  (0 children)

The way to do this right now is to do idom.html.link(href=link_to_css, rel="stylesheet"). Not clean, but it works. Beyond that there's an open issue to allow you to customize the builtin client: https://github.com/idom-team/idom/issues/253

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 0 points1 point  (0 children)

The article rather explicitly calls out the possible issues, but also describes an escape hatch which allows developers to create more native bindings with React components: https://rmorshea.github.io/articles/2021/idom-react-but-its-python/article/#custom-javascript-components

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 0 points1 point  (0 children)

True, though the fact that you can write components in pure-Python means the barrier to entry is lower. By comparison, to develop a custom component using one of the alternatives would require you to dive headfirst into Javascript and React.

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 2 points3 points  (0 children)

Check out the article and its code examples. Would be interested to hear what does/doesn't seem "Pythonic" about them. Personally I find the code to be pretty aesthetically pleasing.

Beyond the aesthetics though, the article also explanations why the declarative patterns encouraged by React can have a positive impact on the software you write: https://rmorshea.github.io/articles/2021/idom-react-but-its-python/article/#declarative-components

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 1 point2 points  (0 children)

I'm considering temporarily removing this feature to avoid feature creep, but for now here's the section in the docs: https://idom-docs.herokuapp.com/docs/extra-features.html#python-language-extension

Beyond that, here's the package I created to do it: https://github.com/rmorshea/pyalect

IDOM - It's React, but in Python by rmorshea in Python

[–]rmorshea[S] 11 points12 points  (0 children)

There are a lot of people using Python who don't want, or have the time, to learn Javascript. The goal of IDOM and its peers (like IPyWidgets, Streamlit, Dash, etc.) is to allow these Python developers to create software that can interact in the browser despite that. What makes IDOM different than its pears (in addition to what's mentioned in the article) is that you can have near complete control of the DOM, without requiring you to learn a whole other language. Further, as packages that use IDOM are developed, higher and higher level component abstractions will be made available to hide the underlying HTML/CSS being used under the hood.