Forgot your password?
typodupeerror
Google Programming

More Info On Google's Alternative To JavaScript 247

Posted by Unknown Lamer
from the chrome-plated-vendor-lockin dept.
I'm Not There (1956) writes "Last week the news came in that Google is supposed to unveil 'Dart,' a new programming language for browser-based apps. Now an internal email from late last year describes this project as the 'high risk/high reward' path [of Google's browser development strategy]. Apps in this new language will run in a VM on browsers that support it, and can be translated to JS for other browsers. 'Performance, developer usability, and ability to be tooled' are the main characteristics of the language." The email notes that Google will be working on ECMAScript Harmony in the near term, but they describe the project as ultimately doomed by "fundamental problems" with ECMAScript. It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.
This discussion has been archived. No new comments can be posted.

More Info On Google's Alternative To JavaScript

Comments Filter:
  • by alen (225700) on Wednesday September 14, 2011 @09:42AM (#37398090)

    and make you code anything for their services in GLang so that they will be their own part of the internet separate from the open one

    • Yep, pretty much like they did with Google App Engine [slashdot.org]. Lock the developers down first, then raise prices significantly. Oh, and since it's unique platform and the backend is closed, you either have to accept whatever price Google is asking or abandon the project and code it again from the beginning. So much for Google's openness. Their new business motto seems to be borrowed from Microsoft - "Embrace, extend and extinguish".
      • then raise prices significantly.

        That's debatable. The pricing model changed, and it's likely more expensive, but also clearer and potentially cheaper.

        Oh, and since it's unique platform and the backend is closed, you either have to accept whatever price Google is asking or abandon the project and code it again from the beginning.

        Disclaimer: I contribute to dm-appengine, a DataMapper (for Ruby) layer for Google App Engine. It's part of why people can run Ruby on Rails on JRuby on App Engine.

        But I think dm-appengine alone makes a compelling case that you don't have to code from the beginning unless you've done something fantastically stupid. DataMapper has backends in everything from sqlite to Oracle, from RDF to IMAP

  • -yawn- (Score:5, Insightful)

    by Aladrin (926209) on Wednesday September 14, 2011 @09:48AM (#37398168)

    Until I actually get my hands on the language, no amount of hype is going to do anything for me.

    Besides which, CoffeeScript has got to be stealing their thunder. I have to wonder if they aren't regretting developing Dart yet.

    • CoffeeScript is also fundamentally flawed by putting semantics into unprintable characters.

      • So really, javascript, which is a huge security concern for everyone will not go away any time soon because of apathy. At least that's what *I'm* taking away from this thread...
        • by ultranova (717540)

          So really, javascript, which is a huge security concern for everyone will not go away any time soon because of apathy.

          Anything that replaces Javascript will also be a security concern, because it must include at least as much functionality.

          • Functionality doesn't == same security risk. Or as many. Might introduce more. I don't believe it necessarily means "as many" however. And certainly a replacement client side scripting language implementer should look into minimizing those risks.
      • by mortonda (5175)
        Tell that to python. It seems to have maintained a pretty good success with that. (for the record, I don't like python)
      • by slim (1652)

        Surely a space is the *easiest* character to print.

  • Until I see some sample code, that's the name I'll give it.

  • by eldavojohn (898314) * <eldavojohn@gm[ ].com ['ail' in gap]> on Wednesday September 14, 2011 @09:51AM (#37398200) Journal

    It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.

    Yeah? How many free license programming languages have you released and continued to support?

    As a developer, I love to learn a new language. I write a few simple programs in the new language. I explore what advantages and disadvantages that language has and then I put it in my toolbox. If a problem comes along that I must fix, I select the best tool for the job from said toolbox. I don't know how any sane developer could get by any other way -- there is no silver bullet programming language.

    The more tools I have at my disposal, the more effective I am. So shut your hole. I don't want people to stop exploring new languages just because it hurts your feelings that the market might fracture and you might have to -- *gasp* -- learn something new!

    • by gbjbaanb (229885)

      Rubbish attitude - this is why software is regarded as a 'hobby' for inexperienced and generally poor developers - you're too busy 'learning something new' all the time and not focussing on getting things done.

      The software industry will never become as established and professional until this attitude disappears, we need masters of things, not continual change to something else.

      Now, I don't have too much problem with a new language, but the bar for adoption really needs to be set very high to avoid the "chan

      • Rubbish attitude - this is why software is regarded as a 'hobby' for inexperienced and generally poor developers - you're too busy 'learning something new' all the time and not focussing on getting things done.

        I don't know what to say other than I feel really sorry for you if you're a developer. I grew up coding C/C++ and had I only had your attitude, I never would have used LISP, PROLOG, Java, Ruby, etc. Could I be some badass C/C++ developer if I had never been "sidetracked" and "not getting things done"? Maybe.

        But -- at the risk of being modded down as a shill -- I submit to you a recently launched site [patternizer.com] I coded with a friend. He did the canvas stuff, I did the backend. I could have picked any solutio

        • by gbjbaanb (229885)

          I've learned a fair few languages - which reinforces my point that we don't need loads more. It seems that every week there's a new language (or framework or development paradigm) that's supposed to be a silver bullet. Guess what, they never are. What they do achieve, is to draw you away from getting better at the 'old boring' stuff while you learn how to do the new - and then you ave to spend longer than you think mastering the new anyway.

          There are better ways to achieve what you need, by adding functional

      • by Khazunga (176423)

        Rubbish attitude - this is why software is regarded as a 'hobby' for inexperienced and generally poor developers - you're too busy 'learning something new' all the time and not focussing on getting things done.

        You can't possibly be a top-notch developer. Any good coder out there is just a bit hampered by the use of a new language in a new project. Languages are easy. It's a couple of hours to grasp the syntax. APIs are more difficult, but then again, the slowness in developing against a new API wears off

        • by slim (1652)

          Languages are easy. It's a couple of hours to grasp the syntax.

          Languages that differ only in syntax are a bit boring.

          The Pragmatic Programmer suggests you learn a new language every year. Not to the extent that you're fully proficient in it and know the APIs inside out, but to the extent that you grasp the core concepts. To be worth learning, the language should have new concepts -- but that's pretty common.

          Often a little tinkering in a language with some new paradigms, or just a shift in emphasis, can help you improve your programming style in whatever language you us

    • by Kjella (173770) on Wednesday September 14, 2011 @10:59AM (#37398896) Homepage

      The problem with the toolbox analogy is that your screwdriver never has to interact with your hammer. Software code on the other hand is notoriously bad at working with code from other languages, sure there's language bindings and and various ways of making them somewhat talk to each other but the cost of mixing languages is huge. It's more like building bits and pieces of the system to work on optical signals and the rest on electrical signals, not like pounding one nail and screwing one screw into a board.

      It's very rarely you need a programming language to do just one thing, maybe they go into specialty or research projects but anything commonly used has to be a swiss army knife. Most of the time you want to ask "Can I add another tool to this knife?" not design an entirely new dedicated knife for that purpose. There's a place to mix products for a "best of breed" solution, but languages are not it. Your narrow choice of language is likely to fail as the project expands and it really needs other sets of functionality.

      If you want to see a prime example of that, look at VBA projects that have run out of hand. Quite probably it wasn't such a bad choice for the original task, just tack on this little bit to Excel and it works. Then it grows and grows and all those limitations get very limiting and you're forced to rewrite everything. That's what happens with other narrow languages too, if you go beyond that scope it's very good at things falls apart. Not to mention all the indirect effects like the available employee pool and the complex skills required to take over.

      That is why there's a very significant drop-off in languages. I'm not saying you should try making a square peg fit a round hole, but very often the languages you, the team and the company knows and is familiar with beats trying to get everyone up to speed on a new language. But that goes for everything, should you work within the system to improve it or outside the system to overthrow it. I guess it all depends on how broken the old system is but people have a tendency to idealize the system on the drawing board.

      • by gtall (79522)

        What you describe, i.e., the dirty snowball effect happening to smaller systems as they get inflated, doesn't necessarily need a narrow programming language for it to occur. It occurs quite frequently in C and even hardware. To be fair, put yourself in a salesman/manager shoes. You have a perspective client, but it is only one. You want to give them what they want but you cannot afford a brand new development to do it. The customer relationship might blossom into big money later but you cannot know that now

      • by NF6X (725054)

        The problem with the toolbox analogy is that your screwdriver never has to interact with your hammer.

        If your screwdriver came with a lifetime warranty, then it is a hammer.

    • by Sleepy (4551)

      Your comment is so well-written irony that I can not decide if you sincere in what you say, or cleverly trolling for the other side of your argument. When you are arguing for (what seems to be) more languages merely for the sake of more languages, and presenting as evidence how you personally like to dabble in every new language... well, that incites a backlash to your argument.

      Google is very interested in bandwidth memory and power conservation. Google apps use a specific subset of Javascript, and they kno

      • by BitZtream (692029)

        Google has credibility and trust... they're not Microsoft

        Really? Cause the first thing I thought when I read this story was 'wow, this feels a lot like a Microsoft move I've seen before'.

  • Lua would be better (Score:5, Interesting)

    by Anonymous Coward on Wednesday September 14, 2011 @09:53AM (#37398230)

    Lua [lua.org] is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT [luajit.org] is incredible.

    • Lua [lua.org] is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT [luajit.org] is incredible.

      LuaJIT is not much faster anymore.

      LuaJIT gets to about 2-3X slower than the fastest gcc, while the latest JS engines (V8 with CrankShaft, SpiderMonkey with TypeInference) get to 3-5X slower than gcc. That's still a significant difference, but the JavaScript engines are also improving faster. In a year or so the difference will have vanished.

      Those numbers are also a little misleading. They are mainly simple benchmarks, where LuaJIT's tracer is phenomenal. But if you take a complete program, with a lot

  • by slim (1652) <john@nOspam.hartnup.net> on Wednesday September 14, 2011 @09:53AM (#37398232) Homepage

    It's interesting that this should come about when Javascript seems (to me) to be undergoing quite a surge.

    The community has carved out a set of practices that makes Javascript pretty satisfying to work in -- Crockford's efforts, the require/export conventions etc.

    Callback oriented programming habits learned in the browser with jQuery (etc.) have shown that Javascript lends itself quite well to that style of programming. Underscore has promoted a functional style.

    Node.js seems to be more popular than forebears such as Twisted, presumably because of all those JS-in-the-browser programmers who can apply their callback habits to Node.

    CoffeeScript is there for people who want a more expressive syntax. ... and just as people are coming around to the idea that JS isn't that bad after all, Google says "nah, it's irredeemable"

    • by Sancho (17056) *

      Whether or not Google's problems with Javascript are reasonable, it's perfectly understandable that now is the time that they would start caring so much about the future of JS. We're starting to really push the envelope, and when you do that, the shortcomings often rear their ugly heads much more dramatically.

  • by Eraesr (1629799) on Wednesday September 14, 2011 @09:54AM (#37398246) Homepage
    So what is it going to be called? Dart or Dash? The email refers to it as Dash while the older articles refer to it as Dart. It's going to be Dash then, I assume, if Google internally refers to it as Dash?
  • Forgot to mention Brightly in my submitted story! This part is FAQ of the email is interesting:

    How does this affect our cloud IDE (Brightly)?

    Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. As soon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspects of Brightly that will come on line in the future will be more Dash focused.

    We expect Brightly itself to be the first application written in Dash.

  • by OG (15008) on Wednesday September 14, 2011 @10:11AM (#37398396)
    The whole point of the "type" attribute in the script tag is that a browser can support multiple scripting languages. The introduction of Dart wouldn't necessitate dropping JS for the browser, but if other browsers implemented it (or Google created extensions for other browsers), it would provide an alternative.
    • Backwards compatibility is not just browser support, it's also the hundreds of JS libraries that don't exist for Dash/rt. It would be nice if it was designed to be interoperable with existing codebases.

      • by OG (15008)
        So many libraries exist to help with flaws/lack of functionality in vanilla JS. Perhaps the libraries that come out-of-the-box with Dart get rid of the need for such libraries (though it will probably have its own issues, thus resulting in Dart-specific libraries). And again, the libraries won't suddenly become unusable, as Javascript engines will still exist to utilize them.
  • Makes sense (Score:5, Interesting)

    by Concern (819622) * on Wednesday September 14, 2011 @10:11AM (#37398398) Journal

    Javascript is something of an accidental success. As with many languages before it, its users valiantly cope with its flaws and do their best to dress up the squalor they live in, but it's not funny for Google anymore. They have to develop, maintain, and test one of the largest JavaScript codebases in the world, and the it's-the-90's-and-I'm-high-on-cocaine-at-4am-and-it's-due-tomorrow scripting language design philosophy is not helping them. In fact the story of the last few years has been the quiet proving out of the "extra keystrokes for correctness" paradigm, from simple assertions (including "type assertions" aka good old fashioned strong typing) to unit tests to highly complex integration tests of harrowing complexity.

    If I understand correctly, Google already writes much of their JavaScript in an intermediate language that adds certain features. They have long needed a compile step anyway for compression/"obfuscation" and I suspect it was a natural outgrowth of that. This appears to be another step in the evolution of that development pipeline.

    There are many interesting developments brewing in the browser these days. I wish the browser guys luck, because I think have just a little longer to get their act together before the world gradually changes out from under them, and a purpose-designed, clever, far more powerful platform, such as Android or iOS, might actually start to change the web browser's position in the computing ecosystem. A modern scripting language is only part of the price of admission to staying relevant as a platform.

    • by dingen (958134)

      Javascript is something of an accidental success.

      Just like PHP, MySQL, Apache, HTML, Linux, the web or the internet itself for that matter. The technology of the web is a giant happy accident and it's really quite amazing it all seems to work as decent as it does.

      I'm not saying this situation is perfect and improving upon it would be bad. I'm just saying Javascript isn't any worse than all the other popular technology that makes the web tick.

      • by Concern (819622) *

        It is worse. Quite a bit worse than emerging alternatives. So much worse that the web could become gradually marginalized as a rich client platform if it isn't replaced. But don't take my word for it. Google has said so as well, and they know a thing or two about client-side scripting. PHP was originally quite simple in implementation, but it was purpose designed from the very beginning for its primary use to this day - a scripting and template language for dynamic website development. MySQL was directly in

        • by slim (1652)

          I know it's a bit pedantic to distinguish between the DOM and Javascript, but I think it's important to do so here.

          One of the ways "Javascript: The Good Parts" made JS look OK, was to exclude the DOM from the book altogether. Most people seem to agree that the DOM is a bit of a mess.
          One of the things that makes jQuery popular is that it wraps the DOM's methods with something altogether more usable and consistent across browsers.

          Your image rollovers example, for example, to me seems all about the DOM and lit

          • by Concern (819622) *

            These distinctions, while quite valid in their context, are irrelevant to the creators of alternative platforms that take a holistic approach to developer productivity and capability. Android is a platform that is composed of languages, APIs and tools that work extremely well together as a coherent whole, benefiting from synergies that can only occur as each part is made to fit with the others. HTML5 is a sloppy mess that is half attempts at incremental evolution by pragmatists who want to offer rich client

        • by SiMac (409541)

          I think this is all patently false. There are some really wonderful things about JavaScript. There were some pretty awful incompatibilities between the DOMs of major browsers, and there were/are some inadequacies in the capabilities afforded to JavaScript. However, none of these are reasons to knock the language itself. You haven't named any flaws in JavaScript as a language, and there are a lot of things that JavaScript does really well. Try doing what an asynchronous XMLHttpRequest does in Python, or Java

      • by w_dragon (1802458)
        All the things you list there have either full standards specifications or high-quality documentation. To me that is the thing missing from javascript.
    • They have to develop, maintain, and test one of the largest JavaScript codebases in the world, and the it's-the-90's-and-I'm-high-on-cocaine-at-4am-and-it's-due-tomorrow scripting language design philosophy is not helping them.

      Code to maintain
      High on cocaine
      Google is ready, time to take heed
      Cruft up ahead
      Hacks left behind
      Google, release something before I lose my mind

  • It seems to be taken as a given in this document that Javascript is unusable.... But there is no explanation of why this is the case (except perhaps for google's business needs) - what exactly is the problem with it? Performance is quite good these days thanks in large part to google's chrome folks. Few languages are easier to use, but it is still quite powerful.

    • Re: (Score:2, Informative)

      by juancn (596002)
      There are a few things wrong with it. Which do not matter much for small-ish code bases, but tend to be a pain for larger products. For me most revolve around the interpreted nature and the lack of types.

      Off the top of my head:

      • Performance: Current javascript engines are as fast as they get for an untyped language. There isn't much more you can do to speed it up. Even optional type annotations would open a large number of potential optimizations.
      • Tooling: For large projects, not having much type inform
      • by juancn (596002)

        • Load time: You have to compile javascript each time a page loads. This adds some latency that could be minimized with a proper binary format

        Pressed "post" too soon.

      • by SiMac (409541)

        Performance: Current javascript engines are as fast as they get for an untyped language. There isn't much more you can do to speed it up. Even optional type annotations would open a large number of potential optimizations.

        Tooling: For large projects, not having much type information is painful. Refactoring code becomes a guessing game (some tools do it better than others).

        Then add optional type annotations. You don't need a new language to do it.

        Load time: You have to compile javascript each time a page loads. This adds some latency that could be minimized with a proper

        JS compilation is very fast. Usually, the time it takes to load the JS is a bigger issue. However, the availability of an intermediate bytecode representation is unrelated to the semantics of the language itself. You could implement this on top of JS without a problem.

        Lack of integral/decimal numbers: This might not seem like much of a problem, but handling money with only floating point numbers is painful. Also, things such as WebGL would benefit from having better ways to deal with raw data.

        Again, you could add these on top of JS. If the only problem with JS is that it's missing features, the obvious solution is to add those features, not to throw out ever

        • by juancn (596002)
          You can extend it to your hearts content, but you might as well build something different and leave Javascript as is, completely undisturbed. It's a choice they can make.

          It is probably faster to take a chance and build an entire new language unilaterally, than gaining consensus with all the players to get the right set of modifications to a well known language (standard committees are a pain in the proverbial arse).

          Since they are planning to make their language to be able to cross-compile to Javascript, t

    • Theres a few annoying quirks around the duck typing ( e.g. 01234 gets treated as an octal number, bloody stupid decision)

      typeof is useless

      The class system is a bit klunky, but I'd far prefer it to something like Java where OO mandatory and you soon end up abstractFactoryFactoryGetter'd up the wazoo.

      There is no native include directive.

      But most of the problems are with a certain browsers inconsistent use of the DOM, dodgy standards support and bizarre bugs that never get fixed.

    • by NoNonAlphaCharsHere (2201864) on Wednesday September 14, 2011 @10:33AM (#37398624)
      Javascript is a language that combines the type-safety of Perl with the object paradigm of pre-ANSI, pre-STL C++, the power and expressiveness of Visual Basic, the ambiguity of HTML, and the readability and maintainability of C.
    • It seems to be taken as a given in this document that Javascript is unusable.... But there is no explanation of why this is the case (except perhaps for google's business needs) - what exactly is the problem with it? Performance is quite good these days thanks in large part to google's chrome folks. Few languages are easier to use, but it is still quite powerful.

      While I am not quite as aware of the problems in JS/EcmaScript as Google is, from my own extensive JS coding I can tell you that it is a pain writing JS to work on a multitude of browsers, namely because of how fractured the DOM environment is - especially when you consider supporting Internet Explorer. Getting everyone on a common DOM is itself a big enough challenge - but would very well be worth it. (That is, browser specific DOM should not be relevant to JS writers which should be able to stick to a wel

  • The language can be as great as you want. It doesn't matter if it is not supported by _all_ major browsers out there. Javascript support is probably less broken than CSS support, and you can do something and expect it to work in most browsers, most of the time. It took a long time to get there. The community is starting to build up, even using the language for server-side stuff (node.js).

    When introducing a new language, don't just tell me how awesome it is, tell me your long-term plan on how and why most pe

    • by slim (1652)

      Of course, maybe they could use some trickery and have the language compiled to .js (in addition to having its own VM) just so legacy browsers can still load a dart app and run it as js.

      This is exactly what they are doing.

  • So Google will "extend" javascript with more capabilities for the supported browsers while other browsers would get a less than optimum solution. Because of the increasing market share of Chrome, all others would be forced to start supporting Dash and perpetually play catch up. If Microsoft did this, (and it has), we all would be shouting E, E & E, (and we have).
  • Google has a history of homegrown languages. If few elsewhere in the world dont adopt it, then its not going to prosper.
  • From the horse's mouth:

    Why are you killing Javascript?
    We are not! Google has a huge interest in keeping the evolution of Javascript on track. In fact, our investment in TC39 (the Javascript standards body) will likely increase somewhat, and we will continue to honestly and whole-heartedly improve the language within the constraints.

    Besides, Microsoft will fight this all the way.

  • All languages are syntactic sugar for the IR code that gets generated. Fundamentally, all compilers translate from a Source language to a Target language (machine language in a lot of cases).

    Whether the compiler checks that the types match, that there will be overflow, that you're doing signed vs unsigned comparison - it's up to the compiler and its developers. Clearly, one compiler can have more features than the other one. To access those new features, the compiler needs to see syntactic constructs in
  • projects when they get bored, tell me again why I would invest > zero seconds of my precious time on this?

  • and we are.. "The knights who say NIH!!!"
    (Not Invented Here)
    as far as rejecting ECMAscript 4

  • When ooxml came out, M$ was wanting to come out with their own version, could this be the same thing here, where they want to have more control and be the more prominent company out there to follow for these new standards

"Our reruns are better than theirs." -- Nick at Nite

Working...