This looks interesting! I want to try it out for a project we are working on, but we would need some of the features like callers, doctoring, and typing
https://reflex.dev/ is all made in Reflex and has raised a seed round! There are also a few YC companies using Reflex that have raised seed rounds too.
We do use nextjs but I think what's the most handy part of Reflex is the simplification of state management and event handling so there is more complexity to the framework.
Opt-out telemetry in companies based on open source projects has become a critical component of YC applications, VC pitches, and acquisition pitches. If it was opt-in of course nobody would turn it on. It's shady but I also somewhat understand the founders who are doing product-led growth by giving out the product on GitHub/PyPI, yet still need some usage metrics to quantify the stickiness to their backers. Pip installs and git clones/forks are only a loose indicator of real usage.
if it's a paid product and it's part of an agreement for support then sure, but for a free product? when you know some high percentage of users are never going to even know that the option to opt out exists?
Yeah I see your point it's definitely something we are going to try and reduce in the future. We wanted to give the users the ability to wrap external react components and leverage that ecosystem so there were trade off we had to make.
The 3MB of JS is in dev mode or prod mode? (Is this similar to the other comment where they were running in dev mode but when they ran in prod it was much smaller ~ 340KB?)
We have 5 badges in total, and 1 of them to points to our integrations test passing. And the integration test do serve an important purpose in making sure we are compatible on multiple different os and don't make a change that would break WSL for example. More info here https://github.com/reflex-dev/reflex/tree/main/.github/workf...
The others are the current latest version, python version we support, how many people are on our discord (A metric to see community activity), and a badge that points to our docs. I think all of these are important but open to suggestions on ones you think would serve a better purpose.
Can you be more specific in your criticism wrt disabled people? It's a lot easier for someone to receive feedback when it's specific, especially when discussing something like a README. It can be helpful to others reading who are on the fence about badges and their ilk, too.
What, specifically, is the issue with the badges concerning accessibility? Most badges I see can be reduced to a div containing two spans and some text, which should be usable with a screen reader. Is there missing alt text, aria attributes, etc?
Re: tests, it comes down to developer culture. It may be acceptable for experimental or alpha/beta versions to not pass tests, live on a separate branch, etc. Distros should be live-testing any packages they ship, too; upstream releases aren't guaranteed to be tested, depending on the upstream you're working with. It's nice to know that the latest commit is actually working without having to double check CI locally. However, tests also aren't created equally. The project author(s) could be learning how to refine their tests, and not actually trust the CI's results (yet).
Can we argue that's sloppy, or that they should've never done that before merging and pushing? Sure. Not sure where it gets us. Actionable feedback and cautionary advice is useful, though.
What is the timeline on the coming soon features?