Yeah, a few weeks old news. But yeah, their new frontend rendering 2.0 is in type script (brainfart can't remember name). Update: angularjs 2.0
In general I think Google should work with other browser such as Mozilla and Microsoft if they want a default language. I think Mozilla is firmly with Javascript seeing how they have Brendan Eich (creator of javascript).
I'm also hoping there is a good alternative to javascript supported out of the box from other browsers. No transpiler. Don't get me wrong, I've invested a lot in learning Javascript but I really dislike it when you're writing tons of lines of code. Reason being it's loosely type and dynamic.
edit:
The reason for me thinking Mozilla sticking to javascript. They have lots of project in javascript, PDF renderer, etc.. They also have already allocating resources into Rust. And for a while now Microsoft and Google have offer their take on an alternative javascript (type script & dart). I don't recall Mozilla offering any alternative to javascript.
I'm all in favour of TypeScript instead of JS. Unlike CoffeeScript (despite their 'it's just javascript') it is a superset so you can just rename .js .ts. So really TS: 'It's just JavaScript'.. but improved.
Yes, TS is improved since it comes with the top IDE: VS. :-P
Seriously though. Watching how people use IDE to code on Twitch can be so boring. Everyone is quick to suggest to step the code with the debugger. When just printing stuff to the console would be better.
I hope that TypeScript never makes it into the browsers. I would take JavaScript without the types by default. It can even be more static than it is. But please, no types by default. Types make for bloated code.
Someone yesterday spent 2 hours on Twitch dabbling with the Eclipse IDE and could not get unstuck, since they weren't even referring to the documentations or making quick changes to test their code.
In theory. In practice many of the mainstream languages make for bloated code. Yesterday I was seeing type casts and so on increasing the size of the code.
But developers can grow used to bloated code. Like they can get used to stepping the code with the debugger. I for one prefer to print debug info. On the browser I have custom code that helps with that. But I understand that many developers don't have anything like that and they have to use a standard debugger instead.
I grew used to debugging with print outs on Ruby. Before that I used to use IDEs like Delphi and Eclipse.
I also hear that one of the problems people may have on OCaml is that sometimes when they want to print some data structures they first have to make it printable. I like languages that make the structures printable by default like in Ruby.
It sounds like you want Typescript and Flow. And they already exists. We shouldn't add another high level language in the browser. Developers are happy enough transpiling code and coupling language features to browser upgrade cycles doesn't make sense.
"...Developers are happy enough transpiling code..." - happy the way disaster survivors are happy to live in makeshift sheds rather than, you know, being dead. And the number of shed designs on offer doesn't matter.
Google works on SoundScript [https://developers.google.com/v8/experiments]: graudual but sound typing for JavaScript with the goal to allow for more aggressive optimisation in the VM.
> I don't recall Mozilla offering any alternative to javascript.
Mozilla is offering two alternatives to what most people probably mean by "JavaScript" (ECMAScript 3 or 5):
1) A better JavaScript, where more of missing things people complain about are present and most of the present things people complain about have options they're less likely to complain about (though a certain famous quote by Stroustrup comes to mind).
2) JavaScript as a well-performing target, something for people whose reasons for complaining are either subjective or simply unaddressable to go to without deeply fragmenting the browser-as-runtime.
Try to read article before commenting. Most important project of Google now using Dart for client-side.
Dart tools are really great - they invested in IDE support, debugging tools, and it's a real pleasure to work with Dart. Only thing which stops me for using Dart on server-side is dynamic nature of language - I fed up by dynamic brittleness in PHP. But it's just me, and I'm sure there are billions of people who love dynamic languages.
I'll try to use Dart for client-side code, when ng2 will be more ready for experiments (routing, http, forms).
As PHP and Golang shows, solid (reach) std lib and good documentation are keys for fast and wide adoption, so I hope Dart team will also invest in std lib expanding and more human-friendly documentation. I wish them luck.
If you actually work at Google I would encourage you to do a search of the codebase for files named .*\.dart and you'll spot a broad cross-section of Google, from Google Fiber (set top box and the customer portal), to AdSense and AdWords, to Election Maps, to folks in Geo are using Dart for their front-ends.
It doesn't matter. Javascript is the default and what Google does with Dart does not matter unless everyone else is on board. This is a dumb, clickbait title.
I have experimented a lot with Dart, both client and server side. I nice language and ecosystem. Smart move concentrating on compilation to JavaScript.
Clojurescript has been my favorite client side language for a while, but I am considering jumping to Typescript - a really well designed and implemented language.
It really doesn't seem to matter which language one writes in that can be transpiled to JavaScript. Pick one you like or just use plain JavaScript. This seems to be one of those cases where you can just pick what you like - a different situation than choosing between Java or C# or Haskell, etc.
>It really doesn't seem to matter which language one writes in that can be transpiled to JavaScript. Pick one you like or just use plain JavaScript. This seems to be one of those cases where you can just pick what you like - a different situation than choosing between Java or C# or Haskell, etc.
Google should redirect the Dart project's resources toward the creation of a legibly-errored, fast, golang to js transpiler.
The open source community has already performed the heavy lifting with the gopherjs project. Google should get on board and support its own language in browser space. A project like gopherjs would take off with the weight of Google behind it: all it needs are increased examples, tutorials, and publicity.
Dart was designed to be be easy transpiled to JS. It's not possibile with Golang by design AFAIK.
Also golang is not 'C-like' syntax lang so I doubt it would get any traction among mainstream devs (java,c,c#,js).
Following your logic, one could argue that Google should drop Go and use only Dart since it's client and server since day 1. Both positions are silly IMHO.
Since I know it'll come up: no, we don't need a web bytecode. We already have JavaScript. Any new "web bytecode" would be unnecessarily reinventing the wheel, and lack most of JS's advantages.
JS is a great compiler target. In fact, modern JS even includes features to make it more optimal for this (new Math functions, for instance).
The problem with JavaScript is that it has a complex grammar which means startup times can suffer. Beyond that it does a pretty good job of substituting for a real bytecode (though it requires a bit of hoop jumping).
For the record, I did not downvote you (I actually upvoted you, since I think your comment contributes to the discussion, even though I disagree with it).
> JS is a great compiler target.
The only thing that makes Javascript an attractive compilation target is its ubiquity. The importance of ubiquity should not be discounted. Many languages have succeeded in their target markets on this basis alone, and Javascript may certainly be one of them! But let's not forget that, in almost every other way, it falls short of ideal.
Some examples:
* Very difficult to parse (while not strictly necessary for a compilation target, still very helpful)
* Esoteric type conversion system (leads to bugs)
* Lack of integral type (this can be worked around, but the fact that it needs to be worked around makes it a bad target).
* Highly dynamic type system (makes it difficult to optimize code, and a good compilation target should be easy to optimize)
* Paucity of parsers (I may be wrong, but to my knowledge, there are very few parsers that are neither (A) written in Javascript, or (B) developed as part of a browser rendering engine[0]. If I remember correctly, Facebook's Flow is one of the rare counterexamples[1].)
* Single-threaded runtime (makes it challenging to implement languages that explicitly allow parallel execution as part of their semantics)
There are ways to address each of these. For example, asm.js limits the scope of the language with the goal of increasing performance of a subset of the language. But they're still shortcomings that have to be dealt with in the first place.
Not that any compilation target is perfect in all of the above ways, but Javascript's combination of all of these makes it a very frustrating choice.
[0] For example, V8 and Spidermonkey were both originally motivated by Firefox and Chrome. The fact that so few people attempt to write their own (except in Javascript), even for fun/experimentation, should give a very rough indication of how challenging it is.
[1] Someone may be able to provide clarity on this: I know Flow is written in OCaml, and I know that at least some of the parsing happens in OCaml, but I also know that Spidermonkey is involved somehow. Is it just that the AST produced is identical to the Spidermonkey AST, or does it actually use Spidermonkey itself at some part of the parsing process?
I figured that any attempt to make a superior target language/bitcode would run into the same problem that JavaScript has of eventually needing things bolted onto it making very complex and fall short of perfect in order to fill some important use case the creators didn't think of at the time.
The Closure compiler both parses and prints JavaScript (it can be used as a minimizer) and it's written in Java.
Also, if you're writing a compiler that outputs JavaScript you need to print JavaScript, not parse it, and you can use whatever subset you like. There are hundreds of projects to do this. JavaScript is actually an easier compiler target to deal with than x86 since it's not assembly language and you can read the output, and you don't have to deal with things like register allocation.
The hard part isn't generating code; it's making it run fast and reducing the output size so it's competitive with hand-written JavaScript, having great interop with JavaScript so you can reuse existing libraries, and making the whole ecosystem easy to use (editors, debuggers, and so on). GWT was a pioneer in this and TypeScript and Dart are solid efforts. I'm also a fan of GopherJS and Elm. I'm not going to try to pick winners but I think one of them will eventually succeed.
As a target language, JavaScript would be fine if it had some additional data types like 64 bit ints. ES6 helps by adding a built-in Map type, and providing a common module system which will help interop.
Disclosure: formerly on GWT, now on Dart. But I try not to be partisan.
There's a huge win in compiling to JavaScript, though: there's a standard that more or less fully describes the language, and there are multiple competing implementations. There are weird corner cases in JavaScript, but they're at least documented. That's more than can be said for most other languages.
They use the Spidermonkey AST, but the parser is written with OCaml https://github.com/facebook/flow/blob/master/src/parser/pars... and the Lexer is generated with OCamllex, since there is support for compiling OCaml bytecode to Javascript it still runs in the Browser.
The reason this matters is that we are inherently limiting ourselves to JavaScript's characteristics. We definitionally cannot get better than JavaScript since it is our standard.
If we could get all the player involved to agree to a new Bytecode standard, we could get better performance, and better standards. We might not have to even use a new standard. JVM's bytecode could work. .NET even.
Sure, as time goes by, byte code would need improvement. It would need additions or corrections. This is just the fact of a human world. To say we shouldn't do something else because of the fact that change exists, again, limits us.
Look at what we've got with real bytecode targets. Scala, Clojure, F#, C# and VB.NET to name but a few. They each target a specific family, and they perform well. As a result of targeting a more robust bytecode, they out perform JavaScript.
While I agree that we shouldn't throw out JavaScript anytime soon, I would like to see a more efficient interchange and structure for web projects. The Web and its browsers appear to be the future. Let's try to do better than a hacked language made 25 years ago by a defunct company.
It was never going to be. Any language claiming to be the new web language needs to convince Google, Apple, and Microsoft to all cooperate and put it in their browsers.
So any language created by just one of the three of them is dead in the water.
> So any language created by just one of the three of them is dead in the water.
Have a look how Microsoft influenced JavaScript/ECMAScript 6+ with their TypeScript intermediate language lead by Anders Hejlsberg. MS shaped ES6 how they wanted, Trojan horse or "Elop" style. Not at all surprising given the companies long extensive history (IBM, DOS, OS/2, Novell, Word, Excel, Powerpoint, Internet Explorer, Nokia).
JavaScript5 is a lean and nice language if one adheres to the "Good Parts" of Douglas Crockford. Some of the ES6/7 concepts were influenced and are in the wrong direction IMHO.
> Have a look how Microsoft influenced JavaScript/ECMAScript 6+ with their TypeScript intermediate language lead by Anders Hejlsberg.
To say that Typescript influenced Javascript in anyway in revisionism(i.e. a blatant LIE)
ES6 had classes way before Typescript. Furthermore, ES6 classes and Typescript classes are different.
Typescript didn't influence ES6 at all. Most ES6 influences comes from Coffeescript and Python.
Finally you're forgetting all the ES4 fiasco (basically JS looking like ActionScript3) where Microsoft said a BIG NO.
So please explain us where you got the idea that Typescript influenced or is influencing ES6. Even if you consider annotations, Traceur(Google) had them before they were implemented by Yehuda in Typescript.
BRENDAN [Eich (JavaScript creator)]: Again, TypeScript is
smart because it’s embracing and extending. Let’s hope
Microsoft doesn’t try to extinguish. That’s the third E.
JAMISON: [Laughs]
BRENDAN: I don’t think they will. I think they actually
bought into JavaScript at some level. And I’ve talked to
people like Anders Hejlsberg about this.
I know this interview, where does it says that Typescript influenced Javascript? nowhere. In fact, as I said before, the minimal class proposal existed way before Typescript was made public. Your quote says nothing about Typescript classes being an influence for ES6, because it's not true. But perharps Eich could come here and confirm this in person.
Confirm: ES6 and the Harmony agenda influenced TypeScript. Where TS went its own way on things like open modules, MS has promised to track the Ecma standard versions ASAP.
In particular, TS classes were purely an extension to ES6's design, while ES6 was not frozen. There was not feedback the other way, at least not phrased in terms of TS -- the MS folks on TC39 had to make more generalized arguments for changing the draft ES6 spec.
Any of the three of them can and have influenced the direction of Javascript incrementally throughs standards groups and implementing features that become de facto via popularity.
None of them can replace it with another language.
snarky comments shows that we can't have fully open source and much better lang than JS (perf, sdk, lexical this, tooling, IDE) replacing JS because of...google ressentiment
What does that "switch" mean in that context? He's (publically) played with a lot of different languages because he likes trying things out. But nothing on the scale of a new commercial game, since that's not what he's intending to do any more.
Your link is from 2013, mine was from 2014. He sold Minecraft to Microsoft. So he has no pressure to develop games, he does it for fun (little games these days).
> played with a lot of different languages
He experimented with the Unity game engine and Dart+WebGL - as seen in his Twitch streams and the little games he put on his personal website. Do you have any source for your claim?
My point was more about the fact that -- as you also say -- isn't doing any professional game programming anymore. Minecraft was done in Java, but since he's only programming for fun now, I thought the term "switch" wasn't quite the right one here.
43 comments
[ 5.3 ms ] story [ 99.4 ms ] threadIn general I think Google should work with other browser such as Mozilla and Microsoft if they want a default language. I think Mozilla is firmly with Javascript seeing how they have Brendan Eich (creator of javascript).
I'm also hoping there is a good alternative to javascript supported out of the box from other browsers. No transpiler. Don't get me wrong, I've invested a lot in learning Javascript but I really dislike it when you're writing tons of lines of code. Reason being it's loosely type and dynamic.
edit:
The reason for me thinking Mozilla sticking to javascript. They have lots of project in javascript, PDF renderer, etc.. They also have already allocating resources into Rust. And for a while now Microsoft and Google have offer their take on an alternative javascript (type script & dart). I don't recall Mozilla offering any alternative to javascript.
Seriously though. Watching how people use IDE to code on Twitch can be so boring. Everyone is quick to suggest to step the code with the debugger. When just printing stuff to the console would be better.
I hope that TypeScript never makes it into the browsers. I would take JavaScript without the types by default. It can even be more static than it is. But please, no types by default. Types make for bloated code.
Someone yesterday spent 2 hours on Twitch dabbling with the Eclipse IDE and could not get unstuck, since they weren't even referring to the documentations or making quick changes to test their code.
But developers can grow used to bloated code. Like they can get used to stepping the code with the debugger. I for one prefer to print debug info. On the browser I have custom code that helps with that. But I understand that many developers don't have anything like that and they have to use a standard debugger instead.
I grew used to debugging with print outs on Ruby. Before that I used to use IDEs like Delphi and Eclipse.
I also hear that one of the problems people may have on OCaml is that sometimes when they want to print some data structures they first have to make it printable. I like languages that make the structures printable by default like in Ruby.
Anyways...
had.
It sounds like you want Typescript and Flow. And they already exists. We shouldn't add another high level language in the browser. Developers are happy enough transpiling code and coupling language features to browser upgrade cycles doesn't make sense.
Mozilla is offering two alternatives to what most people probably mean by "JavaScript" (ECMAScript 3 or 5):
1) A better JavaScript, where more of missing things people complain about are present and most of the present things people complain about have options they're less likely to complain about (though a certain famous quote by Stroustrup comes to mind).
2) JavaScript as a well-performing target, something for people whose reasons for complaining are either subjective or simply unaddressable to go to without deeply fragmenting the browser-as-runtime.
This is old news.
Dart tools are really great - they invested in IDE support, debugging tools, and it's a real pleasure to work with Dart. Only thing which stops me for using Dart on server-side is dynamic nature of language - I fed up by dynamic brittleness in PHP. But it's just me, and I'm sure there are billions of people who love dynamic languages. I'll try to use Dart for client-side code, when ng2 will be more ready for experiments (routing, http, forms).
As PHP and Golang shows, solid (reach) std lib and good documentation are keys for fast and wide adoption, so I hope Dart team will also invest in std lib expanding and more human-friendly documentation. I wish them luck.
http://developers.whatwg.org/scripting-1.html#scriptingLangu...
Clojurescript has been my favorite client side language for a while, but I am considering jumping to Typescript - a really well designed and implemented language.
It really doesn't seem to matter which language one writes in that can be transpiled to JavaScript. Pick one you like or just use plain JavaScript. This seems to be one of those cases where you can just pick what you like - a different situation than choosing between Java or C# or Haskell, etc.
Google should redirect the Dart project's resources toward the creation of a legibly-errored, fast, golang to js transpiler.
The open source community has already performed the heavy lifting with the gopherjs project. Google should get on board and support its own language in browser space. A project like gopherjs would take off with the weight of Google behind it: all it needs are increased examples, tutorials, and publicity.
Also golang is not 'C-like' syntax lang so I doubt it would get any traction among mainstream devs (java,c,c#,js).
Following your logic, one could argue that Google should drop Go and use only Dart since it's client and server since day 1. Both positions are silly IMHO.
JS is a great compiler target. In fact, modern JS even includes features to make it more optimal for this (new Math functions, for instance).
> JS is a great compiler target.
The only thing that makes Javascript an attractive compilation target is its ubiquity. The importance of ubiquity should not be discounted. Many languages have succeeded in their target markets on this basis alone, and Javascript may certainly be one of them! But let's not forget that, in almost every other way, it falls short of ideal.
Some examples:
* Very difficult to parse (while not strictly necessary for a compilation target, still very helpful)
* Esoteric type conversion system (leads to bugs)
* Lack of integral type (this can be worked around, but the fact that it needs to be worked around makes it a bad target).
* Highly dynamic type system (makes it difficult to optimize code, and a good compilation target should be easy to optimize)
* Paucity of parsers (I may be wrong, but to my knowledge, there are very few parsers that are neither (A) written in Javascript, or (B) developed as part of a browser rendering engine[0]. If I remember correctly, Facebook's Flow is one of the rare counterexamples[1].)
* Single-threaded runtime (makes it challenging to implement languages that explicitly allow parallel execution as part of their semantics)
There are ways to address each of these. For example, asm.js limits the scope of the language with the goal of increasing performance of a subset of the language. But they're still shortcomings that have to be dealt with in the first place.
Not that any compilation target is perfect in all of the above ways, but Javascript's combination of all of these makes it a very frustrating choice.
[0] For example, V8 and Spidermonkey were both originally motivated by Firefox and Chrome. The fact that so few people attempt to write their own (except in Javascript), even for fun/experimentation, should give a very rough indication of how challenging it is.
[1] Someone may be able to provide clarity on this: I know Flow is written in OCaml, and I know that at least some of the parsing happens in OCaml, but I also know that Spidermonkey is involved somehow. Is it just that the AST produced is identical to the Spidermonkey AST, or does it actually use Spidermonkey itself at some part of the parsing process?
Also, if you're writing a compiler that outputs JavaScript you need to print JavaScript, not parse it, and you can use whatever subset you like. There are hundreds of projects to do this. JavaScript is actually an easier compiler target to deal with than x86 since it's not assembly language and you can read the output, and you don't have to deal with things like register allocation.
The hard part isn't generating code; it's making it run fast and reducing the output size so it's competitive with hand-written JavaScript, having great interop with JavaScript so you can reuse existing libraries, and making the whole ecosystem easy to use (editors, debuggers, and so on). GWT was a pioneer in this and TypeScript and Dart are solid efforts. I'm also a fan of GopherJS and Elm. I'm not going to try to pick winners but I think one of them will eventually succeed.
As a target language, JavaScript would be fine if it had some additional data types like 64 bit ints. ES6 helps by adding a built-in Map type, and providing a common module system which will help interop.
Disclosure: formerly on GWT, now on Dart. But I try not to be partisan.
Irrelevant for a compiler target.
> * Esoteric type conversion system
Mostly not an issue, because compilers are not producing code using the type conversions.
> * Lack of integral type
JavaScript has integer support up to 32-bit, it just doesn't have 64-bit.
The reason this matters is that we are inherently limiting ourselves to JavaScript's characteristics. We definitionally cannot get better than JavaScript since it is our standard.
If we could get all the player involved to agree to a new Bytecode standard, we could get better performance, and better standards. We might not have to even use a new standard. JVM's bytecode could work. .NET even.
Sure, as time goes by, byte code would need improvement. It would need additions or corrections. This is just the fact of a human world. To say we shouldn't do something else because of the fact that change exists, again, limits us.
Look at what we've got with real bytecode targets. Scala, Clojure, F#, C# and VB.NET to name but a few. They each target a specific family, and they perform well. As a result of targeting a more robust bytecode, they out perform JavaScript.
While I agree that we shouldn't throw out JavaScript anytime soon, I would like to see a more efficient interchange and structure for web projects. The Web and its browsers appear to be the future. Let's try to do better than a hacked language made 25 years ago by a defunct company.
So any language created by just one of the three of them is dead in the water.
Have a look how Microsoft influenced JavaScript/ECMAScript 6+ with their TypeScript intermediate language lead by Anders Hejlsberg. MS shaped ES6 how they wanted, Trojan horse or "Elop" style. Not at all surprising given the companies long extensive history (IBM, DOS, OS/2, Novell, Word, Excel, Powerpoint, Internet Explorer, Nokia).
JavaScript was always a prototype inheritance based language, with ES6 it got the "class" keyword (syntactic sugar) from class inheritance based language (Java or the inspired C# from Hejlsberg): http://en.wikipedia.org/wiki/Prototypal_inheritance , http://en.wikipedia.org/wiki/TypeScript , http://en.wikipedia.org/wiki/JavaScript , http://en.wikipedia.org/wiki/Anders_Hejlsberg , http://en.wikipedia.org/wiki/Stephen_Elop (Ex-MS, Ex-Nokia, MS Trojan horse)
JavaScript5 is a lean and nice language if one adheres to the "Good Parts" of Douglas Crockford. Some of the ES6/7 concepts were influenced and are in the wrong direction IMHO.
To say that Typescript influenced Javascript in anyway in revisionism(i.e. a blatant LIE)
ES6 had classes way before Typescript. Furthermore, ES6 classes and Typescript classes are different.
Typescript didn't influence ES6 at all. Most ES6 influences comes from Coffeescript and Python.
Finally you're forgetting all the ES4 fiasco (basically JS looking like ActionScript3) where Microsoft said a BIG NO.
So please explain us where you got the idea that Typescript influenced or is influencing ES6. Even if you consider annotations, Traceur(Google) had them before they were implemented by Yehuda in Typescript.
In particular, TS classes were purely an extension to ES6's design, while ES6 was not frozen. There was not feedback the other way, at least not phrased in terms of TS -- the MS folks on TC39 had to make more generalized arguments for changing the draft ES6 spec.
regards.
None of them can replace it with another language.
I would certainly have added Mozilla to the list. Just look what's happening with asm.js, which is really the closest thing to what's being discussed.
It didn't get adopted by the others until much later and it's certainly winning in its particular niche.
e.g. a Doom renderer in Dart: https://github.com/xNotch/dark , http://notch.net/2014/09/doom/
http://notch.tumblr.com/post/58707926941/so-thats-what-im-go...
> played with a lot of different languages
He experimented with the Unity game engine and Dart+WebGL - as seen in his Twitch streams and the little games he put on his personal website. Do you have any source for your claim?