the future of component?

[timaschew]

It seems that contribution of some main contributors of component becomes low, due to some progress in the last months: https://github.com/component/component/graphs/contributors

• @visionmedia left node.js land
• people from segment.io use their own tool: duo
• @jonathanong started with normalize.io

// edit

• browserify seems to become more popular and works also for assets

we at our company use component heavily so it's very interesting for us how the future of component looks like and in which direction the development is going?

[wryk]

@matthewmueller @yields
Me too, I really love component and I wonder a lot about his future

Duo looks like a next version for component (mix from [email protected] and browserify ?).
Thankfully, it seems backwards compatible (I hope so much)

[ismay]

Me too, I really love component and I wonder a lot about his future

Me too. I hope that duo will be backwards compatible with component, or that someone'll take over component.

[vendethiel]

@visionmedia left node.js land

I think he said he'd continue to use nodejs for websites, though ;).

Duo takes a much more declarative approach than nlz, which pretty much "guesses".

[bmcmahen]

Having used Duo a bit, it seems mostly backwards compatible... and it also seems much easier to use. Specifically, there is way less boilerplate, which is a big + for me. Definitely seems to combine the benefits of component with those of browserify. Still a few bugs with it right now, but that's understandable since it hasn't really been released yet :)

[stephenmathieson]

@bmcmahen yeah, you probably shouldn't be using it yet haha

[sankargorthi]

@bmcmahen tests everything in production. 👨

[tj]

changed my mind about using node for sites as well haha, too much boilerplate to use Koa nicely right now, maybe when everything in core/npm is promise-based it'll be fine

[bmcmahen]

@stephenmathieson haha, yeah. just curious, that's all. ... and sick of writing component.json files everywhere.

[stephenmathieson]

yeah thats fair. there are still major decisions being made atm, so i wouldn't get too used to it yet

[markreg]

What happened to the duo github repo?

[jonathanong]

yeah normalize won't be backwards compatible. it also only supports what the browser supports, so there are no JSON files, you can't try/catch require()s, no dev dependencies, etc.

[vendethiel]

Yeah, they're for different things alright (and i'm not going on the go boat but anyone is free to!)

[timaschew]

The only difference between duo and component 1 is the implicit vs. explicit listing of dependencies, right?
All other reasons in the Readme of duo referring to component are pointed to the vesrion 0.x

The decision (implicit or explicit) is a matter of opinion. We decided at our company with a big code base project to use the explicit version. So browserify and duo are not compatible at this point.
So only component seems to be a solution.

[jonathanong]

i don't know man, explicit dependencies are only going to make your big code base bigger :P

[matthewmueller]

So a few things:

• Duo is about 95% ready to ship. I plan to open source it in about a weeks time. Basically I want to fix up some stdio issues, add a few more tests, and bring in the watch command.
• It's private right now, but all duo related things will live at: http://github.com/duojs
• @timaschew there's a few additional differences. I've added the latest documentation to a gist: https://gist.github.com/MatthewMueller/42fa88095b80155a1934. I'd encourage anyone who's interested in Duo to take a look at it.
• @visionmedia you should give Duo a spin once we release, I think you'll reconsider ;-)

[timaschew]

@matthewmueller thanks, sounds interesting

@jonathanong yeah, but if your project is already big, does it really matter? 😛

if you use explicit dependencies you have more control. for instance if you want to switch a component or a version, you need only to change it in your component.json instead of replacing every file which using this dependency.

[tj]

I like in-file deps too, don't need extra tooling to see what you're not using, and eliminates the need for manifests all together

[clintwood]

@timaschew, I share your concerns and for me these concerns are growing...

@matthewmueller, our company has made a strategic choice to depend heavily on component... we are in early development of 3 systems that form the core of our business strategy and will serve a large user base in the public and private sector. I've read the readme you pointed to above and am very interested in giving Duo a go (with a lower case G @visionmedia)!

We are at a point where we could switch to something like Duo and TBH the component boilerplate is something that has cost us in terms of time especially during this period of switching to 1.x.

@matthewmueller, how can I get more info on Duo so that I can evaluate it as soon as possible?

[darsain]

@matthewmueller the readme looks nice! A few questions :)

1. Can you try/catch require calls? finally? please??
2. If you can't try/catch, how do you consume development dependencies?

Also a feature I always wanted in component: I'd love build to somehow set environment flags & properties so I can check for env.development environment, or set stuff like env.apiurl ...

