Javascript: A Language in Search of a Standard Library and Module System | Hacker News Reader

Javascript: A Language in Search of a Standard Library and Module System

zef.me

50 pointssamstokes37 comments

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.

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.

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.

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.

To my mind, part of the point was that there's no standard way of importing additional libraries. Many modern languages have some sort of symbolic import statement that instructs the interpreter or compiler to add additional libraries to the execution context, but there's no single way of doing that from within JavaScript. Of course, that somewhat makes sense, as you don't want every random site making cross-domain imports and bypassing same-domain policies. At the same time, as the author demonstrates, you can have an agreed-upon API that provides much of the same functionality using XHR, which would make working with multiple libraries from different vendors a lot nicer.

Cross-domain is not really an issue here, its quite silly that I can't in JavaScript require one file on my domain from another file in my domain. Instead, people have spent countless hours trying to figure out "the right way" to have interdependent code that doesn't block through a synchronous XHR. Sometimes this has resulted in requiring build tools which turn imports into script tags, etc (which is frustrating for a language that shouldn't require building).

This is why Objective-J has @import:

    @import <Foundation/CPSet.j>
    @import <AppKit/CPView.j>

    alert(CPView);

What's really upsetting is that we're getting the first update to JavaScript in like 10 years, and these fundamental concerns are still not being addressed. Instead of saying "what can give us the next generation of web apps", we've dropped the with keyword. Objective-J was really designed as "man, these features should have been in here ages ago". @import allows you to require code without a build step, without downloading or running twice, and still having it all take place asynchronously so that we don't block on some slow file.

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!

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.

Three cheers for the mixed economy!

C++, Java, C#, even common lisp programmers are socialists then? And hey, JavaScript is a standard too. Does this mean JavaScript is the tool of socialists?

I personally consider it actually funny how the notions of socialism and capitalism are used by some posters on this website as if we still had 1970 or something. How old are you?

While josh33's point about politics was pretty inane, there is indeed danger in picking one framework as the "standard". Imagine if C++ adopted Qt as the standard, leaving WxWidgets, Ultimate++ and others in the lurch. I think this would be the proper analogy to the proposal of pulling jQuery into the JavaScript standard.

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.

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.

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.

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.

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.)

In my post I link to JSAN, which is exactly that: http://openjsan.org

It has its own module system.

At the time I created that library, JSAN was a dead site. There were rumors that it would be revived some day, but it hadn't happened.

  >> 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.

"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'})"

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.

Yeah agreed. The edit was intended to concede that your statement about only being able to use strings was technically correct and mine about using objects was misguided :)

One good use case for objects as keys in hashes is functions. When you use a function as a key it is reliably converted to its definition, cross-browser. Doesn't make your point any less valid though.

> 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?

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.

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.

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.

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

This is why everyone is still coding to within the limits of NCSA Mosaic 0.8b?

Or, could be that though change can sometimes seem painfully slow for people who have to support every browser under the Sun, things do change over time. Without people pushing the standards forward we wouldn't even have javascript, let alone XHR, let alone CSS 2, or proper PNG support. Standards should evolve. It's not wishful thinking, it's forward thinking. Perhaps on a longer timetable than you're used to dealing with but unless you enjoy the limitations of HTML 1.0 then you need to thank every single person who had the foresight and expended the requisite elbow grease to push the standards forward. The surest route to defeat is to surrender.

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.

Nobody is forcing web developers to deliver equivalent experiences on older versions of Internet Explorer. Look at your statistics and make an informed decision about what you should care about. You may not have to care about anything but IE8. Or you may be able to deliver a simplified style-sheet and JavaScript to IE7 and below. Encourage your users to upgrade.

People have overreacted to the bad practices prevalent 15 years ago. "This site requires Internet Explorer," was folly, but so is, "This site looks and works exactly the same on everything from IE6 to the latest WebKit build." The former lets you build cool stuff but limits your audience, the latter keeps you from building cool stuff.

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(){...}

})

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

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.

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.

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

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).

Just use Dojo, problem solved

Reply on news.ycombinator.com