Domainzomg is really a brainstorming tool, so it just uses DNS lookups and a fairly permissive list of TLDs. Red definitely means "taken", but green doesn't necessarily mean "available", it just means "this domain doesn't seem to have a DNS entry". Check with a real registrar for availability, use domainzomg for brainstorming.
> but green doesn't necessarily mean "available", it just means "this domain doesn't seem to have a DNS entry"
You really have to make that clear. That's worlds different. Are you looking for an SOA record for the zone or are you just running gethostbyname on the domain itself (both very different as well)?
I own several domains that I'm not actively using, but they are in the DNS with an SOA record and no A/AAAA.
Another item of feedback: Can it be done without inserting every incremental search into my history? I played with it enough that my Chrome history was hosed and Back was fairly useless.
I don't really have to make that clear, because I'm the target market ;-)
No, but seriously: it's a tool I wrote for myself (and other people can use it if they like) - I've optimized for the only case I actually know well, which is What I Want. If you want Something Different, man, there's like 430 billion domain search tools out there, most of which are more focused on pleasing other people than mine.
That's not to say you should shut up or anything - your feedback is great, and I may even act upon it, but I don't want to give anyone the illusion that this is a product intended for mass consumption. It's like I made some brownies, and other people should feel free to take one if they want, and you're even free to say "You know what? These brownies would be better without the almonds," but I'm not necessarily gonna take the almonds out. I like almonds, and you don't have to eat them, and people make brownies without 'em all the time, and I think that's swell. Or maybe it's just that it would be better if I used "real" chocolate instead of Hershey's - but meh, it was there and cheap, so I used it.
(On that subject: it's using NodeJS's built-in `dns.resolveNS`, whatever that means. Didn't see anything referencing SOA, but maybe that's the thing to check? In practice I'm not really bothered with the rate of false +/- at the moment, it seems to work ok for my purposes. If it's a matter of changing one function call, I'd do it, but I'm not going to hack my own DNS wrapper just to get a specialized query. At least, not while I'm in the middle of exams.)
I can't perceive the difference between domainzomg.com and instantdomainsearch.com. The latter is using plain old ajax. Theoretically I'm not even sure if I should see a difference. A plain old ajax call will get sent on an existing sleeping HTTP 1.1 connection, and should take 1 packet each for the request and response. WebSocket can't get any better than that.
tl;dr: Request/Response model on the web is already fast enough for small data. Use WebSocket where it matters, like a firehose of updates in either direction.
I'm tempted to actually do a quick test, but I think it probably comes down to something like whether you're closer to the duostack servers or the instantdomainsearch servers.
The reason this is with WebSockets isn't because I needed the speed of them - it's because I wanted to play with [socket.io](http://socket.io/), which provides a really nice abstraction for bidirectional communication, and I wanted to play with Nodejs. It seemed like The Thing To Play With.
The original domainzomg actually loaded hidden images and used onLoad and onSuccess handlers so in theory you didn't even need XMLHttpRequest support in your browser for it to work. So that's the opposite end of the spectrum. Then I figured I'd try rewriting it for ease of maintainability. It's really just a tool I use myself, and a couple friends started using. I'm going to use whatever technology I feel like playing with at the time.
Also, I'm not technically versed in how multiple requests on an HTTP 1.1 connection would work, it's possible that it may even be slightly faster if you just have one XHR request rather than 3 WebSocket requests. WebSockets should be used when you need to push data to the client that isn't part of a direct request-response loop - if you have the request-response loop, XHR is just fine.
tl;dr: 100% right that WebSocket doesn't always get you performance improvements (it might even be slower for some use cases), but socket.io is a super nice abstraction layer that makes programming more fun.
Yes! I just launched this (quietly): http://domainjig.com to provide related suggestions and check availability, both instantly. I'll be announcing it here (and elsewhere) soon.
In the mean time, any comments/suggestions are appreciated.
I like the simplicity of the center part, but the polka dots on the edge are killing me. But if you like them, don't change it just because I don't like 'em, design by committee never goes well.
Thanks for this comment. The reason it doesnt work is that the input box is built from scratch, so devices that use on-screen keyboards (usually mobile devices) don't know to automatically display the keyboard. On android devices, long-pressing the menu button will reveal the on-screen keyboard. I don't know how to force iOS devices to show the keyboard...
Yeah, I wrote this as my own tool for similar reasons (actually I just wanted to use it locally, http://domainzomg.com/ is for when I'm not on my own computer and for friends who want to use it).
But it's soooo much faster if you run it locally, it's not even a comparison. Maybe I'll open-source this so other people can just run it locally and not worry that I'm stealing their BRILLIANT DOMAIN NAME IDEAS. ;-)
Small usability suggestion: set the anchor portion of the URL after results return or a predefined timeout. It took me way too many clicks of the back button to get back to the front page.
Yeah, in practice I always run this in its own tab, so it's not a thing that has ever bothered me. I put that in because it did bother me that I couldn't Cmd-(L+C) to get a paste-able URL to show other people. In the long run, I might change it to have a time-out, maybe use `history.pushState` where available to make cleaner-looking URLs? It's not high on the priority list, though. Ultimately it's just about making a tool that does exactly what I want it to do - if it works for other people, they're welcome to use it, if not, there are only 500 million other sites that do almost the same thing, but with a slightly different take on it.
19 comments
[ 3.0 ms ] story [ 50.7 ms ] thread"red/black trees" -> "redtrees.com", "blacktrees.com", "red-trees.com", "red-tre.es", ...
Also, http://domainzomg.com/somedomainname should work if you just want to fire off a quick query.
Caveat:
Domainzomg is really a brainstorming tool, so it just uses DNS lookups and a fairly permissive list of TLDs. Red definitely means "taken", but green doesn't necessarily mean "available", it just means "this domain doesn't seem to have a DNS entry". Check with a real registrar for availability, use domainzomg for brainstorming.
You really have to make that clear. That's worlds different. Are you looking for an SOA record for the zone or are you just running gethostbyname on the domain itself (both very different as well)?
I own several domains that I'm not actively using, but they are in the DNS with an SOA record and no A/AAAA.
Another item of feedback: Can it be done without inserting every incremental search into my history? I played with it enough that my Chrome history was hosed and Back was fairly useless.
No, but seriously: it's a tool I wrote for myself (and other people can use it if they like) - I've optimized for the only case I actually know well, which is What I Want. If you want Something Different, man, there's like 430 billion domain search tools out there, most of which are more focused on pleasing other people than mine.
That's not to say you should shut up or anything - your feedback is great, and I may even act upon it, but I don't want to give anyone the illusion that this is a product intended for mass consumption. It's like I made some brownies, and other people should feel free to take one if they want, and you're even free to say "You know what? These brownies would be better without the almonds," but I'm not necessarily gonna take the almonds out. I like almonds, and you don't have to eat them, and people make brownies without 'em all the time, and I think that's swell. Or maybe it's just that it would be better if I used "real" chocolate instead of Hershey's - but meh, it was there and cheap, so I used it.
(On that subject: it's using NodeJS's built-in `dns.resolveNS`, whatever that means. Didn't see anything referencing SOA, but maybe that's the thing to check? In practice I'm not really bothered with the rate of false +/- at the moment, it seems to work ok for my purposes. If it's a matter of changing one function call, I'd do it, but I'm not going to hack my own DNS wrapper just to get a specialized query. At least, not while I'm in the middle of exams.)
tl;dr: Request/Response model on the web is already fast enough for small data. Use WebSocket where it matters, like a firehose of updates in either direction.
The reason this is with WebSockets isn't because I needed the speed of them - it's because I wanted to play with [socket.io](http://socket.io/), which provides a really nice abstraction for bidirectional communication, and I wanted to play with Nodejs. It seemed like The Thing To Play With.
The original domainzomg actually loaded hidden images and used onLoad and onSuccess handlers so in theory you didn't even need XMLHttpRequest support in your browser for it to work. So that's the opposite end of the spectrum. Then I figured I'd try rewriting it for ease of maintainability. It's really just a tool I use myself, and a couple friends started using. I'm going to use whatever technology I feel like playing with at the time.
Also, I'm not technically versed in how multiple requests on an HTTP 1.1 connection would work, it's possible that it may even be slightly faster if you just have one XHR request rather than 3 WebSocket requests. WebSockets should be used when you need to push data to the client that isn't part of a direct request-response loop - if you have the request-response loop, XHR is just fine.
tl;dr: 100% right that WebSocket doesn't always get you performance improvements (it might even be slower for some use cases), but socket.io is a super nice abstraction layer that makes programming more fun.
I like the simplicity of the center part, but the polka dots on the edge are killing me. But if you like them, don't change it just because I don't like 'em, design by committee never goes well.
I only use my own tool on my own server and I check the registries directly to avoid ISP snooping for nx-domain queries.
But it's soooo much faster if you run it locally, it's not even a comparison. Maybe I'll open-source this so other people can just run it locally and not worry that I'm stealing their BRILLIANT DOMAIN NAME IDEAS. ;-)