Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.
Fast forward, I understand nothing of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could not lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand nothing about painting the background the correct shade of blue!
It's like a whole world I had been sealed off from has reopened.
Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?
https://github.com/streamlit/streamlit/issues/1440
It's over a month old now, with multiple people reporting the same bug and iterating on the problem with no apparent narrowing towards a reason for why this happens, let alone a solution.
As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usually resolving that problem.
[1] https://github.com/streamlit/streamlit/pull/1494 [2] https://discuss.streamlit.io/t/displaying-images-from-opencv...
I know this is a complicated problem domain (because it's the web, Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and a default value; the image breaks before the input control is touched. And it's not a slider, it's a dropdown that makes the app query a db first... I mean, I think I can do this in plain Ajax if I get my story right about sending images. But it's a hobby project meant to explore mathematical ideas...
If you can't do sliders reliably, they should be moved to a beta branch. Streamlit overpromises and underdelivers. But it's a great project, I don't want to be too negative about it.
As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.
Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.
Or maybe your app passes a 'theme' through various contexts and you have to find the right theme and find the thing you need to tweak the background colour for, which might be in a CSS file pulled in through Webpack if you're lucky.
If you're not lucky, maybe there's some funky SASS/LESS setup where all of the colours are stored in variables describing their purpose, in one of a dozen specially categorised files for storing globals. Now there are six or seven values all with '#xxxxxx' as the colour value and you don't know which one it is, so then you're thinking, is this `lightBlue7` or `darkBlue-3` or `cyanish4`.
Or maybe a few event listeners pull down style information into the component state after first rendering with a bunch of placeholders, so now the component you're looking to change the background of is a function of the time spent on page.
Or, maybe you found some CSS and it was an easy change, but then the project is in Typescript and the CSS is actually derived at build-time from an enum containing all of the config, which is used to replace specially formed strings in the CSS while having sensible defaults in dev.
If you're cursed, the CSS isn't even in your frontend at all and a server-side rendering system is generating your styles from DB backed configurations, which are queried by a graphql layer in your frontend so users can customise their UI in their profile settings, so you have to write a database migration and run a full deployment to add the new colour and its customisation UI to the frontend.
Now...I'm lost. Every time I poke at the frontend, I get lost again. >10 years as a backend developer of various stripes, three of those in Node even...still lost.
Anyone who really grokked REST would never say it's nonsense to use with a JSON API.
Let me show you my reasoning:
JSON is not a hypertext, even if you include URLs in it. [0]
HATEOAS requires a hypertext (see the first word of the acronym)
HATEOAS is "an essential part of the of the 'uniform interface' feature of REST" [1]
Therefore a JSON API, even with some embedded URLs, using multiple HTTP Methods and following a traditional hierarchical path scheme, is not REST-ful.
[0] - A sufficiently advanced client could interpret a JSON-encoded hypertext in a general, uniform manner. However, in practice, this is almost never the case.
On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner.
HTML is a good-enough-to-great hypertext, we should probably stick with it.
I'm sorry, I couldn't resist the pun.