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

11–20 of 49 posts

Re: Towards a More Modular Future for JavaScript Libraries

#11

Post by davedx »

hyperpape wrote: post #8
jsmcgd wrote: post #7

The graph of library growth is stunning: http://modulecounts.com/ For all of JS quirks it is clearly getting something(s) very right.

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.

Re: Towards a More Modular Future for JavaScript Libraries

#13

Post by knome »

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.

While it certainly has good points besides platform ubiquity, if you were trying to derive an equivalent of big-O for the popularity of javascript, language level criticisms and acclamations would count as, at best, linear concerns, where platform ubiquity is an exponential concern.

Platform ubiquity is so completely important in the determination that all other concerns can be ignored entirely.

Given a choice of supporting half of systems in javascript, and all systems in brainfuck, people would begin writing brainfuck-targeting compilers immediately.

Re: Towards a More Modular Future for JavaScript Libraries

#15

Post by clarle »

alanning wrote: post #9

The yui library has an interesting concept of cleint-side modules. They were able to consolidate a lot of their widget code during the rewrite of yui2 to yui3. I'm also excited to see what the Meteor team comes up with for their v1.0 release. They already have reusable packages for the client and server but currently it's only designed for those using the core meteor framework. Would be interesting to see if what the…

I'm on the YUI team - we'll be doing a lot more work in the module space coming up in the future. We have a few goals coming up - mainly to make each YUI component interoperable with different module systems, so that developers can use each individual YUI module whether they're using AMD, CommonJS, just plain YUI modules, or even ES6 modules.

Our goal is to play better with other libraries, so that we don't have the idea of a "walled garden", and that people can use whatever other libraries they want together with YUI, which has been a bit more difficult in the past.

Eric Ferraiuolo gave a good talk on this last week at YUIConf. Unfortunately, the full videos for the talks aren't out yet, but his slides are right here:

https://speakerdeck.com/ericf/yui-and-the-future

Keep posted - we definitely think that smaller, more reusable modules are the better way to go for front-end development in the future, and we'll have some interesting projects soon that anyone - even if you're not using YUI - can use.

Re: Towards a More Modular Future for JavaScript Libraries

#16

Post by SkyMarshal »

Good writeup, thanks. As someone recently shifting focus from backend to frontend this was a good overview of the state of things.

If you're hankering for future blog articles, I'd love to see your take on the tradeoffs b/t using require.js vs Browserify. Or more generally a followup article on your whole FUD section would be useful.

PS - amusing typo, it's CPAN, not CSPAN :)

Re: Towards a More Modular Future for JavaScript Libraries

#17

Post by SkyMarshal »

thenmar wrote: post #10
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…

You don't think it has anything to do with Node?

Node only came about b/c Google wrote V8 for high-performance browser JS. Node has certainly expanded JS's reach in a big way, but wouldn't have existed in the first place if, say, Lua were the lingua franca of all web browsers (or maybe V8 and Node would still exist but target Lua instead).

Re: Towards a More Modular Future for JavaScript Libraries

#18

Post by hernan604 »

See JSAN: http://openjsan.org/ (without www)

You can download the JSAN Server, and upload modules. And it takes cares of dependencies.

Check it out, and if you like, contribute there and dont reinvent the wheel.

I too belive we need a more modular javascript.

Plus, you can use JOOSE-js to create modular modules. I recommend JOOSE-js. Its great and works in all browsers, also with node (backend) and frontend

Re: Towards a More Modular Future for JavaScript Libraries

#19

Post by hernan604 »

hernan604 wrote: post #18

See JSAN: http://openjsan.org/ (without www) You can download the JSAN Server, and upload modules. And it takes cares of dependencies. Check it out, and if you like, contribute there and dont reinvent the wheel. I too belive we need a more modular javascript. Plus, you can use JOOSE-js to create modular modules. I recommend JOOSE-js. Its great and works in all browsers, also with node (backend) and frontend

Also, in the non-perl world, i see a lot of web frameworks that likes to provide an all in one solution. That leads the developers and applications to tie themselves onto those frameworks(which is bad). ie: someone using webframeworkX that provides ormY builds all his site using that stack... and that is not good, because to use the ormY they will need the webframeworkX.

That sucks. because if i need to use cron for that app, i will need to load the webframework because the app is tied onto it... bah.

The best solution is to have ormY separated from the webframeworkX. So you can build your app with ormY, and use any webframeworkX Y or Z (only on the web facing part of your app). And no need to use orm at all (from the framework)

Post reply on HN