componentjs / component

frontend package manager and build tool for modular web applications
https://github.com/componentjs/guide
MIT License
4.55k stars 306 forks source link

component.io site down #587

Closed ghost closed 9 years ago

ghost commented 10 years ago

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

netpoetica commented 10 years ago

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 https://github.com/component/component.io/issues/80

xmojmr commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

tj commented 10 years ago

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 commented 10 years ago

@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 https://github.com/Automattic/socket.io-client/issues/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 commented 10 years ago

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

tj commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@clintwood: :+1: ..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 https://github.com/component/component.io/issues/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: :+1: ..would be component user move on to something else leaving to die quietly..

clintwood commented 10 years ago

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 commented 10 years ago

@visionmedia Cool thanks for clarifying

tj commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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 commented 9 years ago

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