Dependency management > Atomify

[andreasgrimm]

https://github.com/atomify
"Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules"

I just want to throw it in because I find it an interesting alternative to webpack or component. some see it as an extension of the browserify approach.

Ben Clinkinbeard wrote a good atomify introduction article

[sindresorhus]

Interesting. Does it have any adoption?

[andreasgrimm]

afaik it's relatively new but it's development seems to thrive and if one searches for requireJS/Browserify alternatives he'll find atomify mentioned in several places. I'm currently not aware of the grade of adoption in somewhat bigger projects .. but I just asked the creator of atomify Daniel Erickson (@techwraith) about it on twitter.

Admittedly, it's about more than just javascript module dependency management. As component(1) does, it handles more things than just javascirpt files, e.g. css and other asset files.
As it (mis)uses npm, imho component(1)'s concept of using github as the repository is a cleaner approach.

[bclinkinbeard]

@andreasgrimm is correct that we are fairly new and so adoption is nascent. I am using it at my job (not public code) and @techwraith's company, Getable, is using it as well. @kristoferjoseph has alluded to some emerging use within Adobe as well.

Regarding "misuse" of npm, I think that is a mischaracterization. npm has explicitly stated it approves of its use for client side artifacts, including non-JS files. As mentioned in my intro post linked above, both Bootstrap and normalize.css, among others, have adopted the style property in their package.json files, so one could argue they have adopted the "standard" that atomify introduced/advocates for.

@sindresorhus I would LOVE to see atomify in the book, but even if that doesn't happen I'd be extremely interested in any feedback you have on the project. Thanks.

[andreasgrimm]

@bclinkinbeard thanks for the clearification regarding npm's content type concerns :) I was obviously wrong there.
comparing to component(1), component(1) then at least has the benefit of a greater flexibility regarding naming/namespace.

Including Atomify into the book would feel natural to me, as dependencies and their management play a role in frontend development not only regarding javascript files. separation of concerns, the whole "web components" thing getting stronger. It makes sense and would just fit in.

[Munter]

I guess I should write a chapter on Assetgraph as well then. That certainly fall directly into the category of dependency management

[andreasgrimm]

maybe it could be integrated into the Browserify chapter? ... as the lines in this regard are blurring anyway, e.g. there are overlaps regarding building concerns and dependency management concerns (which is true for component(1) as well)

[sindresorhus]

We would be happy to include a page or something on Atomify in the Browserify chapter. I agree it makes sense to put it there. Does that sound ok? Anyone interested in writing this?

[sindresorhus]

@Munter Yes, we need to have something on Assetgraph too. Can you open a new ticket for it?

[bclinkinbeard]

I can do the Atomify page/section.

On Fri, May 30, 2014 at 7:00 PM, Sindre Sorhus [email protected]
wrote:

@Munter Yes, we need to have something on Assetgraph too. Can you open a new ticket for it?

Reply to this email directly or view it on GitHub:
#64 (comment)

[sindresorhus]

@bclinkinbeard cool. what do you think makes sense covering? It should be something not already covered by vanilla browserify.

[bclinkinbeard]

Agreed. Focus will be around the CSS and asset stuff, and a bit on the dev server.

On Fri, May 30, 2014 at 7:11 PM, Sindre Sorhus [email protected]
wrote:

@bclinkinbeard cool. what do you think makes sense covering? It should be something not already covered by vanilla browserify.

Reply to this email directly or view it on GitHub:
#64 (comment)

[andreasgrimm]

awesome. I'd appreciate seeing some short clearification and resource (links) on npm being not only about js (anymore).
maybe in general some split up of utilities in the different concerns they're addressing? e.g. like component too, being relevant in regards of dependency management and build as well.