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 component@0.9 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. :man:

[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? :stuck_out_tongue:

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...

[jonathanong]

the cli works is pretty well for nlz already if you want to test it. there's been some people playing with it and helping me. i'm working on the spdy push static server right now, which is where all the magic is. that might take some time to be production ready. i don't expect any of this to be "production ready" until es6 is finalized because shits probably going to change until then, though you could still use require()s.

i think adding private remotes to nlz should be pretty easy, especially github-style git remotes like bitbucket. haven't tested that yet though. but github + npm already works.

right now you have to setup your own proxy though because i haven't setup nlz.io. i'll probably do that soon so that trying nlz(1) would be a little easier.

[clintwood]

@jonathanong, thanks, will have to put some time aside to take a look at both nlz and duo...

[tj]

we shouldn't have 1.x'd component it's totally not a 1.0, I'd look at Duo as being the first 1.x of a component-ish thing, it was never about a specific implementation anyway so it's awesome to see something more robust that isn't coupled to npm

[clintwood]

@visionmedia, @MatthewMueller, looking forward to it... Duo eta to open source?

[matthewmueller]

this week :-)

[clintwood]

Awesome...

[timaschew]

I'm surprised that no one is supporting component. I understand that for some people explicit listing of files and refactoring in a manifest is annoying. But duo has also its drawbacks.

One of them breaks this philosophy: https://github.com/component/guide/blob/master/component/vs.md#when-is-component-right-for-me

Component's philosophy is the UNIX philosophy of the web

