Skip to content
This repository has been archived by the owner on Mar 27, 2019. It is now read-only.

component.io site down #587

Closed
ghost opened this issue Jul 13, 2014 · 22 comments
Closed

component.io site down #587

ghost opened this issue Jul 13, 2014 · 22 comments

Comments

@ghost
Copy link

ghost commented Jul 13, 2014

Not sure who is looking after component.io but it has been down for some time.

@netpoetica
Copy link

You can connect to it via http://component.github.io/component.io/ if need be.

I linked this issue over to component.io issues here component/component.github.io#80

@xmojmr
Copy link

xmojmr commented Jul 14, 2014

1 Original site founder (@visionmedia) is not going to look after the site anymore, at least this article seems to say that - https://medium.com/code-adventures/4ba9e7f3e52b

2 The domain was registered (WHOIS record) by @guille

3 If you just want to find something you can use http://component.xmojmr.cz

@tj
Copy link
Contributor

tj commented Jul 14, 2014

sorry yea, should switch to jonathan's thing, we still need a server for the cli search but linode is crap, I haven't had time to look into it. there's going to be a new component thing soon that takes the best of browserify / component and combines them, so we'll get all this rolling again soonish I imagine. In the meantime the wiki works fine. thank god it runs on GH :D would have an npm catastrophe on my hands

@sankargorthi
Copy link
Member

How often does the search refresh from the wiki? Some components don't seem to be searchable (lodash for example).

@tj
Copy link
Contributor

tj commented Jul 14, 2014

every 15 minutes or so, something must have screwed up. good old reliable node, i'll check it out when I have some time

@ghost
Copy link
Author

ghost commented Jul 14, 2014

@visionmedia The browserify / component combination sounds interesting. As is stands I like the flat structure of dependencies and using git repos so will see where this goes. Browserify does not have a decent way of managing images and other files and somehow cannot bring myself to include these in a node_module.

Component has been from the start a simple and elegant way of managing dependencies without a mess of nested dependencies. That said, its difficult for folks to rationalize multiple manifests.

Was disappointed recently by a move by socket.io-client maintainers to recently exclude component citing the die back of component.js as the reason for removing support for it socketio/socket.io-client#729. Seems by number of stars on this repo that it continues to attract developers but perhaps this is a sign that a resolution is necessary.

@stephenmathieson
Copy link
Contributor

Duo (component+browserify) will have the same flat dependent structure you're used to, and should be mostly backwards compatible with component ;)

@tj
Copy link
Contributor

tj commented Jul 15, 2014

yea we're still taking the best of component for structured asset management etc, the main thing from browserify is just less boilerplate to get started without a manifest. I have some future things in mind to ditch entirely, the more I use Go the more I think manifests don't make any sense.

The rest of npm/browserify is mostly bad stuff, a Go approach would be much better IMO, once ES6 module loaders are in play. Browserify will eventually die out too, they all will haha, long-term none of them make sense, builds are no fun

@jasonkuhrt
Copy link
Member

@visionmedia Can you summarize Go re build/package management as you see it in relation to future ideas for component, duo, etc.? You're name tech dropping pretty hard here, I am genuinely curious what the material substance is.

@tj
Copy link
Contributor

tj commented Jul 15, 2014

we already sort of take the Go approach but ideally once ES6 modules roll around we just parse those deps out of the import statements and leave all the manifests out, making them optional. I didn't think they bugged me so much but now that I never have to write them in Go it's really really nice, and no package manager to fuss with

for now builds are sort of necessary which sucks but some day!

@clintwood
Copy link
Contributor

@visionmedia, @jonathanong, A road-map of sorts would be great... the die-off/fragmentation of component is becoming obvious and a concern for myself and others I would assume... The fact that component.io site (apart from being up and down) doesn't really 'sell' the concept of component to one, I believe, makes the would be component user move on to something else leaving to die quietly. The core concept of moving away from monolithic libs like jQuery is what brought me to component but I have found it hard work to select components and perhaps this is due to the lack of an informative repository...

@jonathanong
Copy link
Contributor

I wouldn't worry about using the components themselves. Except for the browser compatibility ones, they are here to stay.

What will change is the package management, which will only become easier with es6 and spdy. What you'll basically have to do to upgrade is remove all your component.jsons

@tj
Copy link
Contributor

tj commented Jul 15, 2014

yea never really got around to making a real site, I have a feeling our front-end gurus at segment will want to make one for Duo, so we'll have something then, but @jonathanong is right, it was never really about any given implementation, more the packages. You could think of Duo as 2.0 (or 1.0 I guess), the packages themselves won't fragment

@xmojmr
Copy link

xmojmr commented Jul 15, 2014

@clintwood: 👍 ..I have found it hard work to select components and perhaps this is due to the lack of an informative repository...

That is why I resorted to building and running the component search tool as an temporary answer to component/component.github.io#78 (BTW yes it was my homework playground to learn things and it was fun)

But the someone somewhere someday will do something approach resulting in tool with bad support makes me to consider

@clintwood: 👍 ..would be component user move on to something else leaving to die quietly..

@clintwood
Copy link
Contributor

Right now what component gives me is require(...) with all it's boilerplate namespacing and component identity (user/component#ver) what could/would be great is a well orchestrated repository/package manager that really sells the concept... So for Duo I'd suggest that the presentation and marketing needs to be a very high priority so that it gets good traction... With good traction comes better community support and energy in general... BTW (@visionmedia, @jonathanong and component friends), your efforts are really appreciated :) thanks...

@jasonkuhrt
Copy link
Member

@visionmedia Cool thanks for clarifying

@tj
Copy link
Contributor

tj commented Jul 16, 2014

@clintwood for sure, I agree. Wish I originally had time to polish things more and get to a 1.0 at least haha, kinda feel bad but :p free is free I suppose.

@clintwood
Copy link
Contributor

Woha... @visionmedia... with all your contributions... you should never ever feel bad... Anyhow, for Duo, if it becomes a thing, we need marketing angle that makes it stick!

@jasonkuhrt
Copy link
Member

What @clintwood said. Thanks @visionmedia .

Would be nice if duo leveraged @joliss's broccoli build tool which seems well designed and aims to be better than gulp which duo is based on.

@augbog
Copy link

augbog commented Aug 25, 2014

For the time being, can the Github repo description change the link from component.io to http://component.github.io/component.io/ at least until this issue is resolved?

It's confusing users.

@timaschew
Copy link
Member

so since moving / renaming to componentjs the current url is: componentjs.github.io/component.io/

@guille a whois query show me that you're the owner of the domain, not sure who else has access, but can you redirect component.io to the github page? or give me access to manage it.

@timaschew timaschew mentioned this issue Sep 15, 2014
21 tasks
@timaschew
Copy link
Member

we switched to http://component.github.io

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants