Comments URL: https://news.ycombinator.com/item?id=47354816

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47122400

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46947108

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46921584

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46121799

Points: 81

# Comments: 48

Comments URL: https://news.ycombinator.com/item?id=45835703

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=45651617

Points: 2

# Comments: 0

I run a bunch of small projects (at one point 15+ static sites built with Astro, Hugo, and Next.js in static mode). The one thing that consistently caused me pain wasn’t the frontend — it was handling form submissions.

Some sites had PHP mail hacks, others were wired to Google Sheets, a few went through Zapier. It was messy, error-prone, and easy to miss leads. I wanted one clean, reliable backend where I could point all my forms and centralize everything.

So I built JSONPost: * Drop-in form endpoints (works with HTML, React, Vue, or anything that makes HTTP requests) * Email notifications with templates * Webhooks (Slack, Discord, Zapier, custom URLs) * Spam protection (honeypot, domain validation) * Analytics dashboard + CSV export * RESTful API with JSON and form-data support

Free tier includes 500 submissions/month, enough for side projects and small sites.

I’d love feedback from the community — especially from those who manage multiple static websites. * Does this solve a real problem you’ve hit? * What would make it more useful in your stack? * Any obvious gaps I should fix?

I’m treating this like a long-term tool rather than a quick hack, so honest criticism is welcome. If you sign up, you’ll get an email from me directly (I’d love to learn how you use it).

Thanks HN

PS :- I am giving away free pro accounts for 6 months if you really plan to use it on your websites. Just signup and reply to my email mentioning HN.

Comments URL: https://news.ycombinator.com/item?id=45351947

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45115288

Points: 3

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=44523072

Points: 7

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=44087301

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43960470

Points: 47

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=43831135

Points: 7

# Comments: 0

Looking through the available website clone options, none of them seem able to do all the things I want, namely: 1. Clone all the routes and resources for the site, rewriting the routes to work with the local copy 2. Let the data requests come back filled, then copy it as a static dataset for that component or page’s request.

Any tool suggestions out there?

Comments URL: https://news.ycombinator.com/item?id=43700538

Points: 3

# Comments: 2

So, I decided to build my own. txtl tries to autodetect what mode you want based on the input, and in general is fast and gets out of your way as much as possible. For example, if you paste in a number then it will show base conversions, but if it looks like an epoch timestamp then it will display the corresponding date. And of course it's open source at https://github.com/viveksjain/txtl/

This was partly also a way for me to try using LLMs to build a frontend/new project. This could probably be a whole blog post, but I see why some people can say that LLMs can 10x their coding productivity (I certainly didn't find this true in my day job) - I was really impressed with what o1 can do, it probably got me 70% of the way there in one shot. And as someone not familiar with frontend development, iterating was way faster. But, it still requires plenty of feedback and requires handholding - I had to completely rewrite the diff rendering logic, no matter what I tried I couldn't get an LLM to get it right.

Would love feedback on the autodetection and overall usability!

[1] https://github.com/DevToys-app/DevToys/issues/1296

Comments URL: https://news.ycombinator.com/item?id=43175182

Points: 65

# Comments: 8

Comments URL: https://news.ycombinator.com/item?id=42894660

Points: 39

# Comments: 7

While this approach might be time-consuming, I enjoy the process of creating something on my own and improving it step by step.

Now that the blog is running smoothly, I just need to refine a few details. After that, I'll publish the code on GitHub.

Comments URL: https://news.ycombinator.com/item?id=42693502

Points: 3

# Comments: 5

I’m the co-creator of Orbiter, a dead simple tool for uploading and hosting static sites. We built Orbiter for ourselves and realized it would probably be useful for others.

Static site content is some of the simplest on the web, yet hosting this content has gotten increasingly complex over time. Many of you are engineers and don’t have much problem with CI/CD pipelines as a mechanism for deploying a website. This is true for me as well. But there are times when I want to just upload a simple website. I might not even want to put it under source control. And I know this is true for a lot of others who don’t have the same level of coding and deployment experience as I do.

Combine this with AI’s rise in popularity and how easy it is now for anyone in the world to create a website, and Orbiter seems like a nice solution to getting static websites online.

On the technical side, we did something interesting. We actually use blockchain and IPFS behind the scenes. Having worked with IPFS for a number of years now, it’s always struck me as a really good tool for public content, especially when that content needs to be versioned. Websites fit this model nicely.

We wanted to create a system by which websites were not necessarily locked into Orbiter’s platform. So, every site that is uploaded gets its own smart contract on the Base blockchain. The site itself is uploaded to IPFS, and the CID is mapped to the site’s smart contract. When someone makes a change to their site and uploads new content, the new CID is mapped to the contract.

This does two things:

1. It allows anyone in the world to build a version history of the site 2. It allows the site’s creator to easily migrate off Orbiter without even having to access the Orbiter web app if they want

Ultimately, people may not care about the blockchain and IPFS aspects of the technology, and that’s fine. We specifically built it so that you didn’t even see this tech.

Would love to get feedback on the product, the idea, and the technology!

Comments URL: https://news.ycombinator.com/item?id=42566051

Points: 9

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=42275801

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41995074

Points: 2

# Comments: 0