
Javascript: A Language in Search of a Standard Library and Module System - samstokes
http://zef.me/2856/javascript-a-language-in-search-of-a-standard-library-and-module-system?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zefme+%28I+am+Zef%29
======
phaedrus
He seems to be arguing that the existence of multiple javascript frameworks is
caused by it lacking a standard library, but I don't think you can conclude
one based on the other; as a counter example the Java language has an
extensive standard library, yet it has many, many 3rd party frameworks as
well.

The other thing most of these frameworks provide is cross browser
compatibility. If there were a large standard library built into javascript, I
fear it would just be more things for different browser makers (especially
Microsoft) to implement with different quirks, and you'd still need a 3rd
party compatibility framework layered on top of it to be cross browser
compatible, only now it would have to cover a large framework instead of just
16 objects.

~~~
mnemonicsloth
It's not that many js frameworks imply the need for a standard library. It's
that many js frameworks, _all providing the same functionality that many
people want_ imply the need for a standard library. You mention cross-browser
compatibility, he mentions web widgets. I don't see how anyone could oppose
standardizing OS stuff like threads and IO on the server.

 _If there were a large standard library built into javascript, I fear it
would just be more things for different browser makers (especially Microsoft)
to implement with different quirks..._

It's a lot easier to release your own incompatible (possibly "extended")
version of a standard than it is to break existing software. MS can't even
phase out IE6, even though they _and the companies stuck using it_ acknowledge
that IE6 needs to die. If MS released a browser version that broke many
previously-working pages, it would probably trigger antitrust action by the
government.

~~~
jacobolus
There are many approaches to concurrency (“stuff like threads and IO”). It’s
not at all clear to me that a one-size-fits-all approach is appropriate, and
so while few might opposed the _idea_ of having a standard, I posit that
whatever standard you actually proposed would be vehemently opposed by those
who prefer a different approach.

------
n8agrin
_The growing body of Javascript code also means Javascript needs more than
just those 16 objects._

I don't know, I don't disagree with the sentiment that the standard lib is
pretty bare, but I also think that's the beauty of JS. Also, there are any
number of other libs (as the author points out) that add much of the desired
missing functionality.

To the author's point of having many libs (jquery, etc) and no chosen
standard, I don't see that as a bad thing. To me that just shows that the
language succeeds in allowing authors to use it according to their own style
and liking.

~~~
josh33
Standard library = socialism

Many open libraries = capitalism

Since capitalism elucidates turrets in some people, I'll add that what I'm
driving at is competition breeds innovation and quality. If one library adds
functionality another doesn't have, then it will add it, and in the process,
improve on it. Awesome!

~~~
spoondan
A standard library does not preclude third-party libraries. In fact, a good
standard library can make it more likely for third-party libraries to
_meaningfully_ compete. Reducing the amount of incidental (utility) code that
needs to be written can:

1\. Allow established entrants to focus on more beneficial areas.

2\. Lower the barrier to entry for new offerings.

3\. Reduce the number of defects by shifting resources away from maintenance
of incidental functionality.

~~~
RyanMcGreal
Three cheers for the mixed economy!

------
btilly
I don't care about the lack of a standard library. I care about the lack of an
equivalent to CPAN.

For instance a couple of years ago I ported Statistics::Distributions from
Perl to JavaScript. I looked for a place to put it. Nobody could suggest any
place for a random piece of code like that. Eventually I stuck it on
<http://code.google.com/p/statistics-distributions-js/>. I doubt that anyone
has ever looked for it there or found it. And the need is so specialized that
it doesn't make sense to try to get a user base.

I doubt anyone has ever found it there. If they did it is probably because
Ohloh picked it up.

~~~
wvenable
Isn't that putting the cart before the house. JavaScript has no standard way
of importing/using libraries -- that seems like a prerequisite for something
like CPAN. Otherwise instead of an organized repository of libraries, you just
have a bunch of code.

~~~
btilly
JavaScript has no standard way for one library to include another. But it is
very easy to insert a library into a web page.

The code I ported is a standalone library that can be imported into a web page
and then its functions can be called. There is a lot of useful code that looks
like that. It is a shame that there is no standard bit bucket that you can put
it in.

~~~
demallien
Yes, but here's the problem. I am using JavaScript outside of the browser on a
project at the moment. I want to use your library, but your library directly
loads a dependency, by trying to load a webpage. My JavaScript motor doesn't
know how to load webpages, so now I can't use your library. On the other hand,
if we had a standard call for loading libraries, each implementation could do
as it needs - web browsers could try to load the code from a known repository
on the current page's server. Embedded JavaScript and server-side JavaScript
could load from a known repository, or from a repository specified at the
launch of the JavaScript session. And we could all specify our dependencies in
a clean manner that would be transportable.

~~~
btilly
I feel like you are not responding to what I wrote.

My statement is that having a widely known repository is still useful for
random libraries which are simple enough to not have dependencies. I
completely agree that having a standard way of loading dependencies would make
such a thing much more useful still, but it still has utility without that.