I also don't mind listening to reasons why I'm retarded and how to do things in a better way :)

[timoxley]

@darsain just fyi you can get these in browserify with: https://github.com/hughsk/envify and https://github.com/hughsk/remove-catch-require/https://github.com/hughsk/remove-try-require

[matthewmueller]

if you use explicit dependencies you have more control. for instance if you want to switch a component or a version, you need only to change it in your component.json instead of replacing every file which using this dependency.

@timaschew the manifest is optional. When I'm building a big web app, I'll probably use explicit dependencies as well for the reasons you mentioned.

how can I get more info on Duo so that I can evaluate it as soon as possible?

I'd just start playing with it :-P. The examples should get you started and I'd read the readme one more time. As with anything there's a learning curve, but for component users it should be pretty minimal.

[matthewmueller]

@darsain

Can you try/catch require calls? finally? please??

Duo ignores dependencies it cannot find. So it supports try-catch deps, but so did component with:

try { 
  var tip = require('tip');
} catch(e) {
  var tip = require('tip-component');
}

If you can't try/catch, how do you consume development dependencies?

This needs to be better documented, but you build a development bundle to test from. @yields has done a lot of work to make this easier with duo-test, which is an improvement over component-test.

[matthewmueller]

Also a feature I always wanted in component: I'd love build to somehow set environment flags & properties so I can check for env.development environment, or set stuff like env.apiurl

You could make a plugin, or if gulp has one, we'll support all gulp plugins by release :-)

[matthewmueller]

Overall, Duo is not a huge departure from component 1.x. In fact it supports 99% of existing components. The only components that would need to be updated are CSS components that have CSS dependencies. The only components I found that do this are logo components.

Duo reduces boilerplate, so it will make component development easier, not harder.

Nonetheless, it's going to take a bit of effort on your end to try it out and give it a shot. If you're not ready to do that or you don't have the time right now, then I would keep using component 1.x. Just be aware that most of us have moved on to using Duo or Browserify or Normalize and so Component updates will be infrequent.

Duo is the most like Component of the 3 options, so if you enjoy using Component, I would give it a shot.

[ghost]

@matthewmueller Browserify is weak on CSS and assets where Component excels for modularization. I assume images, fonts, files etc are handled in same way as Component without the additional manifest boilerplate.

Can you explain the scenario for CSS components with CSS dependents. This may not be common in public components but more apt to crop up in modular CSS Components that are private.

When you say that most of us are onto something else, are you suggesting component needs a new maintainer? Can someone be clear about the segment.io sponsorship for the project and where this stands.

It would be good to understand the circumstances for those with a vested interest in continuing with Component. There are valid concerns if development has stalled.

[jonathanong]

if you'd like to contribute let me know, i can add you as contributor.

[jonathanong]

segmentio only sponsored component for a little while. i guess you could consider duo as being sponsored by segment since @yields has been working a lot on it.

really, CSS should just be @imports. it doesn't have to be more complicated than that, and inlining CSS (or anything really) in JS is silly

[matthewmueller]

@fairwinds:

Can you explain the scenario for CSS components with CSS dependents. This may not be common in public components but more apt to crop up in modular CSS Components that are private.

Sure, for example, https://github.com/logo/apple has the dependency https://github.com/logo/logo in the manifest here: https://github.com/logo/apple/blob/master/component.json#L17.

In Component, CSS files are included from the manifest. In Duo they're loaded in the code. This gives CSS an actual load order and only includes the CSS you actually use.

To retrofit https://github.com/logo/logo to use Duo, you'd simply include @import "logo/logo"; at the top:

@import "logo/logo";

/**
 * Apple logo.
 */

.logo[data-logo="Apple"] {
  width: 0.8113207547169812em;
}

// ...

When you say that most of us are onto something else, are you suggesting component needs a new maintainer? Can someone be clear about the segment.io sponsorship for the project and where this stands.

Honestly not sure who the main contributors of Component are right now. What I do know is TJ is in Goland, Cloudup team @ Automattic is using Browserify, Segment is using Component 0.x & Duo, and Jonathan is using Normalize. That pretty much covers the core contributors that I know of anyway.

[ghost]

@matthewmueller This looks good. If we are looking at a flat dependency structure and
ES6 transpilation, CSS preprocessing through transforms, this could be pretty nice. Honestly, NPM has to go away in favour of consistent module management for client and server. Life will not be rainbows and unicorns until it is gone.

[clintwood]

@jonathanong, @matthewmueller, can we get an indication on how close/far either of these solutions are for community use/contribution/adoption. @fairwinds, agreed on npm, also need to go beyond GitHub for locked down in-house/intranet dev/solutions but that looks covered by both nlz and Duo...

[ghost]

@stephenmathieson Hey, have you got your bitbucket code started or visible anywhere. I'll likely be taking some time to start something if not. I've had a read through the code to review the gh support at this point but ready to dig into this.

[stephenmathieson]

@fairwinds nope, not yet. There's basic custom provider support in ./duo/lib/parse.js, but that's all I've been able to convince @matthewmueller to merge thus far :p

I think the eventual BB support will be something like:

var module = require('bitbucket.org/somebody/[email protected]:index.js')
// ... etc

I've got basic semver support with bb-resolve, but it needs a bit of work still.

I think the plan is to get Duo as stable as possible, then add features like BitBucket, etc.

edit: there's a PR for duo-package which adds support. I think it's conflicted at this point tho :/

[tj]

I can only speak for myself but I think keeping it GH only is a feature haha. When I see something that isn't on GH in Go-land I just don't use it, ~95% of Go software is on GH, the odd thing is on shitty Google code or Bitbucket. Maybe it could be supported but out of the box it's almost a negative instead of a positive IMO

[stephenmathieson]

@visionmedia i can only speak for myself too, but i use BB for business logic and GH for everything else. BitBucket offers free private repos, so it's hard to justify paying to host ~50 SLOC javascript components on GitHub.

[ghost]

@stephenmathieson Sadly, I am not able to access the duo-package repo just yet. Just don't want to repeat work someone may have already done. Agree with @stephenmathieson. Bitbucket may be behind on some capabilities but good value for private repos.

[kevva]

@fairwinds, you can download it from npm.

[tj]

@stephenmathieson ah yeah for private stuff that's cool

[clintwood]

@visionmedia, we run our own GH-like component server in-house for business logic (private) components (of which there are many) which we can't push to GH, so being limited to only GH is a non-starter for us.

@matthewmueller, @yields, is there a way to add additional GH-like resolvers to Duo? I see duo-package uses gh-resolve and that looks pretty baked in... if that's that case would this be where it could be extended to use additional resolvers?

[jonathanong]

does anyone using bitbucket use mercurial? i wonder if that's something package managers should ever bother supporting

[lancejpollard]

@jonathanong i think @stephenmathieson ways saying he uses bitbucket so he can have lots of free private repos. makes sense, especially if you want to follow component's super-modular conventions but don't have a few hundred dollars a month to spend on github

[jonathanong]

yeah i'm asking a different question. haha. bitbucket supports both git and mercurial repositories, but i don't know if people even use mercurial. if you only support git, then you can git ls remote bitbucket like it's github, just change the hostname

[lancejpollard]

oh haha, sorry yeah i see now

[yields]

, is there a way to add additional GH-like resolvers to Duo? I see duo-package uses gh-resolve and that looks pretty baked in... if that's that case would this be where it could be extended to use additional resolvers?

i think we agreed on something like duo.provider(regexp, obj), obj has #auth, #resolve and #tarball, so should be pretty easy to add a provider i think.

[clintwood]

@yields, that would be great. I don't see it there now... :) so will hack away until it's OS...

[netpoetica]

does anyone using bitbucket use mercurial? i wonder if that's something package managers should ever bother supporting

I have seen Mercurial used by software devs much more than web devs, but Git is slowly taking over there as well. Only one web app company I worked for used Mercurial, but the lead dev who chose is was a C++ guy who did svn -> mercurial path. I imagine by now they have moved to git just for pure convenience of all web packages being on Github

[stephenmathieson]

@jonathanong I used hg on a project years ago just to test it out. never again though haha

[tj]

I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha

[tj]

Oh and the cool thing is if it goes more Go-like then you can have many packages in a single repo no problem without any special exporting code. I have 33 Go packages in one repo right now for example, then if you need to break compat you just append -v2 or move it to its own repo

[stephenmathieson]

I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha

agreed ;)

[jonathanong]

then if you need to break compat you just append -v2 or move it to its own repo

lol

[clintwood]

..., otherwise it's just pure rage haha

hahaha, lovely...

[timaschew]

closing due to #601 (comment) and #604

[timaschew]

related: #639