Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Google Intel Programming

The Great JavaScript Debate: Improve It Or Kill It 482

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.'"
This discussion has been archived. No new comments can be posted.

The Great JavaScript Debate: Improve It Or Kill It

Comments Filter:
  • by VGPowerlord ( 621254 ) on Friday September 23, 2011 @05:13PM (#37496366)

    In my opinion... kill it! Kill it with fire!

    • Everything they may replace it with is worse...

    • by hjf ( 703092 ) on Friday September 23, 2011 @05:19PM (#37496414) Homepage

      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.

      • Exactly. JavaScript performs well now (generally) and it gives us programming goodies like Ajax, transitions, flat dialogs, etc. I'm actually in like (not love yet) with the language.

        • Yes but does Javascript provide access to hardware (camera, microphone) and sockets? Flash does. The sockets in particular (and the new 3d features just added) should make it considerably better for games.

          Now don't get me wrong, I'm not flash evangelist. I'm just wondering whether to invest my time in Actionscript or Javascript. One can now develop mobile apps with MXML and Actionscript or one can develop them using Javascript and various new (i.e., experimental) frameworks.

          I do find it odd that everyone

          • Re: (Score:3, Insightful)

            by smagruder ( 207953 )

            I think both should be kept around. They both have their strengths and weaknesses. As a programmer, I like picking the best tool for the implementation.

          • by aztracker1 ( 702135 ) on Friday September 23, 2011 @05:39PM (#37496658) Homepage
            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.
            • I understand what you are saying about the language vs. the browser API, but would also like to point out that the enormous variation in API implementations is still a very serious problem for Javascript. This is why you have things like JQuery and Mootools providing a buffer layer between the JS programmer and the browser in the often fruitless attempt to shield a JS programmer from some peculiar browser implementation. One also encounters peculiar browser behavior in flash every now and then when trying

          • by Toonol ( 1057698 )
            Yes but does Javascript provide access to hardware (camera, microphone) and sockets? Flash does. The sockets in particular (and the new 3d features just added) should make it considerably better for games.

            Javascript easily could. The browser doesn't. That's the limiting factor. People mistake the limitations that the browser enforces as limitations of Javascript.
          • I agree, death to Flash. The last thing we need is more and better security vulnerabilities.

          • I'm just wondering whether to invest my time in Actionscript or Javascript.

            If you're asking that question in 2011, the answer is Javascript. 10 years ago the answer would have been different. I'm not sure which "experimental" frameworks you've looked at, but I would suggest using a mature framework like ExtJS version 4 []. You won't find better documentation in a Javascript framework, and it even has a version specifically for mobile devices (Sencha Touch []).

            • I'm not talking about 'web apps', I'm talking about mobile phone apps that do not require server access to function.

              Granted, I haven't read all the documentation, but I don't see anything in ExtJs that would help you to write a native mobile application for iPhone/iPad, Android, and Blackberry with a single code base that:
              * lets you access hardware (microphone, camera, gps, accelerometer)
              * lets you manipulate a client-side database
              * lets you establish a socket connection to a server

              I'm still looking into it

        • These are not goodies. These are nightmares. We hates it.

      • by syousef ( 465911 )

        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.

        We hate everything you young wiper snapper. Get off my lawn!!!!

      • 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.

        This is not 2009, either. We've since hated Wave into oblivion. Gotta jump out in front of the Dart...ouch!!!

    • In my opinion... kill it! Kill it with fire!

      I'm sure reasonable people can reach a compromise that would satisfy everyone. Improve it, and then kill it.

  • How about neither? (Score:5, Insightful)

    by Hatta ( 162192 ) on Friday September 23, 2011 @05:15PM (#37496378) Journal

    Leave the web for documents. Run applications natively. Why is this so hard?

    • by hjf ( 703092 ) on Friday September 23, 2011 @05:17PM (#37496402) Homepage

      Because Google needs you to run everything in their cloud so the NSA,FBI,CIA, and even the DMV can get easy access to all your documents.

      • Seems silly at this point. They will have access to your Medical Records [] under ObamaCare.

      • Comparitively google seems far more interested in keeping your data to themselves for their advertising cash cow. Historically google has flat out refused law enforcement access to peoples accounts without a court order (vs similar situations in which police pretty much just ask and get instant access to peoples facebook). This dosn't Make them angels by any stretch, they still horde all your data like crazy, but in terms of corporations of massive size, google seems to be one that gives the least amount of
    • Re: (Score:3, Insightful)

      by amicusNYCL ( 1538833 )

      The web is not for documents, it is for storing and displaying data. Flexible and powerful interfaces to that data are a part of the web. A client-side scripting language is required for any interface that doesn't require a page refresh on every click.

      Leave the web for documents. Run applications natively. Why is this so hard?

      Yeah, and phones should only be used for making and receiving calls. And GPUs should only be used for rendering graphics.

      I'm sorry you're getting old, but things change whether you want them to or not.

      • I would add to this...

        The web as document-only is a ship that has sailed, and that trip was in the last century.

      • Because HTML / CSS are the hugest kludge ever. Get it, EVER!!!!!

        The controls suck ditch water, the implementation is without a doubt completely sophomoric and having to contain divs with divs within spans within divs and having to have just the right CSS reset file to make fucking CSS work right, having to jump through insane hoops with CSS which has the most ASS syntax imaginable just to make a pull down menu work correctly completely exposes the utter stupidity of its designers.

        The DOM is the worst bit o

    • by Lisias ( 447563 )

      Leave the web for documents. Run applications natively. Why is this so hard?

      Because native applications "are hard to make", and is run on an equipment not owned by the software maker.

      Web Applications, on the other hand, "are easy to make and deploy", and, most important, are run on software maker's owned (or rented) hardware.

      Had you ever tried to deleted your FaceBook account? ;-)

    • by Hooya ( 518216 ) on Friday September 23, 2011 @05:42PM (#37496704) Homepage

      > Why is this so hard?

      Two reasons, from my experience:

      1. we have large corporate clients (think multinational). They use our services exactly once every year. Over 1,000,000 people in total. Imagine the logistics involved to get a desktop/native application deployed - for that one time use? What if we need to tweak something halfway. How do we re-deploy?

      2. That application is "distributed". Everyone does a little bit that is then accumulated. Sure, we could write a client-server app. Then we'd need to figure out threading issues on the server side, work out the communication protocols, work out locking issues. Or we could let, say, Apache handle the threading (we're good but i'd rather trust software that has undergone years and years of usage - there are other web servers that do this better, i know.) Let HTTP be the communication protocol. Let the backend database handle data locking issues (at least using standard SQL concepts allows everyone to be able to wrap their heads around the issues involved). You could argue that we could use a native app that then uses HTTP. For that, see #1.

      Native apps were great. Far richer experience in terms of UI. But far, far, poorer in terms of distributed-ness and ease of deployment. Or, looking at it another way, the current state of things are due to the evolution of one native app - the browser. It's just that it comes with an established integrated communication protocol and a UI that's flexible/extendable and the guarantee that the shell/runtime is multi-vendor - but largely compatible and available on most computers shielding you from deployment hassles. So it IS a native app that comes with the pieces you need (comm protocol, extension language, widespread availability).

      • by mikeg22 ( 601691 )
        Their are native application platforms that are easy to distribute. Flash and Silverlight are 99% as easy to distribute/update as html/js apps (at least to desktop boxes).
    • by grumbel ( 592662 )

      A large part of the problem with "running applications natively" is that the native programming interfaces aren't really build to handle the kind of applications that run on the web. How would Wikipedia look as a native Gtk+ app? How would Facebook? It's kind of hard to imagine that type of applications stuffed into a classic GUI toolkit. Of course it could be done, but you would probably end up doing it by embedding a HTML widget and then you are basically back at square one.

      That of course doesn't mean tha

      • by Hatta ( 162192 )

        That's actually a large part of the benefit of native applications. Consistent look and feel, remember that? If Facebook were a local application, it would look a lot like our email and usenet clients. That's all facebook is anyway. A poor reimplementation of email, usenet, IRC and finger.

    • Re: (Score:2, Funny)

      by Tablizer ( 95088 )

      Leave the web for documents. Run applications natively. Why is this so hard?

      I hereby sentence you to two years of corporate desktop support.

    • Re: (Score:3, Interesting)

      by izomiac ( 815208 )
      Apparently, someone thought the concept of files, folders, applications, and menus was too complicated for the 'average person'. Over the years, this idea has spawned countless variations of these concepts in an attempt to make them 'easier' for this hypothetical user. Ironically, the inconsistency and countless layers of abstraction made everything much harder.

      Today, users aren't expected to know what any of that stuff is. The modern user isn't expected to understand what application they're using, o
  • by qbast ( 1265706 )
    Kill it, bury it, salt the earth.
  • by smagruder ( 207953 ) <> on Friday September 23, 2011 @05:17PM (#37496398) Homepage

    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?

    • People keep figuring out how to do even more with JavaScript, forgetting that just because you can, doesn't mean you should.

      • True enough. But this notion can be applied to just about any programming platform. When a programmer tries to put all their expectational needs into one technology basket, bad designs can happen.

    • The design flaws are terminal. It deserves to be replaced with something that is statically typed.

      If you want to keep it around for a few years as a legacy thing, fine. But it really is the VB5 of the 21st century.

      We want something else.*

      *Ripped off from a great MASH episode.

  • Now we can all switch to using Javascri... oh. Crap.

    • mod parent up. If all these cavemen want to go back to the days before reliable client-side scripting, let them all adopt IE 6!

  • If there's a greener pasture, someone with resources similar to those possessed by the original javascript developers would be seeding it.

    Now, knowing what we know about how fugly Javascript is, the question is: why hasn't anyone replaced it yet?

  • I like Javascript, it allowed me to code without having to install big fancy development platform. Given how widespread it has become, I fail to see how killing it make any sense. I don't care about dogma, I care about reality.
    • I like Javascript, it allowed me to code without having to install big fancy development platform.

      So would a number of other and largely better programming languages.

  • JavaScript was meant to manipulate documents, and is used to make those documents into applications.

    Lets just throw out HTML altogether and come up with a new language to make the client side section of web apps with. HTML was never envisioned to do this.
  • The unpopular vote (Score:4, Interesting)

    by gadzook33 ( 740455 ) on Friday September 23, 2011 @05:30PM (#37496546)
    I know I'm going to get banned from /. for all time, but can we talk about something like Silverlight please? It's a dream to program for and it does all the stuff that we wish javascript did. Ok, begin anti-M$
    • by Microlith ( 54737 ) on Friday September 23, 2011 @05:33PM (#37496582)

      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.

    • by Ragun ( 1885816 )
      I think you answered your own question.

      How on earth is a standard supposed to spread when everyone and their mother distrusts the people producing it? No one trusts them to contribute to the field without some kind of nasty lock-in, and their is a reason for that distrust.
  • by drolli ( 522659 )

    If you want to replace JS for the sake of its limitations, then use java or C#. Both are fully grown languages with all mechanisms and tools you would ask for, a huge programmer base, good JIT implementations and an awesome amount of code already written.

    If you have another agenda, i cant help you.

    • by jmorris42 ( 1458 ) *

      This! Except forget C#, too much political and patent frenzy to get a majority to come on board that disaster. But why can't a Java app be given access to the DOM of a page? Everyone already knows Java, plenty of tools exist, most browsers already support it and it just about HAS to run faster than compiled JS even with all the (rightful in my humble opinion) abuse we have heaped on Java over the years for performance issues. In this case though we are comparing Java to JS, not native C++ code. The sec

  • by PeanutButterBreath ( 1224570 ) on Friday September 23, 2011 @05:32PM (#37496570)

    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?

  • I used to hate javascript. I'd disable it in my browsers up until a few years ago and avoid it like the plague in all of my web development tasks. A year and a half ago I became a full time web developer.

    I had to shut up and learn to love javascript, and I really do. There's nothing wrong with it.

    A language like PHP3 lacks enough features to make many common patterns possible. Progressing to PHP4, and PHP5, more and more patterns became possible. PHP can now house proper code, though it frequently doesn't b

  • I wouldn't mind Lua (Score:4, Interesting)

    by FictionPimp ( 712802 ) on Friday September 23, 2011 @05:41PM (#37496682) Homepage

    I wouldn't mind if they added Lua to web browsers.

  • Static Strong (Score:5, Interesting)

    by kervin ( 64171 ) on Friday September 23, 2011 @05:44PM (#37496722) Homepage

    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?

    • by Yold ( 473518 )

      How about a Javascript that's more Java-like?

      Real private and public modifiers would be nice, but I wish people would take the time to understand why the LISP-like qualities of JavaScript make it awesome. I often find myself wishing that .NET and Java were more like JavaScript. To be an exceptional .NET or Java programmer, you need to know tons and tons of specifics about the language. To be a good JavaScript programmer, all you really have to understand are the concepts related to objects and scope.

      I think Java and .NET are great enterprise langu

  • Who needs javascript now that every website ends up being rewritten in Objective-C?

  • It would be great if they could evolve it in the direction Adobe did with Actionscript 3.0. That is a nice little language.

    The biggest problem, though, isn't Javascript; it's the horrible API and document model it has to struggle with when doing anything in a web browser. That would make programming in any scripting language a nightmare.
  • I am hoping for another Google project: Native Client (NaCl).

    What we need is not yet another language with a new set of limitations. Instead we need a system that allows any language, even ones not invented yet. And without waiting for every single browser out there to update to the most recent language specification. Without having to program for every bug in every browser.

    Native Client solves this by allowing binary executables and a standardized byte code (LLVM) as alternative. You can code in assmbly, C

  • by Okian Warrior ( 537106 ) on Friday September 23, 2011 @05:52PM (#37496808) Homepage Journal

    I think many people are missing the point of Javascript.

    The new spec includes the ability for Javascript to open sockets. Once that takes hold, you'll have the ability to completely control the browser window from the home server.

    When that happens, it will be big. The browser is essentially a rendering machine which makes it trivially easy to show things and is largely machine independent. Instead of selling a huge monolithic program, companies can simply sell time on their servers to run their programs.

    Imagine that you want to use a big engineering program - Orcad or Altium Designer, for example.

    Instead of paying $10,000 for a copy of the program and taking a chance that it's as good as it's marketing claims, you can buy a month of usage for $100, and the executable will run on the company's servers while using your browser to paint the screens. Sort of like how World of Warcraft runs on servers, but paints the screens locally.

    This has many advantages for the user:
    1) You don't have to risk an enormous sum of money to try something out
    2) You don't pay for the product more than you need it
    3) You have NO installation issues
    4) You are always using the most up-to-date version
    5) The vendor can keep backups of your files for you
    6) You can access your files and the application from anywhere on the net

    And for the vendor:
    1) The code is never given out (only runs on the server): no piracy!
    2) You don't need multiple versions for different architectures (reduced engineering)
    3) You don't have to push updates to the users all the time
    4) You can tune the compilation/installation to make the best use of the server
    5) Rendering is much easier - the bulk of the code is written for you by others (reduced engineering)

    There are some disadvantages - the vendor has access to the document, which means that they can also sell the document to spammers (designs to China, for example). This can be dealt with by using a trust model; ie - the company will have an online reputation which will get quickly tarnished once this happens.

    That's the promise of Javascript, and the real potential of the cloud. Companies supplying online services to compete for customers.

    • (Responding to my own comment)

      I'm waiting for someone to come up with a simple transport layer in JavaScript that does nothing but make the DOM visible to the other end. All you would need is

      1) Interrogate the DOM, send back value
      2) Set DOM variable to passed value
      2) Pass back messages based on the user actions ("button X was clicked").

      I'd *love* to see a python or perl interface for this. Making a GUI for something would be almost trivial.

    • by OzPeter ( 195038 )

      I think many people are missing the point of Javascript.

      The new spec includes the ability for Javascript to open sockets. Once that takes hold, you'll have the ability to completely control the browser window from the home server.

      When that happens, it will be big. The browser is essentially a rendering machine which makes it trivially easy to show things and is largely machine independent

      Did you just invent X-Windows?

  • by Tablizer ( 95088 ) on Friday September 23, 2011 @05:55PM (#37496842) Journal

    I doubt very much a language syntactically and stylistically optimized for light-duty GUI event scripting can be a good language for implementing OS-like features and vice-verse. Leave JS alone and create a new language that's a better fit for "deep guts" programming.

    What's next, ADA-Script?

  • Remember when we thought SQL was so much slower and not fit for the big work? Well it was'n SQL, it were the early implementations that were slow.
    Now the Javascript specs are very powerfull. And the engines (implementations) are getting faster all the time. I see SproutCore and Objective-J pushing the envelope, amongst others. Javascript has only just arrived.

    Anyways, that's only my impression.

  • by rabtech ( 223758 ) on Friday September 23, 2011 @06:04PM (#37496944) Homepage

    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.

  • If Google would actually get around to releasing some details on Dart, rather than just trying to shoot down an established language, then maybe this could be a rational discussion.

  • Specifications? A Benjamin Franklin List would be useful. Benchmarks? Working ... Demos?

    Hay Intel! How about a Metaphysical Interface?

    Hay Google, How about a Protocol Definition?

    If Google, and Intel could combine a Metaphysical Interface with a Protocol Definition, maybe there would be something new to march around the breakfast table about?

To be is to program.