Seriously, if you need to be able to calculate several standard probability
distributions to 5 digits of precision in JavaScript, you can do it today with
the library that I ported. Either embedded or server side. Doesn't matter. Go
ahead and use it. (If GPL/Artistic doesn't work for you then I'm sorry. I
can't grant a more generous license than the Perl version I started with.)

------
axod

      >> JSON parsing and serialization
      Yes, it has this
      >> Testing
      console? alert? what do you want :/
      >> Cryptography
      For why?
      >> Date handling
      Date object works pretty well for that,
      >> DOM querying
      There's extensive functions to get at the DOM.
    

>> It would be oh-so-nice to have a de-facto standard library for this stuff.

I don't see what extra you need. Sure, if you want ready made widgets/UI
effects, then go use one of those funky js libraries the kool kids use. I
think one of the best things about javascript is that you can do things a ton
of different ways, there is no right or wrong way to do OO, do it whichever
way makes most sense.

On the question of modularization/imports, I don't see an issue really, it's
simple enough to include using script tags, and set your build/deploy script
to remove those and combine/minify to a single js.

Seems like a rant about how flexible and diverse javascript is, and how that's
somehow a bad thing.

------
kwamenum86
"Objects are typically also used as maps (although the keys can only be
strings, and not even all strings)"

What do you mean keys can only be strings? And not even all strings? Wait, you
mean the following will not work:

    
    
      arr = [1,2,3]
      regex = /a/g
      x={}
      x[arr] = 'array, ha!'
      x[regex] = 'regex, ha!'
      x['function'] = 'function, ha!'
      alert(x[[1,2,3]])
      alert(x[/a/g])
      alert(x.function)
    

In javascript, you can use objects as keys and ANY string including reserved
words, so long as they are wrapped in quotes.

[edit] I guess technically the keys are the result of the toString function of
the object used as a key so:

    
    
      x = {}
      x[[1,2,3]] = 'wtf'
      x.toSource() === "({'1,2,3':'wtf'})"

~~~
Zef
Alright. So now I want to iterate over all original keys, how do I do that
(i.e. their original values, not the stringified version)?

Plus, a random object (that doesn't have a meaningful toString method) will
probably result in something like "[object]" as a key, which would break when
you use more objects like that as keys.

~~~
teamonkey
> So now I want to iterate over all original keys, how do I do that

for(var key in obj) { if(obj.hasOwnProperty(key)) val = obj[key]; }

Or did I misunderstand the question?

~~~
kwamenum86
The key is now effectively '1,2,3' in the case [1,2,3] . You can iterate using
that string and even pass in the array using bracket notation. But when you
iterate using for..in the key will be a string not the original array, and you
lose that data. The string is now indistinguishable from the subset of strings
with comma delimkted data. May that is inconsequential in your app but for
some apps it dampens the effectiveness of the construct.

Ain't JavaScript a riot? [I just found an excuse to use snowclone in an HN
comment. Pats self on back]

Functions on the other hand work very well because the key is the function
definition (call toString on a function). There is no reason for two functions
to have the exact same definition in JavaScript.

------
docgnome
I was pretty much turned off by "At the very least it needs a de-facto
standard way of doing object-oriented programming, having the choice between
classical, prototypal, or, sure, why not lazy inheritance is not doing it for
me." Javascript has one way of doing oop. It's prototypal. You can fake
classical if you want but that doesn't negate the fact that the language
itself is still prototypal.

------
arantius
I find the fact that so many people decided to create their own "standard
libraries", even after so many others were available a strong statement for
the fact that one standard would be bad. Obviously, all these people had
reasons strong enough not to use the existing tools, wanted something so
different, that building it themselves, with all the effort involved, was a
better solution.

------
mhansen
Wishful thinking. We're always going to have older versions of Internet
Explorer that won't support any new JavaScript features.

~~~
bugs
This is the problem you have people that think they need to fully support
these older browsers and cripple their systems in the process. I really hope
the movement of upgrading browsers and furthering the web standards starts
happening more.

The real problem is that the internet has such a low barrier to entry because
of the way everything is setup, this is why when you call tech support for a
broken modem you have to go through thirty useless steps like is plugged in to
the wall is it plugged in to the computer, people are becoming helpless
towards new technology because we are letting them be helpless.

People have a very large ability to learn even when they are older, my
grandfather for example has learned how to use the computer to buy movie
tickets, buy plane tickets and check into flights, and keep in touch with the
family without any help from me or any other person in my family. Of course I
help him if he has an issue but the thing is he tries to solve the problem
himself and maybe once in 3 years I have had to help him with troubleshooting.

Contrast that with the facebook login debacle, people so frustrated and
helpless that they are posting on a blog post about how they don't understand
why they would change the login page that they don't realize they are on the
wrong site. This could be solved if they went to a class on how to use the web
or even a child or friend giving them a step by step paper guide on what to do
when you are looking for a site.