with duo components are not self-contained anymore, because when you write require('/lib/foo') or require('../foo) you are reference to a scope out of your component. A component should know nothing about the external world and paths.

And this has a big side effect for the build process, especially when you're using transcompiler and use them separate from components build process. The result is that you cannot build particular components anymore, so incremental builds not working anymore, you need to build everything, the whole app. This feature is only possible with a manifest per component which contains the dependencies.

[jonathanong]

i agree that dependencies should never use / because it requires knowledge of the server and environment it's running on.

A component should know nothing about the external world and paths.

i disagree with this, though maybe i don't understand what you mean. if you have any dependencies, that's an external world or path. having it in a manifest or inline makes no difference.

import jquery from 'https://rawgit.com/components/jquery/2.1.1/jquery.js'

this will work in browsers natively, and if the package manager doesn't support it natively then it's not going to last very long.

And this has a big side effect for the build process, especially when you're using transcompiler and use them separate from components build process. The result is that you cannot build particular components anymore, so incremental builds not working anymore, you need to build everything, the whole app. This feature is only possible with a manifest per component which contains the dependencies.

i'm not sure i understand what you mean here either. seems like you've created an overly-complex build process for your app. external components shouldn't require a build process otherwise they aren't very good components.

[ghost]

@MatthewMueller Can you advise on the bitbucket support. Thanks.

[timaschew]

I mean that the manifest (component.json) should be the one and only interface to the external world. At this place you define local and remote dependencies and provide access to them via a namespace mechanism.

i'm not sure i understand what you mean here either. seems like you've created an overly-complex build process for your app. external components shouldn't require a build process otherwise they aren't very good components.

I mean something different:

We have an app and it's not a single page, we have about 80 (local) components and we use coffeescript, stylus and jade. So we need to convert these files and run component on the generated files. Since it's not a single page app, we want to build single components during development (only the files we've changed) and not the all 80 components.

We can achieve this incremental build by generating makefiles from all our component.json files.

[yields]

we want to build single components during development (only the files we've changed) and not the all 80 components.

duo uses Stat.mtime to only parse / build / fetch stuff that are not installed / built already, if that's what you meant ?

[timaschew]

yes :)

[stephenmathieson]

@fairwinds i've been working to get BitBucket support built-in. I don't think it'll land before the initial release, but it is in the works!

[ghost]

@stephanmthieson Great, let me know if you need help.

[ghost]

A bit of perspective. Components was about a components and the spec at the outset, not the package manager that works with them as much. It seems duo uses a duo.json that breaks with the existing component spec @MatthewMueller can you clarify.

I also understand the concern about a manifest. Component/Component(1) is currently being used for more than front end work as a general tool – even by folks outside of the node community. It is part of many build workflows and one that doesn't particularly care about whether it is specifically used as front end javascript package and build tool.

Looking forward, developers are also doing a number of things today that are not going to mean much with the future for JavaScript. npm and manifests fit into this category. Transformation or transpilation processes can be handled differently. That said, we are in this transition and tools that facilitate the newer workflows that allow developers to evolve is going to be helpful.

The problem we have with Component/Component(1) project atm is practical and we want an end to the limbo it is in. This was the reason for the thread. The fact the site is down and development stalled at an rc5 is hurting components in general and the adoption of an asset workflow that is better – regardless of what software is used to manage it.

Jonathan suggested splitting the Component/Component(1) code into its own github org account so it could continue to evolve. Duojs living in another org and the component org remaining as it is with the all the general component code and maintainers live here. Component and Duo are both tools that manage components.

We've offered to sponsor the component.io site and the continued work on Component(1). We'll support the newer workflows as they evolve regardless. Component plays a role for us which is why we'd do this. If Duo is the next Component 1.0.0 living here we are fine with that also. One way or another, we want this resolved and the site back up for anyone to have confidence in components of any kind.

[matthewmueller]

@timaschew

with duo components are not self-contained anymore, because when you write require('/lib/foo') or require('../foo) you are reference to a scope out of your component. A component should know nothing about the external world and paths.

This is not quite true. All remote components have the root set to their contained directory. So if you ran require('/lib/foo) on components/component-emitter@master/, you'd resolve to components/component-emitter@master/lib/foo.

As far as breaking out locally, it's all about application design. You can shoot yourself in the foot with both package managers. The only difference between component's local components and duo's local components is require('local-component') => require('../local-component') or require('/lib/local-component'). In both cases you're breaking out of the component.

In Duo we opted for less magic in the resolving process. The upside is you have a better idea of where your assets are, especially when there's new eyeballs looking at the code. The downside is it does take maybe 3 extra minutes to prepare a local component for open souce if/when you want to push it up to github.

@fairwinds

It seems duo uses a duo.json that breaks with the existing component spec

Duo is pretty much entirely compatible with existing Components. Certain CSS assets, that I discussed earlier are not compatible. Also assets that get linked in the manifest, but are not referenced in the code will not get picked up. I've searched through most the public repos with a component.json and there are very few cases where the component itself would need to be updated.

We haven't been basing our decisions on the existing Component spec as we don't think Component is sufficient. The "spec" of Duo is taking the good parts of Browserify & Component, with inspiration coming from Go.

Looking forward, developers are also doing a number of things today that are not going to mean much with the future for JavaScript. npm and manifests fit into this category. Transformation or transpilation processes can be handled differently. That said, we are in this transition and tools that facilitate the newer workflows that allow developers to evolve is going to be helpful.

Completely agree, however I do think the work we're doing here will be better than anything the browser comes up with. At least for a while. Duo is just another evolution in the workflow.

---

FWIW, I'm not pushing anyone to start using Duo. I've been using component for the last 2 years and it changed my perspective on front-end development. I have immense respect for the project and if it's working for you, then you should keep using it.

[ghost]

@MatthewMueller The efforts behind Duo look solid but am not sure I agree with the insufficiency of the component spec, only that its scope was different.

From what I have seen, Duo is more purpose built with an alternative resolver that takes a lesson from browserify. It steps back to a builder with sensible plugins. These are both good things but may have been accomplished by offering resolver options in Component and reverting the direction that the builder took with the RC candidates (to arrive at a final with interesting character).

I see this as both good and bad. If there is a stigma attached to Component as being onerous for its manifests, Duo might be a fresh start without the burden of its legacy. That said, evolving Component may have demonstrated that the mind share behind Component was able to resolve its warts and reward its community with a release. Perhaps this is what @visionmedia was getting at, hard to say. if Component's effect was to evolve alternatives that is also a good thing and expect Duo to be quite shiny. Its all good.

[bmcmahen]

I don't see duo as necessitating or encouraging less modular design by taking away 'locals'. In effect, it's simply taking the reference path -- the knowledge of the rest of your app -- from the component.json and putting it into your javascript require statements themselves. This has the benefit of increased explicitness... i.e., you are in fact using a local component, and not something from github.. and increased flexibility. It's a lot easier to organize your app in different ways now, with a lot less effort.

I do wonder a bit about stylesheets now, though. You can't (unless I'm missing something) import the same stylesheet into multiple modules without significant code duplication. That is, if I want to have a module for my stylesheet variables which multiple components import, then my variables are contained within my code for every import. @MatthewMueller is this how it works?

[matthewmueller]

I do wonder a bit about stylesheets now, though. You can't (unless I'm missing something) import the same stylesheet into multiple modules without significant code duplication. That is, if I want to have a module for my stylesheet variables which multiple components import, then my variables are contained within my code for every import. @MatthewMueller is this how it works?

This was fixed by @lancejpollard :-). It should be in the latest Duo release: https://github.com/component/duo-pack/commit/560b859acb3597c3bb592d3b07b06359f79890f2

[bmcmahen]

@MatthewMueller ahah! Excellent.