Yes, #00. Of course we'd count from 0.
New here? Jeamlit 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 Jeamlit 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 Jeamlit with a selected few by email, then later on Reddit. I was glad to see the project was well received! Jeamlit 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: Jeamlit does not support all of Streamlit's components yet, but this will come with time. Jeamlit 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. Jeamlit's core logic is tiny and actually way simpler than Streamlit's. While Streamlit had to evolve an existing codebase that was first designed with way less information, I could just look into Streamlit's doc to identify what features were impacting the core logic, and design around it from scratch.
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 Jeamlit/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 Jeamlit's roadmap here: https://github.com/jeamlit/jeamlit/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.