Forgot your password?
typodupeerror
Programming

Trying To Bust JavaScript Out of the Browser 531

Posted by timothy
from the first-disable-the-guard dept.
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 iamacat (583406) on Tuesday December 01, 2009 @12:27PM (#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.

  • by OverlordQ (264228) on Tuesday December 01, 2009 @12:27PM (#30284460) Journal

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

  • Better Idea (Score:3, Insightful)

    by physicsphairy (720718) on Tuesday December 01, 2009 @12:27PM (#30284462) Homepage
    I think everyone can agree what we really need is web-executable COBOL.
  • Re:My thoughts (Score:4, Insightful)

    by rayharris (1571543) on Tuesday December 01, 2009 @12:28PM (#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.
  • by Viol8 (599362) on Tuesday December 01, 2009 @12:28PM (#30284476)

    ... the browser might just as well support GWBasic. However fancy javascript may be , it doesn't take the worlds most advanced scripting language to to do pop up windows ,mouseover events and selective loading.

    Instead of trying to makd the browser a cut down OS as both MS and Firefox coders seem to be headed for, they should go back to basics and make the browser a simple reliable graphics display program with some user I/O thrown in. Not some bloated monstrosity that has all the reliability of a 20 year old unserviced Trabant. Having to support an ever more complex OO interpreted language doesn't help this reliability.

  • A huge pain (Score:4, Insightful)

    by mafian911 (1270834) on Tuesday December 01, 2009 @12:29PM (#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).
  • by Anonymous Coward on Tuesday December 01, 2009 @12:31PM (#30284518)

    C'mon. Perl has them. Lua has them. Ruby has them. Sheesh -- even Python has them. I'd guess even PHP has lexical closures these days. Advanced? You just disqualified yourself. Under which kind of rock have you been living the last 30 years?

    Besides, I'd rather compare Javascript to a Gingko fruit. The stink is similar ;-D

    [wow: captcha was "discord". This slashcode is developing some prescient intelligence, I fear]

  • by Blakey Rat (99501) on Tuesday December 01, 2009 @12:41PM (#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 TheRaven64 (641858) on Tuesday December 01, 2009 @12:44PM (#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.

  • by Anonymous Coward on Tuesday December 01, 2009 @12:44PM (#30284674)

    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.

  • by gestalt_n_pepper (991155) on Tuesday December 01, 2009 @12:44PM (#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.

  • Re:Why bother? (Score:5, Insightful)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Tuesday December 01, 2009 @12:53PM (#30284828) Journal

    I actually wish JavaScript and other client-side browser scripting would be done away with completely,

    Why?

    JS is not a particularly 'good' language.

    People who say this very often don't know Javascript well at all. It's Lisp in C's clothing. It's actually a surprisingly elegant language -- it has a few warts, but they are almost certainly not what you're thinking of.

    Google Douglas Crockford.

  • Re:Why bother? (Score:5, Insightful)

    by ThatMegathronDude (1189203) on Tuesday December 01, 2009 @12:59PM (#30284914)
    A-friggin-men. JavaScript is one of the few popular languages with first-class functions. How many JS-bashers have actually written something more than document.write() rubbish?
  • Re:Why bother? (Score:4, Insightful)

    by Anonymous Coward on Tuesday December 01, 2009 @01:04PM (#30284980)

    Mod parent up. Javascript, or ECMAscript gets a bad rap because a lot of code-pounders don't really know how to use it beyond defining a few c-style functions. It's a fairly powerful language once you understand the grammar. IE6 shoulders most of the blame for fucking it up - things that should work but need a bunch of ridiculous if(ie) incantations chase away most programmers from understanding the fundamentals of the language better. Once you realize that it's *even more* object oriented than Java(sun) then you begin to understand.

  • by fulldecent (598482) on Tuesday December 01, 2009 @01:05PM (#30284990) Homepage

    so when is dom2 coming out?

  • Re:Why bother? (Score:4, Insightful)

    by Alan Shutko (5101) on Tuesday December 01, 2009 @01:10PM (#30285056) Homepage

    It's a poor Lisp in C's clothing. Give me LET already!

  • Re:My thoughts (Score:4, Insightful)

    by ShieldW0lf (601553) on Tuesday December 01, 2009 @01: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.
  • Re:Why bother? (Score:3, Insightful)

    by pyrbrand (939860) on Tuesday December 01, 2009 @01:18PM (#30285160)
    I tend to go by the thickness of Crockford's book, vs the thickness of any "Complete Javascript" book when determining how much "good stuff" the language has. The truth is it's an accident of history, a tech demo that should never have been released, a baby not even its creator could love (and the Ecmascript 5 group had to tear out of his hands to ensure it remained a compatible language for the web).
  • by multipartmixed (163409) on Tuesday December 01, 2009 @01:26PM (#30285268) Homepage

    > most implementations of JS have threads, its just that its transparent to the language.

    Really? Name two.

    To the OP: Threads are not the only solution to concurrency. JS works will event loops.

  • Re:c++ is good (Score:5, Insightful)

    by ArcherB (796902) on Tuesday December 01, 2009 @01:26PM (#30285270) Journal

    it's just sometimes, it's a resource hog.

    A bad workman always blames his tools

    When you are given a screw driver to drive a nail, blaming the tool makes sense!

  • by s4m7 (519684) on Tuesday December 01, 2009 @01:48PM (#30285572) Homepage

    I know I shouldn't feed the trolls but...

    Whether or not current browser implementations of javascript are or are not a resource hog is not at issue here. This article, and thus the discussion, are about a new implementation for the server. Unless you have used and experienced this particular server-side implementation, you cannot say something like

    when an app is written in JS it is more likely to be a resource hog than the same app written in compiled C

    Because you don't know. I'm willing to bet that you haven't benchmarked it, and that you can write code in neither language, so in reality you have no idea what you're talking about. Maybe you can come to understand why and learn from that, if you so choose.

  • Re:Why bother? (Score:2, Insightful)

    by Anonymous Coward on Tuesday December 01, 2009 @01:49PM (#30285602)

    Commonly believed fallacy: "the standard desktop has tons of memory/CPU [to spare]"

  • by Idiomatick (976696) on Tuesday December 01, 2009 @01:57PM (#30285732)
    You forgot "get off my lawn"
    Seriously, that isn't what the web is anymore, deal with it. Nothing at all to do with javascript.
  • Re:Why bother? (Score:3, Insightful)

    by Glabrezu (215236) on Tuesday December 01, 2009 @01:59PM (#30285762)

    You mean the Douglas Crockford that wrote http://www.crockford.com/javascript/private.html [crockford.com]?

    When I talk about an object oriented programming language I'm referring to a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way. I don't want to write a library and helper methods to write an OO program, I want to use the language.

    It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript, just stop trying to force it to be something that it was not meant to be (that is a general purpose language to write medium to large scale applications).

  • Re:Why bother? (Score:5, Insightful)

    by slim (1652) <john.hartnup@net> on Tuesday December 01, 2009 @02:06PM (#30285896) Homepage

    I tend to go by the thickness of Crockford's book, vs the thickness of any "Complete Javascript" book when determining how much "good stuff" the language has.

    I believe there are two reasons for this:
      1. Crockford's writing is concise and to the point. It assumes prior programming knowledge.
      2. Crockford's book does not concern itself with the DOM

    So I believe a good chunk of the extra stuff in the fatter books is "here's what a loop is", "here's what if() does", and a bigger chunk yet is about HTML and CSS.

  • by iamacat (583406) on Tuesday December 01, 2009 @02:27PM (#30286236)

    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 than runtime checks, however this leads to long startup times and it is still not as efficient as hardware memory protection implemented by modern CPUs.

  • Re:Why bother? (Score:3, Insightful)

    by Wizel603 (1367631) on Tuesday December 01, 2009 @02:30PM (#30286292)

    The javascript hate probably isn't coming from people that have done web development.

    It's probably coming from people that have done web browsing.

  • by Anonymous Coward on Tuesday December 01, 2009 @02:31PM (#30286318)

    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.

    Maybe we're using different terminology, but how exactly is

    mystring.replace(/^\s+|\s+$/g, '');

    a user-defined function?

    Sure, there are libraries for this, blah blah but still, the truth remains that there is no trim() function.

    Why do you need a function to do it when another (well-defined and accepted) method exists?

  • by parlancex (1322105) on Tuesday December 01, 2009 @03:24PM (#30287294)
    How about those demos where Google was demonstrating V8, one of the "fastest" JS implementations available, which DOES use JIT to native machine code? They were PROUD to demo like a few hundred bouncing balls on a modern computer at not even 60 fps.

    Written in C you could write an app to draw and compute the motion of tens of thousands of fucking balls at 60 fps on a modern computer.

    Within 2 orders of magnitude is not "close" to C performance. Within 2 orders of magnitude is not "acceptable" performance.
  • by Sloppy (14984) on Tuesday December 01, 2009 @03:28PM (#30287354) Homepage Journal

    It isn't meant for huge projects

    Small projects turn into huge projects. You use a cheesy tool for a job, it works, and then someone wants a feature, so you add it and feel a little uncomfortable about it. A few weeks later, it happens again. After a few years, all the little discomforts add up to a giant pain in the ass.

    Look at how all these little languages (e.g. PHP) have evolved and tried to grow up, to varying degrees of success. Do you know why they did that? Because someone had legacy code investment and needed the language to grow up r at least half way grow up. Shit, I wrote a log analyzer in PHP not because it was a right tool for the job, but because I had some legacy code from a custom CMS that did what I needed, so I could just include it, call some old debugged fucntions, get the job done, and move on to my next TODO. It ain't pretty, and you can bet your ass that n years ago when someone started writing this stuff in PHP, they had no idea what size project it would become.

    You just never know what projects will blow up into big deals and which ones can survive cheesy tools forever. So I'd say: go ahead and improve javascript implementations, but for fuck's sake, don't ever start a new project, no matter how small you think it is, using javascript (or PHP ;-), unless javascript is just the only choice you have (e.g. you need to run inside a web browser). Even if your project seems small enough -- will it always be? If you use a "grown up" language and then your project evolves/expands, maybe you won't be fucked.

    Language designers need to think big from the get-go. When they don't, people suffer. And yes, that means namespaces (thank you, Python) and local scopes (good fucking grief, Javascript!!).

  • Re:Why bother? (Score:3, Insightful)

    by mujadaddy (1238164) on Tuesday December 01, 2009 @03:51PM (#30287718)

    How do you hide or move a DOM object in real time with css? For example how do you do this with css (jquery example)

    $("p").click(function () { $("p").fadeOut("slow"); });

    I'm not a javascript fan, but I have to use it daily for the tasks given to me.

    Congratulations, you've just loaded 50-300kb of javascript (depending on your jQuery version) to fade out an element.

    The "fading slowly" part is the ONLY bit that can't be accomplished with CSS. Hiding and moving is trivial, even cross-browser. Trust me.

    I'm the lead programmer for a Fortune 300 site, and we're handed third-party content forced onto us by Marketing, et al, that uses Jquery, et al, to accomplish the SIMPLEST of tasks. I have yet to see something implemented in jQuery that would require more than 20 lines of javascript.

    jQuery is NOT for programmers, it's for tools who think they're coding when they lay out HTML.

  • Re:Why bother? (Score:3, Insightful)

    by ShieldW0lf (601553) on Tuesday December 01, 2009 @04:09PM (#30288004) Journal
    How do you hide or move a DOM object in real time with css? For example how do you do this with css
    (jquery example)

    $("p").click(function () { $("p").fadeOut("slow"); });

    I wondered that myself when attempting to put dynamic effects in a myspace page.  They strip out any script you put in, but they leave css alone.  This is what I used:

    < style >

    .leftthumbnail span{
    position: absolute;
    top: 0px;
    left: -1000px;
    visibility: hidden;
    text-decoration: none;
    }

    .leftthumbnail span img{
    border-width: 0;
    padding: 2px;
    }

    .leftthumbnail:hover span{
    visibility: visible;
    left: 120px;
    }

    .rightthumbnail span{
    position: absolute;
    top: 0px;
    right: 10000px;
    visibility: hidden;
    text-decoration: none;
    }

    .rightthumbnail span img{
    border-width: 0;
    padding: 2px;
    }

    .rightthumbnail:hover span{
    visibility: visible;
    right: 120px;
    }

    < / style >

    < div style="position: absolute; top: 200px; left: 10px; width: 100px;" >
    < a class="leftthumbnail" href="http://www.myspace.com" >
    < img width="100" src="http://path.to.your.first/pic.jpg" border="0"  />
    < span >< img width="400" src="http://path.to.your.first/pic.jpg" />< / span >
    < / a>
    < a class="leftthumbnail" href="http://www.myspace.com" >
    < img width="100" src="http://path.to.your.second/pic.jpg" border="0"  />
    < span >< img width="400" src="http://path.to.your.second/pic.jpg" />< / span >
    < / a>
    < / div>

    < div style="position: absolute; top: 200px; right: 10px; width: 100px;" >
    < a class="rightthumbnail" href="http://www.myspace.com" >
    < img width="100" src="http://path.to.your.third/pic.jpg" border="0"  />
    < span >< img width="400" src="http://path.to.your.third/pic.jpg" />< / span >
    < / a>
    < a class="rightthumbnail" href="http://www.myspace.com" >
    < img width="100" src="http://path.to.your.fourth/pic.jpg" border="0"  />
    < span >< img width="400" src="http://path.to.your.fourth/pic.jpg" />< / span >
    < / a>
    < / div>

    What this is doing is taking advantage of the CSS hover selector for the anchor (link) tag to adjust the style of the span tag contained within.  That span contains our large images, which are shunted way off to the left of the screen out of sight when you're not hovering over the link and are positioned on screen when you are hovering over the link.  You can use this to generate quite a selection of effects if you're creative.
  • by onefriedrice (1171917) on Tuesday December 01, 2009 @04:19PM (#30288164)

    ... you cannot say something like

    when an app is written in JS it is more likely to be a resource hog than the same app written in compiled C

    Actually, that's a perfectly reasonable thing to say, albeit pointless because of the obviousness of it. It doesn't matter what runtime implementation you use, Javascript will always use more resources than an equivalent C program can, if only because of the overhead of the unused but still loaded runtime features. That doesn't mean Javascript is necessarily a resource hog, but the statement your quoted is not very outrageous, especially since he qualified the statement with "more likely."

  • Re:Why bother? (Score:3, Insightful)

    by drx (123393) on Tuesday December 01, 2009 @04:21PM (#30288178) Homepage

    jQuery is NOT for programmers, it's for tools who think they're coding when they lay out HTML.

    So what? Who cares about 50 kilobytes of extra data coming down the wire? Probably the logo graphic of your Fortune 300 company uses more bytes.

    If your only diffenrentiation from "amateurs" working with jQuery is that you can spare a 50kb download then probably your skillset is not adequate for today's world, dude!

  • Re:Why bother? (Score:3, Insightful)

    by FictionPimp (712802) on Tuesday December 01, 2009 @05:19PM (#30289034) Homepage
    You would rather I wrote 20 lines of javascript to get my point across? I've used prototype, jquery, dojo, etc for a variety of things depending on the requirements. Most web developers can understand jquery quickly so it made a good choice for the example. If that was the only 'animated' event on my page, then yes I probably would not use jquery. Lately I'm doing a lot of complex table/datagrid manipulation with tons of silly animations (I create the page, I don't make the requirements, my customers do). Jquery handles the ajax, the datagrid, the animations, the dialog windows, the modal windows, etc with just two fairly small libraries. Life is easy, customers are happy, I'm paid.
  • Re:Why bother? (Score:3, Insightful)

    by pyrbrand (939860) on Tuesday December 01, 2009 @07:42PM (#30290974)

    You're right, I was making a rhetorical point, not a logical one.

    The main thing I dislike about Javascript is that it's not a designed language. What I mean by this is that the most basic way of doing things should be the correct way. By this metric, Javascript fails miserably. There's so much broken - scope, the this keyword, scope for eval'd code, the hoops you have to jump through to make "private" functions and variables, etc. I also have a strong bias against untyped languages and those whose syntactical correctness you can only test by running it with complete code coverage. Even tools like jslint are miserable compared to the compile errors, warnings and other static analysis info you get from a well tooled, typed, compiled language. On at least part of this last part, Brendan Eich agrees with me, although the rest of the world managed to convince him it didn't belong in Ecmascript. http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704?page=0,3 [infoworld.com]

"You don't go out and kick a mad dog. If you have a mad dog with rabies, you take a gun and shoot him." -- Pat Robertson, TV Evangelist, about Muammar Kadhafy

Working...