Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards a More Modular Future for JavaScript Libraries

flippinawesome.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Towards a More Modular Future for JavaScript Libraries

#41

Post by jongleberry »

paultannenbaum wrote: post #33
ianstormtaylor wrote: post #29

Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we think about and write Javascript in the best way possible. (Need to write a few more blog posts about this soon since it's never explained well in these comparison articles.) It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't…

Just curious, have you guys given bower a chance, and if so why did you guys end up going with component. Component seems to be slightly more opinionated, less adopted, but really nice.

1. bower doesn't do much. it downloads all your deps and its deps, but then you have to figure out how to consume the package. component handles all of that for you. if all i wanted to do is download and resolve dependencies, i would just use npm.

2. component doesn't just manage 3rd party packages - it helps manage your internal code/styles/templates as well. see https://github.com/jonathanong/bigpipe-example/tree/master/c.... keeping CSS/JS/HTML for a component of your site in completely separate folders is a thing of the past.

3. it's less adopted because it doesn't have Twitter's marketing and man power. TJ also hasn't had the time to document or market it well. it's also much more difficult to teach (well).

4. i hate requirejs due to its unnecessary callback and defining modules through function arguments. if i weren't using component, i'd use browserify. i have not seen any non-requirejs implementations of a build step, and i'd rather have a single step than two.

5. it's easier to share code between node and the browser. with requirejs, it's a little harder, but it's easiest with browserify.

6. most bower packages are bloated and require other large dependencies like jQuery, and I can't filter through that. component modules, on the other hand, tend to be very small, lightweight, focused, and overall better quality. for example, https://github.com/yields/select is becoming pretty excellent, much better and less bloated than select2.

7. bower packages tend to come with excessive amounts of options (because people request them, ex. select2) and excessive boilerplate code (because people want it to look good right way, ex Font Awesome). component packages tend to be the opposite - minimal, structural styling and very few options.

Re: Towards a More Modular Future for JavaScript Libraries

#42

Post by jdd »

hackula1 wrote: post #28

Both awesome libraries, but I think including lodash and jquery in the list of small modules is a bit of a joke. Both are big old fashioned utility belts. This https://github.com/lodash/lodash/blob/master/lodash.js is hardly the ~200 LOC module being described.

It may help rereading the post as it does explain why both are on the list.

FWIW you're linking to the pre-build dev source.

Lo-Dash is available as modules for AMD, ES6, CommonJS, Node.js, and npm packages per method.

https://npmjs.org/package/lodash-amd

https://github.com/lodash/lodash-es6

https://npmjs.org/package/lodash-node

https://npmjs.org/browse/keyword/lodash-modularized

Also, jQuery is using AMD internally and allows custom builds.

There is even a project to convert it to something more easily consumed by browserify:

https://github.com/kirbysayshi/node-ddd-jquery#rationale

Re: Towards a More Modular Future for JavaScript Libraries

#43

Post by EGreg »

ianstormtaylor wrote: post #29

Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we think about and write Javascript in the best way possible. (Need to write a few more blog posts about this soon since it's never explained well in these comparison articles.) It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't…

Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY

Re: Towards a More Modular Future for JavaScript Libraries

#44

Post by wyuenho »

Bockit wrote: post #32
wyuenho wrote: post #26

I've written about JS modules in the past. https://medium.com/what-i-learned-building/5a31feb15e2 While I think OP's link is quite informative, I think it suffers from the same oversight as most others on this topic has - confusing JS modules with Web components. The JS world is split in 2 right now - client and server - for good reason because they are 2 very different domains with very different requirements. While…

What do you think of browserify coupled with transforms providing html templates[1] and css inclusion[2]. [1]: E.g., https://npmjs.org/package/browserify-jade [2]: E.g., https://npmjs.org/package/stylify

package.json doesn't have any place to define the styles and templates your component exports, so browserify can't meaningfully resolve dependencies and build your assets for you. For really good support, you'll need to be able to rewrite the URLs inside CSS too due to different directory structures within each component. Component does that for you.

Re: Towards a More Modular Future for JavaScript Libraries

#45

Post by ianstormtaylor »

EGreg wrote: post #43
ianstormtaylor wrote: post #29

Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we think about and write Javascript in the best way possible. (Need to write a few more blog posts about this soon since it's never explained well in these comparison articles.) It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't…

Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY

Yup exactly. Your use of the word "entire" is what is wrong with your thinking, and what every other package manager gets wrong too. There is so much duplicated code out there as a result of people thinking to themselves "this is too small to be its own component". Instead, they just copy-paste it into the bottom of the file.

Yes the "on-escape" component just attaches an escape handler to the document. One of the reasons for it is just to not have to write that code yet another time, since doing that is boring and, more importantly, prone to bugs.

But the other reason is that it turns this:

  document.attachEventListener('escape', fn, false);
into this:

  onEscape(fn);
without losing any clarity whatsoever.

It's also more performant than attaching tons of different escape handlers, because across all components everyone will share the same event listener. Even for components that somebody else wrote and you're just using.

So yes, there's a component just for onEscape.

Re: Towards a More Modular Future for JavaScript Libraries

#46

Post by EGreg »

ianstormtaylor wrote: post #45
EGreg wrote: post #43

Earlier quoted context omitted.

Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY

Yup exactly. Your use of the word "entire" is what is wrong with your thinking, and what every other package manager gets wrong too. There is so much duplicated code out there as a result of people thinking to themselves "this is too small to be its own component". Instead, they just copy-paste it into the bottom of the file. Yes the "on-escape" component just attaches an escape handler to the document. One of the re…

Don't get me wrong, I think there's a lot of value in components. If you look at my company's logo, you will see that it is three building blocks. Our framework and platform are all about reusable code blocks. Having said that, though, I think this is taking it way too far. Most of these things are trivial one liners in JavaScript. Yes, it is true that you can have many places in the code hooking into the same event listener, but guess what, having many event listeners hooked into the same event dispatcher is rather as edficient. And what if later I want to press the letter K? Do I need a component for every letter? For that matter why don't you have a component for addition and subtraction and another component for pressing the ? I mean, look at node modules. They do more than handle a single key press. Socket.io for example has an overall theme, so does express, and so do other modules. What is the theme here? Make every line into a component so I can introduce setup and teardown code for it?

Re: Towards a More Modular Future for JavaScript Libraries

#47

Post by Bockit »

wyuenho wrote: post #44
Bockit wrote: post #32

Earlier quoted context omitted.

What do you think of browserify coupled with transforms providing html templates[1] and css inclusion[2]. [1]: E.g., https://npmjs.org/package/browserify-jade [2]: E.g., https://npmjs.org/package/stylify

package.json doesn't have any place to define the styles and templates your component exports, so browserify can't meaningfully resolve dependencies and build your assets for you. For really good support, you'll need to be able to rewrite the URLs inside CSS too due to different directory structures within each component. Component does that for you.

That's a pretty fair point about the CSS url rewriting, it's possibly the kind of thing you can fix with a browserify transform, but iffy and as you say component is doing it already.

Re: Towards a More Modular Future for JavaScript Libraries

#48

Post by ericgj »

EGreg wrote: post #46
ianstormtaylor wrote: post #45

Earlier quoted context omitted.

Yup exactly. Your use of the word "entire" is what is wrong with your thinking, and what every other package manager gets wrong too. There is so much duplicated code out there as a result of people thinking to themselves "this is too small to be its own component". Instead, they just copy-paste it into the bottom of the file. Yes the "on-escape" component just attaches an escape handler to the document. One of the re…

Don't get me wrong, I think there's a lot of value in components. If you look at my company's logo, you will see that it is three building blocks. Our framework and platform are all about reusable code blocks. Having said that, though, I think this is taking it way too far. Most of these things are trivial one liners in JavaScript. Yes, it is true that you can have many places in the code hooking into the same event…

The point is with component you have a choice of how granular you want your components depending on the project, and there is very low cost to breaking things down and having a bunch of dependencies. Whereas the tendency almost everywhere else is to either use monoliths and toolbelts with a bunch of stuff you don't need, or on the other hand to "cut & paste the wheel" on the other.

There are some components that bundle several components together, e.g. component/dom or component/enumerable. And there are certainly more general components for key handlers. But if you need just one piece of it, you don't have to install the whole bundle. And if you use it just once or a few times or in limited contexts, you're right, you can inline it and skip the dependency altogether. But the point is you have a choice depending on your needs.

Post reply on HN