Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Add forms to your static site – no iFrames required (formspree.com)
233 points by colevscode on Feb 25, 2014 | hide | past | favorite | 99 comments



Is this what I think it is? A resurrection of those free hosted formmail scripts we used when I started writing web pages in the late 20th century?

Edit: http://www.formmail.com/ still seems to be going, in fact.


The whole static site craze is a rerun of the 90's.


Right? This is the one I switched to after getting fed up with FormMail. It was self-hosted and runs on PHP instead of CGI, whohoo! Pratically magic for 2001. http://regretless.com/scripts/scripts.php#dodosmail


I could be wrong, but it looks like it requires CGI


You either download the CGI script and host it yourself or you pay the formmail.com people to host it. In the olde days there were free ones where you specified the destination in the form, but spam put paid to that.


It's free, unless you exceed 1000 submissions/month:

> How much does it cost?

> Formspree is free for 1000 submissions per email each month. If you need more, please reach out.


This is even more 90es:

<form action="mailto:my@email.com" method=post enctype="text/plain"> ... </form>


That's how my very first website worked, which let users vote for Coke or Pepsi. I would get emails during the week and then update the count on the site manually. Horribly inefficient, but as a kid I thought it was pretty great.


I'm probably missing something obvious but I don't understand how this is different apart from costing money


When you submit a form with a "mailto:" action, the browser opens the mailto protocol handler, which is the user's email client. So you hit submit on the form and then see a draft email filled out with your form responses.


To expand on that:

If the user doesn't have an client-side email client setup (eg, they use Gmail/Hotmail via the browser) a box will pop up prompting them to setup an email account.

Even if they do have one setup up, most users will immediately dismiss the email, so you'll never get it.

This is different to serverside email, where the client submits a form to the server, and the server sends you an email.

Unlike the "mailto:" method, the second method will actually get you some responses.


Which was one solution to the then very frequently asked question "How do I get the email addresses of all my visitors?"


Another option is to host your static site on BitBalloon (https://www.bitballoon.com) - we make the forms on the site work without any backend programming.

This doesn't leave your email in the HTML and we also do spam filtering on the form submissions (get a bit of traffic and your contact form will get lot of spam).


Seems like an enourmously awesome solution, but, again, I ask: who are the users of these kind of services (BitBaloon, Formspree etc.)?

(or, better asked: what is the problem these solutions solve?)


People are looking to static sites more and more for a couple of reasons:

1. speed - you can't beat an optimized static sites hosted on a CDN. In part I suppose the increased focus on speed i driven by mobile traffic. 2. Github - front-end developers have now gotten really used to having everything under version control. Dumping the most important content into an unversioned database just doesn't feel as good as having everything as Markdown in Github 3. Jekyll - or rather build tools and static site generators in general. The combination of GitHub and Jekyll and flag ship projects such as the Obama Campaign platform [1] definitively played an essential role in the growth of static site generators we're seeing now.

Our clients range from beginners launching their very first HTML site, over agencies with really cool flows built around Middlemand/GitHub/Draft/Similar services, to companies that are integrating site publishing into their products in various forms.

One of the cool examples is a startup doing a site builder for progressive candidates running for national campaigns. They use our API to handle the publishing, and use our form feature for gathering volunteer submissions and contact mails.

In general I think publishing a website with a form on it, is one of the most basic features of the web. Making it faster, easier and better is a pretty obvious plus for a lot of people.

[1] http://kylerush.net/blog/meet-the-obama-campaigns-250-millio...


Thanks. I'm answered.


I use BitBalloon!

Basically, I build static sites for some small businesses in the area. They want to be able to choose where everything goes, to the pixel, so it's easiest to work with just html and css. Then I can upload to BitBalloon and everything works exactly as it did on my laptop. Forms work, everything gets optimized, and setting up my own domains is super simple. And it's cheap.

I could use S3 or something else, and it would be cheaper, but deploying in a half second really is useful. Everything is done right with no effort on my part other than building the site itself.

I also built a site just for fun and host it there. 750,000 page views in the last couple weeks, didn't worry for a second. http://gallerrit.com/ It has also been very easy to push updated versions with no down time.


That will do it for me.


We did something similar a year ago but it didn't get any traction. http://instant.jotform.com


Great idea. I'm not sure about the pricing though. I'd expect anyone who reaches 1000 submissions per month to probably make the effort to get their own form handler. I'd make it 100/month or maybe 1000 submissions total until you have to pay. Then make it an annual fee so that customers think "OK, I'll pay $X not to have to deal with this for another year."


I'd advise against making it a total submissions limit. I would not bother attempting to use a service that is guaranteed to blow up on me one day even if the site remains low traffic.


I've been using SimpleForm(http://getsimpleform.com/) for my static site forms, It's quite easy to set up and you can add some spam prevention with Akismet.

This project looks interesting because there no need to register unlike SimpleForm.


You can make a custom form submit to a Google Forms endpoint, and it will go straight into a Google spreadsheet.


It seems to me that would be so much more useful than a bunch of emails.

Or expose an API for a CSV download, or a data feed, or something.


Anything to stop someone sending 1000 submissions to someone else's form as a trolling Denial of Service (DoS) attack?


Or more importantly, to stop someone sending an email to N different emails just 1 time?

EDIT: Okay, I missed the part where the email must be registered with them. Assuming no one is interested in spamming with the confirmation email, which seems fair.


Rate limiting per IP would be pretty easy to implement.


Doesn't help much when there is a botnet spamming you with one mail per minute from 10000 ip-numbers.


Cool idea -- what kind of spam protection can it offer though?

I'm not worried about the email address being in the open, but my original contact page form was getting hundreds (thousands?) of spam submissions a day until I implemented some simple javascript 'traps' to filter out the bots.

I've still not worked out why a bot wants to fill in a contact form with spam anyway, seems like a real waste of time.


Best and simplest trick I've found for this is having a CSS hidden honeytrap field, something like <input name="message_body" type="text" class="hideme" />

Bots will put something in the field but humans should never see it, so if the server sees anything in there it can safely toss the whole thing.


Two pitfalls: 1) You should add some text to indicate to people using screen readers that this field should remain blank. 2) You should make sure to name the field something unlikely to be autofilled. There are browser toolbars out there that will happily autofill even hidden fields and trigger your spam filter.

