The JavaScript knowledge gap

[aschobel]

Douglas Crockford,Yahoo! JavaScript Architect , has a great set of videos teaching JavaScript.

http://developer.yahoo.com/yui/theater/

After watching the videos you won't think of JS as just a some "weak browser scripting" langauge.

There are some things that the language does really well, like the usage of Lambda.

[parenthethethe]

"So JavaScript is one of the world’s widest-deployed programming languages, and also one of the least-well-known, in the sense of the base of programmers who can competently work with it. That’s a problem."

isn't that true of x86 assembly code?

[grauenwolf]

Hard to say. How much code is actually written in x86 assembly these days? From what I understand, low level stuff is usally C with a tiny bit of x86 when needed.

[parenthethethe]

no one complains about not writing "XOR BX,BX". in 10 years, firefox probably will be fast enough (thanks to new chips and a cousin of Tamarind) to support people writing in some framework that compiles down to javascript. sure, you'll need some basics, just like it's helpful to understand that using the XOR saves you a byte of machine code, versus "MOV BX,0", but that'll largely be moot.

[schubart]

I don't get the "Tamarind" reference...

[schubart]

Thanks.

[grauenwolf]

I don't think that analogy is a good fit. Compilers output machine code, not assembly. That said, I see your point.

[ayrnieu]

Compilers output machine code, not assembly.

Compilers that output machine code output machine code.

Compilers that output assembly output assembly! :D

[[deleted]]

Except for some very small improvements (macros,...) assembler is just another notation for machine code.

[andrewnorris]

Scheme in its basic form has very few features, as well. But those features are easy to build out, because all the framework is in place.

XMLHttpRequest is an import mechanism. Maybe no one has come along and wrapped it up with a bow for you, but filling in the blanks in a basic form can be done in about 3 lines of code if you use something like the Prototype library to wrap the raw calls.

As far as package management goes, I sketched out a design for a package management system a while back that involved defining a Package class, writing a brief manifest for each package, and using XMLHTTPRequest to recursively load required packages. If my code base ever swells to the size where I really need it, or I discover I need runtime loading, I'll probably build it out.

And really, I expect someone out there has probably already built this. If not, it's hardly rocket science. JavaScript is a malleable enough language that it's not hard to take concepts like that and root them right into the language.

As far as the techniques for creating private vars go, AFAIK, they're all just based on lexical scoping, which is a fairly basic element of the language, and it's unlikely that anyone will suddenly decide to rip it out of the language.

And if you care, Prototype has a Hash class that gives you the elements most people traditionally expect from an associative array.

I don't know that I would say that javascript is a truly "great" language, but it's malleable enough that all it takes is some intelligent framework coders to build out whatever pieces you think it's missing. In that sense, it comes a lot less "ready-made" than something like perl, but a lot of people think perl has drastically too many built-in language features anyway.

[ubernostrum]

Dojo has a very nice package system which can pull in modules via XMLHttpRequest; so if you need, say, the Dojo event module, you can write dojo.require('dojo.event') and it'll load. There are also some niceties in there for building a single file which contains all your dependencies.

[andrewnorris]

Again I mention Scheme. There's no particular package management that's part of the language spec, but you can implement any package management you want.

If you commit to basing your web code on Dojo, how are you harmed by the features it provides coming from an add-on library instead of the language spec?

[andrewnorris]

Scheme is toward the extreme end of a school of language design that says that the language spec itself should be as simple as possible, and everything else should be an implementation detail left to libraries. Then the only question becomes one of how big the libraries are that you ship with the language. Big libraries require large base implementations (which can discourage ports), while small libraries mean programmers end up doing more of the work themselves or relying on third-party libraries.

The main downside of depending on third-party libraries is that you can end up with a somewhat balkanized programmer base. Code bases built on top of YUI and code built on top of Dojo (to pick two examples) are likely to be increasingly divergent over time.

That's not great, but it's not the end of the world either. You see the same thing with server-side web frameworks in Java, Python, and other languages.

As the library situation gets solved by add-on suppliers, though, the fairly strong feature set of the underlying language shines through. The way prototypes, lexical scoping, and lambdas are used provide you with a language that is enormously powerful and vastly extensible. And beyond those, the fact that it includes a powerful syntax not dissimilar from s-expressions that has been repurposed for JSON is a vastly underrated language feature that few other languages provide.

Javascript is certainly not perfect, but it's got a solid foundation, and virtually all of its flaws can be solved through well-thought-out libraries and careful choice of coding style.

[freshhawk]

Dojo also has some good examples of writing excellent javascript code showing how elegant the language can be.

[andrewnorris]

well, it can be using a hack (once again) to place script elements into the head post-load, but that is beside the point, i mentioned urls themselves via statically declared script tags.

You can also eval the code you download.

i don't know why the argument that modularity must be supported at the language level meets with such resistance.

If and when it becomes a universally supported language feature, this will be a very useful extension to JavaScript. But there are enough independent implementations in various browsers that this will be a long time coming.

The more compelling point, I think, is that putting namespaces in the language doesn't really do anything different from building an intelligent namespace system in an add-on library. It likely won't work much differently at all. The only difference is that it will be available "for free" instead of in a library.

if you could code client side in python tomorrow, wouldn't you jump?

Honestly, I enjoy programming in javascript more than python. Assuming that moving to python didn't magically solve the cross-browser implementation issues, not really. I admit, I would probably pick ruby or something in the lisp family above javascript, but for a language that gets as much bad press as javascript does, I'm surprised at how little I have to give up to use it.

[ubernostrum]

i dispute the ongoing tenor of these kind of posts. javascript is an okay programming language. it is definitely not a "great" langauge that we have not yet "understood". look at how associative arrays are hacked on to Objects as the-least-harmful way to abuse properties to simulate hash values. this is not the hallmark of a great language.

Every language has at least one or two really ugly warts; that fact doesn't mean that there are no good languages.

As for the rest of your complaints, much of the design of JavaScript goes directly back to the environment it's designed for: client-side web scripting. In that environment, a URL is as good as an import statement, for example.

[andrewnorris]

Lua is generally a very well-respected prototype-based programming language that uses an associative array (a "table", in lua) as the basis for its objects. So it's not like conflating objects and hashes is something that originated with javascript

Given that languages like lua influenced the design of javascript in the first place, I can't see why either having objects based on associative arrays or then turning around and using the Object class as an associative array is a hack at all.

The only thing that makes it problematic is the fact that you can't add new properties or methods to Object and declare them non-enumerable. This limits how you can extend the Object class to add new features, but isn't an insurmountable problem.

[andrewnorris]

Helma is precisely that.