Vorheriger Artikel Nächster Artikel

Dart: 10 Punkte, in denen es JavaScript übertrifft

Googles Programmiersprache Dart ist zwar noch „in der Mache“, aber es lohnt sich schon heute, einen Blick darauf zu werfen. Dieser Post nennt euch zehn Punkte, in denen Dart besser ist als – oder zumindest logischer und konsequenter aufgebaut.

Dart: 10 Punkte, in denen es JavaScript übertrifft

Was Dart ist

Dart ist eine von entwickelte Programmiersprache, die mittlerweile als Open-Source-Projekt verfügbar ist. t3n hat über Dart bereits letztes Jahr berichtet. Derzeit befindet sich die Sprache im technischen Preview und ist noch nicht produktiv zu verwenden, aber man kann schon prima damit rumspielen.

Aus Dart kann JavaScript generiert werden (ähnlich dem CoffeeScript Ansatz) oder es kann nativ im Browser laufen. Es gibt bereits Webkit- und Chrome-Branches, die Dart unterstützen sollen. Trotzdem: Es wird noch einige Zeit vergehen, bis man wirklich von einer weiten „nativen“ Unterstützung von Dart in den Browsern sprechen kann.

Aber wie erwähnt: Glücklicherweise kann man aus Dart auch JavaScript machen, weshalb die Sprache trotzdem interessant ist.

Screenshot der offiziellen Website zu Dart.

Warum ich mich mit Dart beschäftige

Aber warum das Ganze? JavaScript ist immerhin weit verbreitet und hat viele Anhänger gefunden.

Vor zirka einem Jahr begann ich mich ernsthaft mit JavaScript zu beschäftigen. Ich komme aus der Java-Welt und musste daher einiges lernen, bevor ich wirklich produktiv arbeiten konnte. Die Art zu Denken unterscheidet sich doch sehr zwischen Java und JavaScript.

Manche Leuten sagen, dass man sich besonders tief mit JavaScript beschäftigen muss, ansonsten könne man nicht über die Vor- und Nachteile diskutieren. Ich bin nun wirklich kein JavaScript-Ninja. Aber ich glaube fest daran, dass eine Sprache leicht zu erlernen und leicht zu verstehen sein sollte. Zudem sollte eine Sprache konsequent sein, wenn es um Syntax und Konzepte geht.

Auch jetzt, nachdem ich bereits so lange Zeit mit JavaScript gearbeitet habe und dessen Schwächen kenne, muss ich leider sagen, dass ich immer noch sehr, sehr, sehr vorsichtig arbeiten muss, wenn es um mein tägliches Brot geht. JavaScript hat ein paar sehr gute Ideen - aber trotzdem: Die fehlende Sicherheit beim Entwickeln empfinde ich als sehr nachteilig. Eine Sprache sollte den Entwickler unterstützen - und nicht umgekehrt.

Ich habe im Folgenden 10 Punkte aufgelistet, die mich besonders mit meiner täglichen JavaScript-Arbeit beschäftigt haben und die jetzt mit Dart gelöst werden (sollen). Wegen dieser Punkte - aber nicht nur - werde ich irgendwann zu Dart wechseln. Dabei darf man aber nicht vergessen, dass Dart immer noch „in der Mache“ ist und sich somit noch einiges verändern kann – ungefragt und jederzeit.

1. Dart kennt nur einen "falsify" Wert

In diesem Post kann man recht schnell sehen was ich meine. Die Werte: false, null, undefined, "", 0, NaN in JavaScript gelten als „false“. Das heißt, man kann solche Dinge machen:

var a = null;
if(!a) {
   // do
}

In Dart gibt es nur einen Wert der „false“ ist, nämlich „false“ selbst. Natürlich muss man den pre dann etwas anders schreiben:

var a = null;
if(a != null) {
   // do
}

Sechs verschiedene Ausdrücke, die „false“ ergeben - das muss man erstmal wissen.

2. Dart arbeitet mit Typen, wenn man das will

JavaScript-Entwickler sagen oft, dass Typen die Flexibilität reduzieren. Okay, das mag wahr sein. Aber zu viel Flexibilität reduziert auch die Qualität der Software ;-) Manchmal will man eben mit Typen arbeiten, und Dart erlaubt es einem, wenn man es möchte. Man muss einfach nur den Typechecker anschalten, schon kann man damit loslegen.

3. Man braucht ein weiteres Framework in JS um gut mit dem DOM arbeiten zu können

In JavaScript gibt es unsere alten Freunde:

getElementsById()
getElementsByTagName()
getElementsByName()
getElementsByClassName()
querySelector()
querySelectorAll()
document.links
document.images
document.forms
document.scripts
formElement.elements
selectElement.options

Ganz schön viel. Glücklicherweise haben wir jQuery und Co, die uns aus dieser Geschichte raushelfen. Aber, sollte es heutzutage wirklich noch nötig sein, ein extra Framework einzubinden, nur um mit dem DOM zu arbeiten? Eigentlich doch nicht.

Dart hat sich jQuery ansehen und daraus genau zwei Methoden abgeleitet:

elem.query('#foo');
elem.queryAll('.foo');

Besser.

4. Klassen und Interfaces

Wenn Java-Entwickler mit JavaScript anfangen, versuchen sie oft, JavaScript so zu programmieren wie sie auch Java schreiben würden. Da gibt es dann Konstruktoren und klassenähnliche Elemente. Das ist aber nicht im Sinne des Erfinders und sollte anders gemacht werden: JavaScript ist eben Prototyp-basiert, alles ist ein Objekt. Das ist ziemlich cool. Auf der anderen Seite kann man die Gang of Four Patterns weitgehend außer acht lassen und anstelle dessen ein Buch über JavaScript Patterns lesen.

Ich habe in meiner Laufbahn einige Entwickler getroffen, die bereits sehr lange Zeit benötigt haben, um die gängigen Patterns zu verstehen. Nicht jeder ist ein Geek. Eine Sprache, die nicht Mainstream ist, in einer Mainstream-Umgebung zu verwenden, führt geradewegs in das Zentrum des absoluten Chaos.

5. Vererbung

Dr. Rauschmayer erklärt in seinem ausgezeichneten Blogpost, warum JavaScript-Vererbung einfach ist - und da hat er recht. Es ist wirklich einfach. Aber aufgepasst: Dies ist nicht die einzige Art, wie man Vererbung durchführen kann. jQuery und das Prototype-Framework haben sogar eine extra „extend“-Methode. Anstelle von dem von Dr. Rauschmayer empfohlenen __proto__ kann man das prototype Keyword verwenden (in diesem Post wird sogar von Klassen gesprochen, auch wenn es gar keine Klassen in JavaScript gibt). Natürlich kann man auch seinen eigenen Mechanismus entwickeln und jede Eigenschaft einfach selbst kopieren.

Diese Seiten waren Suchergebnisse von Google, wenn man nach den Wörtern „javascript object extends“ sucht. Es ist eigentlich ziemlich viel, was man lesen kann, obwohl es eigentlich nur ein recht einfaches Ziel zu erreichen gilt: Erweiterung.

Nicht jeder liest Dr. Rauschmayers Blog. Schade, denn das Leben wäre recht viel einfacher, falls das so wäre.

Dart kennt Klassen und kennt auch das „extends“ Schlüsselwort. Ziemlich einfach.

ECMAScript 6 soll das übrigens bereinigen (Spec wird 2013 beendet werden).