People learn by experience and the older generation of people that are just
now gaining access to the web, many still learning how to use a computer
properly, are finding difficulties with simplest of tasks for the rest of us
because they are pushed into shark infested waters with no direction or
guidance.

I think one of the main problems with the web is trying to appeal to every
market; this is why we have people fighting to support internet explorer 6 for
every website or app they create because they have to support that market to
be competitive and if nothing changes soon we will be stuck in a very slow
moving bubble.

------
kwamenum86
I would argue that Javascript has a standard way to build an object hierarchy.
It's just that people find it bitter and can't help but add some syntactic
sugar.

bitter:

myClass.prototype = new parentClass;

myClass.constructor = function(){...}

\---------------------------

sweet (relatively speaking):

myClass = Class({

    
    
        Extends: parentClass,
    
        initialize: function(){...}
    

})

~~~
Zef
That's what I use. But Douglas Crockford suggests using a different way of
building object hierarchies which he uses. I could ignore this, but Crockford
kinda is one of _the_ Javascript guys, who, supposedly knows what he's talking
about: <http://javascript.crockford.com/prototypal.html>

~~~
kwamenum86
Eh, I give Crockford all the respect in the world as one of thee js guys, but
I've always found that object function downright disgusting. I am still trying
to understand what advantages his prototypal toolbox has over his classical
one.

------
Zef
Maybe I wasn't clear enough in my post, but I said this:

> and the good thing is that it does not require any changes in the Javascript
> language itself, nor its browser support.

As far as I'm concerned it would be fine with a standard library in a file
(std.js, or base.js), that I would just include on every page, it does not
have to be implemented in the browser at all. Maybe on the long term, for
efficiency, but necessarily. Indeed, the nice thing about Javascript is that
it is flexible enough to do this "ourselves". So I would say the "but what
about IE" discussion is kind of irrelevant, unless there's some core
Javascript features it doesn't support that we absolutely need.

Let me briefly tell you where I'm coming from. A month or two ago I started
working on an O/R mapper for Javascript, built on top of the HTML5 SQL store
(<http://github.com/zefhemel/persistencejs>). I wanted this library to be
useable from any Javascript framework and supply an as "native" a Javascript
API as possible. There were two problems that I came across:

1) What is the proper way to do OO? I read "JS: The Good Parts", but it
discusses like 3 or 4 ways of implementing OO and variations on inheritance,
each having different advantages and disadvantages, either using the new
keyword or not etc. Personally I'm open to any OO style, just tell me which on
to use. There was no obvious answer. There's a bunch of frameworks that offer
utility objects to do inheritance "properly", do mixins etc., but I didn't
want to buy into any framework in particular. So eventually I went with the
constructor function (function MyObj() { }, new MyObj()) approach, manually
solving inheritance problems as I went along.

If there would be a style, possibly with some utilities of doing OOP in
Javascript that "everybody" would agree on, I wouldn't have had this problem.
I'd just say "ok, let's rely on this std.js/base.js and it's obvious how to do
it". Everybody would understand my code, because they'd use the same style as
well. Sure, it's a very powerful thing that we can do inheritance in 4
different ways, but it doesn't simplify communicating the fact that we're
trying to implement inheritance, or how to use a particular constructor
function (should I call new Bla() or just Bla()?).

2) I needed to implement the observable pattern, I need to respond to changes
in objects. Some JS frameworks contain an implementation of the observable
pattern, but I don't want to rely on any framework in particular, so what
should I do? I ended up implementing a lightweight one myself, which is
included in the library. A bit of a waste of effort, plus of code size when
somebody uses persistence.js together with another framework that also
contains an observable pattern implementation.

The observable pattern is another example of a construct that's common enough
to be in such a standard library. If we decide on a particular implementation,
we can all utilize it without being too dependent on larger frameworks. We
only have a dependency on the small standard library.

I'm currently working on a larger HTML/Javascript problem and there the
modularization problem popped up. I want to declare module dependency and have
them automatically be loaded. Again, Google Closure, Dojo and YUI provide ways
to implement this, but I have been using jQuery so far, should I switch or add
Dojo/Closure/YUI to my project, just to get the modularization features? That
seems a bit excessive.

If we would have agreed upon modularization features in a standard library
that all the frameworks used, I wouldn't have this problem.

------
thewileyone
Won't this just bloat the browser and cause 1) compatibility issues, and 2) a
new level of update hell?

------
GrandMasterBirt
Just had this SAME conversation with co-workers yesterday. Funny eh.

The fact is, while you chose Rhino to get access to Java libs and frameworks
for SSJS development, there is still NO WAY for me to write an open source JS
framework that will work in any environment. Not to mention anything I run
will probably have tons of different implementation of the same few bits of
code, not referring to common libraries for inclusion or whatever. Even how
files are included is different depending on your environment. We seriously
need a standard. Even if half of it is implemented in javascript like Java
Standard Libs are implemented in java (ok lots use java native interfacing).

------
howcool
Just use Dojo, problem solved