But other than that, I agree that this is extremely effective against the common sort of drive-by spam bot. (And, obviously, completely useless against any sort of advanced or targeted attack.)


Good point. My javascript solution uses two hidden fields with very similar names. One that the script fills in and one that it doesn't.

Bots will either hit both or neither and get rejected. Screen readers/toolbars may be an issue, though the names would be hard to think what to autofill with. It has never come up in practice -- the reject message tells people to email us directly

If you have javascript turned off, you'll need to email directly too -- and the site won't work so there probably isn't much lost!


Excellent points, thank you.


Thanks! :)

As many have asked, at least for now there's no real spam protection. Asking you to confirm email for every email/referer pair prevents me from adding your email to zillion sites (although confirmations could also get annoying at that point :) and spamming, but of course that doesn't still prevent bots from filling out your form.

I think in a way it's a tradeoff between ease of use, both for you and the visitor. Alternatively we could do heavier registration process and/or let you configure some running on our server, but then setting things up wouldn't be as easy and you might as well just run your own backend. For the visitors forms provide an easy (than, say just email) way to reach out. I guess the question is, do you prefer false positives (spam) or false negatives (folks not reaching out) :)

Regarding having clear text emails in the source, I'd argue (based on nothing but anecdotes) it doesn't matter, much. As throwawaymsft said elsewhere, bots are pretty good at figuring out what "you (at) email (dot) com" means, so in most cases you'd anyway be getting much spam. We considered a token-based approach instead, but decided to go all-in for simplicity. Also, since we're using forms anyway, they're more likely source of spam than some bot crawling just for addresses.


great idea.

I think you can give the user the option to specify the email hash (MD5 maybe) instead of clear text email.

so either:

<form action="//api.formspree.com/user@example.com">

OR

<form action="//api.formspree.com/b58996c504c5638798eb6b511e6f49af">

You can provide the user a small tool to generate the email hash.

Good luck


Gravatar uses MD5(email) as an identifier, so using that would potentially identify the recipient quite easily.


The recipient can be identified by email or md5(email).


But it's good enough that an auto scraper or spam bot will find it easily.


But then how can they know where to send the email to?


They have the email (confirmed email) in their DB. they can easily calculate the hash on the fly.


I'd use base64 instead of a MD5 hash, but I'm not a huge fan of security by obscurity.


This might also work:

    <form action="//api.formspree.com/user.smith/gmail.com">
Truthfully, base64 is probably better at deterring email harvesters.


How I handle it. Effective so far... http://img42.com/881bp


Genuinely curious: have you measured that field's impact in non-spam form completion?


I haven't. I'm OK w/not getting messages from those that can't/won't follow direction.


Fair enough. Unfortunately that's not an option for everyone.


The example says ...action="//... shouldn't this be ...action="http:// ... ?

This is so seemingly simple but so useful, thanks a lot!

EDIT thanks for explaining, all! :)


It's a protocol-relative URL, which inherits the protocol of the parent page.

http://www.paulirish.com/2010/the-protocol-relative-url/


Ah, I had the opposite remark:

On http://www.formspree.com/ at section 1, they say to use "http://api.formspree.com/your@email.com" while it should be "//api.formspree.com/your@email.com".

I just set up a Jekyll site with links to youtube and disqus. Quite important or it won't work.


That's what confused me, too, the inconsistency between the two.


By removing the scheme from the url, the browser will use http/https based on the scheme of the containing page.


That's known as protocol relative URLs. That way if your static page is HTTPS the form action will be the right protocol.


Regarding the issue of having your email address in the open. This could easily be solved by requiring registration and generating an encrypted URL for each email address that a user associated with their account. I know this highers the barrier for entry, but putting an email address in the open is foolish and making it too easy for the dumbest of email harvesters.


This is what I was thinking as well. An account isn't even necessary, just have a two step process on Formspree.

1. Enter your e-mail address. Click next.

