Show HN: A marketplace for client-side apps(eager.io)
eager.io
Show HN: A marketplace for client-side apps
https://eager.io/developer/features?n
9 comments
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.
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.
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.
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.
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...).
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.
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.
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.
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.
What about "component" or "module"? Well, maybe not "module", but I'm just brainstorming.
Thank you for this clarification. This is very different than what I expected and is novel relative to that expectation.
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.
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.
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
[2]: http://github.hubspot.com/offline/docs/welcome
[3]: http://github.hubspot.com/shepherd/docs/welcome
[4]: http://github.hubspot.com
[5]: https://eager.io/about
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
[2]: http://github.hubspot.com/offline/docs/welcome
[3]: http://github.hubspot.com/shepherd/docs/welcome
[4]: http://github.hubspot.com
[5]: https://eager.io/about
Couple of questions and observations. Referencing an app store page: 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.
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.
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).
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 [2] https://eager.io/signup?developer [3] https://eager.io/developer
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).
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 [2] https://eager.io/signup?developer [3] https://eager.io/developer
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.
Edit: It's not your Bootstrap example, it was the original question. Sorry to confuse that.
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.
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.
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.
You know, if this takes off -- and I hope it does -- you may be in a good position to help solve some of the client-side JS security issues/concerns, particularly in combination with the upcoming webcrypto standard.
I'm thinking in particular about publishing a registry of library hashes and possibly signatures (specified in your json config), and then validating them before your users install.
In fact, if this becomes popular, I think you may have to do this, otherwise you could well become a hive of malware purveyors impersonating popular apps (or whatever you end up calling them -- btw, I don't think "widget" is a bad idea for what you're doing, or even coming up with a new term).
Looking forward to watching this.
I'm thinking in particular about publishing a registry of library hashes and possibly signatures (specified in your json config), and then validating them before your users install.
In fact, if this becomes popular, I think you may have to do this, otherwise you could well become a hive of malware purveyors impersonating popular apps (or whatever you end up calling them -- btw, I don't think "widget" is a bad idea for what you're doing, or even coming up with a new term).
Looking forward to watching this.
> "Introducing install.json"
The JS community is going to love having yet another *.json file in their projects.
The JS community is going to love having yet another *.json file in their projects.
We are considering allowing the information to be placed in an `install` field in the package.json. Is that something you would prefer?
YES! A thousand times yes. Please not yet another json file in the root directory. And I say this as someone who is really interested in what you're doing with this.
I think that would be a step in the right direction!
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
[2] https://github.com/HubSpot/offline/blob/master/bower.json
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
[2] https://github.com/HubSpot/offline/blob/master/bower.json
Isn't this what tag managers like Google Tag Manager do? How is this different?
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/ [2] https://disqus.com/ [3] https://github.com/EagerIO/DeveloperDocs/blob/master/docs/ad...
[1] http://instantclick.io/ [2] https://disqus.com/ [3] https://github.com/EagerIO/DeveloperDocs/blob/master/docs/ad...
[deleted]
[deleted](1)
[deleted]
[deleted]
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