Request for doc.js.org about js.org HOT 6 CLOSED

Hi h2non,
pkgdoc.js.org would be easy as it is not restricted!

But even for the others I have to that your project is close to what I had in mind with this line. What concerns me a bit is the premature state of the project (e.g. only one member in the organisation), but I can see the need for a good URL right from the beginning (and the number of contributions in your activity stream 👍).

I would say we could give it a try!

Some things you should keep in mind:

• Naming-Conflicts (if somebody is building a more trendycommunity-driven project and requests the same domain; don´t panic that never happend)
• I´m not sure if it is possible with heroku to setup more than 1 domain. Do they have a CNAME mapping like GitHub Pages?
• The idea of a community-driveness not always makes a vivid project (see learn.js.org). I wish you more luck with this one.

Feel free to request one your suggested domains!

from js.org.

I thought a bit about your project: Wouldn´t it be nice to use heroku only for the submission, cronjob and page generation part, but use GitHub Pages or Surge to deliver the content in the form of static pages. This is super easy, fast, reliable, and cheap. I mean you would´t have to pay heroku a lot if the traffic goes up.

Thats what I do with stats.js.org. A Banana PI directly conected to my router (heroku for the poor ;-) generates the data and commits it to the gh-pages branch. And GitHub does the rest...

from js.org.

Thank you for the feedback.

Regarding to the domain, since the project is still young, I believe that the best way to move with the domain request would be waiting for a while until the project is more consolidated, but after that I would like to assign the subdomain to the project.
In the other hand, I would not hesitate to give back the subdomain to another initiative with a similar purpose if it becomes more successful or popular than JSDocs.
So, just to clarify, we could froze this request for a while until we improve the project and make it more stable for massive usage. Also, we can assign in the meantime pkgdoc.js.org, just to have something more presentable and also as backup name, sounds reasonable?

Regarding to Heroku and CNAME mapping, the answer is: yes, you can assign multiple aliases to a specific Heroku domain.

About Github pages, I thought about using it as well. My scenario is a bit different: we aren't just storing static pages, we have some backend logic and dynamic rendering and we can't rely completely in static views, however, that constraints are based on the current approach. We could completely rely on Github pages if we use a pure client-side app that talks with an API (e.g: Heroku app) to dynamically render stuff in the browser, but we need to rethink some parts to do that at this time.

I would consider using Github pages, but mostly if we move into a SPA webapp.

from js.org.

As I said the unrestricted domain is no problem at all, just file a PR.

But can you explain me the API on heroku a bit more in detail. I don't know its funtionality and so can't see its benefit.

I would just keep a list of repos that should get generated docs somewhere in the project repo. People can add their project to the list via PR. A cronjob takes the list once a day and checks what has to be generated. The generated docs should work even with JS disabled (I only see a need for a lot of internal links). With JS enabled a client can pick the very same list to make docs searchable (name, description text or tags). But that would just be a goody and I wouldn't call it a SPA.

What is it what you want to provide besides that. Would you be angry at me if I give it a try myself (and keep one of the two restricted domains for that)?

----- Ursprüngliche Nachricht -----
Von: "Tomás Aparicio" [email protected]
Gesendet: ‎18.‎11.‎2015 00:20
An: "js-org/dns.js.org" [email protected]
Cc: "Stefan Keim" [email protected]
Betreff: Re: [dns.js.org] Request for doc.js.org (#485)

Thank you for the feedback.
Regarding to the domain, since the project is still young, I believe that the best way to move with the domain request would be waiting for a while until the project is more consolidated, but after that I would like to assign the subdomain to the project.
In the other hand, I would not hesitate to give back the subdomain to another initiative with a similar purpose if it becomes more successful or popular than JSDocs.
So, just to clarify, we could froze this request for a while until we improve the project and make it more stable for massive usage. Also, we can assign in the meantime pkgdoc.js.org, just to have something more presentable and also as backup name, sounds reasonable?
Regarding to Heroku and CNAME mapping, the answer is: yes, you can assign multiple aliases to a specific Heroku domain.
About Github pages, I thought about using it as well. My scenario is a bit different: we aren't just storing static pages, we have some backend logic and dynamic rendering and we can't rely completely in static views, however, that constraints are based on the current approach. We could completely rely on Github pages if we use a pure client-side app that talks with an API (e.g: Heroku app) to dynamically render stuff in the browser, but we need to rethink some parts to do that at this time.
I would consider using Github pages, but mostly if we move into a SPA webapp.
—
Reply to this email directly or view it on GitHub.

from js.org.

The current implementation of JSDocs is pretty simple, and doesn't require any explicit action like pushing repositories, registering things or setup any cronjob layer.
I think that adds an unnecessary complexibility.
IMHO it should be implicit and easy to use, like GoDoc, so you only have to define the path of the repository you want to see in the URL, for instance:
http://jsdocs.herokuapp.com/github.com/mapbox/mapbox-gl-js

JSDocs dynamically fetches the repository and process it on the fly to generate the docs. Then the repository is registered in the index (for searches and further stuff) and the documentation output is stored for a while to avoid redundant processes (however, that part is very alpha).

The idea (for now) is just to provide a simple and useful way to see HTML API documentation of any public package (for now only hosted in Github) that follows the jsdoc conventions.

Regarding to your final question, do what you want, this is a free world, but if you're interested in doing something similar, perhaps we should collaborate and find a proper way to do something better.
I'm fully open to add new collaborators to the organization, and by the way, taking into account the current stage of the project, we're in a fresh stage where most of the things can be redone from scratch without too much efforts.

from js.org.

Didn´t had the time to deal with the topic, but you can open a pull reques if you are still interested.

from js.org.