Apple und Google streiten um Rendering Engine Webkit

wußte bisher nix von diesen dart - aber kann mir nicht vorstellen, daß es schlechter ist als javascript.
würde mich sehr freuen, wenn javascript endlich abgelöst werden würde.

dart - dann soll sich halt apple aufpudeln.

aber warum blockiert apple mit seinen patenten freie web-standards?

http://my.opera.com/haavard/b... /apple-w3c

apple gehört HOCHKANT aus dem w3c geworfen!

nur mal so am rande

apple ist einer der massgeblichen gründe warum es webkitt überhaupt gibt.
mozillas gecko engine hängt am geltropf von google

und wenn nun google etwas eigenes rausstampft das in beide eingebaut wird, wovon man nichtmal weis wie es sich entwickelt und für was es google haben will und und und

dann ergibt sich halt wieder das selbe bild KONTROLLE...aber jaja dont be evil...ich schmeiss mich weg vor lachen

Oje. Bevor da wieder Geschichtsfälschung betrieben wird.

Webkit entstammt aus KDE/KHTML. Webkit existiert nur deshalb in der jetzigen Opensource-Form, weil die Leute von KDE/KHTML die GPL als Lizenz gewählt haben!

Sprich: Apple MUSSTE seine Änderungen veröffentlichen!

Und was es am Anfang für einen "Wickel" damit gegeben hat, ist nachzulesen!

z.b.: http://news.cnet.com/Open-sour... 03819.html
(oder einfach danach suchen)

Das stimmt schon.

Aber Apple hats weiterentwickelt zu WebKit...

Ähm. Und?

Ich sage nur: WebKit in der Opensource-Form, wie es sie heute gibt, ist den Entwicklern von KDE/KHTML zu verdanken, da diese:

1) offensichtlich eine sehr gute Basis geschaffen haben (warum sonst hätte Apple sonst diese verwendet).

2) es unter GPL lizenziert haben und damit Apple genötigt haben, alle Änderungen ebenfalls veröffentlichen zu müssen.

Also sagen wir ... DANKE KDE/KHTML für eine tolle Basis die erst Webkit ermöglichte!

Verstanden?

WebKit ist auch in der Open Source Form Apple (und zT Google) zu verdanken!

Auch wenn die KDE Entwickler KHTML gestartet haben.

Apple hat es genommen und weiterentwickelt, das zählt! Sie hätten auch jedes beliebige andere Projekt mit anderen Lizenzen nehmen können. Sie haben KHTML genommen weil das eben noch sehr klein war und nicht aufgebläht wie zB Geck.

Später ist dann auch Google und andere Firmen dazugekommen.

Was ich hier geschrieben habe, sind unweigerliche TATSACHEN. Da gibt es kein Nein!

KHTML war die BASIS - das ist unbestritten. Und ohne dieser Basis hätte es Webkit (in der heutigen Form) nie gegeben.
(Das habe ich auch ausführlich begründet hier.)

Klar, haben Apple, Google und Nokia viel beigetragen - das ändert aber nichts daran!

Oje. Bevor da wieder Geschichtsfälschung betrieben wird.

Elduderino780 hat mit seinem Beitrag Recht. Ohne Apple hätte es WebKit nicht gegeben.

KHTML war Basis, ja. Aber WebKit ist schon lange nicht mehr KHTML.

mir ist es jetzt zu dumm.
servas.

wer seinerzeit KHTML geshen hat (dagegen war selbst Netscape 6.0 ein Wunderwerk) und wie rasend sich dann Webkit entwickelt hat, weiß auch, wie groß die Contibution war.

Wo ist jetzt eigentlich das Problem, wenn ein Vendor eine (etwas fragliche) neue Language in die Standards hineinpressen will und damit scheitert? Es spießt sich ja nicht erst bei Webkit, sondern es haben bereits die Hersteller der beiden anderen major engines zuvor eine Absage erteilt. Damit ist der Gewinn schon etwas fraglich, gegenüber den Anforderungen, die so ein gänzlich neuer Slot bringen wüde und der damit verbundenen zusätzlichen Komplexität bei der Implementation neuer Standards. (D.h.: Wollen wir Dart oder schnelle Web-Standards-Implementation?)

Ähm. Ja genau. Und weil es so "schlecht" war, hat es sich Apple als neue Webbrowser-Basis ausgesucht.

Denk mal drüber nach!

KHTML war eine dankbare Basis aufgrund der Lizenz-Lage.
(Bezüglich der damals heraufdämmernden Standards war KHTML ehernur tragisch, HTML4-API-Support eher mangelnd. Dann folgte der Aufstieg zum langjährigen Acid-Test-Sieger ...)

dann gehört MS und Adobe aber auch rausgeworfen, und noch ein paar andere mehr.
Die frage, die ich mir nach dem durchlesen der meldung stelle: Was soll das überhaupt für ein konsortium sein, dessen mitglieder machtkämpfe auf dem rücken der user austragen?