2. Copy the generated code, //api.formspree.com/Kn2JanlPkZ into your form as the action. Obviously this code and e-mail combination is then stored in the Formspree database.


These are for static websites. The idea of an "account" doesn't make sense.

Edit: Ah, you mean that formspree should allow site owners to create accounts. Carry on.


I'm thinking he means registering an account on the formspree site. So your form's `action` attribute doesn't require the inclusion of a plain e-mail address. Instead it gets some encrypted string, which is uniquely tied to your formspree account.


Exactly. And you could generate as many tokens as needed


He's referring to accounts for formspree, not the static sites.


Alternatively, formspree could publish a public key which you could use to encrypt your email address. To make it easy, they would just have a form on their website which does the encryption for you, giving you the opaque string to use in your form.

The UX for the user is the same if Formspree were to just generate a random token and store in their DB mapping it to an email, but this way Formspree doesn't need to store anything in their DB.


In the privacy FAQ you might want to link to Mailgun's privacy policy, or at least their website.


There's another one (getsimpleform.com) that handles uploads and spam prevention via Akismet. It does not expose your email.


There's a problem here. browsers do not send Referrer when on an https site. And they refuse to work without the header

For geeks: could not find "Referrer" header.


Point of interest, it's actually "Referer" - a misspelling that dates back to the original HTTP RFC 1945.

See http://en.wikipedia.org/wiki/HTTP_referer


Oops, good catch, thanks! Hadn't thought of this.

Apparently the problem is just sending a request https->http. https->https should work fine. Adding SSL asap.

EDIT: now you can also use https://api.formspree.com/your@email.com


The rules are more complex. I'd say just do away with the refer(r)er. http://webmasters.stackexchange.com/questions/47405/how-can-...

Maybe later when you have a real problem, fix it then. Let's cross bridges when we come to the river, that way we'll all have much simpler code!


I simply prefer to show my email address. People know what to do with an email address.


Originally, I did just that with my service. The problem is when you need simple information like "What browser and version are you using" when someone says something "isn't working". Capturing User Agent during form submission takes an otherwise painful step out: asking a non-technical person to find out what version of Internet Explorer they are running. There are still people who think "The Internet" is "the Blue E on my computer". Similarly adding required fields like "What's your site's address" when you run a multi-site service. All valuable things to have specified so that you can answer any questions with the first response rather than having to ask a pile of followup questions when customers don't provide enough info.

With a general purpose email, you don't get that.


If you give instructions along with the email, serious people are apt to play along.


I would assume this product really comes in handly when you really want to add some structure to the data that's being submitted.


Nicely done. This kind of stupid simple service makes the web an easier place to work.


Does this not invite spam by leaving email addresses in HTML source code?


Not any more than using an email like:

firstname@domain.com firstletterlastname@domain.com Firstname.lastname@gmail.com

Look, spam happens (unless you obfuscate your address to be unmemorable or unprofessional). Modern email filters are pretty good.


No more so than a company's email being in a Contact Us page.


So... yes.


In other words, this method is on parity with conventional contact methods and the spam harvesting point is moot.


I think that contention is flawed in that it assumes the two methods are, must be, and should be equal in terms of email address exposure.


eh... fair enough.


Undocumented feature: If you put _subject into the name property of an input, it will be used as the subject of the email.


I was recently looking for a nice simple implementation of this for a client. Didn't really find any that I liked so we decided to build this ourselves. Now we have the flexibility of either emailing them the results or storing in our local database for later processing. This looks really nice though.


YES YES YES.

That is all. Thank you.


Kind of easy to crawl and harvest verified emails on web sites that implement that API.


This kind of service will stay low on the radar compared to how many people write their email in plain text on web pages. It's quite unlikely that someone is going to crawl the web and harvest formspree "ACTION" fields when they can simply harvest regular email and get a million more.


This is cool, no JavaScript either.

Also, the contact form at the bottom of the page uses the API :)


Would be especially cool if it supported input type=file as well :)


I don't know who would want this. Is it really a demand from people? It is programmers who love static sites who use this? Or the non-coders everywhere?


Is there a way to denote certain fields as required (on the back-end -- not talking about "required" attribute or js on the front-end)?


Is it 1995 again? Where's my formmail.pl ?


http://www.scriptarchive.com/download.cgi?s=formmail&c=txt&f...


Is there a way to send the form submission to multiple emails using this service?


I guess you could use a new email address that automatically forwards what it receives to multiple emails.


I was looking for exactly this about two weeks ago. Awesome!


Anyone can send mail using "Referer" header?


I would love a self hosted version of this


Oh man, there are HUNDREDS of "scripts" that do this! Here's the PHP one I used to use back in 2004.

http://regretless.com/scripts/scripts.php#dodosmail

I'm surprised this is being touted as such a new idea, but I guess with static sites making a comeback, it was inevitable.


cool, thanks for the pointer.

this seems like a good introductory project to any web framework

when I really sit down to learn node, I think I'll try to make something like this starting out.


OMG blast form the past. Well done guys.


getsimpleform.com as others have mentioned can do all of this plus file uploads and spam prevention.


except it doesnt add a form to your site.


I love it!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: