It would be nice if there were an indication when there's 0 matches found. I was briefly confused as nothing on the page changed at all when I hit 'Search' after entering my criteria.
To me, the tag box has incorrect UX. I would personally expect that hitting the spacebar would end one tag and let me enter a second tag, especially since it is clear that you do not permit spaces in tags. I would also expect the "enter" key to conduct the search. Instead, spacebar adds a space that will get converted to a hyphen anyway, and enter ends one tag and lets me create a second one.
Good job overall; I like the idea. It will be an interesting challenge to capture meaning from these raw text posts. For example, I tried to search for jobs in Florida, but typing in "FL" gives a lot of false positives. That will be the
Well first of all I looked through the recent thread and saw 0 postings in FL.
Little bit of a sidetrack, but it's seriously depressing that 90% of the jobs posted are SF and NY. These companies are seriously limiting their applicant pools.
Outside of helping build a startup, you have literally every other job site at your disposal. Go on any of them.
Within the context of building a startup, Sam Altman suggests it is more than 10x easier in SF and SV - however I think it is more like 50x easier. You can talk to 50 people on "startup" terms in FL before you'll find one person who is as qualified and willing to work on a startup, who will actually do it, as you can find in SF.
For better or for worse, HN is a YC property, and it's mostly about startups. In that sense even NY ranks far behind SF.
In fact, you can go farther and say that inside SF, twenty people can build the better part of a billion dollars in value together from nothing. Outside SF, you will get accused of being a thief and trying to take advantage of the same developers. It's a complete non-starter.
I realize most people posting advertisements are somewhat farther along, but the point stands. SF is where they are funded and able to post startup jobs.
I think you are underestimating the SE. They have the talent but not the employers. I, like most educated young folks I knew from FL, had to move out of the state for non military tech jobs.
seems like a massive waste of resources... you're making 800 http requests to firebase. If you don't want to use a database at least setup some sort of cron that just updates a giant JSON file so the users don't have to DDOS firebase.
Can you add another filter rule where we can remove jobs from the results that aren't interesting to us?
For example, searching for "Remote" and I may stumble onto a post that has "sorry no remote" and I'd like to clear that from the results (so that in the end, I end up only with the jobs that I'd be most interested in applying to).
Per-job 'ignore' flag would be good, too. Could just save to a cookie. Also, per-job 'notes' field, eg. status = applied, sounds like it's run by a control freak, bad weather, etc.
I use HN's Firebase API. This means I need a separate HTTP (XHR) call for every job record. AngJobs has their own database/API. It was my intention to avoid that pattern because I wanted to practice promises in Angular.
I think you could cache the ajax calls and gain some loading performance. AngJobs is using [angular-cache](https://github.com/jmdobry/angular-cache) for example.
(1) is probably going to make it in at some point! Unfortunately, I need to make an HTTP request for every post (that's how the HN Firebase API works) and that gets pretty expensive on slow connections. :/
Yeah, I build http://hnhiring.me well before the API via scraping. I looked into moving over after it was released but found it completely impractical for this sort of thing.
Hopefully it'll be improved at some point, especially given how bad the HN markup is (fun fact: all comments are at the same level in the dom; the indentation is achieved via a blank gif with a width property).
Firebase dev here, the websocket API would be much faster (less HTTP overhead and connection negotiation) and has the potential for more concurrent requests.
The websocket API is the main selling point of Firebase, but I guess you were not actively looking to use Firebase in a product, rather, it was a necessity from HN API. Good luck! Don't hesitate to contact us.
Looking at the firebase api docs, I realized how unRESTful, their REST api is. No way to get a list of all stories. You can only get a list of ids and must then query the API with each id to get the content. If you plan on going this route, I def agree you store your results in your own backend db. If you want to stay stateless, look for a better HN job source, e.g., http://hnapp.com/?q=type%3Ajob+|+author%3Awhoishiring. Just one request and you can parse either the json or rss feed.
> Unfortunately, I need to make an HTTP request for every post (that's how the HN Firebase API works)
What's the total size of the jobs data? Would it be possible to grab all the JSON from the API, concatenate it and then self-host it as a single file? I imagine a $5 DO droplet with nginx would suffice for that.
It looks like firebase isn't even gzipping the JSON.
This is pretty neat stateless app, however the current implementation leads to performance issues on slower connections.
Have you thought about some optimizations you could make to filtering/searching to minimize the initial load time, while still keeping all the logic client-side?
