Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Web 2.0, Meet JavaScript 2.0

ScuttleMonkey posted more than 6 years ago | from the just-plain-geeked dept.

Programming 248

Jeremy Martin writes "Well I suppose it's an undeniable fact about us programmer-types — every now and then we just can't help but get excited about something really nerdy. For me right now, that is definitely JavaScript 2.0. I was just taking a look at the proposed specifications and I am really, truly excited about what we have coming."

Sorry! There are no comments related to the filter you selected.

v2.0 (1, Funny)

Methlin (604355) | more than 6 years ago | (#22824712)

Does it have 33% more bugs than v1.5?

Re:v2.0 (1)

hedwards (940851) | more than 6 years ago | (#22824784)

That was basically my thought. JavaScript has sucked so badly for so long.

I have a hard time imagining this as something that is actually going to be used in cases where there's another option available.

It definitely looks like a step in the right direction, but until I don't have to choose between worrying about browser specifics or being overly limited, I'll remain skeptical.

Re:v2.0 (4, Insightful)

snl2587 (1177409) | more than 6 years ago | (#22824996)

I have a hard time imagining this as something that is actually going to be used in cases where there's another option available.

I can. Javascript makes it really quick to hack together a dynamic page. Sure, it results in spaghetti code and the resulting HTML tends to be out of standard, but people will keep using Javascript as long as it remains so damn easy.

Re:v2.0 (5, Insightful)

RCanine (847446) | more than 6 years ago | (#22825018)

Stop thinking about JavaScript as a Internet language. JavaScript and HTML rendering engines are all over the place now: Firefox Extensions, Thunderbird/Sunbird/Songbird, Dashboard, Adobe Air, Acrobat, the Wii, the iPhone...updates to JavaScript are not useful for the public Web, but are incredibly useful for highly-targeted platforms.

Re:v2.0 (1)

TheWanderingHermit (513872) | more than 6 years ago | (#22825194)

I'll go even farther. JavaScript has not only always sucked, but should be replaced with something closer to a real language.

I'd love to see JavaScript outdated or made obsolete by a real language each browser could understand.

Re:v2.0 (2, Insightful)

Anonymous Coward | more than 6 years ago | (#22825292)

A poor workman blames his tools. DOM incompatibilities will exist even if every browser supported a "real" language (maybe you should just stick to internet explorer and VBScript).

Re:v2.0 (3, Insightful)

bnenning (58349) | more than 6 years ago | (#22825688)

Javascript is a decent language by itself. It's the obtuse DOM and the eleventy billion browser incompatibilities that make it appear to suck; no language could look good under those conditions.

Re:v2.0 (5, Funny)

smitty_one_each (243267) | more than 6 years ago | (#22825082)

That depends. http://en.wikipedia.org/wiki/ECMA_Script [wikipedia.org] is on version four.
To paraphrase Palmerston:

only three people ever understood the Java* numbering schemes: a German professor, who went mad, Prince Albert, who died, and Larry Wall - who, asked to come up with something, promptly wrote a perl script and forgot it.

Re:v2.0 (0)

Anonymous Coward | more than 6 years ago | (#22825452)

Javascript is the one language which has been fscked up more by Microsoft than any other. I love working with Javascript *proper*, but the problem you come across all the time is that you have to defer to the lowest common denominator because the most common language platform (Internet exploder) sucks UNBELIEVABLY!!! It makes me sick to see M$ harping on about CSS and Acid2 in IE's 7&8 when their javascript implementation is as slow, old and crap now as it has been for the last 5 years (at least).

Re:v2.0 (1)

Garridan (597129) | more than 6 years ago | (#22825518)

You haven't tried to support Konqueror and Opera, have you?

Meh. (0, Troll)

Anonymous Coward | more than 6 years ago | (#22824718)

Not really exciting.

I've been playing around with Silverlight though, now THAT's where the future lies. You get the majority of the .NET framework on the client side. Doesn't get much better than that.

Re:Meh. (5, Interesting)

Timothy Brownawell (627747) | more than 6 years ago | (#22824900)

The main problem is that given MicroSoft's history, I'm not sure I trust it. Who's to say they won't try to use it to somehow force people to their proprietary stuff?

Re:Meh. (4, Interesting)

Embedded2004 (789698) | more than 6 years ago | (#22824930)

Heh. Silverlight is proprietary in it's entirety is it not? Microsoft hasn't released any patents they hold on .net/C# have they?

Re:Meh. (0)

Anonymous Coward | more than 6 years ago | (#22824906)

What about the 5% of us that don't use Microsoft?

Re:Meh. (2, Funny)

netsavior (627338) | more than 6 years ago | (#22825048)

it works 95% of the time, every time.

Yes (1, Funny)

Anonymous Coward | more than 6 years ago | (#22824730)

Yes, we are nerds. But do you really have to rub it in?

Sounds awesome, (1)

elloGov (1217998) | more than 6 years ago | (#22824738)

but what about more meaningful(detailed) errors?

Re:Sounds awesome, (4, Informative)

cheater512 (783349) | more than 6 years ago | (#22825076)

Use the error console in Firefox/Seamonkey. Very specific errors.
Seamonkey even has a javascript debugger.

If your using IE, well then *snigger* your screwed. ;)

Ugh (5, Insightful)

TheRaven64 (641858) | more than 6 years ago | (#22824756)

Introducing classes for all of the Java programmers who can't understand a Self-like language. Great addition. Fixing the constructor syntax would have been nice, but introducing classes into a prototype-based language just doesn't make sense. Traits objects already do the same thing and a prototype style is much better suited to JavaScript's primary role, namely defining interfaces (look at some of the papers published by the Newton team in the '90s).

Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command.

All of the proposed changes are a step backwards. JavaScript is currently a language with great, clean, semantics and slightly ugly syntax. They want to make the semantics less clean and the syntax even more horrendous.

Re:Ugh (4, Funny)

mrbluze (1034940) | more than 6 years ago | (#22824976)

All of the proposed changes are a step backwards. JavaScript is currently a language with great, clean, semantics and slightly ugly syntax. They want to make the semantics less clean and the syntax even more horrendous.

But wait until Sunday and we'll hear that Javascript 2.0 has arisen and all the stains of previous imperfect languages will be taken away.

Re:Ugh (1)

mortonda (5175) | more than 6 years ago | (#22825484)

If that means Java will be thrown into the fiery pit, count me in!

Re:Ugh (1)

Curien (267780) | more than 6 years ago | (#22825050)

Javascript has always had overloaded operators. Or do you really think that string concatenation and arithmetic are similar operations?

Re:Ugh (2, Informative)

Paradise Pete (33184) | more than 6 years ago | (#22825178)

Javascript has always had overloaded operators. Or do you really think that string concatenation and arithmetic are similar operations?

User-defined overloading, obviously. And it's considered by some to be a bad idea. [elharo.com]

Re:Ugh (5, Insightful)

Curien (267780) | more than 6 years ago | (#22825320)

User-defined overloading, obviously.

Grand-parent gave an example of built-in operator overloading, not user-defined operator overloading. So no, it isn't "obvious" that he means user-defined operator overloading.

From the linked-to article:
Features that are guaranteed to be misused should be eliminated.

What a load of utter bollocks! Show me a feature that cannot be misused, and I'll show you a feature that isn't terribly useful.

If you dont know the difference between a group, a ring, and a field, you have no business overloading operators.

What an arrogant asshole! That's as non-sensical as an assertion that only parents have any business creating class hierarchies.

Re:Ugh (1, Interesting)

Paradise Pete (33184) | more than 6 years ago | (#22825352)

What a load of utter bollocks! Show me a feature that cannot be misused, and I'll show you a feature that isn't terribly useful.

He said guaranteed, not could, which carries quite a different meaning. But go ahead and post your thoughts there. Perhaps he might expand on it.

Re:Ugh (1)

Curien (267780) | more than 6 years ago | (#22825438)

He said the feature is "guaranteed to be misused". This has two possible meanings:
1. The feature will be misused every single time. There is NO POSSIBLE correct use.
2. The feature will be misused at least once.

Meaning 1 is completely indefensible, and the author doesn't even make an effort at substantiating it. He provides exactly one example of misuse. Chances that meaning 1 were intended: slim to none.

Meaning 2, on the other hand, actually fits with the rest of the article.

As the number of uses of a feature increases, the chance of a misusable feature actually being misused approaches unity. Therefore, any feature which CAN be misused, WILL be misused eventually. QED.

Keep 'em coming. We're on a roll.

Re:Ugh (0, Offtopic)

Paradise Pete (33184) | more than 6 years ago | (#22825836)

Never mind. It's clear that it's important to you that you need to find a way to interpret things in such a way as that somehow you are not wrong. I'll bet that comes up a lot in your life.

Re:Ugh (0, Offtopic)

Curien (267780) | more than 6 years ago | (#22825902)

It's better than resorting to insults when you can't come up with a cogent argument.

Re:Ugh (1)

odourpreventer (898853) | more than 6 years ago | (#22826042)

And it's considered by some to be a bad idea.

If you'd bothered to read the comments on that page, you would've seen plenty of examples why operator overloading is a good thing.

It's amusing seeing Java fanbois whining about operator overloading being a "bad idea", since Java is already riddled with shitty implementations. Just look at containers, for example.

Re:Ugh (2, Insightful)

MikeBabcock (65886) | more than 6 years ago | (#22825056)

Wake me up when JavaScript isn't taking the same bad trip down bloat ware lane that VisualBasic did back in the day.

Re:Ugh (1)

modmans2ndcoming (929661) | more than 6 years ago | (#22826098)

huh? you mean Javascript and VBscript are different?

I think thats the point. (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#22825262)

Most javascript is written by developers that are not using self like languages on the back end. Making the two more similar should allow more developers to write more complex javascript.

And in my book having more javascript is the huge step backwards.

Re:Ugh (5, Insightful)

SanityInAnarchy (655584) | more than 6 years ago | (#22825408)

Introducing classes for all of the Java programmers who can't understand a Self-like language.

I do agree with you there -- we don't need classes. And if we did, we could implement them, in JavaScript.

Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command.

If you really, really want to, then yes. But that it can be abused doesn't strike me as a serious reason for not including it.

I had a problem awhile ago. It was developing for HD-DVD, meaning we didn't have full JavaScript -- meaning I couldn't, say, extend Array. Even if I could, I'm not sure how much better I could make this... I had created a control for displaying a scrolling menu of widgets of some kind. The point is, the control itself shouldn't care about what those widgets are, or even that it's operating on something that's actually an array. It would've been nice to let it work with an array for now, knowing I could always roll something that pretends to be an array later.

Instead, what I ended up doing was wrapping the Array in a monstrosity which contained methods like getValue(), setValue(), etc. It was hideously ugly, but it would tend to work, and would even automatically wrap an Array if needed.

But it's ugly hacks like that which drove me away from Java in the first place. I'd rather duck-type it properly, like I do in Ruby. If it claims to have a working [] operator, and has methods like size() or length(), either it's an array, or it's pretending to be one, so treat it like an array.

Or as James Gosling is supposed to have said... (1)

weston (16146) | more than 6 years ago | (#22825466)

Q: "If you could do Java over again, what would you change?"
James Gosling: "I'd leave out classes!"

The functional/prototype hybrid in Javascript was a little odd and hard to get used to, but once I did, I've found I like it better than a Class model. Interface/implementation works for me too, but especially in Javascript, I never feel like I really need that fancy keywords to get that done.

There's an awful lot of serious work in the Java community, but I sometimes feel like a lot of *common* practices have evolved because people condensed "best practices" into a formula without disseminating the principles behind them, and it's ended up becoming a lot of busywork. Now it's filtering out to languages like PHP and Javascript that apparently want to grow up to be like Java.

I take some comfort in the fact that there will almost certainly have to be a backward compatibility layer for a long time. And I like the idea of units and constants and namespaces. But I'm not sure this is Javascript anymore, and I'm pretty certain it's not a step forward for the language.

Re:Ugh (1)

free space (13714) | more than 6 years ago | (#22825834)

... a prototype style is much better suited to JavaScript's primary role, namely defining interfaces (look at some of the papers published by the Newton team in the '90s).

I'm interested! Care to point to any patricular papers? Thanks in advance.

Re:Ugh (1)

TheRaven64 (641858) | more than 6 years ago | (#22825906)

This one [waltersmith.us] was published in 2005, so it's a bit later, but it's still worth reading.

Re:Ugh (1)

odourpreventer (898853) | more than 6 years ago | (#22825926)

now you can enjoy C++ style code, where left shift and print are the same command.

Why would

print("astring" + "anotherstring" + "thirdstring");

be better than

cout << "astring" << "anotherstring" << "thirdstring";

?

Semantically, they're both equally bad.

Re:Ugh (1)

nuzak (959558) | more than 6 years ago | (#22826114)

> introducing classes into a prototype-based language just doesn't make sense.

That's fine, sounds to me like they're throwing away the prototype part. Bastards.

> Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command.

Yes, because of course that's mandatory. God forbid that anyone be allowed to express a thought not approved of for the original datatypes hardwired into the language. Seriously, do you actually consider this argument valid? I guarantee the people actually designing languages and actually, you know, accomplishing something don't.

Cross-Browser (3, Insightful)

Anonymous Coward | more than 6 years ago | (#22824762)

These new features are nice and all, but what I really want as a Web developer is for a Javascript standard thorough and widespread enough that I can write scripts that work on most browsers without a bunch of hacks to make sure that each browser gets the right code. Anyone have a prognosis on this?

javascript or DOM/etc.? (1)

Animaether (411575) | more than 6 years ago | (#22824826)

just curious.. are you referring to actual differences in how javascript is handled, or in how things like DOM access/structure (page layout scripting and such) are handled per browser?

The latter having nothing to do with the actual javascript syntax, semantics... i.e. the language

Re:Cross-Browser (1)

Curien (267780) | more than 6 years ago | (#22825062)

Your comments are nice and all, but what I really want is coders who actually understand the difference between a language and a run-time environment.

I write CLI programs in Javascript, you insensitive clod!

Re:Cross-Browser (1)

Daengbo (523424) | more than 6 years ago | (#22825480)

Why? You just made my brain bleed!

Re:Cross-Browser (2, Interesting)

Curien (267780) | more than 6 years ago | (#22825802)

Because by default, Windows 2K/XP comes with three scripting languages: cmd.exe (useful, but not COM-enabled), VBScript, and Javascript (well, technically it's "JScript", which is Microsoft's embraced and extended version of Javascript). I'd sooner scratch out my eyes than use VBScript for anything longer than five lines, so Javascript it is.

For example, some corporate environments think that disabling all the programs in system32 to be a "security feature"... which means you can't do things like fix corrupt registry entries in your own HKCU hive! So I wrote a command-line registry editor (similar to reg.exe) in Javascript+WSH+WMI. I also used it to write a little utility that basically replicated the remote installation feature of SMS. Except mine doesn't break all the fucking time on networks that aren't always up (SMS server was separated from all the clients by a TACLANE that's only brought up as-needed).

Oh, and I wrote a DB app in Javascript that just happened to use a browser for a GUI (but there was no webserver middle-ware). Again, mostly because I loathe anything VB-related (such as VBA usually used to script Access). See http://www.kuro5hin.org/story/2005/7/14/13942/7643 [kuro5hin.org] .

Re:Cross-Browser (0)

Anonymous Coward | more than 6 years ago | (#22825304)

Yo! You might want to think b4 posting:

Javascript != DOM

sorry buddy but you win a sign today...

Re:Cross-Browser (4, Informative)

stephanruby (542433) | more than 6 years ago | (#22825436)

These new features are nice and all, but what I really want as a Web developer is for a Javascript standard thorough and widespread enough that I can write scripts that work on most browsers without a bunch of hacks to make sure that each browser gets the right code. Anyone have a prognosis on this?
You mean this [haxe.org] ? An (almost) universal metalanguage that generates the right Javascript/Actionscript/Neko scripts for different environments.

Re:Cross-Browser (1)

Hao Wu (652581) | more than 6 years ago | (#22825768)

You're not still developing for Netscape 4 are you? I get more serious problems with different CSS versions than any Javascript issues.

Not defending it, but why were "layers" so different than the now standard "z-index"? People were strangely hostile to them.

JavaScript 2.0, Meet NoScript 2.0 (4, Funny)

imtheguru (625011) | more than 6 years ago | (#22824772)

... soon.

Re:JavaScript 2.0, Meet NoScript 2.0 (1)

electrosoccertux (874415) | more than 6 years ago | (#22826148)

This just made me think of how annoying it was for noscript to update every single day it seems (well having to deal with it on 3 machines and multiple OS installs on each doesn't help), almost just to make that darn tab open up after update and direct me to the noscript page (so I can click ads maybe for revenue? Who knows).

You can disable that new tab that gets opened after every update by opening a new tab to about:config and searching for

noscript.firstrunredirection
and setting to false.

Just wanted to put that out there in case nobody thought of searching the about:config for something to let you turn off that pesky new tab every time it updates.

Javascript (2, Funny)

Anonymous Coward | more than 6 years ago | (#22824774)

alert("keep it simple");

JavaScript changing into Java (4, Insightful)

Frans Faase (648933) | more than 6 years ago | (#22824800)

I am getting the impression that JavaScript 2.0 is slowly heading into the direction of Java by adding all those new features. I would not be surprised if the next step will be "pre-compiled" script modules, just like the Java .class files. Adding features to an already existing language is not always making a language better.

JavaScript changing into Python (4, Interesting)

xant (99438) | more than 6 years ago | (#22825374)

Actually, if you consider Python to be the opposite of Java (and I very nearly do), just the opposite is happening. Because Javascript is changing into Python, and this makes me happy.

There are indeed many Java-y features being added, such as "use unit" and classes, but these are also Python features. The one feature I saw from the article that looked distinctly Java-ish was static type checking at compile time, and Python will have something similar by the time JS 2.0 is generally usable (i.e. both are optional).

Features in nearer-term versions of JS are even more obviously Pythonic, though. Generators and tuple unpacking, for example.

I'll lay my cards on the table and say that I think Java makes programming laborious and unpleasant, and Python does just the opposite. These features don't seem to make JS any more programmer-unfriendly, and they add a lot, so I'm looking forward to Pythonic JS 2.0.

Re:JavaScript changing into Python (1)

nuzak (959558) | more than 6 years ago | (#22826222)

The one feature I saw from the article that looked distinctly Java-ish was static type checking at compile time, and Python will have something similar by the time JS 2.0 is generally usable (i.e. both are optional).

Unless you're talking about PyPy, it won't. It sure doesn't in 3.0, which added type annotations that only work on functions and methods. And these annotations? They don't actually do anything at all.

As long as I got my Framework (2)

DigitalisAkujin (846133) | more than 6 years ago | (#22824832)

As long as I can keep using Prototype as a framework I'll be happy.

As for specific features. I'm looking forward to cleaner and easier to manager asyncronous AJAX. While the client requesting from server has been well thought out, the server sending to the client is still very patchy and not particularly easy to develop for.

It would be nice if I could create socket connections with AJAX to say IRC but still go over HTTP proxy.

I'd also like to see AJAX file uploads that don't have to run through Flash. I think FF3 supports this already.

Re:As long as I got my Framework (4, Interesting)

SeanTobin (138474) | more than 6 years ago | (#22824978)

FYI, I've done ajax file uploads using jQuery. Works in IE6/7 and FF2/3. See jQuery [jquery.com] and the jQuery form plugin [malsup.com] .

Re:As long as I got my Framework (1)

DigitalisAkujin (846133) | more than 6 years ago | (#22825010)

Oh sorry I forgot to mention. Ability to track the status of the file upload would be a requirement. At the moment Flash is the only thing that supports it.

Re:As long as I got my Framework (2, Informative)

larry bagina (561269) | more than 6 years ago | (#22825378)

you can track the status.

Use a perl (or some other language that handles everything manually*) script to receive the upload submission and write it to disk in a known location with a known name*. A second script can then compare the file size as it's uploading. Somewhat ugly

* PHP won't work since file uploading is handled behind the scenes.
** this may involve storing statistics in a database, manipulating session data, etc.

Re:As long as I got my Framework (0)

Anonymous Coward | more than 6 years ago | (#22825114)

Using an iframe doesn't count as ajax, by any stretch of the imagination.

Re:As long as I got my Framework (1, Funny)

Anonymous Coward | more than 6 years ago | (#22825628)

asyncronous AJAX
Maybe you should use synchronous AJAX instead. Oh, wait...

Javascript 2.0, usable by 2015... (5, Insightful)

curunir (98273) | more than 6 years ago | (#22824862)

It's all well and good that there's new language features spec'd out, but JavaScript, at least its most common usage (web client-side) has the distinct disadvantage of lowest-common-denominator. Yes, you have JavaScript 2.0 in all it's less-horrbily-broken splendor, and you may even get Mozilla, Opera, Safari to implement it mostly correctly reasonably soon. Hell, you might even get Microsoft to include a halfway-compliant version in IE 8 or 9 (complete with a few proprietary extensions). But you'll still need to support IE 6 for a year or so and then IE 7 support will be necessary until at least 2012.

By the time JavaScript 2.0 is available in nearly all browsers you find in the wild, there will already be a JavaScipt 4.0 spec out and you'll be able to write this exact comment with the dates and browser versions updated.

The point being that client-side programming is a complete mess right now. Instead of new versions of scripting languages, we should be pushing browser makers to allow scripting to be installed via plug-ins rather than being native to the browser. That way, a website can trigger the user to update to the latest version of the language spec (ala the much-maligned-here flash plugin). That should also allow website authors to use any language, not just JavaScript. After all, if you're developing your site in RoR, wouldn't it be easier to use Ruby for the client-side scripting as well as the server-side? The same would go for Python, Perl, PHP (/me shudders) or even Java/Groovy.

But as long as we are beholden to the browser manufacturers to release updates of their browsers in a timely and compliant manner, we'll be stuck in this cycle where we can't use the latest-and-greatest features until they're no longer latest-and-greatest.

Re:Javascript 2.0, usable by 2015... (0)

Anonymous Coward | more than 6 years ago | (#22824932)

How dare you make so much sense?!

Re:Javascript 2.0, usable by 2015... (1)

cmburns69 (169686) | more than 6 years ago | (#22825100)

What you wish WAS available for previous versions of IE. PerlScript [wikipedia.org] was one scripting language that made use of the technology. The technology behind it has been deprecated in favor of .NET. The technology is available, but your users won't (or aren't allowed) to download the plugin just to see your site. At least with the lowest-common-denominator strategy we have now, you can build fairly robust sites. I fear the world you describe where I have to ask my users to install my specific language plugin before my site will work.

Re:Javascript 2.0, usable by 2015... (2, Interesting)

maxume (22995) | more than 6 years ago | (#22825200)

Mozilla has a project underway to make a plug-in run javascript 2.0 inside of IE:

http://wiki.mozilla.org/Tamarin:ScreamingMonkey [mozilla.org]

Re:Javascript 2.0, usable by 2015... (0)

Anonymous Coward | more than 6 years ago | (#22825266)

IE 7 support will be necessary until at least 2012
... and then the world will be destroyed by an ancient Mayan god, rendering support unnecessary.

Don't forget about ECMAScript and Actionscript! (2, Informative)

jinushaun (397145) | more than 6 years ago | (#22825278)

For those who didn't RTFA, it should be noted that Javascript 2.0 is actually ECMAScript 4.0 (ES4). Even if IE9 and FF4 supported ES4 completely, we'll still have to develop for the legacy browsers! Oy vey! Such is the life of a front-end web developer!

That being said, Flash Actionscript 3.0 (available now) includes many of the new features found in ES4 such as real classes. The next version of Actionscript will most likely be ES4-compliant.

Notable features in ES4 include:
- Classes and interfaces
- Generics
- Packages and namespaces
- Compile-time type checking
- Constants
- Operator overloading
- Record types (i.e., structs or light-weight classes)
- Typed arrays and hash maps
- Iterators
- Exceptions

More info: http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]

Re:Don't forget about ECMAScript and Actionscript! (1)

modmans2ndcoming (929661) | more than 6 years ago | (#22826146)

Flash actionscript is an abysmal joke.

Re:Javascript 2.0, usable by 2015... (1)

AttillaTheNun (618721) | more than 6 years ago | (#22825456)

Any reason this couldn't be done today (at least for Firefox)? I'm not too familiar with the Firefox architecture - could one write a Python interpreter plug-in, for example, that would have sufficient integration with the browser to replace Javascript?

All it would take is one example to set the bar for others to follow.

Re:Javascript 2.0, usable by 2015... (1)

tknd (979052) | more than 6 years ago | (#22825622)

Instead of new versions of scripting languages, we should be pushing browser makers to allow scripting to be installed via plug-ins rather than being native to the browser.

I'm afraid of this idea. Partly because it reminds me of Java applets and Flash.

Re:Javascript 2.0, usable by 2015... (1)

VGPowerlord (621254) | more than 6 years ago | (#22825640)

Wait, wait, wait, you're advocating that an indeterminate number of possibly incompatible versions of an indeterminate number of interpreters would be less messy that the six or so versions of one interpreter we have now?

Thanks, but no thanks.

Here's the short list of potential problems with that:
  1. Each interpreter needs a partial or complete standard library.
  2. Each interpreter needs to be sandboxed or have potentially dangerous functions modified or removed.
  3. Each interpreter needs to have DOM support added to it.
  4. Each browser needs a way of adding media types for supported scripting engines.
  5. For that matter, each scripting engine needs an IANA assigned media type if it doesn't already have one. Java, Perl, PHP, Python, and Ruby are all missing from the application media type list [iana.org] .

I'm sure I can list more if I stopped to think about it.

Re:Javascript 2.0, usable by 2015... (1)

Hatta (162192) | more than 6 years ago | (#22825642)

How about we push all the code execution back onto the server where it belongs?

Re:Javascript 2.0, usable by 2015... (1)

metachimp (456723) | more than 6 years ago | (#22826012)

How would a server know how to appropriately position an element on a page if all the processing was put back on the server?

Javascript - the guaranteed backdoor (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22824872)

The only people who can get excited about a "new" javascript are those who really don't understand computers.

Sorry, but javascript programmers are in the same league as the Webmonkeys of the dot-com era. They aren't real programmers. Real programmers don't deliberately implement broken systems. Instead, they fix them if they are using them.

I don't mean to sound trollish here. But that's how I view javascript technology.

why won't javascript die already? (1)

spiffmastercow (1001386) | more than 6 years ago | (#22824876)

Okay, look... Javascript isn't horrible for static pages. But sometime in the mid to late 90's the server side of things started taking a lot more importance, and javascript was not really suited to deal with this. Sure, it could be hacked to work. We now even have standard methods for implementing this horrible solution in ways that only occasionally make web developers want to pull their hair out. But really, when I think about what's involved in web programming, we have: 1.) A markup language for the layout of the pages (XML, HTML, DHTML, etc.) 2.) A language to manipulate that markup on the client side (javascript) 3.) A language to manipulate that markup (and the client language code) on the server side (PHP, ASP.NET, Ruby, etc.) 4.) (usually) a database language (SQL) Can't we eliminate at least one of those? I really feel like we should have the same language running on the server as on the client. I personally would prefer python, but I don't really care what language it is. I'm just tired of the inconsistency.

Re:why won't javascript die already? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22825068)

I really feel like we should have the same language running on the server as on the client. I personally would prefer python, but I don't really care what language it is. I'm just tired of the inconsistency.


Time for a slashdot car analogy.

On the roads, we have motorbikes, cars and 18 wheeler trucks. I don't care which one we all use, as long as we eliminate 2. I'm tired of the inconsistency.

The fact of the matter is SQL would suck at manipulating the dom on the client. Javascript would suck as a language to query a database. Server side scripting (php, python etc) could be hacked to natively query a database or manipulate the browsers dom, but it would be ugly AND require support from every browser. I hardly think IE is likely to natively support python.

We have different tools for different jobs, this is for a reason.

Re:why won't javascript die already? (1)

Lennie (16154) | more than 6 years ago | (#22825144)

Yes you can, it's the database. :-)

Re:why won't javascript die already? (1)

ramone1234 (588375) | more than 6 years ago | (#22825538)

While it's hard to disagree that python would be ideal for both client-side and server-side, I think you probably realize that realistically that's not going to happen anytime soon. With that said, there certainly is the possibility to use javascript on both ends, via server-side options like jaxer ( http://www.aptana.com/jaxer [aptana.com] ), helma ( http://dev.helma.org/ [helma.org] ), or maybe even JScript.net if you're stuck on windows.

I think you'll find that this latest version (2.0) of javascript is very pythonic, with its array comprehensions that are a lot like Python's list comprehensions.

As an aside, you're not still writing SQL queries are you? Almost every web dev platform out there has that abstracted nowadays... SQLAlchemy is a great choice for python...

Re:why won't javascript die already? (1)

Kashra (1109287) | more than 6 years ago | (#22825860)

Servers and clients do different things with the data. It makes sense that different languages would be employed on either side.

Re:why won't javascript die already? (1)

modmans2ndcoming (929661) | more than 6 years ago | (#22826168)

Sounds like you need a good healthy dose of Silverlight 2.0

"Program Units" - potential for misuse (3, Interesting)

willy_me (212994) | more than 6 years ago | (#22824904)

Reading the article I found "Program Units" to be interesting. Most importantly, how does the running program know that the downloaded script is safe? At first glance it appears that one could easily inject malicious script via a man in the middle attack. Now I'm sure that the designers have thought about this so my question is, how does JavaScript 2.0 protect against this?

William

Re:"Program Units" - potential for misuse (2, Insightful)

smallfries (601545) | more than 6 years ago | (#22825668)

This would be a complete non-problem. If you could inject a malicious script then you could replace the original rather than a script downloaded on demand. It's not secure against a man-in-the-middle because downloading and running non-authenticated scripts off the web is not secure anyway. Given that you could hijack the original script, why try and hijack one of the sub-units?

js should be shot (1)

tute666 (688551) | more than 6 years ago | (#22824934)

Yet another example of buggy/horrible technology which has prevailed due to backwards compatibility. The future should be browsers that can be extended with various scripting languages.

Is writing Evil Javascript still supported? (2, Insightful)

billstewart (78916) | more than 6 years ago | (#22824958)

I've really disliked Javascript since Netscape 2.0 or thereabouts. The problem isn't that you can't write perfectly good safe Javascript; it apparently works quite well for some things. The problem is that unlike Java, you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript. So if I leave Javascript turned on, because there are sites that require me to use their Javascript to do the things I want to do there, my browser's open to Evil Javascript on other sites, plus there's enough Bad Javascript out there that after I've done enough browsing, Firefox is burning most of my CPU on leftover broken cruft that I have to kill it.


Yes, I'm aware of NoScript and similar add-ons, and I'm happily using them. That helps, but there's still too much bad and ugly stuff out there to be happy about anything good that JS can do.

Re:Is writing Evil Javascript still supported? (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#22825312)

Sorry I don't have mod points. Its just scary to ready other people's javascript on sites. I respect the google app level of javascript, but it seems like js is used far too often to do add nothing to the usability of a site.

Re:Is writing Evil Javascript still supported? (1)

ubernostrum (219442) | more than 6 years ago | (#22825476)

The problem is that unlike Java, you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript.

I took that as a challenge, and in just under a minute I had an implementation of the naive (exponential performance) Fibonacci algorithm in Java, and told it to spit out the first 1000 Fibonacci numbers. It's sucking CPU like there's no tomorrow. Were you under the impression that Java couldn't do that?

Re:Is writing Evil Javascript still supported? (1)

Curien (267780) | more than 6 years ago | (#22825570)

[U]nlike Java [emphasis added], you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript.

That's different from Java... how?

Re:Is writing Evil Javascript still supported? (0)

Moridineas (213502) | more than 6 years ago | (#22826142)

So if I leave Javascript turned on, because there are sites that require me to use their Javascript to do the things I want to do there, my browser's open to Evil Javascript on other sites, plus there's enough Bad Javascript out there that after I've done enough browsing, Firefox is burning most of my CPU on leftover broken cruft that I have to kill it.
This never happens to me. There are obviously a lot of people out there who feel like you do (and use NoScript, etc) but I've never really gotten it. Where are these websites which kill your browser or do otherwise unwanted things? Is it that huge a problem?

(I use Safari more than Firefox, and while it's improved vastly in its latest versions, Safari has traditionally sucked both speed and correctness with javascript in comparison with FF)

Yuck. (1)

Tabithy (1256584) | more than 6 years ago | (#22825044)

Making javascript more like java is not what I would consider an improvement.

Re:Yuck. (0)

Anonymous Coward | more than 6 years ago | (#22825132)

Well you obviously don't understand the value in taking the worst of two worlds and mashing them together into something that will make the stablest browser crack at the seams. oh the horror.

looks nice but... (1)

WoollyMittens (1065278) | more than 6 years ago | (#22825096)

I know I'll be coding for the "vast minority" of people still using Internet Explorer 6 while refusing to upgrade for the best part of this decade. Why do people buy a new mobile phone every year, but keep the same browser they got with their computer back in the late 90's?

Things to come... (1)

fahrbot-bot (874524) | more than 6 years ago | (#22825222)

... JavaScript 2.0. I was just taking a look at the proposed specifications and I am really, truly excited about what we have coming.

I'm predicting "NoScript 2.0" :-)

I'm actually not looking forward to this (1)

fatalGlory (1060870) | more than 6 years ago | (#22825636)

I think that this new revamped javascript might really cause me some irritation down the track. I'm all for cleaning up javascript a little, but OOP? Does it really need it? I guess there might be a place for it with AJAX apps, but most javascript work is for really simple little functions like checking form input before submitting - and it has been great for that.

For so long, I've been recommending to people who want to learn to program to start with javascript because it is syntactically lenient and has a very quick learning curve (if you know even a little HTML). I'd say leave Java's jobs to Java. Javascript has an entirely different purpose IMHO.

Re:I'm actually not looking forward to this (4, Insightful)

TheRaven64 (641858) | more than 6 years ago | (#22825750)

Java already has OOP, in the form of a Self-like object model. Self is sufficiently general that you can implement the Smalltalk object model in it very easily. The problem I see with many of these 'improvements' is that they just don't belong in the language. The nice thing about the Self family of languages (of which JavaScript is a member) is that it is really easy to add constructs to them without modifying the language. Classes in JavaScript are basically just traits objects, and can easily be implemented on top of the core language. If you want classes, you can add them yourself in a few lines. Same with generics (trivial in any language with type introspection, but not really needed in languages with dynamic typing).

JavaScript is a language with first-class closures and a rich Self-style object model. The syntax is a bit ugly, but the language is really a joy to work with once you get past the 'it looks like Java' stage.

Bleah. Classes. (1)

argent (18001) | more than 6 years ago | (#22825638)

I agree with Gosling. Classes are an unnecessary abstraction layer. Why shouldn't you be able to inherit from any object?

Standards rule (2, Interesting)

heroine (1220) | more than 6 years ago | (#22825716)

Instead of writing specs in essay form & expecting someone else to translate them into software, why can't these guys just write the spec in the form of the software to actually implement it and then rely on someone else to optimize it?

class keyword (2, Insightful)

essence (812715) | more than 6 years ago | (#22825852)

Why is there so many people surprised about the class keyword finally being implemented? I remember reading the reserved words for javascript way back in the 90's and seeing class in there. I always wondered how long it would take to be implemented. Here is a list of javascript reserved words [about.com] .

It should all die.. (1)

Chrono11901 (901948) | more than 6 years ago | (#22825946)

HTML,JS,CSS,PHP,ect...

Right now web 2.0 is the Frankenstein of codeing.
-php to get dynamic data
-html to see the page
-css to make it look pritty
-javascript to alter a current page

So for me to update a section of a page without doing a complete reload need to... create a call in javascript that grab the html from a new page that is created by php, then we use javascript again to inject it into the html tag we want.

From the geeky side it seems cool... but for someone who develops web 2.0 pages, it would be nice if one standard framework would be developed that encompassed all these things. So that coding "Web 2.0" pages would be cleaner, easier, simpler, and more efficient.

compile-time checking (1)

wralias (862131) | more than 6 years ago | (#22826022)

From TFA:

Compile Time Type Checking JavaScript 2.0 components can request to be compiled in strict mode. This will test the integrity of several key aspects before execution. A partial list of these checks includes:

Static type checking
Verification that referenced names are known
Checks for illegal assignments to constants
Insures that comparisons are only made between valid types
Awesome. JavaScript needs constants - it's the big missing piece as far as types. And I personally love static type checking. Waaaay easier to debug... As someone who does hardcore "OOP" in JavaScript, I'm excited by the prospect of these changes, even if they are years away from being implemented by all browsers.

xss 2.0 (1)

Heembo (916647) | more than 6 years ago | (#22826048)

Ah cool! Cross Site Scripting and site defacement 2.0!

Great. (1)

multi io (640409) | more than 6 years ago | (#22826116)

This looks like a weird combination of the "second system effect" (introduce a Java-like class system because supposedly that's what people want now), fixing what wasn't broken (introduce a Java-like class system to a language that didn't need it), not fixing what was broken (the strange constructor function/"this" semantics), and, inventively, breaking what wasn't broken (operator overloading). There's also a tiny bit of actual fixing what was broken (namespace system), but I don't think that that will save the day :-P

Interesting evolution (2, Funny)

Anonymous Coward | more than 6 years ago | (#22826190)

As an "old timer", I find it both fascinating and horrifying to watch the evolution of static web pages into "rich applications", shoehorned into the request/response model with a crazy wobbling mass of server-side languages, client-side language(s), browser plug-ins, HTML, DOM, CSS, JSON, XML... God knows what else. It's like GUI and client/server programming didn't exist before and they are trying to reinvent in the most illogical way possible.

Is it humanly possible to make this any more complicated, brittle, or insecure?

Don't answer that... I'm sure somebody's working on it.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?