
Show HN: A marketplace for client-side apps - adamschwartz
https://eager.io/developer/features?n
======
malandrew
I hate to do this because I don't like when the first or at least most upvoted
comment is dismissive, but I really must ask:

Why?

What purpose does a marketplace serve for web apps? There is not reason for an
app maker to give up revenue to a third-party gatekeeper like Apple or Google
and discoverability is best done via what's worked for the almighty hyperlink?

Furthermore, why not use the same exact install metadata file format that
Mozilla is already using? [https://developer.mozilla.org/en-
US/Apps/Build/Manifest](https://developer.mozilla.org/en-
US/Apps/Build/Manifest)

~~~
zackbloom
This is a really good question. I (one of the cofounders) have a few thoughts.
Just to clarify, when we talk about apps, we mean single purpose client-side
javascript and css which add functionality to an existing site, not web apps.

Installing client-side code is pretty difficult right now for non-technical
people. You have to know how a script tag works, where to put it, how to host
files, etc. There is great software on Github, but 99% of website owners just
don't know how to find it. Even the best-in-class platforms like Wordpress
lock you into a specific platform.

Most javascript library builders have zero revenue right now. I think that
giving them a way to charge for what they do is great, if that's what they
wish. Every app is free if that's what its creator chooses.

SaaS businesses which rely on client-side embeds have an uphill battle. It's
difficult to get people to install something on their site (for the technical
reasons above). We hope that by making it easier we can create an ecosystem
where quality apps get found quickly, and generate users and revenue just as
fast. We hope that in that world, the cost of customer acquisition will be so
much lower that there is room for us to take a cut.

We didn't use the Mozilla format as that's intended for full web apps that run
on a platform like FirefoxOS, not libraries which get included in other pages.

~~~
sanderjd
Hey! Thanks for the explanation. That's pretty neat. Like your parent
commenter, I wasn't interpreting this in the way you described it. The term
"app" is already quite overloaded, and I would call what you're describing a
"widget" instead, but I suspect you may be hoping for a quick marketing win
from the corollary to mobile app stores.

I'm really curious about your vision of who the potential customers are. It
seems like it is targeted at a segment of the wordpress audience that is not
using wordpress. Is there such a segment already, or is the goal for this
project to create one?

In any case, it seems like a very good and novel (to me) idea! Kudos.

~~~
zackbloom
Hi and thanks! It's a really good point. We use apps because it's the most
logical word in our minds for 'self contained bit of code which does
something'. Widget is a good suggestion (although I have to admit it makes me
think of [http://www.idealaunch.com/blog/wp-
content/uploads/2010/02/ya...](http://www.idealaunch.com/blog/wp-
content/uploads/2010/02/yahoo-widget-engine.jpg)).

The prospective customer is anyone who has a website but isn't technical
enough to be considered a web developer. This definitely includes the 60+
million sites on WordPress. Many of the great open source client-side
libraries and tools out there aren't available as WordPress plugins. We
certainly think Eager is something you can use along with (or instead of) the
WordPress plugin marketplace, along with SquareSpace or even static sites on
GitHub.

The hope is that we can convince these people that they will have a better
experience coming to Eager when they need a lead generation tool or a comment
widget than the wordpress marketplace itself.

~~~
nmjohn
Honestly I think you should coin your own term...

I, like both other commenters had the same questioning nature when I heard the
word app. But when I read your original explanation to the parent post, I
realized that this actually is a pretty darn good idea.

Widget on the other hand just reminds me of windows vista and the awful of
widgets of a few years ago.

This is where a new term, one that doesn't already have strong connotations,
is very valuable in my mind. Because what you're doing doesn't really fit with
any term out there. It also could do wonders from a marketing perspective. If
I hear, oh, there is this new app store providing client side apps, I'm not
intrigued. But If I hear hey there is this new store providing client side
NEW_WORD, I'm immediately intrigued. I'm going to want to learn asap what this
new technology that I've not heard of is.

------
smt88
Your landing page needs examples. I'm about 20% sure I understand exactly what
the purpose of this is.

