search

tooling / book-of-modern-frontend-tooling

The Front-end Tooling Book
http://tooling.github.io/book-of-modern-frontend-tooling/
2.53k stars 177 forks source link

Dependency management > Atomify #64

Open andreasgrimm opened 10 years ago

andreasgrimm commented 10 years ago

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

Interesting. Does it have any adoption?

andreasgrimm commented 10 years ago

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

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

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

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

andreasgrimm commented 10 years ago

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

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

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

bclinkinbeard commented 10 years ago

I can do the Atomify page/section.

On Fri, May 30, 2014 at 7:00 PM, Sindre Sorhus notifications@github.com 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: https://github.com/tooling/book-of-modern-frontend-tooling/issues/64#issuecomment-44708626

sindresorhus commented 10 years ago

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

bclinkinbeard commented 10 years ago

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 notifications@github.com 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: https://github.com/tooling/book-of-modern-frontend-tooling/issues/64#issuecomment-44709232

andreasgrimm commented 10 years ago

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.