5 ms·

Show HN: A marketplace for client-side apps

75 points by adamschwartz 12y ago

deleted 12y ago
[deleted]
- zackbloom 12y ago
  Edit: The now-deleted question was about reliability. Hi, I'm one of the cofounders. Without reliability (and security) there's not much point in running this business. Our files are served by the Fastly Global CDN which is used by Twitter, Github, Shopify, and Imgur. Files are built when you make changes, and shipped to a static file host (Amazon S3), meaning your files keep being served even if all of our infrastructure falls of the face of the earth. We also have procedures in place for doing DNS failover to another CDN provider, should Fastly have issues. We monitor test requests to our infrastructure continuously from hosts around the globe. Feel free to follow our status page for continuous updates: http://status.eager.io/ http://status.eager.io/, and contact us with any questions: help@eager.io.
  - smt88 12y ago
    Amazon has outages, too. I'm sure you've thought of that, but don't assume Amazon to be available 100% of the time.
    - zackbloom 12y ago
      Very true, I remember the three day outage of '08 well. Fortunately there are enough cloud providers these days that maintaining parity between providers is easier than it used to be.
  - legutierr 12y ago
    Can I ask you why you've chosen Fastly over other alternatives? I've been interested in trying them out, but haven't taken the plunge.
    - zackbloom 12y ago
      Sure. The simple reason is they're more configurable. We, for example, route traffic differently if you are an Eager user testing your site than if you are visiting a site with Eager installed. Using Fastly has allowed us to not touch requests which don't need special handling at all, making our file delivery faster and preventing us from having to roll out our own edge servers.
malandrew 12y ago
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 12y ago
  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.
  - malandrew 12y ago
    Thank you for this clarification. This is very different than what I expected and is novel relative to that expectation.
  - sanderjd 12y ago
olegp 12y ago
Isn't this what tag managers like Google Tag Manager do? How is this different?
- zackbloom 12y ago
  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/adding-your-app.md#install-json https://github.com/EagerIO/DeveloperDocs/blob/master/docs/ad...
smt88 12y ago
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 12y ago
  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
rubiquity 12y ago
> "Introducing install.json" The JS community is going to love having yet another *.json file in their projects.
- zackbloom 12y ago
  We are considering allowing the information to be placed in an `install` field in the package.json. Is that something you would prefer?
  - rubiquity 12y ago
    I think that would be a step in the right direction!
    - afschwartz 12y ago
      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
  - 12y ago
leepowers 12y ago
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 12y ago
  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
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]

75 points by adamschwartz 12y ago

deleted 12y ago

[deleted]

zackbloom 12y ago
Edit: The now-deleted question was about reliability. Hi, I'm one of the cofounders. Without reliability (and security) there's not much point in running this business. Our files are served by the Fastly Global CDN which is used by Twitter, Github, Shopify, and Imgur. Files are built when you make changes, and shipped to a static file host (Amazon S3), meaning your files keep being served even if all of our infrastructure falls of the face of the earth. We also have procedures in place for doing DNS failover to another CDN provider, should Fastly have issues. We monitor test requests to our infrastructure continuously from hosts around the globe. Feel free to follow our status page for continuous updates: http://status.eager.io/ http://status.eager.io/, and contact us with any questions: help@eager.io.
- smt88 12y ago
  Amazon has outages, too. I'm sure you've thought of that, but don't assume Amazon to be available 100% of the time.
  - zackbloom 12y ago
    Very true, I remember the three day outage of '08 well. Fortunately there are enough cloud providers these days that maintaining parity between providers is easier than it used to be.
- legutierr 12y ago
  Can I ask you why you've chosen Fastly over other alternatives? I've been interested in trying them out, but haven't taken the plunge.
  - zackbloom 12y ago
    Sure. The simple reason is they're more configurable. We, for example, route traffic differently if you are an Eager user testing your site than if you are visiting a site with Eager installed. Using Fastly has allowed us to not touch requests which don't need special handling at all, making our file delivery faster and preventing us from having to roll out our own edge servers.

malandrew 12y ago

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 12y ago
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.
- malandrew 12y ago
  Thank you for this clarification. This is very different than what I expected and is novel relative to that expectation.
- sanderjd 12y ago

olegp 12y ago

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

zackbloom 12y ago
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/adding-your-app.md#install-json https://github.com/EagerIO/DeveloperDocs/blob/master/docs/ad...

smt88 12y ago

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 12y ago
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

rubiquity 12y ago

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

zackbloom 12y ago
We are considering allowing the information to be placed in an `install` field in the package.json. Is that something you would prefer?
- rubiquity 12y ago
  I think that would be a step in the right direction!
  - afschwartz 12y ago
    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
- 12y ago

leepowers 12y ago

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 12y ago
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

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]