the future of component?
timaschew opened this issue · 77 comments
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?
@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)
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.
@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".
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 :)
@bmcmahen yeah, you probably shouldn't be using it yet haha
@bmcmahen tests everything in production. 👨
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
@stephenmathieson haha, yeah. just curious, that's all. ... and sick of writing component.json files everywhere.
yeah thats fair. there are still major decisions being made atm, so i wouldn't get too used to it yet
What happened to the duo github repo?
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.
Yeah, they're for different things alright (and i'm not going on the go boat but anyone is free to!)
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.
i don't know man, explicit dependencies are only going to make your big code base bigger :P
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 ;-)
@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.
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
@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?
@matthewmueller the readme looks nice! A few questions :)
- Can you try/catch require calls? finally? please??
- 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 :)
@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
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.
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.
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 :-)
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.
@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.
if you'd like to contribute let me know, i can add you as contributor.
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
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.
@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.
@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...
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.
@jonathanong, thanks, will have to put some time aside to take a look at both nlz and duo...
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
@visionmedia, @matthewmueller, looking forward to it... Duo eta to open source?
this week :-)
Awesome...
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.
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.
@matthewmueller Can you advise on the bitbucket support. Thanks.
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.
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 ?
yes :)
@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!
@stephanmthieson Great, let me know if you need help.
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.
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.
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.
@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.
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?
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: duojs/pack@560b859
@matthewmueller ahah! Excellent.
duo uses Stat.mtime to only parse / build / fetch stuff that are not installed / built already, if that's what you meant ?
Yes, but how I explained, we need all manifest files to generate the make rules to build the assets (js, css), because we don't want to use component builder plugins (for coffee-script and stylus). So manifest files are mandatory for us.
I think it depends on the architecture of your app which tool (component or duo) fits better.
I don't want to argue against duo, I think for the most architectures you can use it and it boosts your development. That's the reason why I created a tool to convert all your local components into duo compatible require paths.
https://github.com/timaschew/component2duo
your feedback is welcome :)
@timaschew sounds like your build process is overly complex. why don't you want to use plugins?
coffee support could be as simple as:
var coffee = require('coffee-script')
module.exports = function (opts) {
opts = opts || {};
return function coffeePlugin(file, duo) {
if ('coffee' != file.type) return;
file.type = 'js';
file.src = coffee.compile(file.src, opts);
};
};gotta agree with @stephenmathieson here, i can't understand how manifests tie in with Makefiles or why would auto generating makefiles is better / easier than just using duo.
we don't want to use it, because we don't want to tie too much with component, maybe we wanna switch to another tool in the future which doesn't support builder plugins like component, so the switch would be easier.
why would auto generating makefiles is better / easier than just using duo.
It's not only about easier, it's kind of architecture philosophy. With manifest files you have only one place per component with an overview of your dependencies, refactoring is done only in one file with a documented scheme. At the other site you have all your dependencies spread over your source files.
@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.
@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/module@x.y.z:index.js')
// ... etcI'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 :/
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
@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.
@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.
@fairwinds, you can download it from npm.
@stephenmathieson ah yeah for private stuff that's cool
@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?
does anyone using bitbucket use mercurial? i wonder if that's something package managers should ever bother supporting
@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
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
oh haha, sorry yeah i see now
, 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.
@yields, that would be great. I don't see it there now... :) so will hack away until it's OS...
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
@jonathanong I used hg on a project years ago just to test it out. never again though haha
I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha
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
I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha
agreed ;)
then if you need to break compat you just append -v2 or move it to its own repo
lol
..., otherwise it's just pure rage haha
hahaha, lovely...
closing due to #601 (comment) and #604