Home » forums » LtU Forum

Holding onto JavaScript's past

I know I have made mention of this before, and I would like to thank many for making comments, espicially Dan Shappir. But I would like to throw an idea out to those of you, the many, that are smarter at this than I am. =)

The paper I have read concerning JavaScript 2.0 doesn't hold a lot of water with me; not necessarily because of the technical modifications being made, but because the future ECMA standard is leaning towards what is 'en-vogue' instead of sticking to what makes JS distinct. I do feel that JavaScript needs some changes, and I would like to ask the opinions of everyone as to what changes they see that need to happen, as well as listen to one of my own.

One change I would like to see JavaScript is the addition of being able to declare identifier's to be of a certain object type. I was always a fan of dynamic typing merely because I have always been bad at planning my code, so I always felt that static typing got in my way, and caused many edits in my code. I of course blamed this on the language, instead of what the real problem was... namely me, and my poor skills.

Although I see the benefits of typing, mainly for type checking. I do not think it is a panacea, and also think that JS's 'var' keyword provides a suitable syntax for declaring dynamic identifiers. Not to mention, 'var' can be implicit when an identifier is not declared, but instead immediately assigned.

This is just a thought I had run through my head, and over-all I think that it is a good idea. I would like to hear other's opinions concerning the problems with JS as well as my suggestion for a change in the semantics of JS.

Best Regards,

Mark

By mjstahl at 2004-07-05 04:58 | LtU Forum | previous forum topic | next forum topic | other blogs | 11980 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

My own take is...

...that JavaScript would benefit more from the W3C embracing forms processing in HTML. For whatever reason, we've been stuck on the same 10 form types now for nearly ten years (text, password, button, checkbox, radio, submit, reset, hidden, select, textarea). Why not expand the toolbox with some more modern form controls (combo-box, menus, popup menus, grids, etc...).

Personally I think it's a conspiracy in that the perpetrators don't want html forms to compete with their favorite son technologies like Java and .Net.

As for the JavaScript language itself, I'd like to see optional typing introduced at the function signature level. Won't allow static type checking per se, but it would force autoconversion, if applicable, or an exception if there's a parameter mismatch in the function call. As it stands, the functions have to do a bit of work to check the type when the parameters are received.

By Chris Rathman at Mon, 2004-07-05 07:01 | login or register to post comments

More on forms

Glad to see that I'm not the only one who sees a conspiracy to handcuff HTML forms.

By Chris Rathman at Tue, 2004-07-06 15:06 | login or register to post comments

Brendan Eich on Gillmor Gang

Audio Interview of Eich, Mozilla's chief architect. Eich also happens to be the creator of JavaScript - which ties this conversation back into the original question of JavaScript.

The main topic of conversation is the WHATWG effort. Though the topic is only tangentially related to PL, I do think it interesting to compare the question of incremental improvements versus start from scratch efforts. Should we go to the pristineness of XHTML/SVG/XForms, or should we go down the path of making a more approachable solution with HTML extensions. Some would consider HTML hopelessly borked and beyond redemption. Others would point out that it may not be perfect, but a lot of people are getting real things done with it. Seems like there's a lot of parellels in the PL world (C=>C++|Java vs. ....).

By Chris Rathman at Fri, 2004-07-09 20:02 | login or register to post comments

The paper I have read concern

The paper I have read concerning JavaScript 2.0 doesn't hold a lot of water with me;

Which paper is that?

By Anton van Straaten at Mon, 2004-07-05 15:57 | login or register to post comments

Re: The paper I have read concern

JavaScript 2.0: Evolving a Language for Evolving Systems
Waldemar Horwat

Link to PDF

By mjstahl at Mon, 2004-07-05 16:33 | login or register to post comments

JavaScript... selling out?

I found out about JavaScript 2.0 because of Flash MX 2004, which has a new version of ActionScript called ActionScript 2.0. The ActionScript language is almost exactly the same as JavaScript, which means that until recently it was prototype-based. ActionScript 2.0 tries to be just like JavaScript 2.0, so it has a "class" keyword, along with a lot of other Java-ish stuff like interfaces, privates, and "strong typing".

[Rant: What the folks at Macromedia refer to as "strong typing" is really a very minimal, optional static type system, which sits atop an otherwise weakly-typed language. Like JavaScript, ActionScript is full of automatic coercions between types such as strings and integers, which can be convenient but tend to bite you in the ass eventually. I'm a fan of strong, dynamic typing, or static typing with inference; I have little desire for a weak, slightly static type system.]

I guess the news of AS 2.0 was a bit of a disappointment; I've been impressed that a prototype-based OO language was able to fly under the radar and enjoy a moderate success for awhile, but it seems like JS is going the way of Java/C#, no doubt a result of Macromedia's push to get people writing more Remote Internet Applications ("RIAs", as they call them). They are trying to gain the respect of a more mature software development crowd, but to me it seems like they are just playing dress-up. The resemblance to Java, as always, is superficial.

On the plus side, at least the new JavaScript will make it easier to write modular code. The preferred way to structure JavaScript programs so that they can scale up in size has not been very well-defined. Hopefully with classes and imports this will get easier.

Aside from Flash, I don't know when to expect JavaScript 2.0 in the browsers. It doesn't seem like Microsoft is doing much with IE these days, but if Mozilla doesn't become wildly successful, we're stuck with the old versions of the languages that IE supports. No matter how cool JavaScript 2.0 might be, if it's not in the browsers, where is it? On the server side? It's got so many languages to compete with. I guess time will tell...

Does anyone know of any browsers that currently support all or part of JavaScript 2.0?

By Dave Benjamin at Wed, 2004-07-07 07:55 | login or register to post comments

RE: JavaScript... selling out?

Well concerning the support of JS 2.0 in browswers, I would definately have to say that is a long way off. The C implementation of JS (aka 'SpiderMonkey') resides at mozilla.org and hasn't even stabilized JS 1.5. So I believe this future rewrite of the standard is merely dictating a roadmap for the JS's future.

Although currently the lexer and parser support keywords like 'class', 'protected', 'private', etc... it currently is only used in JS's live connect code which allows it to instantiate Java objects.

Which brings up something interesting, but none the less, something I don't know if it is possible.

I was working on a JavaScript clone called 'Color', which was to be aimed at server-side web development, since I couldn't find a suitable mod_js for Apache. LiveConnect, and PerlConnect peeked my interest, and made me ask... "It can never be expected, or rather shouldn't be expected, that developers will flop to another language when the language is new, and unfounded... but that doesn't mean that the developers of this new language should suffer by making their code not interoperate with other server side dev languages. So would it be possible to do a PHP bridge, VB bridge, etc, etc?"

By mjstahl at Wed, 2004-07-07 15:54 | login or register to post comments