Also, something like this should be marketed as, "You know that thing you've
been doing the hard way? We're helping you do it the easy way."

I don't really understand what it is I've been doing the hard way. If we
haven't already been doing something that you're now making easier, you should
go back to the drawing board. It's hard to create new behavior.

~~~
afschwartz
Hey, I‘m Adam, and I designed this page. Thank you so much for this feedback.

When building this page, I definitely struggled with what to put where. The
Steps 1, 2, 3 are hopefully clear about what action to take, but I agree that
more motivation at the top would be great.

Here’s the thing we believe can be made easier:

When my co-founder and I built Pace [1], Offline [2], Shepherd [3], etc. [4],
one of the problems we came across was that while we could get stars on
GitHub, non-developers struggled to get the benefit from these projects.
Often, the step they struggled with was adding the `<script>` or `<link>` tags
to their page, and configuring any of the options these apps/widgets/plugins
had.

Our About page [5] explains something to this effect, but bringing some of
that motivation to this landing page seems like a good place to start. Thanks
again! I hope this was helpful.

Perhaps in addition to:

“Anything you can include in a <script> tag can be installed through our UI.”

We could add:

“Example: You wrote a JavaScript library which works by having the user paste
a `<script>` tag in their page. With Eager, instead you users can install your
library by simply clicking a button.”

[1]:
[http://github.hubspot.com/pace/docs/welcome](http://github.hubspot.com/pace/docs/welcome)

[2]:
[http://github.hubspot.com/offline/docs/welcome](http://github.hubspot.com/offline/docs/welcome)

[3]:
[http://github.hubspot.com/shepherd/docs/welcome](http://github.hubspot.com/shepherd/docs/welcome)

[4]: [http://github.hubspot.com](http://github.hubspot.com)

[5]: [https://eager.io/about](https://eager.io/about)

------
leepowers
Couple of questions and observations. Referencing an app store page:
[https://eager.io/app/uY5Di0FqBVvn](https://eager.io/app/uY5Di0FqBVvn)

1) Why install Bootstrap from Eager? As a developer I can pretty easily find,
download and use the Bootstrap from getbootstrap.com

2) Not that I don't trust you but .... how can I verify that the Bootstrap
source files haven't been tampered with in some way?

3) Related to #2 - Can anyone upload an app? How do you verify that an app
doesn't contain XSS or other vulnerabilities?

4) Do you always load the latest version of Boostrap? That could be a problem.
If I built a site using a 3.x version and automatic update to 4.x could be
disastrous for the layout of a site.

~~~
zackbloom
1) One simple reason is if you're one of the millions of website owners who is
not technical enough to install it manually. We hope to have the ability to go
one step further for example and select from a set of themes to make it even
easier to make a beautiful site.

Another reason which relates to #4 is to make it easier to update versions in
the future. We hope to build ways of testing those version changes to make
version updates something better than the dredded task they are now.

Beyond that, when we chose the apps for our launch, part of the decision was
based on showing variety and proving out the power of the system (“See, you
can do CSS libraries, too!”). The plan is for anything which can be on a site
to be in Eager.

2) Very good question. If you log in to the system, we show you the source
([http://oi60.tinypic.com/21kjn6c.jpg](http://oi60.tinypic.com/21kjn6c.jpg)).

In addition to the source, we’ll show you the version (if in say, the case of
jQuery), there’s more than one [1].

One of the great benefits of client-side code is that all the cards are on the
table. Anyone is able to inspect the content of what we deliver. We hope that
by choosing Eager, you gain safety, by having access to an ecosystem of
validated apps.

3) Yes! After creating an account [2], you'll be able to view the developer
dashboard [3] which includes a button to create an app. You can create an app
from any GitHub, Bitbucket, Launchpad, or Google Code project. Just provide
the URL and your tagged versions will be ready for import.

All apps come from specific tagged releases of public projects, meaning you
can't just paste some malicious code into our UI.

Right now we manually verify apps through a moderation process. We are
experimenting with techniques that will hopefully allow app developers to
specify what permissions they require (similar to Chrome Apps), and for us to
validate those permissions in an automated way.

4) No, when you install the app you can choose which version you'd like to
install (or we choose the latest version for you if that's the only one the
app creator has made available). You are locked to that version until you
decide to change it. We never change your bundle (the files delivered to your
site) without your specific intervention.

