I would like to summarize few parts of that post:
on real world we should use the proper flag in order to generate files where only necessary parts of the library is included
...
I agree that at this stage can be premature to judge the quality of Dart code, once translated for JavaSript world
...
Google is a great company loads of ultra skilled Engineers
...
n.d. I have proposed a fix for Dart code
...
you may realize how much overhead exists in Dart once this is used in non Dart capable browsers
...
Was operator overload the reason the web sucks as it is?
...
everything 2 up to 10 times slower for devices, specially older one, that will never see a native Dart engine in core
...
Not Really What We Need Today
...
What are the performances boost that V8 or WebCL will never achieve ?
...
What is the WebCL status in Chromium ?
...
Where is a native CoffeeScript VM if syntax was the problem ?
...
Doesn't this Dart language look like the VBScript of 2011 ?
You can understand the whole post is not about the number of lines, it's indeed about what this extra layer means today for the current web.
I beg you to please answer my questions, any of them, so that I can understand reasons behind Dart decision.
I have also always admired Google and its Engineers, and I am asking, after GWT and Dart, why many of them seem to be so hostile against JavaScript, the programming language that made Google "fortune" on the web ( gmail, adsense, and all successful stories about Google using massively JavaScript )
Thanks for your patience and please accept my apologies since I followed the blaming mood rather than ignore it or better explain what I meant.
All of this is for a better web or a better future of the web, none of this should fall down into insults.
I think the last one is easy. Google is one of the companies with products taking JavaScript to it's boundaries (performance wise) and they realize that it just isn't fast enough. And by the design of the language, it is very hard to increase performance.
ReplyDeleteThey have improved performances 1000 times challenging JIT.
ReplyDeleteMozilla is improving performances even more challenging a tracer combined with a JIT.
Are you saying they are giving up ?
It's not a matter of giving up, but a matter of how fast can you get the code without actually breaking the guarantees given by the language (Improving performance is seldom a linear process). There will always be a difference between native and JavaScript code.
ReplyDeleteAnd while most people won't need that kind of performance, some do and can't achieve it with JavaScript.
WebCL has this aim, brings ultra fast native performances as separate process WebWorker style.
ReplyDeletetyped Arrays and future StructType, ArrayType, and ParallelsArray have the same aim.
There are tons of rooms for improvements and I don't see how starting from the scratch with something not that new and incompatible with current web can be a faster process.
Hey Andrea, stop trying to convince those Java-background programmers. It's superior to them. They can't accept the existence of Javascript and they are even more pissed off by the last achievements. Even I think that Dart is like a regret from the V8 Engine.
ReplyDeleteAs PPK said, "If you want to work with the web, learn JavaScript. If you don’t want to learn JavaScript, stay the hell away from the web". Such easy as that.
I don´t see the point in having another language and the need for an extra VM to interpret it. Sounds like Flash/Silverlight and not really open to me. In the end we have browser with Dart plugins...
ReplyDeleteThe performance talk sounds to me like the "old" C/C++ vs. Java discussion. Many results showed that Java can be almost as fast as C/C++ with some exceptions. With things like Emscripten where the compiled JS was 3 to 8 times slower than native C++ code I am sure we will reach the point where JS is nearly as fast as native C code.
I liked your post in the first place. I don´t get point of Dart and I am rather looking forward to the next versions of ECMAScript.
Unfortunately, the 70s brought so much type errors at runtime that abstract type systems were thought to be neccessary.
ReplyDeleteWith the advent of OOP I don't really believe in the necessity of typesystems, however, this myth could not be killed off.
Therefore, people need a typed version of javascript, something which ES4 was to provide for them, yet it was vetoed by Crockford basically.
I'm not talking about "JS does have types": I know it does; I talk about enforced parameter handling, which can be checked at compile time.
Of course, nothing stops anyone from introducing a coffeescript-like, yet typesafe language; with that, a lot of our blaming would be solved I guess.
As for "staying away from web"... this cannot be done unfortunately. A huge bunch of people are trained to Java at uni, and most of them end up being a java code monkey at an enterprise. Since 95+% of enterprise applications have a web frontend, they cannot avoid javascript, but man, how they wish to do so.. together with all the UI jobs...
they had already GWT !!!
ReplyDeleteHave you ever tried to _debug_ GWT?:) It's fun :) (No.)
ReplyDelete