Yes, #00. Of course we'd count from 0.
New here? Javelit is Streamlit for Java. Find it on GitHub.

Being a solo developer 100% focused on building, with no one to hinder you with reporting, feature asks and catch-up meetings. Such a great feeling. Such a great road to failure.
After 3 months building Javelit with no feedback, only for friends that would make Mom's Test moms sound like Cruella, it was time for a reality check.
This week I finally shared Javelit, first with a selected few, then on Reddit.

Glad to see the project was well received!
Javelit even got hacked to showcase the new JBang-powered Jupyter notebook. Way to go! 

So many things... it's the first iteration of this dev log after all.
What you need to know at this point: Javelit does not support all of Streamlit's components yet, but this will come with time. Javelit already supports 30+ components, multipage apps and forms. 

Not talking to people. Not supporting all features. So how did I prioritize?  Mostly by exploiting the late mover advantage to it's fullest. 

Phase 1
The core of Streamlit is its development model: the user updates a state in the frontend --> the backend reruns the app with the new state to re-render the frontend. The app runs top to bottom, and every component called is stacked in the frontend, in the same order. Easy enough: a list of states, some key and a diff operation would do. Claude Code doable.
This quickly gets more hairy though: out-of-order positioning, components nesting, forms support, multiple pages, re-render optimization, etc... all of this is supported by Streamlit.

In the first months, my roadmap was simple: design and build to support all the features above. Smells like over-engineering? This is not. Javelit's core logic is tiny and actually way simpler than Streamlit's. Streamlit had to evolve an existing codebase, adapting to unanticipated use cases as they emerge. I just had to look into Streamlit's doc to get a 360 view of which use cases are impacting the core logic, and rethink everything from a clean slate.
Learn from others' experience, as they say.

Phase 2
The meat of Streamlit is its components. For anything you might need in a webapp, Streamlit has a ready-to-use answer in its library of 110+ components. 
A simple way to know which components should be prioritized is to estimate usage statistics from public GitHub projects.

Using GitHub API, we can count the number of times st.title is used with the following query:

// look at code
url = "https://api.github.com/search/code?q="
// look for st.title( in Python projects that uses streamlit  
query = '"st.title(" language:Python "import streamlit"'

Repeat this for every component and you get a ranking: 
 

                                                                              the list goes on... 

Of course there are many hypothesis that may not hold true here:
- I did not exclude Streamlit (the company) repos.  Streamlit repos may not be faithful to "real" usage, biasing the statistics
- the Java and Python communities may have different use cases for Javelit/Streamlit
- Timeliness: old components will have more use than newer ones... just because they are older.

A good example of the last point was for chat_inputs and chat_message components. These components make it simple to build LLM chats interface. While the usage statistics for these components was pretty low, I quickly got the feedback this week - from real humans! - that they were much desired. Sounds obvious: chatbots are all the rage these days. Yet not obvious from GitHub stats!

While the late mover advantage was effective to get a head-start at design and high-level prioritization, it's now time for me to talk to people!  Find Javelit's roadmap here: https://github.com/javelit/javelit/discussions/39

Take care.
Cyril

Thanks for reading. No AI was used in any way to write this blog. I am not a native English speaker. I'd be happy to get your (human) feedback on the writing.