Slashdot Mirror
The Great JavaScript Debate: Improve It Or Kill It
snydeq writes "Recent announcements from Google and Intel appear to have JavaScript headed toward a crossroads, as Google seeks to replace the lingua franca of the client-side Web with Dart and Intel looks to extend it with River Trail. What seems clear, however, is that as 'developers continue to ask more and more of JavaScript, its limitations are thrown into sharp relief,' raising the question, 'Will the Web development community continue to work to make JavaScript a first-class development platform, despite its failings? Or will it take the "nuclear option" and abandon it for greener pastures? The answer seems to be a little of both.'"
Leave the web for documents. Run applications natively. Why is this so hard?
Give me Classic Slashdot or give me death!
If someone wants to add to its mission, or write a client-side language with a different mission, go for it.
But a lot of the web is running nicely with JavaScript, and pulling out the JavaScript rug from web developers and website owners is really not an option.
Let's call for some pragmatism here, shall we?
Steve Magruder, Metro Foodist
Why? This is not 1999. We don't "hate" javascript anymore, like we did years ago.
Now we hate flash. Get on the wave, man.
I decided it would be a neat hack to flood my living room and turn it into an indoor pool. Boy, did that reveal some serious shortcomings in my home's electrical system. Can any recommend an electrician who doesn't suck as bad as the guy who installed the one I have now?
Soon as Microsoft surrenders language and library development to a 3rd party that operates in an open manner and allows any and all uses without royalty requirements.
As it stands? No way. That's just handing Microsoft what they've always wanted.
What you are talking about isn't the responsibility of the language, but the underlying API provided by the browser. And yes, there is some movement towards exposing those hardware elements to the JS API. Though not formally part of the DOM... The language itself is in my opinion a very elegant functional prototype based language. Though recent movements are to avoid use of the prototype aspects of the language.
It seriously bugs me when people confuse the DOM/JS API for a given platform and the language itself. One is not intrinsically tied to the other. JS has been a favorite language of mine for a very long time (since around 1996). It gets a bad rep. mainly because of the browsers' DOM implementations in the v4 browser war... Don't hate the player, hate the game.
Michael J. Ryan - tracker1.info
Give us a static strongly typed alternative/extension without the literally hundreds of known design flaws.
How about a Javascript that's more Java-like?
A beautiful rant killed by an ugly fact.
Learning HOW to think is more important than learning WHAT to think.
The history of the Internet and examples like IPv6, HTTP, SMTP, etc have shown us over and over that "good enough" + evolution trumps replace almost every time.
The path forward is clear: improve JavaScript, extend it, improve HTML, and keep on trucking. Neither will ever be replaced on a wide scale, only evolved.
The reason we don't already have worldwide IPv6 deployment is they redesigned IP instead of just extending the addresses.
Natural != (nontoxic || beneficial)
You really need to read Crockford's "Javascript: the good parts". You absolutely do make private methods and vars (ever noticed that you can't directly call jQuery's internal methods? Or TinyMCE's? Or any other major library/framework?)
He also makes the case that actually JS has more patterns to allow code re-use. That's why things like Mootools can even fake things that look like classical class inheritance patterns for you, if you really want to do that.
Check out http://www.crockford.com/javascript/inheritance.html and http://javascript.crockford.com/prototypal.html and http://www.slideshare.net/douglascrockford/javascript-the-good-parts-3292746