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

31–40 of 49 posts

Re: Towards a More Modular Future for JavaScript Libraries

#31

Post by ericgj »

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…

I completely agree and recommend component for all the reasons Ian mentions. It is shocking how little-known it is in javascript land. Don't be put off by lack of documentation and examples, it is seriously awesome. In fact I can't imagine doing client-side dev without it.

Re: Towards a More Modular Future for JavaScript Libraries

#32

Post by Bockit »

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

Re: Towards a More Modular Future for JavaScript Libraries

#33

Post by paultannenbaum »

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.

Re: Towards a More Modular Future for JavaScript Libraries

#35

Post by pekk »

davedx wrote: post #11
hyperpape wrote: post #8

Earlier quoted context omitted.

Yeah, it's available in the browser. I'm not even trying to slam JavaScript--I sort of like it for all of its foot-guns, but this is literally the only reason worth considering for its success. Edit: I like several things about JS. Certainly if it didn't have first class functions, or easy object literals, that would be a pain. Likewise, if it didn't have insane implicit conversions and painful APIs, that would be gr…

What about closures and first class functions? Or easy interop (JSON), object and array literals? JavaScript has more going for it than platform ubiquity.

Many languages have these things.

The problem is this spurious inference drawn from package count to language superiority. In reality what's popular is targeting browsers, and there simply aren't any other languages with first-class support by browsers no matter how much we want them. This isn't a matter of Javascript being better than everything else, it's a matter of historical accident and network effects.

Re: Towards a More Modular Future for JavaScript Libraries

#36

Post by camus2 »

alkonaut wrote: post #27

why not add a real module and dependency system to js at the language/runtime level? Considering how important JavaScript has become, isn't it completely amazing that this discussion is even happening now ?

TC39 is working on it ,i think they are 10 years late of that matter, and the solution they chosed is not even that good.

Re: Towards a More Modular Future for JavaScript Libraries

#37

Post by camus2 »

ben336 wrote: post #25
marknadal wrote: post #21

Please don't use Require.js, it overwrites how require is actually suppose to be used. Try using something that doesn't break instead, like HTTP://github.com/amark/theory (disclosure: this is my library, you should check out my tech talks).

"it overwrites how require is actually supposed to be used" According to whom? RequireJS is an implementation of the AMD spec.

spec written by whom? anybody came write something and claim it's a spec. There is no AMD spec.

Re: Towards a More Modular Future for JavaScript Libraries

#38

Post by etler »

I've had success with npm and browserify. There are still script tag dependencies I haven't gotten around to cleaning up, but the whole system is working well.

I'm absolutely in love with the npm system though. It's so simple, easy to use, and powerful. It's absolutely a killer reason to use node.js in general. I've never use a framework where installing a project was as easy as `npm install`.

Re: Towards a More Modular Future for JavaScript Libraries

#39

Post by ericgj »

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.

I haven't tried bower, but I always get a little confused when it gets compared to component. Bower seems like a downloader with some 'dependency management'. But its 'dependencies' are disconnected from a module/build system. Great if you have a separate tool to do your build, but frankly most of them out there are awful, and it would be a nightmare even with the best to wire them up to all the conventions of all the libraries you pull in.

As Ian said, component's opinions encourage more modular, better code, and allow you to do what Web Components only now are promising within the DOM itself: bundle together templates, css, code, data, etc. And it does this without imposing a framework. For instance, if you have a pure javascript library, it is extremely easy to package for both component and NPM. Most of the UI components are framework-independent and that is encouraged. The component ecosystem and community is fantastic. And it's not sponsored by a corporation on the NYSE :) These were the main reasons I was attracted to component. The learning curve is a bit steep, but getting better all the time.

Re: Towards a More Modular Future for JavaScript Libraries

#40

Post by marknadal »

ben336 wrote: post #25
marknadal wrote: post #21

Please don't use Require.js, it overwrites how require is actually suppose to be used. Try using something that doesn't break instead, like HTTP://github.com/amark/theory (disclosure: this is my library, you should check out my tech talks).

"it overwrites how require is actually supposed to be used" According to whom? RequireJS is an implementation of the AMD spec.

According to NodeJS, which given its dominance is rather important.
Post reply on HN