Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming

Trying To Bust JavaScript Out of the Browser 531

eldavojohn writes "If you think JavaScript is a crime against humanity, you might want to skip this article, because Ars is reporting on efforts to take JavaScript to the next level. With the new ECMAScript 5 draft proposal, the article points out a lot of positive things that have happened in the world of JavaScript. The article does a good job of citing some of the major problems with JavaScript and how a reborn library called CommonJS (formerly ServerJS) is addressing each of those problems. No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"
This discussion has been archived. No new comments can be posted.

Trying To Bust JavaScript Out of the Browser

Comments Filter:
  • by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Tuesday December 01, 2009 @11:17AM (#30284318)

    Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.

    It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it. Things change when you realize how useful something actually is.

    • by iamacat ( 583406 ) on Tuesday December 01, 2009 @11:27AM (#30284452)

      Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution. Inability to perform CPU-intensive computations due to these dynamic types of yours, lack of threading or any other explicit or implicit parallelism support, no library facilities to modern 2D/3D graphics libraries. Javascript is a nice experimental language like so many others but it shouldn't be running 90% of mission-critical applications.

      • Javascript is a nice experimental language like so many others but it shouldn't be running 90% of mission-critical applications.

        But alas, it's driving a majority of the web.

      • by sydneyfong ( 410107 ) on Tuesday December 01, 2009 @11:45AM (#30284690) Homepage Journal

        - The speed issue is largely due to the crappy implementations of Javascript, which are improving due to competition among browsers. Javascript can be JIT-ed. What you probably can't do is compile it to native code and expect it to have the speed of C/C++. But then would *you* run arbitrary native binary code off the web? Sandboxing makes things slow again.

        - I'll give you the lack of threading.

        - 2D/3D libraries - C doesn't have one in its standard, C++ doesn't have one, in fact most don't. But you're free to implement one. It just doesn't make too much sense having a full fledged 2D/3D library in the browser, since that's where most javascript code are used in.

        - experimental language, as in first appearing in 1995, used extensively for almost 15 years. Of course most people never really utilize its full power, but it's not the fault of the language

        - And you use a "mission-critical application" written in Javascript running inside a web browser?

        Don't ditch the language due to poor implementation and crappy users.

      • Re: (Score:3, Interesting)

        by Ed Avis ( 5917 )
        1. Of course the CPU-intensive parts of an app (compression, encryption, database things like DBM or SQLite) are still in native code and Javascript is just a wrapper. 2. The new generation of Javascript engines (Google's V8, Mozilla's Tracemonkey, etc) are one or two orders of magnitude faster than the Javascript interpreters of a few years ago. Not nearly as fast as native code, of course, but certainly good enough for a lot of applications. 3. You're right that threading and parallelism is missing. A
      • Re: (Score:3, Interesting)

        Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution.

        • Some sort of interpreted language was needed for the web, to run untrusted code in a secure way. C couldn't be used for that. So it was a slow language or no language, back then. The only alternative at the time was Java, but it actually had worse performance in the way that most mattered to the web - startup times (not much use if it gets fast later on, if you need to wait an annoyingly long time for each page).
        • New JavaScript engines are slower than C, but by less than an order of magnitude - and getting
        • Re: (Score:3, Insightful)

          by iamacat ( 583406 )

          Some sort of interpreted language was needed for the web, to run untrusted code in a secure way. C couldn't be used for that.

          Well, that sure hasn't worked out as planned. There is more malware written in Javascript than in any other language in existence. The only connection between language and security is performance of things like bounds checking, and Javascript is not exactly known for performance. C can easily be interpreted or compiled to verifiable code and still be faster than JS for CPU-intensive inner loops written without complicated pointer use. JVM is specially designed to allow more load-time verification rather tha

    • Re: (Score:3, Insightful)

      by OverlordQ ( 264228 )

      Or maybe more like Oxygen, poisonous in high concentrations (re: pressures).

    • It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it.

      Javascript reminds you of tomatoes? My favorite salad [google.com] seldom seems to have tomatoes. I see how you got your nick name ;-)

    • With no feature-set testing capability coupled with the intent of handing off raw code to 3rd party virtual engines. With no 'reference' platform to validate code (with such simple things as which string functions are supported) and no useful error messages when making language library mistakes (nor any type-safety to determine it out of the box). And with respect to dynamicity, no equivalent 'perl -c foo.pl', 'use strict', or '-warn' pragma. No package namespaces. No legitimate mechanism of loading 3'rd party library files, much less a way of namespace collision resolution/isolation. No defined order of execution (some run in-line, others run on browser completely loaded, etc).

      I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.

      Sure a command-line javascript can define it's own standard and I'm confident that it can solve all these problems.. That's the great thing about standards - everybody's got one.
      • by Blakey Rat ( 99501 ) on Tuesday December 01, 2009 @11:41AM (#30284642)

        I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.

        jQuery (prototype, mootools, etc) solves shitty DOM implementations, not shitty Javascript implementations. In fact, I don't think jQuery addresses a single "lack" in Javascript-- I could be mistaken-- virtually everything, if not everything, it does is fixing DOM's bad design and browser's inconsistent implementation of it.

        This is why Javascript gets a bad rap: pair it with DOM, and *any* language would look awful, because DOM is awful.

    • by Blakey Rat ( 99501 ) on Tuesday December 01, 2009 @11:33AM (#30284542)

      Most of Javascript's bad reputation come from the W3C's DOM. When the majority of programmers think "Javascript," they're actually thinking "Javascript + DOM," and since the DOM is so awful, they think Javascript is awful as well. Not so.

      Pair Javascript with a decent library, and it's extremely powerful. Maybe not as suited for large projects as languages with namespaces, but its template system and introspection features are simply amazing. If anybody ever writes a program that evolves itself until it becomes super-intelligent and takes over the Earth, it'll probably be written in Javascript.

      Correction to the parent, though: Javascript isn't an object-oriented language in the classic definition of the term... it lacks many features to make it truly OOP. Instead, it's based around object templating, which is nearly as powerful, but not the same thing.

    • Re: (Score:3, Informative)

      by slug359 ( 533109 )
      Here's my three favourite language flaws, which make the language nearly unusable for non-trivial projects:
      • Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.
      • A lack of namespaces.
      • Lack of block scope (despite the fact the language has blocks), i.e:

        function a() {
        var b = 1;
        {
        var b = 2;
        }
        alert(b);
        }

        will alert 2.

    • by mcrbids ( 148650 ) on Tuesday December 01, 2009 @11:41AM (#30284640) Journal

      Javascript makes many hard things simple, and many simple things hard.

      Need to find out what the user typed in box foo? While most client libraries require fairly detailed memory schemes in order to keep track of which box is which, Javascript reduces all that to getElementById(); - a win in any programmer's book!

      But in the reverse, what about trimming that input? The offense to the mind that you have to use a USER DEFINED FUNCTION for trimming just boggles the mind. Sure, there are libraries for this, blah blah but still, the truth remains that there is no trim() function. The lack of any kind of meaningful class structure makes the special word "this" almost worthless because you can't be sure consistently what it's referring to. (yes, it is possible to figure it out, but why should you have to?) If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

      So javascript has its warts. Lots and lots of them. It is clearly a hacked-together language that is only successful because of its ubiquity, which is the same reason why it evolves so extremely slowly, which is why we still have to manually implement things like trim(), and why so many of us are doomed to deal with javascript with all of its warts.

      Javascript, however, has been free of the browser for some time, due to the Mozilla's JS engine being modular. They call it spidermonkey, and I actually considered using it as a replacement for PHP on the server side in order to keep langauages consistent. Unfortunately, nobody's embedded it into Apache as a module (with any kind of stability) so this means that js scripts would have to run as separate executables, which causes all kinds of performance and security problems.

      • and I actually considered using it as a replacement for PHP on the server side in order to keep langauages consistent.

        I always thought that would be a good thing - consistency in language means you don't have to learn 5 or so to do meaningful work. Unfortunately, whilst MS appears to agree with me (everything in C#), the rest of the world doesn't. So until we get a javascript world takeover, we'll be stuck with PHP, Perl, Python and Java server-side systems. I'd love for one to win, and JS may as well be th

        • Bad idea. The fact that you have to use different languages separates domains as they should be.
          Django does something similar by using a templating language that is not Python and runs in a different context.
          I feel that if you start putting JS on both client and server you'll start to blur the line between client and server and make the code much harder to read. You'll start using some of the same routines in both client and server. With separate languages you make sure that those types of things are onl

      • Need to find out what the user typed in box foo? While most client libraries require fairly detailed memory schemes in order to keep track of which box is which, Javascript reduces all that to getElementById(); - a win in any programmer's book!

        That's DOM, not Javascript.

        But in the reverse, what about trimming that input? The offense to the mind that you have to use a USER DEFINED FUNCTION for trimming just boggles the mind.

        That's a lack in DOM, not a lack in Javascript.

        So javascript has its warts. Lots and

        • Re: (Score:3, Informative)

          The absence of a trim method is not a DOM problem: I should be a method available on String.

          As for the lack of this consistency, this is due how Javascript scopes references to methods. Being able to change this behaviour can be handy at times, but often not the expected behaviour.

          Read http://www.alistapart.com/articles/getoutbindingsituations/ [alistapart.com] to see how apply/call can help set-up the correct binding for this and a method.

          JavaScript behaves this way to support prototypal inheritance.

        • by rycamor ( 194164 ) on Tuesday December 01, 2009 @12:44PM (#30285520)

          If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

          That one I can't speak to... interesting if true.

          Yes, delete will mull the value of an array element but leave the index. To remove an array element, use splice(), which removes AND returns the indexed element in question:

          js> arr = [4,5,6,7];
          4,5,6,7
          js> print(arr.splice(2));
          6
          js> print(arr);
          4,5,7
          js> delete arr[1];
          true
          js> print(arr);
          4,,7

    • by TheRaven64 ( 641858 ) on Tuesday December 01, 2009 @11:44AM (#30284666) Journal

      JavaScript is a Self dialect with ugly syntax, a broken model for unboxed numeric values, monumentally broken semantics for closure evaluation, and no sensible second-chance dispatch mechanism. Oh, and all current JavaScript implementations are slower than the Self VM from a decade ago.

      Apart from that, it's a great language.

    • It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it.

      That's not even remotely true. When I'm driving a car load of drunken cheerleaders to the abortion clinic, and I stop off at McDonalds, I enjoy an unequivocal Constitutional right to shoot the McMonkey in the balls if he puts tomato in my salad after I've told him not to.

    • Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.

      I for one wish JS have the same broad success as Lisp!

    • by MobyDisk ( 75490 ) on Tuesday December 01, 2009 @12:09PM (#30285040) Homepage

      Javascript is too dynamically typed. In my experience, testers constantly find bugs caused by type-mismatches, misspelled variable names, or other basic things that a compiler could have detected. The next most common set of problems is that Javascript generally doesn't report errors right away: they show up 200 lines later. Suppose a variable doesn't exist when it is referenced? It just makes one up right there on the spot, and assigns it a null value. That's terrible. Then there's the null -vs- undefined mess that constantly trips-up even experienced programmers.

  • JavaScript is already out of the browser, but unofficially or rather unstandardized. Look at languages such as JavaScript in Flash, or the use of JavaScript in Acrobat PDF Reader, etc. Microsoft allowed their JScript (variant of JavaScript) to be used on the server side years ago in classic Active Server Pages - so I coded JavaScript on the server several years back.

    However I am in support of a more official representation of JavaScript on the server.

    • by dpilot ( 134227 )

      > However I am in support of a more official representation of JavaScript on the server.

      I suspect that part of the thrust here is migration of server CPU cycles to client CPU cycles. Server CPU cycles are typically planned, purchased, tracked, and constrained. Client CPU cycles are typically wasted. The "cheap box" today at the local big box retailer has more CPU power than a scientific mainframe of not that long ago. Most of that compute power is spent waiting for the user to press a key or move the

    • Look at languages such as JavaScript in Flash [..]

      I wouldn't say JavaScript = Actionscript; they're both descendants of ECMAScript [wikipedia.org].

    • Look at languages such as JavaScript in Flash,

      Flash doesn't use Javascript, it uses Actionscript. Both are based on the ECMAScript standard, but Actionscript 3 is actually pretty far-removed from Javascript now. (Actionscript 2 is much closer.)

      Anyway, I get what you're saying, it's just that Adobe's version is modified quite a bit.

  • My thoughts (Score:4, Funny)

    by davidbrit2 ( 775091 ) on Tuesday December 01, 2009 @11:19AM (#30284338) Homepage
    As somebody who's attempted to write object-oriented Javascript code, my response would be GOD NO.
    • Re:My thoughts (Score:4, Insightful)

      by rayharris ( 1571543 ) on Tuesday December 01, 2009 @11:28AM (#30284472)
      JavaScript uses a different type of object than you're used to. JavaScript uses prototype-based objects whereas most other languages use class-based objects. I've seen a lot of work put into developing "class-like" objects in JavaScript and I've wondered why they just didn't learn to write code using prototypes instead.
      • Re:My thoughts (Score:4, Insightful)

        by ShieldW0lf ( 601553 ) on Tuesday December 01, 2009 @12:12PM (#30285092) Journal
        JavaScript uses a different type of object than you're used to. JavaScript uses prototype-based objects whereas most other languages use class-based objects. I've seen a lot of work put into developing "class-like" objects in JavaScript and I've wondered why they just didn't learn to write code using prototypes instead.

        Too educated to learn.
    • Umm, Javascript is great for object-oriented programming. I don't think you are using it properly..
  • No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"

    If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get? I'm a developer and I can't think of anything MORE front then the front end...

    If you're talking about Taking Javascript and making it more integrated with the actual web page display, AJAX already handles most of that. We don't need Javascript to become like PHP, where you're using PHP to write your HTML inside of your PHP script tag inside of an HTML body.

    • If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get? I'm a developer and I can't think of anything MORE front then the front end...

      If you're talking about Taking Javascript and making it more integrated with the actual web page display, AJAX already handles most of that. We don't need Javascript to become like PHP, where you're using PHP to write your HTML inside of your PHP script tag inside of an HTML body.

      1) JavaScript is not Java,despite the name.
      2) You can get lots more Java if that's what you want.
      3) Are you a developer, or a guy who makes web apps?
      4) The OS desktop is MORE front than the front end of your web app running inside a browser.
      5) PHP (and JSP among others) doesn't have to be written like that.

      • 3) Are you a developer, or a guy who makes web apps?

        Wait, since when is there a difference? I consider myself a developer, but my applications are only available on the web..

        • Wait, since when is there a difference? I consider myself a developer, but my applications are only available on the web..

          The difference is really understanding the technologies you're using, the context you're using them in, and effective ways to use them. I didn't get the impression that the OP necessarily had that understanding.

      • 1) There are enough similarities between the two to associate them together. Obviously one is a script and the other is not, so Java needs to be compiled and you have to watch your syntax more in Javascript. But the way I declare and use my variables is most similar to the way I would handle them in Java as opposed to VB.

        2) Yes I've written a GUI in Java, wrote the back end in Java, etc etc, and no, thats not what I want. It's not fun.

        3) I actually only maintain web apps on occaison, most of my hobbying is

    • If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get?

      Repeat after me: Javascript is not Java. Don't confuse the two, they are completely different technologies.

      • I know that, everyone knows that. One is a scripting language where the other one needs to be compiled before running and blah blah blah yes we know. But there are obviously more similarities between Java and Javascript then say Javascript and C#.

  • I've been a big user of BSH ever since it came out, and before that a hacked Rhino/Spidermonkey fan for building system automation components that were scriptable via javascript.

    I say bring it on.
  • While JavaScript has a good thing going with the web scripting niche, it has a long road to catch up with established players in the heavyweight "everything and the kitchen sink" language category currently filled by C# and Java. It is very difficult to see mainstream platform developers selecting JavaScript as their general purpose language in favor of C#, Java, or even C or objective C (for the Linux and Mac developers respectively). JavaScript would do better to reduce its footprint and burnish its crede
    • C or objective C (for the Linux and Mac developers respectively)

      Some of us use Objective-C on Linux (or, in my case, FreeBSD) too. It even works on Windows...

  • by Karellen ( 104380 ) on Tuesday December 01, 2009 @11:27AM (#30284446) Homepage

    Javascript is a beautiful, elegant, small and generally well-formed language. It has a couple of warts, but what language doesn't.

    However, the way that Javascript interacts with web browsers, web pages and all other things web-like is a disgusting, crufty, bloated piece of shit. The DOM bindings are horrible, as far as they go, and they're woefully incomplete. The browser deficiencies in their implementations of the DOM bindings, and the browser-specific work-arounds needed to circumvent said deficiencies, are Lovecraftian nightmares.

    (The willful violation of the javascript object model for document.all in HTML5 [w3.org] (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))

    Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      The idea of Javascript is nice. In practice it's hardly what you describe.

      Consider how closures work in Javascript. It's totally retarded and the scoping doesn't work like you think it would.

      Lua [lua.org] has basically the same semantics as Javascript but it much simpler, faster, and you get a better design (eg. closures work like they should). Lua is a better Javascript than Javascript.

    • Re: (Score:3, Informative)

      by brundlefly ( 189430 )

      >> The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example...

      Not really nasty to implement at all:

      get document all() {
      return document.getElementById.apply(document, arguments);
      }

      That's interpreted code, of course, not native code. But if you're in the business of writing parsers and compilers, rolling that into native code is about a 10-minute operation.

      Now... I might agree with you that it's misleading to newb

  • Better Idea (Score:3, Insightful)

    by physicsphairy ( 720718 ) on Tuesday December 01, 2009 @11:27AM (#30284462)
    I think everyone can agree what we really need is web-executable COBOL.
  • the Johnny Knoxville of programming languages
  • A huge pain (Score:4, Insightful)

    by mafian911 ( 1270834 ) on Tuesday December 01, 2009 @11:29AM (#30284488)
    I'm not sure why anyone would want JavaScript anywhere else. I believe that the only reason why JavaScript is "popular" in the first place is because it is the only option available for client-side processing on the web.

    A lot of the pain of JS, like its inconsistent experience across browsers, can't really be held against it. Each browser has to implement JS according to its own interpretation of the standard, virtually guaranteeing a non-consistent experience across the board. I understand that. But what truly kills JavaScript for me is the lack of development tools and a solid reference. Debugging JS with an alert window is a horrible experience.

    Again, why anyone would want this stuff everywhere is beyond me. I was shocked a long time ago when Palm Pre decided it was a good idea to use JavaScript for app development. Shocked I tell you. And look where that went. Like I said, the only reason I would consider JS "popular" on the web is because there is no other way to do client-side processing. It's literally our only choice (VBScript doesn't count).
  • Sure a JavaScript engine may have shipped on "every computer ever" but it's been embedded into a browser. So the next step is to decouple it from that browser-based engine and use it to create local apps?

    What would you run this script engine in? A Virtual Machine? Some kind of embedded OS Framework? A behind-the-scenes browser instance (shudder).

    Either way, I don't get it, what magical app could I write only with JavaScript that I couldn't write with something else? Actually I do kind of get it, there are p

  • by asc99c ( 938635 ) on Tuesday December 01, 2009 @11:39AM (#30284612)

    A lot of the comments are pointing out the problems in Javascript, and ignoring the problems in the big heavyweight languages like Java and C#.

    It's not really in praise of Javascript, but a very good read is Joel's article 'Can Your Programming Language Do This?' It accurately points out a number of ways in which Java development very quickly takes up a lot of lines of code compared to more lightweight approaches. I personally prefer the light weight approach for many applications.

    http://www.joelonsoftware.com/items/2006/08/01.html [joelonsoftware.com]

  • I don't think it's fair to call JavaScript a crime against humanity -- most humans aren't software developers...

  • I would say that JavaScript has potential, just like Luke Skywalker. Both had the ability to do great things and both had/have the ability to do terrible things.

    Question is... who is.. Who's JavaScript's father? And will he lead him down the dark side?

  • by gestalt_n_pepper ( 991155 ) on Tuesday December 01, 2009 @11:44AM (#30284676)

    It's a tolerable front end language for browsers. It's not as flexible or as fast as C++, but here's a newsflash to the "I'm living in Mom's basement crowd." It doesn't have to be.

    It can suck up resources and not be especially fast and not be able to manipulate pointers or be much good for creating new classes and....

    (sing it with me now) IT DOESN'T MATTER AND 99.99% OF WEB DEVELOPERS DON'T CARE.

    Not all languages are C++, or Ruby, or Java or anything. Nor should they be. Use the right tool for the right job.

  • by slim ( 1652 ) <{john} {at} {hartnup.net}> on Tuesday December 01, 2009 @11:51AM (#30284792) Homepage

    This is the book that'll make you realise Javascript is OK:
    http://oreilly.com/catalog/9780596517748 [oreilly.com]

    It's not afraid to call out the bad parts, and to show you how to work around them. That's down to a rushed standardization process.

    It doesn't deal with the DOM at all - after all, that's not part of JS.

    It leaves you thinking JS is pretty neat, if you use it right.

  • Just make the damn thing behave exactly the same way in every browser and I'll be sound as a pound!
  • the browser is the os. or rather, the browser will become the os. anything and everything of any value to 99% of us in the modern internet-centered world will be interacted with through the browser

    so instead of talking about jailbreaking javascript, the more relevant subject should be jailbreaking the browser. such that when joe user turns on his computer in 2015, he gets a browser, and only a browser, and nothing but a browser. native javascript implementation then continues merrily chugging along in the b

  • by Hurricane78 ( 562437 ) <deleted&slashdot,org> on Tuesday December 01, 2009 @12:04PM (#30284984)

    If you think JavaScript is a crime against humanity,

    In other words “If you can’t program, or if you can’t tell JavaScript from Java or Python,”.

    The new versions of JS are really sweet. But most “web-developers” can’t even write proper code in the old one. Which is quickly visible, if you enable strict warnings, and force the interpreter to the newest version. Most scripts throw warnings or fail after that.

    I say JS and Python are on par with each other. But they use very different paradigms. JS uses prototypes. And that is what most people do not understand. See it like this: Everything is an object (including functions, which allows really powerful functional programming), everything can be written literally (including objects with functions), and everything has a prototype on which it is based and can be the prototype for other objects/prototypes.

    So you build your object, and then use it as a prototype to create other objects with added functionality or changed data.
    The elegance of this is, that inheriting and instantiation really becomes the same thing. And in my eyes, the less rules a language needs, while still having all the power, the better and more elegant it is.

    It’s crazy how, with the newest version, I can write it nearly 1:1 like I would write it in Haskell! You can’t imagine how happy I was, when I noticed that I would practically a “scriptable Haskell in the browser”. Of course it does not have the type strictness of Haskell. But that is kinda the point.

    It even has regular expression literals.

    What’s a bit messy, is DOM. Perhaps because it’s a “design by committee with no own sense of reality” (= no leadership) API.

    Then again, I’m all for more languages in the browser. Python, Ruby, Lua, Erlang, Haskell and Java are good candidates. C/C++ and Perl are not. (Perhaps Perl 6 in 2051. ^^)

    • Re: (Score:3, Interesting)

      by Requiem18th ( 742389 )

      I like Python better than JS for a lot of reasons, that it doesn't deal with undefined vs null vs NaN vs Infinity is a big one. That property access is throughly customizable, as well as item access and function calling customizations. And class definitions inside a class block are more clean and elegant than multiple Class.prototype assigments, the standard way of prototype customization in JS.

      BUT, I admit JS has many nice tricks, Object notation makes returning records really easy to create and to use, a

  • by elnyka ( 803306 ) on Tuesday December 01, 2009 @01:48PM (#30286598)
    A lot of the "JS sux" crowd seem stuck in the Netscape era, recalling the horrors of javascript coding on geocities-look-alike websites that bloomed and died (like red tides) during the dot-com boom.

    RIAs that work well on IE and FireFox (the predominant browsers used in commercial sectors) are being developed today in JavaScript with jquery, gwt or dojo. And crappy client-side applications are being written as well. But anyone with a modicum of work experience knows that the responsibility of writing shitty applications rest squarely on the developer.

    Some of the crappiest, worst code I've seen had been written on Java, C# and C++. And also, some of the clearest, most maintainable and elegant pieces of code I've seen were written in FoxPro and JavaScript. Every single language sucks in one aspect or another.

    A good software professional, a pragmatic one, he looks at the language, at the tool, works around the problems and gets the stuff done with it in a clean manner.

    Shitty programmer OTOH will screw it up no matter what.

    And coding divas will get all emotionally attached to a given language, throwing subjective infantile rants towards whatever language they don't like recalling anecdotal memories mixed with technical impressions too superficial to be called "first-hand educated knowledge".

    I don't like JS global scoping and lack of namespaces, but I do love it's object prototyping capabilities and support for functional programming. You can write some really complex client-side, browser-running systems with a brevity and clarity you cannot match with Java or C#.

    That is the reality. It is a perfect tool? Nope. It is a good tool for what it is intended to? Yes. You can't get emotional against a tool, specially if you have never been able (or are incapable or have never assigned) to create a good NON-TRIVIAL application with it.

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Working...