
Show HN: FasterBadger – browser in the cloud (pages are rendered on the server) - wdrw
https://fasterbadger.com
======
tux
Very nice. Can you do better urls ? So we can link to sites directly; Exp:
[https://fasterbadger.com/google.com](https://fasterbadger.com/google.com) or
use search query in browsers like;
[https://fasterbadger.com/%s](https://fasterbadger.com/%s) Also some custom
!bang commands like DuckDuckGo uses will be nice;
[https://duckduckgo.com/bang.html](https://duckduckgo.com/bang.html)

~~~
wdrw
Thanks. Direct site linking is on the shortlist of features to add next.
Haven't thought about !bang commands, that's an interesting idea.

------
dkarp
This is an interesting idea. Is there an intended use case? The page says to
"speed up browsing on many websites by rendering them in the cloud", but as
far as I can tell this also means we have to wait for the entire page to
render before we are sent the png's. Along with the increased latency by going
through FasterBadger instead of through the CDN's.

Or is it for sites where most of the times is spend on the rendering client
side?

~~~
wdrw
It actually starts rendering even before the entire page is ready (and fixes
up the page later; well, in the current version it just re-renders the page
later). For some sites (news sites tend to be particularly bad here),
rendering on the client takes significant time, especially with older phones -
because of complex scripts, styles, many re-layouts/reflows, ads/trackers
(which bring their own scripts/styles), and so on. Additionally, there's the
issue of the number and size of network requests, which can be a problem over
slow 3G connections. Of course, I could be wrong in these assumptions, and it
could be the case that with improved networks, improved hardware and better-
optimized sites none of this will be an issue. So FasterBadger is an
experiment - will server-side rendering be enough of an improvement for people
to change browsing habits? What about people with slower phones and slower
networks, e.g. in developing countries? We're definitely finding sites today
that e.g. don't display any content for a whole 30-60sec on an iPhone4 and
display in mere seconds via FasterBadger, but of course not every site will be
sped up.

------
vmorgulis
It's well done.

There is another option inside the browser by using WebKit.js
([https://trevorlinton.github.io/](https://trevorlinton.github.io/)) for the
rendering and send the page encrypted to the browser with XHR (or with another
method).

~~~
wdrw
Thanks! WebKit.js could be interesting down the line, thanks for pointing it
out, though I wonder about performance and standards compliance. There's also
the stability issue - the page says it's "experimental/unstable/not yet
alpha". FasterBadger is based on the much more stable PhantomJS, and still
plenty of gnarly bugs are coming out.

------
ocdtrekkie
This seems like it'd be particularly helpful for dealing with the incredibly
excessive CSS layers in Google websites like Google+ (which locks up my
browser for five seconds when it loads). But I'd be pretty iffy giving my
login details through a proxy like this.

~~~
wdrw
We don't store anything you type into forms, and don't store any cookies any
longer than the browsing session is alive (currently expires after 5min of
inactivity). But you're right of course, as a user you have no way of
verifying this. The main scenario I was envisioning here is things like news
sites, which often go overboard with complex scripts, CSS,
images/videos/flash, ads, etc, to the point where a simple news article is
difficult or impossible to read - especially on an older device or on a slow
3G connection.

~~~
ocdtrekkie
I see the actual speed benefits immediately, I tested it with a public G+ post
URL, and it loaded much faster than my laptop can load a G+ page normally, and
without causing my browser to freeze up.

Out of curiosity, what's the monetization or business plan with this?

~~~
wdrw
Thanks! Monetization is not fully thought out yet but I'm envisioning a
freemium model down the line. Basically, either start charging after a certain
usage threshold (e.g. an hour of free browsing per day), or charge for extra
features like server-side ad-block, ability to pick the country in which the
server's IP is located, HTTPS access (even though HTTPS is currently free),
etc.

~~~
ocdtrekkie
The biggest concern, particularly down the road, is assuring people you're
above board on security. When I mentioned it on G+, the first suggestion was
that you guys could inject ads and such, which obviously would be a huge
problem.

But generally if there's a solid paid model, a company can be pretty free and
clear of those problems.

The other thing you would want to consider is Firefox and Chrome plugins where
you could set specific sites to open via your protocol. Maybe Engadget doesn't
work well on my computer for whatever reason, so I tell the extension to open
all Engadget URLs through your service, or something like that.

~~~
wdrw
Agree on the security aspect, and injecting ads would be horrible, I
definitely think there are better monetization models here. Plugins are an
interesting idea, will give it some thought. Though for now, I'm thinking in a
different direction... I think FasterBadger is mainly applicable to mobile
(since complex pages would be much more overwhelming to phones than desktop
machines), and plugins are less of a thing there. However, a native app that
speaks the FasterBadger protocol (essentially an alternative browser app)
could be interesting.

------
cdvonstinkpot
My first thought upon seeing this is regarding a way to build this into a web
proxy, & let a local server do the work while clients only have to be
configured to use the proxy. Dunno if its feasible, not knowing how it works,
but it seems promising.

~~~
wdrw
Interesting idea. Unfortunately FasterBadger is far from being a universal
browser now, there are still many sites that it won't support or won't support
well (anything that relies on more than just basic click and keyboard input
events), so the degree of integration you're talking about probably isn't
appropriate yet... but perhaps will be in the future.

------
drnetae
Interesting concept Bookmarked. Luck!

~~~
wdrw
Thanks!