Wird ein neuer Web-Standard entwickelt, steht es jedem frei, sich an der Entwicklung zu beteiligen. Mitglieder einer Entwicklergruppe müssen den anderen ihre Patente kostenfrei zur Verfügung stellen, sobald eine neue Entwicklung die Patente der anderen berührt.

Apple hält sich immer wieder aus bestimmten Entwicklergruppen raus, damit sie ihre Patente nicht der Allgemeinheit zur Verfügung stellen müssen. (Es gibt mehrere dokumentierte Fälle!)

Solche "Mitglieder" braucht das W3C nicht - also RAUS mit Apple.

Ahja, wo macht denn Microsoft oder Adobe ähnliches? Wo bleibt eine Quelle?

Jaja. Das Unternehmen, dass ganz maßgeblich an der Weiterentwicklung des Web beteiligt ist, und das mit WebKit die Basis für so ziemlich alles, was heute im mobilen Web-Bereich passiert, gelegt hat, aus dem W3C rausschmeißen, weil sie - so wie allen anderen Firmen - auch ihre Interessen vertreten.

Das W3C funktioniert eben *nicht* so, wie du dir das vorstellst. Die Möglichkeit, sich aus Entwicklergruppen rauszuhalten, wurde ja ganz bewusst geschaffen, und wäre das nicht so, wären heute große Firmen wie Apple, MS, Adobe oder vielleicht sogar Google gar nicht dabei und das W3C würde einfach keine Rolle spielen.

unter dem aspekt, das planmässige vorgehen von apple war mir in der hinsicht wirklich nicht bekannt, gebe ich Ihnen recht.
Allerdings widerspricht das imho dem "steht es jedem frei, sich zu beteiligen" - ich kann mir einfach nicht vorstellen, dass nur apple von dem recht gebrauch macht. in dem konsortium politik zu lasten des eigentlichen auftrags zu betreiben, finde ich auch nicht in ordnung.
bitte mehr info, falls ich noch immer nicht ganz folgen konnte.

"Vor allem für komplexere Anwendungen soll es sich mit einem objektorientierten Ansatz besser zur Entwicklung eignen" ist etwas ungenau. Javascript ist auch objektorientiert, wenn auch auf Basis von Prototypen. Dart unterstuetzt Objektorientierung auf Basis von Klassen, was vielen Entwickler*innen vertrauter seien duerfte.

das ablehnen ist klar; immerhin versucht google mit dem chrome so etwas wie eine eigenes betriebssystem innerhalb beliebiger anderer betriebssysteme zu etablieren. warum mozilla das nicht nutzen möchte, erschließt sich weniger - firefox könnte davon in ähnlicher weise profitieren. abgesehen davon ist es eh ein bissl krank office-suiten u.ä. in einer sprache wie javascript zu entwickeln...

das ist in wahrheit ein uralter traum, den viele unternehmen schon schmerzvoll aufgeben mussten. aber der browser-office hype ist schon ein paar jährchen da, also ist die zielgruppe ebenfalls vorhanden. vor allem wenn man den vorteil hat, der zwangsanhängerschaft (derzeit noch MS) die office-zukunft aufzudrängen.
bei java bin ich mir auch nie so richtig sicher gewesen, ob es im browserumfeld zukunft hat. javascript ist zwar ein anderes paar schuhe, es werden in der entwicklung der browserbasierten environments ähnliche fehler gemacht.

Syntactic sugar von DART ist halt schon sweet und Isolates eine nettes Konzepts Nebenläufigkeiten zu kapseln. Ich würde gerne dart'ln, breitere Untersützung vorausgesetzt.

Das Beste wäre eh ein standardisierter Bytecode statt Javascript. Vorteil: die Sprache selbst ist austauschbar, man ist nicht an JS-Eigenheiten gebunden, und Javascript selbst kann sich schneller entwickeln, da die Browser nicht erst mitziehen müssen.

LLVM würde hier sehr gut reinpassen.

Gratuliere, Sie haben eben Java erfunden.

Im allgemeinen liegt aber gerade der Vorteil von Scriptsprachen darin, dass die Source kleiner ist als der entsprechende Objectcode. (Schon auf dem lokalen FS ist dann die Penalty des Precompilens kleiner als die Einsparung von Ladezeit – und das gilt allemal für's Web.)

Btw. ist JavaScript mittlerweile nicht nur die meisteingesetzte Sprache, sondern auch eine der best entwickelten. Eine andere Baustelle ist allerdings die DOM-API, die aber nichts mit der Sprache an sich zu tun hat.
(Und das JS nichts mit dem DOM zu tun hat, ist auch gut und wünschenswert und sollte auch für jede andere Sprache gelten.)
Bitte nicht auf JS schimpfen, wenn a) die DOM-API oder b) 3rd party DOM-libraries gemeint sind.