I also greatly appreciate getting to see the past few days' history for my location - too many weather sites are only really forward-looking, and I sometimes want to compare to a prior day when the current day feels different somehow.
Thoughts about serving pure text (not HTML) so that someone can pull this using a curl command, awk the output and do various things with it? Wish more sites did that.
Perhaps similar to a command line utility? Arguments could be passed as URL or query parameters. And perhaps a /help route can return the supported arguments.
I love plain text services. One of their benefits is near instant load time. A nitpick, but this takes a few seconds to load on a fast broadband connection for me. I get the delay even refreshing the same page, where I'd expect the cache to be hit.
Sorry about this, and thank you for the heads up. The site runs as a PocketBase instance on a small 512mb DigitalOcean droplet in their London DC, and is getting more load than usual at the moment.
I’ll take a look though at whether there’s anything causing fundamental slowness in the cache read / page rendering pipeline.
Love it. This reminds me of wttr.in, but with the benefit of interactivity and that it works much better on mobile. I also happen to often use terminals in a narrower aspect, so wttr.in doesn't work perfectly for me. It'd be very cool if a curl call to your site rendered a terminal text view!
Great suggestion, thank you. I’ll definitely keep that in mind as an improvement. There’s been some other feedback that it’d be good if there was a ‘true’ plain text only mode, and this ties in well.
My only comment is that the time of the report under the date was a little confusing, for a moment I thought that was the current time. Maybe you could add `as at` so it differentiates the time of the observation window versus the current time?
I'll try using this as my go to over the next week :) thank you for making this.
I was thoroughly confused at why the website was showing the weather for York. Since I studied there (and it's straight up a lovely place), I visit quite often and subsequently check the weather. I thought I had set it but couldn't remember doing so. As someone else said, this being text-based makes it particularly digestible to LLMs. Out of curiosity, I looked up weather MCPs and stumbled upon this: https://github.com/weather-mcp/weather-mcp
Is there a reason why the URL parameters are obfuscated? I think it would more user (and SEO) friendly to have at least the place names in the URL, e.g. brolly.sh/forecast/united-kingdom/yorkshire/york.
Still, great project! Definitely fulfils my desire for minimalism in all things.
It’s a good question. Initially, the URL was lat/long values, and then I did try place names. I ended up with the short code approach to minimise API calls to downstream services.
The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code.
The short code enables a forecast lookup to be a SQLite DB read, followed by a single API call for the forecast.
A more descriptive URL would have required two sequential calls - one to figure out the lat/long and/or place name, and another for the forecast. This wasn’t a huge speed problem, but I struggled to find geocoding APIs with generous free tiers or reasonable low volume pricing. It would have also made the forecast at a given URL somewhat non-deterministic, as the geocoding API could change its output or preferred result over time.
Short codes quite possibly wasn’t the right solution. It’s definitely something I’ll think more about. Thank you!
How about adding the location information as a suffix to the short code, e.g. `/forecast/<shortcode>/united-kingdom/yorkshire/york`? The latter part of the URL is of not use to the site, but is useful for the user.
I don’t get that reason, couldn’t you just use the location name as a field in the database just like you use the short code right now? Where’s the additional API call on lookup coming from?
Situation a:
Someone searches for location XYZ.
The geocoding API returns lat and Lon and canonical name ABC.
You save that and the slugified name abc in your DB.
(If the API doesn’t return a name, you can use XYZ instead of ABC).
You return slug abc to the user.
Situation b:
Someone requests weather for location at slug abc. You look in your DB, ask the weather API for the weather at lat/lon and return that to the user.
Situation c:
Someone searches for a place that happens to already exist in the DB.
You geocode the search term and get a lat/lon pair that’s already in the DB so you return the saved slug.
How is that different than using a shortcode? In which situation are you doing a geocoding API request you don’t need to do with the current system?
Very interesting. The past few days' trend is so common in small talk and general weather discourse ("it was warmer last week") but underrated in weather apps. It's helpful that Open-Meteo provides that data
This output is incidentally perfectly context engineered for LLMs too; I pasted the Delhi page contents into Arena .ai and asked "what's the gist" and qwen3.6-plus said (among other things) " A hot, humid day with a slight chance of afternoon showers." and gemini-3.1-pro-preview said "Mostly clear, but hot and very humid. While the actual high is 34°C, it will feel like 42°C in the afternoon."
That’s frustrating, thank you for the feedback. I’ll take a look at improving the search and potentially switching out the API provider. I currently use open-meteo as I was already using it for the weather forecast (it has a great weather API), and it made sense at the time to keep with a single provider.
Similarly, "Orlando" returns a bunch of results but "Orlando FL" returns none.
It would also be nice if it suggested results before you finished typing. For example, if I've typed out "orl", then Orlando should be the top suggested result.
I tried searching for "Austin, Texas, United States", "Austin, Texas" and just "Texas" and didn't find very much - not sure if I'm missing how they're indexed, but I'd expect at least one of those to find it!
Very small suggestion: it’d be cool if you used a service to geoip the incoming ip address - there’s also https://developers.cloudflare.com/network/ip-geolocation/ that will inject the lat lng directly into the request header to your server
It’d just help set a good enough starting location.
I actually love that it doesn't do this, because the sites that do are a headache (and sometimes entirely unusable) if using a VPN.
And since you can bookmark it with your location setting, automatic IP location could only make the first visit marginally faster for non-VPN users, anyway
Would be nice if desktop rendered in columns. Would be nice if it were curl-able (like not serving raw html to curl). Would be nice if URL pattern was like wttr.in (NYC for example is https://brolly.sh/forecast/YcUDdBLc <---which means nothing to me, vs wttr.in/nyc <---which is plainly obvious)
FWIW, I vibe-coded https://meteo.karteum.ovh/ a few months ago for my own use-case (it interfaces with open-meteo.com. Click in the map to add points, and click in the point to get details)
Also, wanted to note I appreciate your stance on AI:
> I manually designed the site, defined its architecture, structure etc.
> I have however used AI to implement significant portions, whilst keeping the most interesting bits to work on myself.
> I have mixed feelings about AI. I wouldn't have had the time to build this site without it, and use it heavily in my day job to improve velocity. But, there are also points where I deliberately avoid using it, either to keep the joy of focusing on a problem, or to make sure I'm not accidentally AI 'doom scrolling' my way through life. Everything is a balance.
This is cool and I appreciate how compact it is. I'd love to have this as a regular load on my desktop. My only note would be that the precipitation graph feels unnecessarily bulky - wouldn't it work with the same type of horizontal graph seen for the ones below it? I know precipitation demands somewhat more precision and immediacy, but you could also do a variable graph - left half next hour, right half next 12 hours or something.
I agree, it’s definitely something to work on as it takes up a considerable amount of vertical space.
I found the precipitation chart challenging as you need to present both the forecasted precipitation, and the potential likelihood of the precipitation occurring. Something I’ve considered is using a horizontal graph with different shades of grey through black in each bar to represent the probability, but it would somewhat reduce accessibility.
Oh god I'm glad I'm not the only one who hates the new Met Office website/app, but their forecasts and radar maps are the best. Where do you get the data from?
It uses open-meteo.com. Their forecast API returns data from around 30 different models depending on location, and typically uses Met Office data in the UK. I don’t force to only Met Office though, as they don’t give data for everything shown (such as the pollen count per species).
Open-meteo has a very generous free tier, and reasonable pricing. It also lets you fetch weather from previous days, which I’ve included so you can see if it’s relatively hotter/colder etc. than yesterday.
Use-cases will vary widely. For example if I used Brolly for sailing, I'd want wind speed in kts and wind direction as well as dew point, and I'd want a recent timeseries of air pressure to give an idea of the synoptic-scale situation.
Of course these may be far outside your original use-cases. I think when people get a hold of Brolly, they're going to love it immediately, and there will be a flood of feature requests. If that happens, might be good to design the layers needed for diverse customization.
Thanks! I’ve also got a long list of additional data I’d like to see, such as sunrise / sunset times and astrological activity like upcoming meteor showers etc.
I’m starting to think about dedicated sub pages that cover these use cases, with a single section on the main page that links into it. A sailing based page could definitely work here!
Really love this website and its awesome, thanks for making this!
I really love Golang minimalist applications using sqlite. The whole architecture feels really elegant to me personally. I wish you luck for this project and if I may ask, is the project open source, I really love its UI :) ,it feels so cool!
Very cool, and bookmarked. And spot on for the HN crowd, I think. I went in a very different direction with lot’s of visuals. Might not be to everyone’s liking but check it out if you want https://tshirtweather.fyi
I love the graphs, it's a very neat approach!
I also greatly appreciate getting to see the past few days' history for my location - too many weather sites are only really forward-looking, and I sometimes want to compare to a prior day when the current day feels different somehow.
Thoughts about serving pure text (not HTML) so that someone can pull this using a curl command, awk the output and do various things with it? Wish more sites did that.
I’ve had a few pieces of feedback for plain text, and it’s definitely something I’ll look at adding.
OOI, would you expect the output to include a single days weather (like the site does now), multiple, or options for both?
Perhaps similar to a command line utility? Arguments could be passed as URL or query parameters. And perhaps a /help route can return the supported arguments.
I suggest something like traintimes.org.uk, which accepts parameters as URL segments:
https://traintimes.org.uk/vic/brighton/10:30/monday
I love plain text services. One of their benefits is near instant load time. A nitpick, but this takes a few seconds to load on a fast broadband connection for me. I get the delay even refreshing the same page, where I'd expect the cache to be hit.
Sorry about this, and thank you for the heads up. The site runs as a PocketBase instance on a small 512mb DigitalOcean droplet in their London DC, and is getting more load than usual at the moment.
I’ll take a look though at whether there’s anything causing fundamental slowness in the cache read / page rendering pipeline.
Looking at chrome dev tools, it looks like it might be the custom font causing the delay. I'm not sure exactly why though.
Interesting, I’d have naively assumed that’d be cached after first load by Chrome. Definitely one to investigate further.
Might as well drop custom fonts? This minimalist site would be fine with built in font families.
I recommend run Google Lighthouse for a single visitor view of perf and then use a load testing tool (locust, jmeter etc. to check load handling)
If you want to that is :)
Use the system font stack
Weird, on my iPhone it loaded instantly.
Love it. This reminds me of wttr.in, but with the benefit of interactivity and that it works much better on mobile. I also happen to often use terminals in a narrower aspect, so wttr.in doesn't work perfectly for me. It'd be very cool if a curl call to your site rendered a terminal text view!
Great suggestion, thank you. I’ll definitely keep that in mind as an improvement. There’s been some other feedback that it’d be good if there was a ‘true’ plain text only mode, and this ties in well.
It's sort of okay (but not amazing) with
Ideally, you would let someone set an Accept: content type of text/plain, or else have an endpoint like brolly.sh/forecast/RWFP2qW8.txtThis is US only via the finger protocol (using netcat):
printf 'weather:85334\r\n' | nc bbs.airandwave.net 79
More info:
printf 'weather\r\n' | nc bbs.airandwave.net 79
Disappointed you didn’t just say
Heads up, in a lot of locations the city is doubled up (displayed twice). Otherwise, I like it a lot and I have it saved to my weather bookmarks.
My only comment is that the time of the report under the date was a little confusing, for a moment I thought that was the current time. Maybe you could add `as at` so it differentiates the time of the observation window versus the current time?
I'll try using this as my go to over the next week :) thank you for making this.
I was thoroughly confused at why the website was showing the weather for York. Since I studied there (and it's straight up a lovely place), I visit quite often and subsequently check the weather. I thought I had set it but couldn't remember doing so. As someone else said, this being text-based makes it particularly digestible to LLMs. Out of curiosity, I looked up weather MCPs and stumbled upon this: https://github.com/weather-mcp/weather-mcp
From the About page, it’s the authors home
Cool, though for at a glance weather, personally I like images like the bbc one https://www.bbc.co.uk/weather/2633352
Is there a reason why the URL parameters are obfuscated? I think it would more user (and SEO) friendly to have at least the place names in the URL, e.g. brolly.sh/forecast/united-kingdom/yorkshire/york.
Still, great project! Definitely fulfils my desire for minimalism in all things.
It’s a good question. Initially, the URL was lat/long values, and then I did try place names. I ended up with the short code approach to minimise API calls to downstream services.
The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code.
The short code enables a forecast lookup to be a SQLite DB read, followed by a single API call for the forecast.
A more descriptive URL would have required two sequential calls - one to figure out the lat/long and/or place name, and another for the forecast. This wasn’t a huge speed problem, but I struggled to find geocoding APIs with generous free tiers or reasonable low volume pricing. It would have also made the forecast at a given URL somewhat non-deterministic, as the geocoding API could change its output or preferred result over time.
Short codes quite possibly wasn’t the right solution. It’s definitely something I’ll think more about. Thank you!
How about adding the location information as a suffix to the short code, e.g. `/forecast/<shortcode>/united-kingdom/yorkshire/york`? The latter part of the URL is of not use to the site, but is useful for the user.
I don’t get that reason, couldn’t you just use the location name as a field in the database just like you use the short code right now? Where’s the additional API call on lookup coming from?
Re-read their response. They answered both these questions.
I still don’t get it.
Situation a: Someone searches for location XYZ. The geocoding API returns lat and Lon and canonical name ABC. You save that and the slugified name abc in your DB. (If the API doesn’t return a name, you can use XYZ instead of ABC). You return slug abc to the user.
Situation b: Someone requests weather for location at slug abc. You look in your DB, ask the weather API for the weather at lat/lon and return that to the user.
Situation c: Someone searches for a place that happens to already exist in the DB. You geocode the search term and get a lat/lon pair that’s already in the DB so you return the saved slug.
How is that different than using a shortcode? In which situation are you doing a geocoding API request you don’t need to do with the current system?
Seems like a good use case for Unicode weather symbols.
Very interesting. The past few days' trend is so common in small talk and general weather discourse ("it was warmer last week") but underrated in weather apps. It's helpful that Open-Meteo provides that data
This output is incidentally perfectly context engineered for LLMs too; I pasted the Delhi page contents into Arena .ai and asked "what's the gist" and qwen3.6-plus said (among other things) " A hot, humid day with a slight chance of afternoon showers." and gemini-3.1-pro-preview said "Mostly clear, but hot and very humid. While the actual high is 34°C, it will feel like 42°C in the afternoon."
Yes, I'm very annoyed that I cannot look at historical data (even from the past couple of days) in weather websites!
One small tweak would be descriptive urls
London UK is currently 'forecast/zRKY7wMc' you could label all population centres >100k like 'forecast/uk-london', 'forecast/cn-london', etc
How do you turn on the text-only mode? I've tried Accept: text/plain but I always get HTML.
Don't think it's 'true' plain text. HTML/CSS rendering 'like' plain text.
Still beautiful though!
curling it (with the relevant link from browser because locations are encoded in the URL rather than plain like wettr.in) shows html
curl wttr.in
https://github.com/chubin/wttr.in
Looks great. One thing that initially tripped me up, I searched "Raleigh, NC" and got no place found. "Raleigh" worked.
That’s frustrating, thank you for the feedback. I’ll take a look at improving the search and potentially switching out the API provider. I currently use open-meteo as I was already using it for the weather forecast (it has a great weather API), and it made sense at the time to keep with a single provider.
Similarly, "Orlando" returns a bunch of results but "Orlando FL" returns none.
It would also be nice if it suggested results before you finished typing. For example, if I've typed out "orl", then Orlando should be the top suggested result.
I tried searching for "Austin, Texas, United States", "Austin, Texas" and just "Texas" and didn't find very much - not sure if I'm missing how they're indexed, but I'd expect at least one of those to find it!
Congrats!
Very small suggestion: it’d be cool if you used a service to geoip the incoming ip address - there’s also https://developers.cloudflare.com/network/ip-geolocation/ that will inject the lat lng directly into the request header to your server
It’d just help set a good enough starting location.
Cheers!
I actually love that it doesn't do this, because the sites that do are a headache (and sometimes entirely unusable) if using a VPN.
And since you can bookmark it with your location setting, automatic IP location could only make the first visit marginally faster for non-VPN users, anyway
Would be nice if desktop rendered in columns. Would be nice if it were curl-able (like not serving raw html to curl). Would be nice if URL pattern was like wttr.in (NYC for example is https://brolly.sh/forecast/YcUDdBLc <---which means nothing to me, vs wttr.in/nyc <---which is plainly obvious)
FWIW, I vibe-coded https://meteo.karteum.ovh/ a few months ago for my own use-case (it interfaces with open-meteo.com. Click in the map to add points, and click in the point to get details)
This is really pleasing to use, lovely work :)
Also, wanted to note I appreciate your stance on AI:
> I manually designed the site, defined its architecture, structure etc.
> I have however used AI to implement significant portions, whilst keeping the most interesting bits to work on myself.
> I have mixed feelings about AI. I wouldn't have had the time to build this site without it, and use it heavily in my day job to improve velocity. But, there are also points where I deliberately avoid using it, either to keep the joy of focusing on a problem, or to make sure I'm not accidentally AI 'doom scrolling' my way through life. Everything is a balance.
Thanks for taking a look!
This is cool and I appreciate how compact it is. I'd love to have this as a regular load on my desktop. My only note would be that the precipitation graph feels unnecessarily bulky - wouldn't it work with the same type of horizontal graph seen for the ones below it? I know precipitation demands somewhat more precision and immediacy, but you could also do a variable graph - left half next hour, right half next 12 hours or something.
Thanks for the feedback!
I agree, it’s definitely something to work on as it takes up a considerable amount of vertical space.
I found the precipitation chart challenging as you need to present both the forecasted precipitation, and the potential likelihood of the precipitation occurring. Something I’ve considered is using a horizontal graph with different shades of grey through black in each bar to represent the probability, but it would somewhat reduce accessibility.
This is actually a great format for LLM consumption too.
Structured, concise weather information without unnecessary UI noise is much easier for agents to parse and summarize.
A JSON endpoint or an MCP server on top of this would be an interesting extension.
but why? We have apis for this, why parse a site and feed it to a llm?
Searching for and clicking on Sheringham gives a 400 error.
ICAO slugs for quick lookup would be awesome. e.g. brolly.sh/kjfk
Oh god I'm glad I'm not the only one who hates the new Met Office website/app, but their forecasts and radar maps are the best. Where do you get the data from?
It uses open-meteo.com. Their forecast API returns data from around 30 different models depending on location, and typically uses Met Office data in the UK. I don’t force to only Met Office though, as they don’t give data for everything shown (such as the pollen count per species).
Open-meteo has a very generous free tier, and reasonable pricing. It also lets you fetch weather from previous days, which I’ve included so you can see if it’s relatively hotter/colder etc. than yesterday.
It gets my location totally wrong
It's already saved to home screen. Love the simple text interface.
As other users pointed out, it'd be great if this could be curl'd like with wttr.in
I don't see a way to change from F to C...?
This is really cool, and I love the name
would be great to show humidity %
I’ll definitely look at adding this in, along with potential the wet bulb temperature. Thanks for the feedback!
This is a terrific project, thank you!
Use-cases will vary widely. For example if I used Brolly for sailing, I'd want wind speed in kts and wind direction as well as dew point, and I'd want a recent timeseries of air pressure to give an idea of the synoptic-scale situation.
Of course these may be far outside your original use-cases. I think when people get a hold of Brolly, they're going to love it immediately, and there will be a flood of feature requests. If that happens, might be good to design the layers needed for diverse customization.
Thanks! I’ve also got a long list of additional data I’d like to see, such as sunrise / sunset times and astrological activity like upcoming meteor showers etc.
I’m starting to think about dedicated sub pages that cover these use cases, with a single section on the main page that links into it. A sailing based page could definitely work here!
+2 for humidity. great work. keep it simple.
Cool. There's unicode cloud characters. Would be nice to have a visual indication of rain/sun/cloudy etc
I love this idea. The brolly logo at the top of the page is also a unicode character, so this fits well.
Really love this website and its awesome, thanks for making this!
I really love Golang minimalist applications using sqlite. The whole architecture feels really elegant to me personally. I wish you luck for this project and if I may ask, is the project open source, I really love its UI :) ,it feels so cool!
DIG IT. This is how the web used to feel.
Thank you so much for this. It's fantastic.
Can we have METARs for airport codes in this exact aesthetic?
thank you for bringing another TUI into the world!
Very cool, and bookmarked. And spot on for the HN crowd, I think. I went in a very different direction with lot’s of visuals. Might not be to everyone’s liking but check it out if you want https://tshirtweather.fyi