Show HN: Brolly, a plain-text weather forecast site(brolly.sh)
brolly.sh
Show HN: Brolly, a plain-text weather forecast site
https://brolly.sh/forecast/RWFP2qW8
38 comments
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?
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
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.
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 :)
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
w3m -4 -dump https://brolly.sh/forecast/RWFP2qW8
This 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
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
finger weather:[email protected]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.
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
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."
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!
Open Meteo lets you query historical weather data from as old as 1940[1].
They have the only weather API I know of that can get both forecast and historical weather with just a single call[2]
I use Open Meteo for most of the data for https://weather-sense.leftium.com
(If you configure a single constant[3], you can get the max 90 days of historical data with the forecast!)
[1]: https://open-meteo.com/en/docs/historical-weather-api
[2]: https://open-meteo.com/en/docs
[3]: https://github.com/Leftium/weather-sense/blob/fefecb05974065...
They have the only weather API I know of that can get both forecast and historical weather with just a single call[2]
I use Open Meteo for most of the data for https://weather-sense.leftium.com
(If you configure a single constant[3], you can get the max 90 days of historical data with the forecast!)
[1]: https://open-meteo.com/en/docs/historical-weather-api
[2]: https://open-meteo.com/en/docs
[3]: https://github.com/Leftium/weather-sense/blob/fefecb05974065...
Very cool. I would consider changing Celsius to Fahrenheit for US based locations (or just make it as an additional option for settings).
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!
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
https://github.com/chubin/wttr.in
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.
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.
Do you know any other weather sites that show historical weather?
I thought my https://weather-sense.leftium.com was the only current app to do this.
I wrote about this over a decade ago: https://blog.leftium.com/2013/12/how-to-display-temperature-...
I thought my https://weather-sense.leftium.com was the only current app to do this.
I wrote about this over a decade ago: https://blog.leftium.com/2013/12/how-to-display-temperature-...
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.
I opened https://github.com/open-meteo/geocoding-api/issues/33 to keep track of that and will look into it in the next days (supporting it shouldn't be too hard)!
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.
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!
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'll try using this as my go to over the next week :) thank you for making this.
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.
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!
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?
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?
Cool, though for at a glance weather, personally I like images like the bbc one https://www.bbc.co.uk/weather/2633352
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
London UK is currently 'forecast/zRKY7wMc' you could label all population centres >100k like 'forecast/uk-london', 'forecast/cn-london', etc
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!
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
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)
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.
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.
I think you may be able just drop the precipitation chance. While the precipitation chance is interesting, I tend to not experience any actual rain even if the predicted chance is 90+ percent. Even if there is rain, usually the amount is not worth bringing an umbrella for.
My https://weather-sense.leftium.com also uses open-meteo for weather data. And I've been comparing how precipitation amount/chance forecasts compare to real life experience.
Look at how vastly different the precipitation chance and amount were for Seoul the past few days: https://weather-sense.leftium.com/?n=seoul According to the chance, it was raining non-stop 48+ hours. The precipitation bars give a much better idea when actual precipitation occurred.
My https://weather-sense.leftium.com also uses open-meteo for weather data. And I've been comparing how precipitation amount/chance forecasts compare to real life experience.
Look at how vastly different the precipitation chance and amount were for Seoul the past few days: https://weather-sense.leftium.com/?n=seoul According to the chance, it was raining non-stop 48+ hours. The precipitation bars give a much better idea when actual precipitation occurred.
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 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.
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?
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.
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.
[deleted]
Searching for and clicking on Sheringham gives a 400 error.
ICAO slugs for quick lookup would be awesome. e.g. brolly.sh/kjfk
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.
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!
As other users pointed out, it'd be great if this could be curl'd like with wttr.in
It's already saved to home screen. Love the simple text interface.
Is there real plain text without CSS? This is styled HTML, not plain text at all
I don't see a way to change from F to C...?
It gets my location totally wrong
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.
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!
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!
I think the most useful data to add is the 60-min precipitation forecast.
Unfortunately open-meteo doesn't offer this.
So https://weather-sense.leftium.com uses the 60-min forecast from OpenWeather. But you have to specifically request it because the free-tier quota is not as generous. (I think Apple's WeatherKit may also offer this data, but I was unable to get WeatherKit to work at all)
---
After that, the wind is important for people who like outdoor activities. For example, Kayak rentals are paused when it gets too windy. On the other hand, kite boarders like it when it's windier.
Unfortunately open-meteo doesn't offer this.
So https://weather-sense.leftium.com uses the 60-min forecast from OpenWeather. But you have to specifically request it because the free-tier quota is not as generous. (I think Apple's WeatherKit may also offer this data, but I was unable to get WeatherKit to work at all)
---
After that, the wind is important for people who like outdoor activities. For example, Kayak rentals are paused when it gets too windy. On the other hand, kite boarders like it when it's windier.
> A sailing based page could definitely work here!
Even within a niche category like sailing there's a wide range of user needs, for example reporting temperatures in C vs F, or pressure in hPa vs inHg.
Coming from another angle, would it be possible to URL-encode user preferences, so that everyone gets their own bespoke Brolly forecast? There can still be prefab pages for common situations, so that informal and power users are all delighted.
(edit: format)
Even within a niche category like sailing there's a wide range of user needs, for example reporting temperatures in C vs F, or pressure in hPa vs inHg.
Coming from another angle, would it be possible to URL-encode user preferences, so that everyone gets their own bespoke Brolly forecast? There can still be prefab pages for common situations, so that informal and power users are all delighted.
(edit: format)
+2 for humidity. great work. keep it simple.
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!
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.
This is really cool, and I love the name
Thank you so much for this. It's fantastic.
Can we have METARs for airport codes in this exact aesthetic?
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
I made https://brolly.sh, a minimalist, plain text weather forecasting site. You can use it to view weather from around the world, with: 7 day forecast; Previous day log (so you can confirm it definitely was cooler / hotter / wetter / drier yesterday!); Hourly rain, wind, temperature, conditions; Hourly UV, air quality and pollen, including pollen type specific forecasts within the EU / UK; Location search and last 5 locations; Location specific units.
I mostly made the site for myself, if anyone else also benefits from it that’s an added advantage.
You can check out the weather in York, UK at https://brolly.sh/forecast/RWFP2qW8, or search for a location at https://brolly.sh
The site is deliberately styled as a single long scrollable column, to work on mobile phones. You can view it on desktop too, there's just a lot of horizontal padding. I naturally took a lot of inspiration from plaintextsports.com. Despite not being a sports fan, I love its aesthetic. But, you'll hopefully see that this site isn't a rip off, and has its own deliberate look and feel.
Visualisations are really important to showing information at a glance. I spent a lot of time designing the different visualisations and making them work with only characters. My favourite is the hourly heat map used for pollen count.
It's also frustrating to have an interactive site, where you can't share a page with a friend and have them see what you're seeing. To solve this, all page state (i.e. location, selected day, expanded / collapsed sections), is stored in the URL. You can share or bookmark the specific view, and know that you'll always be able to come back to it.
The site uses PocketBase. It’s written in Go and plain HTML/JavaScript/CSS. All pages are backend rendered, with light JavaScript to handle re-loading content without page jumps when using interactive features like next / previous day navigation. Weather forecasts are fetched from open-meteo.com, which has a very generous free tier. However, I also built a custom LRU cache on top of PocketBase’s SQLite DB to cache forecasts for 5 minutes, and avoid putting unnecessary pressure on the open-meteo API.