[1]
[https://eager.io/app/vP1PnpNHAG3j/install](https://eager.io/app/vP1PnpNHAG3j/install)
[2] [https://eager.io/signup?developer](https://eager.io/signup?developer) [3]
[https://eager.io/developer](https://eager.io/developer)

~~~
halisaurus
Sorry, I don't understand your Bootstrap example. If I'm not technical to
"install" BS (script/CSS tags and uploading files to a host) then I'm probably
not technical enough to use Bootstrap's CSS/JS components by writing HTML or
little JS snippets. What real benefit is the one-click install if that's
(probably) the easiest part of using a JS/CSS library?

Edit: It's not your Bootstrap example, it was the original question. Sorry to
confuse that.

~~~
zackbloom
We can allow people to make themes for Bootstrap which depend on the original
Bootstrap app. Those themes can be used out-of-the-box by non-technical
people.

We can also help you to manage the version of Bootstrap you're using to make
it easier to keep your site up-to-date.

Including Bootstrap now though is more of an example of the breadth of what
can be included using Eager, rather than a specific suggestion. I agree that
it's not particularly practical to include it directly in it's current form,
but many of our other apps can be used directly with great success.

As much as I'd love to build something for developers by developers, the
purpose of Eager right now is to help developers get their code to non-
technical people. So the question might be not how to add Bootstrap to your
site, but how can you build an Eager app on top of Bootstrap to make it
accessible to others.

~~~
halisaurus
Thanks for the response. (And responding throughout this thread, too.) I see
the point in using this for dependencies, and there are other apps like Google
Analytics that have minimal configuration to use.

------
rubiquity
> _" Introducing install.json"_

The JS community is going to love having yet another *.json file in their
projects.

~~~
zackbloom
We are considering allowing the information to be placed in an `install` field
in the package.json. Is that something you would prefer?

~~~
rubiquity
I think that would be a step in the right direction!

~~~
afschwartz
While I fully support the ability of using an `install` property in a
`package.json` as an alternative, as a frequent author of package.json,
bower.json, component.json, and install.json files, I feel confident saying
that install.json is a slightly different situation. Take
github.com/HubSpot/Offline for example:

The package.json [1] and bower.json [2] share a lot of the same information:
`name`, `version`, `authors`, and `description` are duplicated properties in
both. Furthermore, updating the `version` property in a file in Git isn’t
always necessary when you can create tagged releases with version numbers.

`install.json` doesn’t have the “Ugh, now I have to add the same information
in a new place”-problem because it introduces two new root properties, namely
`resources` and `options`, which do different (and very useful) things from
the properties in these other json files. These properties define respectively
the resources to include in a page when “installing” the app, and the JSON
options to provide the app upon its initialization. They allow for a common
way that JS and CSS resources be included in pages, which is a useful thing
for the community to start to standardize around, even if this isn’t the
perfect thing yet.

[1]
[https://github.com/HubSpot/offline/blob/master/package.json](https://github.com/HubSpot/offline/blob/master/package.json)

[2]
[https://github.com/HubSpot/offline/blob/master/bower.json](https://github.com/HubSpot/offline/blob/master/bower.json)

------
olegp
Isn't this what tag managers like Google Tag Manager do? How is this
different?

~~~
zackbloom
This is exactly like Google Tag Manager, except expanded to encompass all
client side code you would wish to install. You can install Google Analytics
with Eager, but you can also install InstantClick [1], Disqus [2], or any code
someone can write an install.json [3] for.

[1] [http://instantclick.io/](http://instantclick.io/) [2]
[https://disqus.com/](https://disqus.com/) [3]
[https://github.com/EagerIO/DeveloperDocs/blob/master/docs/ad...](https://github.com/EagerIO/DeveloperDocs/blob/master/docs/adding-
your-app.md#install-json)