6. Globaler Namespace

In JavaScript muss man aufpassen, damit man nicht einfach Zeugs in den globalen Namensraum legt. Das kann ehrlich gesagt ziemlich einfach passieren. Falls man ein „this“ oder ein „var“ vergisst, hat man Variablen auf globalen Level. Jedes Skript hat dann Zugriff darauf. Das ist eigentlich ziemlich schrecklich und sollte verhindert werden. Dank dem Buch von Stoyan Stefanovs namens JavaScript Patterns habe ich ein Pattern gelernt, wie man den Namensraum sauber halten kann. Jetzt geht es mir besser und ich habe wieder mehr Kontrolle über das, was ich tue. Leider brauche ich dafür ein Pattern. Das sollte eigentlich „out of the box“ geliefert werden.

In Dart entwickelt man im „Library“-Scope. Das bedeutet, das Keyword „Library“ verschließt ein Dart-„Paket“ so, dass nur öffentliche Felder, Methoden und Klassen von außen zugänglich sind. Zusätzlich wird jedes Dart-Skript als eigenes Isolate ausgeführt. Das heißt, es hat einen eigenen State und kann nicht auf den State der anderen Skripte zugreifen. Mit Dart muss man zwar immer noch über Sichtbarkeit und Bibliotheken nachdenken, aber es ist sehr viel einfacher und man braucht sicherlich auch kein Buch dafür. Anstelle davon sollte man eigentlich nur über „Separation of concerns“ nachdenken müssen.

7. Dart kennt Nebenläufigkeit

Mit JavaScript sind die Dinge nicht wirklich nebenläufig. Sogar wenn man einen asynchronen Zugriff mittels jQuery durchführt, befindet man sich immer noch in einem „Thread“. Mit V8 scheinen die Dinge anders zu laufen, aber genaueres weiß ich darüber nicht. Umgehen kann man dieses Problem mit HTML5 und Webworkern.

Dart kennt Isolates. Das ist damit ähnlich wie in Erlang. Isolates können miteinander kommunizieren. Wenn ein Isolate zusammenbricht, kann es neu gestartet werden. Das ist ziemlich cool. Natürlich machen Isolates Dart auch für die serverseitige Entwicklung interessant. Und ja, ich habe von Node.js gehört. Aber das ist nicht der Punkt: Dart kann das nämlich von sich aus.

8. JavaScript kennt kein foreach.

Aber Moment. Object oder Array.prototype kann erweitert werden. Das ist natürlich nett.

Für Arrays kann man natürlich auch das machen:

for (var i = 0; i < elements.length; i++) {
  // do something
}

Und man kann das für Objekte machen:

for (key in elements) {
  alert(elements[key]);
}

Douglas Crockford empfiehlt dies jedoch nicht. Er sagt, die Ergebnisse sind nicht geordnet und man kann natürlich auch die Eigenschaften der prototyp-Kette sowie Funktionsnamen sehen. Die man wiederum mit hasOwnProperty ausfiltern könnte.

Letztlich kann man natürlich auch in ein Framework wie jQuery sehen, die sowas wie forEach anbieten.

Zu guter Letzt sei gesagt, dass ECMAScript 5 foreach für Arrrays kennt. Zumindest alle modernen Browser unterstützen das also. Dazu gehört der Internet Explorer 8 aber offensichtlich nicht und der ist dummerweise noch im Einsatz.

In Dart:

for (element in elements) {
  // do something
}

Das Leben ist damit entspannter. Damit iteriert man über eine Liste mit Elementen.

9. Seltsames Initialisieren von Arrays

Das habe ich mir ausgeliehen. Man sehe sich Folgendes an:

var a1 = new Array(1,2,3,4,5);
var a2 = new Array(5);

a1 ist ein Array mit 5 Elementen: [1,2,3,4,5] a2 ist auch ein Array mit 5 Elementen: [undefined,undefined,undefined,undefined,undefined]

Dart ist da sauberer. Ein Array ist hier einfach eine Liste und hat eben ein solches Interface.

List a1 = [1,2,3,4,5];
List a2 = new List(5);

Auch hier enthält a1 fünf verschiedene Elemente, a2 enthält nur den Platz für 5 Elemente. Zusätzlich bekommt man Methoden wie „removeRange“ oder zur Sortierung, wie man in obigen Link von Seth Ladd kann.

10. undefined und null

Es gibt viel zu lernen, wenn man mit JavaScript anfängt. Darunter ist die Weisheit, dass es nicht nur null gibt - sondern auch undefined. Dabei handelt es sich um einen Typ mit nur einem Wert: undefined. Dieser kann überschrieben werden. Und den kann man quasi jederzeit bekommen, zum Beispiel wenn man return aufruft aber keinen Wert zurückgibt. Auf der verlinkten Seite kann man lesen, wie man mit undefined umgeht, wenn man sich vor einem versehentlichen Überschreiben schützen will.

In den meisten Fällen kann wohl null mit undefined ersetzt werden.

Das ist krank.

Dart kennt nur ein null.

Zusammenfassung

JavaScript hat natürlich auch seine guten Seiten. Es gibt einige sehr nette Patterns. Aber derzeit habe ich nichts gefunden, was ich nicht auch mit Dart machen könnte. Dart ist meistens eleganter und lesbarer (meiner Meinung nach). Natürlich werden einigen Hardcore-JavaScript Entwickler dem nicht zustimmen. Aber das ist okay. Man muss JavaScript mögen, wenn man damit arbeiten will. Dart dagegen ist Mainstream. Es gibt kaum böse Überraschungen.

P.S.: In meiner Liste habe ich die EventHandler vergessen, die in Dart sehr gelungen sind.

P.P.S.: Außerdem habe ich die Verwirrung, die das this-Schlüsselwort in JavaScript bietet, vergessen. Vielleicht findet sich ja noch mehr für eine zweite Liste...

Über den Gastautor

Christian ist selbstständiger Software Entwickler und Trainer. Er ist Member der Apache Software Foundation und schreibt außerdem Fachartikel über Java, Dart & PHP. Dieser Artikel erschien zuerst auf Englisch in seinem Blog unter www.grobmeier.de

