41–50 of 80 posts
Like the Idea of fulltext search on history, but I'm not going to send my full history to some random dude on the internet. No offence intended:)
[1] ”Simple full-text search in your browser” http://lunrjs.com/
Why server side indexing and not use something like lunarjs[1] from the beginning? Like the Idea of fulltext search on history, but I'm not going to send my full history to some random dude on the internet. No offence intended:) [1] ”Simple full-text search in your browser” http://lunrjs.com/
Do you just record n-grams indexed against the page url, are you then uploading that index? If you're not uploading it how is there no "local version" available? It's an interesting idea. Personally I have a script that wgets all the pages I bookmark and I very rarely use that content. What use cases are you anticipating?
Thats a use case I have hit a few times. I even started backing up useful posts just in case they died.
http://gigablast.com/rants.html is an example. Its a really good insight into the creation of a search engine which really should be preserved.
One that did dissapear but has since come back is this post http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra... which I went looking for a few years ago but had dissapeared from all search indexes.
Why server side indexing and not use something like lunarjs[1] from the beginning? Like the Idea of fulltext search on history, but I'm not going to send my full history to some random dude on the internet. No offence intended:) [1] ”Simple full-text search in your browser” http://lunrjs.com/
I always thought it surprisingly how poorly the "Search History" feature works in Chrome. Could be super useful if it worked.
Earlier quoted context omitted.
That's a great point. At the moment it only records what's in the DOM (stripped of all HTML) after the first page load event. I'm working on how to include AJAX content but it's not nearly as straight forward.
Take a look at readability.js ( https://github.com/Kerrick/readability-js ) and extract/upload the main DOM content after all the JS trickery has completed.
Earlier quoted context omitted.
I always thought it surprisingly how poorly the "Search History" feature works in Chrome. Could be super useful if it worked.
The idea is simple enough. My concerns would be how many resources it would use after a while of use. It's basically duplicating your already existing history.
I love this idea. Chrome's history is insufficient; I swear, it often doesn't record sites I've visited. But.. I'm not ready to trust an unknown process sending my entire browsing history to unknown servers. Excited for a potential local version.
Agreed. I learned recently that you get better history search by going to Google and having it only show 'visited sites'.
Earlier quoted context omitted.
Out of curiosity, what are you doing with such a simple site (and I don't mean that in a bad way) that requires any conscious effort to fix? It seems like you really need to go out of your way to fuck up the back button and for a fix to be "work". But, recent nuanced trends in web design/navigation aren't my top skill, so I'm asking the question honestly.
The site is built with the meteor framework, so it's not just the simple implementation you might expect from the layout. I imagine the features of meteor are useful in the actual app itself, which is probably not a simple site.
The rest? Maybe meteor is the best choice, cannot really say.