NEU: Lass dir diesen Artikel vorlesen
Ein Service von t3n, in Kooperation mit Narando.
Vorheriger Artikel Zurück zur Startseite Nächster Artikel
37 Antworten
  1. von Felix am 14.01.2012 (13:16 Uhr)

    netter Artikel, danke dafür
    Ich werde mir bei Zeiten auch ein Mal dart ansehen, komme mit Javascript auch nicht so gut klar.. ;)

    Antworten Teilen
  2. von Christian Grobmeier am 14.01.2012 (21:43 Uhr)

    @Felix, danke für den Kommentar :-) Wenn du "up to date" bleiben willst ist http://www.dartosphere.org eine gute Wahl.

    Antworten Teilen
  3. von Tristan Lins am 15.01.2012 (13:02 Uhr)

    Interessante Betrachtungsweise, aber alles in allem die eines Java Entwicklers der "nur statische Typisierung und unveränderbare Klassenhierarchien kennt" ;-)
    Du hast in deinem Artikel viele Punkte angesprochen, die typischen Fallstricke eines Java-Entwicklers sind, der diese Art Flexibilität nicht kennt. PHP Entwickler würden da schon deutlich weniger Probleme haben. Abgesehen davon, dass man diese Dynamik erstmal verstehen und deren Eigenarten lernen muss, hast du in einem Punkt mehr als recht: Die Dynamik verleitet zu "unschönen" Programmieren.

    Ich entwickel selbst regelmäßig in PHP, JavaScript und auch in Java, ich liebe Java aufgrund seiner fixen Strukturen, ich muss mich nicht darauf konzentrieren, guten Code zu schreiben, da mich die Programmiersprache auf einheitliche Muster begrenzt oder wie du sagst "Das sollte eigentlich „out of the box“ geliefert werden.". Das reduziert keinesfalls die Flexibilität von Java, aber auch hier muss man diese Muster oder Pattern erst einmal lernen, wie in jeder anderen Programmiersprache auch.

    Ich definiere den "Aufwand" für "good coding" in diesen 3 Programmiersprachen so:
    - Java: guter Code, bei geringer Eigen Disziplin
    - PHP: guter Code, bei mittelmäßiger Eigen Disziplin
    - JavaScript: guter Code, bei hoher Eigen Disziplin

    Das Problem von "bad coding" ist in meinen Augen kein Problem der Programmiersprache (diese ist nur ein Werkzeug), sondern wie der Entwickler damit umgeht.

    Obwohl ich regelmäßig in JavaScript arbeite, kann ich mich nicht als JavaScript Ninja bezeichnen. Dennoch glaube ich JavaScript gut genug zu kennen, um mitreden zu können. Ich selbst bin auch gespannt auf Dart, weil es weniger von mir abverlangt um guten Code zu schreiben und mehr Struktur in die Programmierung bringt. Oder anders ausgedrückt: Für Dart reicht mir ein A4 Cheat Sheet, während ich für JavaScript ein A2 Cheat Sheet brauche ;-)

    Antworten Teilen
  4. von Christian am 16.01.2012 (09:56 Uhr)

    @Trsitan, da gebe ich dir recht. Ich bin PHP und Javascript Entwickler und finde es recht einfach zu verstehen. Als ich vor ca 2 Jahren mit Javascript angefangen habe bin ich kurz darauf in Jquery eingesteigen und ich liebe es damit zu arbeiten. Vielleicht ist Dart ja wirklich besser wenn es mal offiziel raus kommt aber bis dahin nutze ich weiter jQuery.

    Antworten Teilen
  5. von passsy am 16.01.2012 (10:34 Uhr)

    Habe es selber vor einigen Wochen ausprobiert. Ohne mir die Referenz durch zu lesen konnte ich mir Java und js Hintergrund ohne Probleme programmieren. Am Schluss wird das ganze ja dann sowieso in js konvertiert. Das fand ich dann schade. Ich hätte gehofft, dass zumindest der Chrome das schon nativ unterstützt. So wird nämlich hallo welt schon hunderte kb groß. Das möchte ich einem Nutzer nicht zumuten. Vor allem nicht, wenn ich an große Projekte denke. Dann werden das schnell mal MB

    Antworten Teilen
  6. von Tristan Lins am 16.01.2012 (10:43 Uhr)

    @passsy
    Es gibt schon eine Entwicklungsversion von Chrome, die eine native Dart Engine besitzt. Wenn Dart finalisiert ist, wird die Dart Engine sicher zeitnahe in den Chrome überführt :-)

    Antworten Teilen
  7. von Christian Grobmeier am 16.01.2012 (11:04 Uhr)

    Hallo,

    @Tristan: ich muss die leider mitteilen, dass ich selbst viele Jahre in PHP entwickelt habe (seit 1998) und es immer noch (Open Source: PIWI Framework und Apache log4php) tue. Obwohl ich mich -beruflich- fest in der Java Welt verwurzelt sehe, habe ich also durchaus Erfahrung mit PHP und nicht-getypten Sprachen. Daher waren (fehlende) Typen bei JavaScript nie mein Problem.

    Wie ich finde, muss man sich auch bei Java darauf konzentrieren, guten Code zu schreiben. Klar, ich muss auch hier Patterns lernen: aber eben nur die, die Erich Gamme et al zusammengeschrieben haben. Diese Patterns gelten für viele Sprachen. JavaScript ist eine große Ausnahme, man benötigt andere Patterns. Und zwar welche, die zum Beispiel den Namespace sauber halten sollen. Das ist ein Pattern, das aufgrund einer Sprachschwäche erfunden wurde. Das sind die Patterns die ich bemängle und die meines Erachtens das JavaScript lernen unnötig erschweren. In Ruby musste ich auch erst gewisse Eigenschaften der Sprache erlernen, jedoch kein Pattern, dass eine Sprachschwäche umschifft.

    Ich möchte hier noch anmerken, dass ich auf keinen Fall ein JavaScript Gegner bin. Die Sprache hat seine Vorzüge, wie auch im Artikel erwähnt. Allerdings habe ich auch Projekte geleitet, die mit 10 - 15 Entwicklern besetzt waren. Wenn ich mir da vorstelle, dass diese Menge an Leuten mit "Selbstdisziplin" aufwarten müssen, oder wie der ein oder andere in eine JavaScript Falle stolpert, die man einfach kennen muss, dann wird mir übel. Möglicherweise hat man ja mal JavaScript Geeks auf dem Projekt, aber man kann nicht im Regelfall davon ausgehen. Man kann ja nicht mal davon ausgehen, dass sich Projektbeteiligte überhaupt ernsthaft mit einer Sprache auseinander setzen, die am Projekt eingesetzt wird: der Manager lässt kein Budget für Fortbildung zu, und zu Hause wollen die Kinder Aufmerksamkeit. Wie soll sich Otto Normalentwickler dann noch mit JS Stolpersteine auseinandersetzen? Daher muss eine Programmiersprache, die auf großen Projekten eingesetzt wird, gewisse Rahmen aufweisen, die Fehler ausschließen. ECMAScript wird ja auch weiterentwickelt und geht genau in diese Richtung. Wie man so hört soll ECMAScript 6 einige Schwächen ausmerzen. Wenn dann noch alle Browser ECMAScript 6 unterstützen, dann ist es durchaus interessant. Derzeit is aber doch schon wieder so, das der IE8 foreach von ECMAScript 5 nicht unterstützt.

    Und so weiter, ein endloses Thema. Was ich sagen will, ist, JavaScript ist schon toll, für diejenigen, die denn da wissen was sie tun. Aber es ist nicht pauschal-toll für alle, den man muss auch mit normal-sterblichen Entwicklern arbeiten, die nicht immer genau wissen was sie tun, aber trotzdem damit umgehen sollen.

    @Passsy: Wie Tristan schon erwähnt hat, gibt es mit Dartium einen Browser der Dart native unterstützt. Es gibt auch einen WebKit Branch, der Dart native unterstützt (wird aber kontrovers diskutiert). Wenn du so großes JS nach dem kompilieren erhalten hast, dann verwendest du den Standard-Compiler "DartC". Es gibt jetzt aber schon "Frog", einen Transkompiler der wesentlich optimierteres JS erstellt. Der ist seit neuestem auch im Dart Editor verfügbar. Ein Blogpost, der dich hierzu vielleicht interessiert: http://blog.sethladd.com/2011/12/10-lessons-from-porting-javascript-to.html

    Gruß und Danke für die freundlichen Kommentare! Da hab ich auch schon andere Diskussionsarten zu dem Thema erlebt :-)

    Christian

    Antworten Teilen
  8. von Tristan Lins am 16.01.2012 (11:27 Uhr)

    @Christian
    ich hatte deinen Beitrag auch nicht JavaScript feindlich aufgefasst ;-)
    Natürlich gibt es viele "Stolpersteine" in JavaScript, die andere Programmiersprachen nicht haben. Vor allem erschreckend ist in diesem Zusammenhang, dass die Sprachen JavaScript, PHP, Ruby und Java alle im Jahr 1995 das erste mal aufgekommen sind (laut Wikipedia) und JavaScript trotzdem so hinterher hinkt. Ich denke vieles an der langsamen Weiterentwicklung ist einfach historisch bedingt, man kann eine ganze Sprache ja nicht einfach so über den Haufen werfen. Andererseits denke ich, dass man durchaus merkt, dass hinter PHP, Ruby und Java keine Standardisierungsorganisation wie die ECMA steht, sondern eine Gruppierung/ein Unternehmen, die zwar auch auf äußere Wünsche hören, aber letztlich selbst die Entscheidung fällen können und sich somit langfristige Umfrage/Diskussionsrunden ersparen können.
    Natürlich ist auch der größte Feind der WWW-Weiterentwicklung auch nicht ganz unschuldig daran ;-)

    Also ich habe mich nur Ansatzweise mit Ruby beschäftigt, finde aber dass es auch bei Ruby einige Paradigmen gibt, die Ruby einzigartig sind. Z.B. der Umgang mit Listen/Arrays/Collections ist sehr "gewöhnungsbedürftig". Erinnert mich von der dahinterstehenden Idee irgendwie an deklarative Programmiersprachen :-D

    Antworten Teilen
  9. von Christian Grobmeier am 16.01.2012 (12:08 Uhr)

    @Marco Anderson: ich glaube auch, dass es noch einige Zeit brauchen wird, bis Dart von *allen* Browsern native unterstütz wird. Oder überhaupt - immerhin gibt es auch sehr starke Gegenstimmen, wie ich hier mal zusammengefasst habe (leicht veraltet): http://dartvader.grobmeier.de/google-dart-bald-native-auf-webkit-08122011.html

    Warten würde ich darauf jedenfalls nicht. Allerdings bietet sich mit Dart noch mehr an: Dart könnte recht bald native auf Android laufen (anstelle oder neben Java) und natürlich auch auf der Google App Engine. Damit wäre die fehlende Browserunterstützung dank Frog noch zu verschmerzen.

    Antworten Teilen
  10. von Christian Grobmeier am 16.01.2012 (12:12 Uhr)

    @Tristan: hehe, wie kannst du in deinem Kommentar nur den wundervollen JCP kritisieren ;-)

    Ich geb dir auf jedenfall recht, was die Weiterentwicklung von ECMA angeht. Es ist kein Wunder, dass jemand eine Alternative zu diesem recht "schwerfälligen" Prozess anbieten will, wenn man so darüber nachdenkt.

    Was Ruby angeht, die Collections sind wirklich gewöhnungsbedürftig, die hatte ich jetzt ganz vergessen - aber mein Kritikpunkt ist ja nicht die Syntax an sich, sondern die Menge an impliziten Wissen, das man haben muss, um ordentlich und einigermaßen sicher zu entwickeln. Aber ich sehe, wir haben schon in etwa das gleiche Verständnis

    Antworten Teilen
  11. von kernel am 16.01.2012 (12:40 Uhr)

    Die ganzen Punkte die der Christian Grobmeier anspricht sind nicht wirklich als "besser" oder "schlechter" zu bewerten, Dart ist maximal an Javascript orientiert, mehr nicht. Am Beispiel punkt 7 - Nebenläufigkeit - zeigt sich, dass der Author ein echter Java Programmierer ist und JavaScript nicht zu nutzen weiß. Anscheinend hat er nicht verstanden, dass event-gesteuerte NonBlocking-IO einfach mal besser ist als tausende Threads die man per Semaphore etc. steuern darf - was, bei allem Respekt, echter Brainfuck sein kann.

    Dart wird vorallem seine Schwierigkeiten haben sich im großen Markt zu positionieren bzw. zu beweisen, dass es nicht nur einfach eine neue Sprache ist die "genau das kann was andere können nur anders" und wenn es sowieso 1zu1 in JS verwandelt werden kann, wie der Author beschreibt, ist es meiner Meinung nach mehr syntaktischer Zucker. Mich würde jedoch interessieren wie die Nebenläufigkeit in eine Singlethreaded Umgebung transformiert wird.

    Klärt mich auf.

    P.S.: und Javascript KENNT forEach, es wird nur noch nicht von allen Engines unterstützt. Wer mit V8 arbeitet darf sich über das hier freuen http://www.tutorialspoint.com/javascript/array_foreach.htm

    Antworten Teilen
  12. von Tristan Lins am 16.01.2012 (12:52 Uhr)

    @kernel
    das NonBlocking-IO hat im Event bereich sicher seinen Scharm, aber es gibt Anwendungsfälle, wo echte Parallelisierung durchaus sinnvoll ist, vor allem bei immer größer und komplexer werdenden JS-UIs mit komplexen Verarbeitungsprozessen, bei denen das aktuelle Verhalten von JS schnell zu einem Freeze der UI führt. Dafür gibt es aber die WebWorker und ich vermute mal, dass der Dart-JS-Compiler diese auch für die Parallelisierung nutzen wird.

    Antworten Teilen
  13. von kernel am 16.01.2012 (13:04 Uhr)

    @Tristan was dann auch die Transformierung von Threaded zu SingleThreaded erklären würde.

    Aber nach wie vor bleibt für mich: Dart ist wie CoffeeScript lediglich syntaktischer Zucker - flavoured by Google.

    Antworten Teilen
  14. von Christian Grobmeier am 16.01.2012 (13:05 Uhr)

    @Kernel:

    Dart ist nicht (nur) an JavaScript orientiert. Sicherlich verwendet es von dort Elemente, aber nicht nur. Auch von Erlang, Java und .NET wird fleißig geborgt bzw aus dessen Erfahrungen gelernt. Ich persönlich (! - wie ich das auch am Anfang meines Posts festgestellt habe) empfinde es so, dass die 10 erwähnten Punkte mit Dart besser gelöst sind. Du siehst es offenbar anders, das ist OK.

    Ich persönlich sehe es auch so, dass Dart Isolates besser ist als Java Multithreading. Isolates sind eher an Erlang als an Java orientiert. Es bieten sich unglaublich gute Dinge damit, zum Beispiel kann man via Isolates transparent auf verschiedenen Maschinen kommunizieren (derzeit in Planung). Mit JavaScript gibt es (außer mit V8 bzw WebWorkern) keine echte parallele Verarbeitung.

    Wie du darauf zurück schließen kannst, dass ich JavaScript nicht zu nutzen weiß, ist mir irgendwie schleierhaft. Ich habe es ausprobiert und bin zu so einer Meinung gekommen. Ich hab mich jetzt einige Zeit damit beschäftigt, und wenn ich immer noch nicht wüsste, wie man mit JavaScript denkt, ist das nur eine weitere Schwäche der Sprache, aber nicht meine. Allerdings ist dem nicht so. Ich nutzte selbst eine Menge JavaScript und denke, dass man als Entwickler von einer religiösen Verehrung einer jeglichen Sprache absehen muss. JavaScript hat Schwächen, das bestreitet (fast) niemand. Trotzdem hat JavaScript auch Stärken, die zu unglaublich geilen Code führen können. Ich denke, man darf sich durchaus auch mal negativ über JavaScript äußern, trotz des derzeitigen Hypes. Man sollte eben immer das beste Werkzeug für eine Aufgabe wählen. Manchmal ist das JavaScript. Aber manchmal wird das - zumindest für mich - Dart sein.

    Dart wird sicherlich Schwierigkeiten haben, sich im Markt zu positionieren. Klar, jede neue Sprache hat das. Das streitet auch niemand ab und ist nicht das Thema dieses Posts. Klare Vorteile gewinnt Dart, wenn es auf Android und App Engine läuft. Mal sehen.

    Dart ist jedoch kein "syntaktischer Zucker" (wie du z.b. CoffeeScript bezeichnen würdest). Dart kommt mit einer echten VM, die derzeit in verschiedenen Browsern umgesetzt wird (wird allerdings kontrovers diskutiert, siehe oben in den Kommentaren). Dart kann demnach native und damit unabhängig von JavaScript laufen (theoretisch). Außerdem ist es möglich, die VM serverseitig zu verwenden (ja, ich kenne Node.js).

    Wenn Dart Code mit Isolates zu JavaScript transformiert wird, werden WebWorker verwendet, um parallel zu arbeiten. Isolates werden sich in nächster Zeit noch weiter verändern, also heads up. Hier ein Blogpost zum Thema:
    http://dartvader.grobmeier.de/dart-isolates-08112011.html

    Schade, dass du offenbar Punkt 8 nicht fertig gelesen hast. Dort beschreibe ich recht klar, dass foreach verfügbar ist - außer für den Internet Explorer 8.

    Antworten Teilen
  15. von kernel am 16.01.2012 (13:19 Uhr)

    @Christian Danke für deine Antwort. Richtig. Ich habe Punkt 8 nicht zu Ende gelesen, weil Überschriften entweder korrekt sind oder sie sind es eben nicht. Effekthascherei ganz im Bild Stil möchte (fast) keiner für Gut heißen, deswegen habe ich mir einfach nicht diese Mühe gemacht.

    Mir ist klar, dass Dart in einer eigenen VM ausgeführt wird / werden kann. Das ändert aber nichts an der Tatsache, dass es effektiv keine anderen Eigenschaften als JavaScript aufweist (soweit mir bekannt). Der Syntax mag ein stückweit anders sein, die gewählten Bezeichner ebenfalls. Aber wenn beide doch nur mit dem selben Wasser kochen (Stichwort WebWorker) sehe ich keinen Mehrwert darin viele Stunden in eine Weiterbildung zu setzen für die selben Dinge die bereits auf dem Markt erprobt laufen.

    Antworten Teilen
  16. von Christian Grobmeier am 16.01.2012 (13:34 Uhr)

    @kernel:
    ja richtig, die Überschrift hätte besser sein sollen. Der vorliegende Post ist eine Übersetzung einer älteren Version, in der ich mich auf ECMASCript < 5 bezog. Darauf wurde ich damals hingewiesen, weswegen ich den Punkt überarbeitet habe, aber die Überschrift vergessen habe. Mea culpa.

    Naja, Dart ist schon anders. Es ist klassenbasiert, kennt den library-scope, hat Isolates und so weiter. Das ist nicht nur ein "stückweit die Syntax anders", das ist schon mehr. Aber klar: du kannst im Prinzip alles irgendwie auch mit JavaScript erhalten. Zum Beispiel Webworker. Der Punkt in diese Post ist ja auch nicht, das Dart prinzipiell die feature-reichere Plattform ist. Es geht darum, warum ich persönlich zu Dart wechseln werde. Und das ist eben die klassenbasierte Struktur zum einen. Die optionalen zum anderen. Aber auch die Möglichkeit, dass ich unter Umständen meinen Java-Code entfernen und meinen Server in Dart schreiben kann.

    Aber ich verstehe deinen Punkt: du hast ein Mittel in der Hand, was dir genauso deine Arbeit möglich macht. Jetzt da dabei zu bleiben macht Sinn. javaScript ist etabliert und verbreitet. Dart unterliegt ständiger Veränderung. Die gesamte Core-API wird gerade von Josh Blochua überarbeitet. Die Dinge ändern sich vielleicht für dich, wenn du native Android Apps mit Dart schreiben kannst oder Dart auf der AppEngine zum laufen bringen kannst.

    Antworten Teilen
  17. von kernel am 16.01.2012 (14:04 Uhr)

    Es wird aber nochmal schwieriger wenn ich bald HTML5+CSS+JS Apps für jegliche Windows & Apple Endgeräte schreiben kann. Und Apple (Safari) sowie Microsoft (IE) werden einen Teufel tun und Dart (Google) unterstützen weil sie sich damit stark von einem Konzern abhängig machen der es in der Hand hat eine Sprache nach seiner Vorstellungen weiterzuentwickeln (ich weiß, dass sie Open Source ist).

    Und es geht mir auch nicht darum, dass man alles was man mit JavaScript erreichen kann auch mit Dart zu erreichen ist und umgekehrt. Das sollte ein Fakt sein, da alles sowieso letztlich in Maschinensprache übersetzt wird und JavaScript sich auf der Ebene dann auch nicht von Lisp unterscheidet.
    Es geht mir darum, dass Dart Javascript objektiv einfach nicht übertrifft, wie es der Titel dieses Beitrags verlauten lässt. Vielleicht hätte der Titel besser heißen sollen "Warum ich Dart besser finde als JavaScript".

    Don't feed the troll

    Antworten Teilen
  18. von Christian Grobmeier am 16.01.2012 (14:30 Uhr)

    @Kernel: Richtig, es gibt massig Gegenstimmen zu Dart, siehe hierzu auch: http://dartvader.grobmeier.de/google-dart-bald-native-auf-webkit-08122011.html
    Zudem gibt es ja Cordova/Callback et al, die quasi native Anwendungen auf nahezu allen mobilen Endgeräten möglich machen. Trotzdem ist ja auch Java auf Android nicht obsolet. Wenn Dart Java nach und nach ersetzt (sollte sich im März einigermaßen klar herausstellen -> Gericht Oracle vs Google zu Java Patenten) wird Dart auf jeden Fall einen festen Sitz im Sattel haben. Wie gesagt: wenn.

    Letztlich ist zwar alles Maschinensprache, jedoch heißt das trotzdem nicht, dass man alles, was man mit JS macht auch mit Dart machen kann.

    Den Titel finde ich trotzdem passend. Wie gesagt, ich bin kein JavaScript-Verneiner, sondern ich habe einfach versucht aufzuzeigen, was Dart aus javaScript gelernt hat. Ich habe versucht, das möglichst objektiv zu betrachten. Wenn man Programmiersprachen vergleicht, ist aber jede Objektivität subjektiv. Du kannst aber ja gerne deine Sicht der Dinge erläutern und aufzeigen, warum null/undefined einen Sinn macht und so weiter.

    Antworten Teilen
  19. von Tristan Lins am 16.01.2012 (14:35 Uhr)

    Ich glaube, Christian hat in seinem Beitrag und auch in seinen Kommentaren mehr als deutlich gemacht, dass es sich um seine persönliche Meinung handelt. Dies in dem Titel zu "unterstreichen" ist nicht notwendig. Aus einer anderen Richtung betrachtet kann man genau so gut sagen, das die kontroversen Titel und Überschriften durchaus korrekt gewählt sind und ist als Stilmittel durchaus richtig eingesetzt wurden. Da hat sich Christian keinesfalls irgendwas vorzuwerfen und schon gar nicht, in irgendeinen Bild Stil verfallen zu sein!
    Ganz im Gegenteil, er macht auf diese kontroverse und provozierende Weise es richtig, denn er macht auf Probleme aufmerksam, die andere vielleicht auch stören und bietet ihnen gleich eine (von vielen) Alternativen, ohne jedoch Unwahrheiten zu verbreiten oder den Anspruch zu erheben, dass sein Beitrag objektiv sei, ganz im Gegenteil weißt er mehrfach darauf hin, das er kein JavaScript Ninja ist und es sich um seine subjektive Meinung handelt.
    Bild hingegen verteilt gezielt Fehlinformationen und das nicht nur in den Headlines, sondern auch im Inhalt, was Christian überhaupt nicht macht.

    Es geht bei der Unterstützung auf mobilen Platzformen von Dart auch wohl weniger um WebApps, sondern mehr um native Apps die mit Dart geschrieben werden. Du kannst jetzt schon WebApps (HTML+CSS+JS) für verschiedene Endgeräte schreiben, die dann nur auf dieser einen Platform funktionieren. Diesem Problem kann Dart nicht entgegenwirken, noch kann es dieses Problem verschlimmbessern.

    Ja Dart ist als JavaScript Ersatz konzipiert (zumindest soweit ich mich an die damaligen Ankündigungen von vor einem Jahr erinnern kann), aber Dart ist von Anfang an mehr als nur eine DOM Sprache gewesen. JavaScript verliert diesen Touch einer reinen DOM Sprache dank Node.js und Co immer mehr und mehr, Dart hat diese Fokusierung von Anfang an nicht gehabt. Und damit verfügt Dart als eigenständige Sprache durchaus mehr Eigenschaften als JavaScript. Oder kannst du mit JavaScript auf Dateisysteme Zugreifen? Netzwerkserver öffnen? Ohne Node.js zu berücksichtigen nicht wirklich! Auch die neue File API ist kaum mit einer vollständigen Dateisystem API zu vergleichen.

    Antworten Teilen
  20. von kernel am 16.01.2012 (15:00 Uhr)

    null heißt die Variable ist definiert besitzt aber keinen Wert.
    undfined heißt die Variable ist nicht definiert.

    Das ist ein Riesenunterschied!

    Um dafür ein Beispiel aus PHP aufzugreifen:

    if (isset($_GET['var']) {} würde niemals eine Warnung schmeißen,
    if ($_GET['var']) {} schon.

    Dass einige VMs das stillschweigend hinnehmen löst trotzdem nicht das Problem der Abwesenheit einer Variable.

    Antworten Teilen
  21. von kernel am 16.01.2012 (15:05 Uhr)

    @Tristan nimm dir mal die Stunde Zeit und schau dir das an http://www.youtube.com/watch?v=qzA60hHca9s

    Davon ist zwar vieles noch Zukunftsmusik, trotzdem ist Dateiverwaltung damit nicht nur möglich sondern auch äußerst effizient und einheitlich gelöst.

    Antworten Teilen
  22. von Tristan Lins am 16.01.2012 (15:17 Uhr)

    Ja null und undefined sind definitiv stark zu unterscheiden, da hast du recht.
    Da es in JavaScript möglich ist, undefinierte Variablen abzufragen (wie auch in PHP) ist ein undefined Wert durchaus zweckdienlich, aber nicht unbedingt notwendig. Dart kennt dieses Problem (soweit ich die Spec verstehe) nicht, da in Dart jede Variable deklariert werden muss, was in JavaScript nicht notwendig ist. Aber eine isset() Funktion wie in PHP würde auch Ihren dienst tun, was man jetzt bevorzugt sei jedem selbst überlassen.

    Zum dem Video, das kenne ich sogar, ist aber schon länger her das ich das gesehen habe, daher kenne ich die Details jetzt nicht alle auswendig. Aber verwechsle JavaScript nicht mit Extensions, die mit der Programmiersprache selbst gar nichts zu tun haben und in verschiedenen Engines gar nicht oder anders vorhanden sind. Node.js hat z.B. eine ziemlich umfangreiche Filesystem API, die aber nicht mit der File API Extension für das Web vergleichbar ist (auch wenn da noch mehr kommen wird und in manchen Browserengines schon umfangreicher umgesetzt ist). Da muss man durchaus unterscheiden. Genau so sieht es bei WebWorkern aus, Node.js besitzt afaik auch Threads, Process Management und vieles mehr, was JavaScript selbst nicht besitzt und im Browser nicht besitzen kann oder wenn dann in "abgespeckter" Form bekommen wird. In Dart fehlt imo noch vieles von dem, was damals mal angekündigt wurde (oder die API Doc ist total veraltet), aber Dart ist im Funktionsumfang eher mit Node.js zu vergleichen, als mit JavaScript im Browser.

    Antworten Teilen
  23. von kernel am 16.01.2012 (15:30 Uhr)

    @Christian: "Node.js besitzt afaik auch Threads..." - soweit ich weiß nicht. Zumindest war das immer die Intention von Ryan (dem Entwickler), den ich seit langer Zeit akribisch verfolge. Das einzige was ich darüber jetzt auf die Schnelle finden konnte ist, dass einige FS-Libraries wohl threadbasiert arbeiten weil es sonst nicht non-blockierend (komisches Wort btw) möglich wäre http://www.quora.com/Node-js/Could-Node-js-support-threads-in-the-future

    Das soll jetzt aber nicht Gegenstand der Kommentare werden und beantrage damit wieder auf das eigentliche Thema zurückzukommen.

    Antworten Teilen
  24. von Tristan Lins am 16.01.2012 (15:56 Uhr)

    @kernel
    Ok, da muss ich gestehen das ich Node.js mehr in den Nachrichten verfolge, ich hatte mal was über Thread in Node.js gelesen (vermutlich basierend auf der Diskussion die du gepostet hast), daher hatte ich da was im Kopf. Was aber nichts daran ändert, das die Filesystem API und Prozessmanagement tatsächlich existieren :D

    Mh, was ist das eigentlich Thema? JavaScript vs. Dart? Ist es da nicht Gegenstand des Themas die eine oder andere Programmiersprache auch etwas genauer unter die Lupe zu nehmen?

    Antworten Teilen
  25. von kernel am 16.01.2012 (16:18 Uhr)

    Natürlich! Ohne Frage. Aber es ist halt die Sache, dass man momentan nicht im Großen Stile auf Dart umsteigen wird (ich spreche da jetzt mal allgmein wirtschaftlich) weil die Unterstützung für die Allgemeinheit fehlt und man alles bulletproof in JS über die Bühne bekommt, weil man auf Erfahrungswerte und vorhandene Libs zurückgreifen kann. In Zukunft wird man nicht mehr auf Dart umsteigen wollen weil eben jene JS Programme Einzug in den normalen Betriebsablauf gehalten haben.

    Und solange es nichts gibt an dem JS mal an seine Grenzen stößt, ausgenommen vielleicht Echtzeit Anwendungen bei denen Latenzen von 10ms schon als inakzeptabel angesehen werden, was aber eher der VM-basierten Architektur als der Sprache an sich anzulasten ist, .... wird Dart aufgrund der stetigen Erweiterung und vorallem der guten Erweiterbarkeit (!) von JS nicht allgemeingültig werden. node schult da momentan eher die Großen im Servergeschäft mit 10.000 konkurrierenden Anfragen - in einem Thread! ;)
    Dart wird wohl maximal eine Nische, ja vielleicht eine ganze Sparte bedienen aber dafür möchte ich einfach nicht programmieren ;) Der Leitsatz "Write once - use everywhere", ursprünglich übrigens in der Java Szene entstanden, hat mich da viel zu sehr geprägt. JS scheint dieses Versprechen erstmalig zu halten. Serverseitig wie clientseitig.

    Das eigentliche Thema der Diskussion war übrigens ob Dart JS in irgendeinem Punkt übertrifft. Vielleicht in der Verständlichkeit - das mag sein. Aber rein pragmatisch in wohl keinem Punkt.

    @Tristan: ich habe vorhin auch nicht von Webapps gesprochen, sondern von Nativen Apps in Windows 8 & Co, Geschrieben mit der mächtigsten Dreifaltigkeit, die derzeit im Internet vorherrscht.

    Antworten Teilen
  26. von Christian Grobmeier am 16.01.2012 (16:32 Uhr)

    @Kernel: es geht in diesem Blogpost nicht darum, ob man oder irgendwer auf Dart umsteigen wird oder soll. Allerdings ist es zu früh um zu spekulieren. Dart ist nach wie vor im technischen Preview. Und es besteht die Möglichkeit das Dart die Sprache auf Android wird, ähnlich wie Obj-C auf dem iPhone. Und das es auf der AppEngine läuft. Ob das reicht, damit es von der Nische zur Größe wird, wird sich noch zeigen. Kategorisch ausschließen würde ich es nicht. Bis dieser Durchbruch aber kommt wird noch eine lange Zeit vergehen, wenn er denn überhaupt kommt.

    In meinem Post beziehe ich mich durchaus nur auf die "Verständlichkeit", wie du es sagst, und keinesfalls auf den "Pragmatismus", ob und wie und wann man nun Dart benutzen soll. Dem entsprechend greife ich deine "Religion", die Dreifaltigkeit Windows, JavaScript und HTML5 überhaupt nicht an.

    Antworten Teilen
  27. von Tristan Lins am 16.01.2012 (16:34 Uhr)

    Keiner hat hier je behauptet, das Dart JavaScript kurzfristig, mittelfristig oder langfristig ablösen wird. Trotzdem ist Dart eine Interessante Sprache, die vielleicht ein Nischendasein führen wird, damit aber immer noch mehr Einfluss hat als viele andere Sprachen. Es gibt immerhin hunderte Programmiersprachen, jede hat Ihren ganz eigene Nische, in der sie Ihr Dasein fristet, genau so wie JavaScript. Ich kann mir nicht vorstellen, dass JavaScript im großen Enterprise Bereich jemals als effektiver Ersatz für C/C++, Java und andere höhere Programmiersprachen herhalten kann.

    Das Paradigma "write once, run everywhere" ist ein Paradigma, dass ich sehr begrüße, jedoch kann es JavaScript nicht weniger oder mehr einhalten als Java.

    Und eine "Native WebApp" unterscheidet sich nicht wirklich von einer regulären WebApp, außer dass die App auf dem Gerät fest installiert ist und man zugegebenermaßen etwas mehr Zugriff auf das Gerät selbst hat. Trotzdem wird diese im Browser ausgeführt und unterliegt dessen Regularien.
    Mir ist nicht bekannt das man für iOS oder Android reine native Apps (wie mit Objective-C oder Java) für diese Platformen rein in HTML+CSS+JS entwickeln kann. Mit der Windows Phone Platform kenne ich mich nicht aus, deshalb kann ich da nichts zu sagen.

    Antworten Teilen
  28. von Tristan Lins am 16.01.2012 (16:38 Uhr)

    @hacker
    Ach, ich habe grad nochmal gesehen das du dich gar nicht auf Windows Phone, sondern Windows 8 bezogen hast. Mir ist bekannt, dass man mit Hilfe von CSS+JS in vielen Programmiersprachen bereits Anwendungen entwickeln kann, das geht z.B. in QT oder Java, aber vollständig in HTML+CSS+JS reine Apps schreiben, ohne auch nur ein bisschen davon abweichen zu müssen ist im App bereich vielleicht möglich, im Anwendungsbereich halte ich das für ausgeschlossen, dass das jemals so möglich sein wird.

    Antworten Teilen
  29. von kernel am 16.01.2012 (17:13 Uhr)

    @Christian "Windows"? Witzig :D Ich meinte eigentlich HTML5, CSS und JS mit der Trinität. Wegen mir können Microsoft und vorallem ihr IE eines langsamen und qualvollen Todes sterben.

    Ersteres ist aber in jedem Falle eine Religion die es wert ist ihr Aufmerksamkeit zu schenken. Gerade im Bezug auf die so oft in diesem Beitrag erwähnten GoF Patterns, speziell dem MVC.

    Antworten Teilen
  30. von Christian Grobmeier am 16.01.2012 (17:25 Uhr)

    @kernel: oh, css mit Windows verwechselt ;-)
    Ohne ein Erbsenzähler sein zu wollen, MVC ist kein GoF Pattern: http://de.wikipedia.org/wiki/Entwurfsmuster_(Buch)

    Antworten Teilen
  31. von kernel am 16.01.2012 (17:34 Uhr)

    Danke. Nichts desto trotz ein nicht unerhebliches Pattern, welches geradezu beispielhaft durch eben diese drei komplett entkoppelten Komponenten realisiert wurde.


    Und beim Thema zu bleiben:
    Ich gehe mit, dass Dart in einigen Dingen übersichtlicher ist.

    Antworten Teilen
  32. von Mika am 17.01.2012 (08:57 Uhr)

    Interessante Betrachtungsweise.

    Ich bin mal gespannt, inwieweit sich Dart „etablieren" wird.

    Viele Grüße Mika

    Antworten Teilen
  33. von RubbeDeKatz am 21.03.2012 (21:34 Uhr)

    Wirklich fair ist der beitrag nicht.
    Natürlich ist javascript ohne framework nicht wirklich nutzbar.

    Aber dann gibt es bsp. die
    $('.class').each();
    funktion statt der for each funktion.

    Außerdem für "false" den === Operator.

    Ich komme von PHP fand javascript mit mootools immer sehr elegant als Programmiersprache.

    Antworten Teilen
  34. von alexander.bombis am 18.11.2013 (06:24 Uhr)

    hej :)

    bitte nicht falsch verstehen, aber ich glaube kaum das jquery.js was mit dem Verständnis zu Javascript zu tuen hat.
    Was ist jquery?
    - eine automatieisierte anonyme Funktion,
    also ein Object was uns eine Ansammlung von Methoden liefert, welche wir über $ aufrufen und die mit einander agieren.
    Schön.
    Das heißt aber noch lange nicht das man JavaScript versteht ;)

    desweiteren finde ich es Schade das JavaScript überhaupt mit PHP oder Java verglichen wird.
    Persönlich arbeite ich jetzt seit zwei Jahren mit Javascript und mit PHP.
    Dank PHP - OOP, habe ich JavaScript sogar noch besser verstanden und schreibe nur noch objektorientiert.
    So gibt es auch gar keine Namespaceprobleme, da jeder noch so kleiner Code in einer Methode definiert ist.
    Wenn man JavaScript lieben lernt dann ist der einzige lose Code den man noch schreibt der, der in irgendwelchen DOM Elementen für Events hinterlegt wird.
    Fazit um JavaScript zu lernen bedarf es keiner Frameworks sondern Verständniss, Leidenschaft und ganz viel Liebe wie Kreativität.

    Aber dennoch - mal schauen ob Dart die Chance hat Ecma abzulösen.
    Dieser Tage hat Google seine Sprache freigegeben und sie ist in allen Browsern anwendbar da sie, falls sie nicht verstanden wird in JavaScript übersetzt wird.

    Macht es dann überhaupt Sinn sich mit Ecmascript 6 auseinander zusetzen.

    Und warum veröffentlicht Google Dart in dem Jahr kurz vor Jahresende in dem Ecmascript 6 fertig gestellt werden soll?

    Antworten Teilen
  35. von zamokulee am 02.12.2013 (07:43 Uhr)

    Ich denke, Sie haben Recht. Ich bin PHP-und Javascript-Entwickler und finde es ziemlich einfach zu verstehen. Meiner Meinung nach wäre es cool, wenn Javascript Richtung Actionscript 3 entwickelt - die natürlich auf Entwürfe für eine Art von "Javascript 2.0" basiert.

    lee
    http://net-informations.com

    Antworten Teilen
  36. von Kr0e am 23.12.2013 (11:19 Uhr)

    Ich kann zu diesem Thema ein etwas andere Sichtweise beisteuern:

    Dart wurde von Lars Bak & Kollegen erfunden, jeder der sich mit lowlevel impl. von VM beschäftigt hat, weiß, dass Lars Bak einer dieser Pioniere ist (JVM, v8, etc), die Sprachen ohne direkte Compilierung überhaupt erst performant gemacht haben.

    Und jeder der sich schonmal mit VM Programming beschäftigt hat, weiß, dass JavaScript eine FURCHTBARE Sprache aus Sicht einer VM ist. Die dynamischen Fähigkeiten verhindern annähernd jede "einfache " Optimierung.

    Daraus folgt, dass JavaScript nur mit sehr komplexen Tricks schnell gemacht werden kann, wenn man sich v8 mal anschaut, wird man schnell vom Glauben abfallen, v8 ist ein ziemliches Meisterwerk.

    JETZT komme ich zum Punkt:

    Dart, erfunden von Lars Bak, kann sehr viel leichter optimiert werden, daher muss die VM nicht so komplex sein. Lars Bak sagte in einem Interview, dass Dart ein SCHÖNE Sprache sei, um sie zu implementieren.

    Und das ist auch schon alles worauf ich hinaus will: Dart ist für VM Ersteller gemacht, JavaScript für Anwender. Dart soll schnell und simpel sein, dass das mit der Anzahl der Features kollidiert, ist klar.

    JavaScripts Fähigkeiten übersteigen in jeder Hinsicht die von Dart. Dart ist eine (sinnvolle) Limitierung für unerfahrene Programmierer. Auch Java/C/C++ Leute werden ihren Spaß mit Dart haben, da die Konzepte ähnlich beschränkt sind.

    JavaScript kann effektiv mehr (auch mehr schlechte Dinge). Prototyping ist Klassenbasierter OO mehrfach überlegen, warum ? Nun, weil man Klassen mit Prototyping nachbilden kann, umgekehrt aber nicht.

    Das JavaScript weak typed ist, ist wohl das besonderste daran. Damit kommen viele nicht klar und nutzen überall === bzw !== und denken dann, komisch wieso ist JavaScript so ugly.


    ABER wisst ihr was das tollste an JavaScript ist ? Man braucht meistens keine Sprachefeatures um Probleme elegant zu lösen. DAS ist der Witz an JavaScript. Frameworks und Libraries fixen viele der sprachlichen Unzulänglichkeiten, die in ES6 gefixt werden. Das bedeutet: JavaScript als Sprache ist so flexibel, dass man gewisse Sprachkonstrukte mit Libraries kompensieren kann.


    Fazit:
    Um eine Sprache effektiv zu benutzen, muss man all ihre Features nutzen und nicht nur die, die man aus Java kennt und dann meckern, dass JavaScript dann eben nicht sehr ausdrucksstark ist.

    JavaScript ist in der Tat eine wundervolle Sprache mit vielen kleinen Ecken, die unerfahrene Programmierer zum Verzweifeln bringen.

    Das Problem ist, dass JavaScript als Toylanguage betrachtet wird und die Leute daher keine Zeit aufwenden sich *wirklich* damit zu beschäftigen. JS hat viele tolle Elemente aus der funktionalen Welt (Ja, das ist für C/C++/Java #Neuland :D).

    Wenn man EcmaScript als wertvolle Sprache betrachtet, findet man vlt auch mal die Motivation, sich damit mehr als bloß oberflächlich zu beschäftigen.

    Amen.

    Antworten Teilen
  37. von Kr0e am 23.12.2013 (11:25 Uhr)

    Noch eine Ergänzung:

    Viele Leute sagen, dass "Projekte mit mehreren Tausend/Millionen Zeilen Code JavaScript" schwer zu managen sind. Dart soll ja angeblich besser sein, wegen optionaler Typisierung.

    Dazu sag ich: Studiert CS 101. Komplexität ist ein Grundproblem in der Informatik, welches gelöst.

    Wenn etwas zu komplex ist, dann splitte es auf. Mach Module draus (ES6 oder AMD und Konsorten). Wenn man unabhängige Module hat, die jeweils nur aus relativ wenig Code bestehen, kann man Komplexität komplett vernichten.

    Auch ein Java Projekt mit >2KK Zeilen Code ist nicht mehr schön, ich spreche aus Erfahrung.

    Alle Vorurteile sind meist nur, naja Vorurteile.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Google
Google aktualisiert Richtlinien: Warum du deine robots.txt prüfen solltest
Google aktualisiert Richtlinien: Warum du deine robots.txt prüfen solltest

Google hat am gestrigen Montag eine Änderung der „Webmaster Guidelines“ angekündigt. Demnach sollten Seitenbetreiber ab sofort sicherstellen, dass die robots.txt-Datei ihrer Website den Abruf … » weiterlesen

Echte Nerds spielen JavaScript: Wavepot lässt dich Songs und Sounds in Echtzeit programmieren
Echte Nerds spielen JavaScript: Wavepot lässt dich Songs und Sounds in Echtzeit programmieren

Wavepot macht es unglaublich einfach, direkt im Browser eigene Lieder und Sounds zu schreiben –  in JavaScript. Jede Änderung wird sofort umgesetzt, was zu einem extrem unterhaltsamen Erlebnis führt. » weiterlesen

Google Analytics: Kinderleichtes Tracking mit Boba.js
Google Analytics: Kinderleichtes Tracking mit Boba.js

Boba.js macht das Tracking von Events mit Google Analytics zum Kinderspiel. Wir verraten dir, wie du die Bibliothek in deine Seite einbaust und einsetzt. » weiterlesen

Kennst Du schon unser t3n Magazin?

t3n 37 jetzt kostenfrei probelesen! Alle Inhalte des t3n Magazins Diesen Hinweis verbergen