Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › WebRTC und Odinmonkey: Firefox 22…

Wo bleiben OOP für Javascript

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Wo bleiben OOP für Javascript

    Autor: Kernschmelze 26.06.13 - 06:46

    Warum wird OOP nicht nativ eingebaut? Das finde ich viel wichtiger als Speed. Wer sich Sachen wie JQuery anschaut bekommt die Nackenhaare aufgerichtet. Ein nativer OOP Support würden den Webapps sehr gut tun.

  2. Re: Wo bleiben OOP für Javascript

    Autor: superduper 26.06.13 - 07:51

    Dafür gibt es Entwicklungen wie Coffeescript.

  3. Re: Wo bleiben OOP für Javascript

    Autor: droptable 26.06.13 - 08:09

    was meinst du mit oop? objekt orientiertes programmieren? wenn ja, dann solltest du javascript nochmal ohne jquery-framework lernen.

  4. Re: Wo bleiben OOP für Javascript

    Autor: JohnPaters61 26.06.13 - 09:01

    superduper schrieb:
    --------------------------------------------------------------------------------
    > Dafür gibt es Entwicklungen wie Coffeescript.

    Oder TypeScript, was den Vorteil hat das es zur Compile-Zeit typsicher ist.

  5. Re: Wo bleiben OOP für Javascript

    Autor: timing 26.06.13 - 09:02

    TypeScript

  6. Re: Wo bleiben OOP für Javascript

    Autor: Haxx 26.06.13 - 09:06

    Oder dart das ist auch zu Laufzeit type sicher,zumindest auf seiner testumgebung

  7. Re: Wo bleiben OOP für Javascript

    Autor: Schnarchnase 26.06.13 - 09:13

    Kernschmelze schrieb:
    --------------------------------------------------------------------------------
    > Warum wird OOP nicht nativ eingebaut?

    Javascript ist durch und durch objektorientiert, nur das klassische Vererbungsmodell wird nicht genutzt sondern statt dessen Prototypen.

    > Wer sich Sachen wie JQuery anschaut bekommt die Nackenhaare aufgerichtet.

    Das kann ich nachvollziehen. Die API von jQuery ist aber auch bescheiden, das machen andere Frameworks deutlich besser (Mootools, Prototype, Dojo, …). Ich frage mich wie jQuery zu dieser Verbreitung gefunden hat, meiner Meinung nach taugt es eher für Anfänger oder Leute die Javascript nicht können und auch nicht lernen wollen.

  8. Re: Wo bleiben OOP für Javascript

    Autor: Anonymer Nutzer 26.06.13 - 09:13

    Kernschmelze schrieb:
    --------------------------------------------------------------------------------
    > Warum wird OOP nicht nativ eingebaut? Das finde ich viel wichtiger als
    > Speed. Wer sich Sachen wie JQuery anschaut bekommt die Nackenhaare
    > aufgerichtet. Ein nativer OOP Support würden den Webapps sehr gut tun.

    JavaScript *ist* objektorientiert aber nicht im klassischen Sinne.

    Dort gibt es bspw. keine strikte Trennung zwischen Klassen und Objekten, in JavaScript kann ein Objekt als Prototyp dienen um ein neues Objekt zu erzeugen.

    P.S.: Die klassische Objektorientierung wäre mir persönlich auch lieber, da sie imho eine bessere Lesbarkeit bietet.



    1 mal bearbeitet, zuletzt am 26.06.13 09:14 durch lolig.

  9. Re: Wo bleiben OOP für Javascript

    Autor: Anonymer Nutzer 26.06.13 - 09:16

    JohnPaters61 schrieb:
    --------------------------------------------------------------------------------
    > superduper schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dafür gibt es Entwicklungen wie Coffeescript.
    >
    > Oder TypeScript, was den Vorteil hat das es zur Compile-Zeit typsicher ist.

    Oder Dart ich glaub damit hätten wir alle "bekannten" alternativen ;)

  10. Re: Wo bleiben OOP für Javascript

    Autor: Haxx 26.06.13 - 09:23

    lolig schrieb:
    --------------------------------------------------------------------------------
    > Kernschmelze schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Warum wird OOP nicht nativ eingebaut? Das finde ich viel wichtiger als
    > > Speed. Wer sich Sachen wie JQuery anschaut bekommt die Nackenhaare
    > > aufgerichtet. Ein nativer OOP Support würden den Webapps sehr gut tun.
    >
    > JavaScript *ist* objektorientiert aber nicht im klassischen Sinne.
    >
    > Dort gibt es bspw. keine strikte Trennung zwischen Klassen und Objekten, in
    > JavaScript kann ein Objekt als Prototyp dienen um ein neues Objekt zu
    > erzeugen.
    >
    > P.S.: Die klassische Objektorientierung wäre mir persönlich auch lieber, da
    > sie imho eine bessere Lesbarkeit bietet.
    Die klassische inheritance bringt dir vorallem mehr geschwindigkeit durch die feste Form von Objekten.

  11. Re: Wo bleiben OOP für Javascript

    Autor: Anonymer Nutzer 26.06.13 - 09:35

    Haxx schrieb:
    --------------------------------------------------------------------------------
    > Die klassische inheritance bringt dir vorallem mehr geschwindigkeit durch
    > die feste Form von Objekten.

    Das ist natürlich auch ein netter Nebeneffekt aber meine Fokus liegt halt eher bei Lesbarkeit und Wartbarkeit, solange der Rest darunter nicht überproportional leidet und da ist OOP in JavaScript, selbst wenn man es gescheit strukturiert, echt miserable.

  12. Re: Wo bleiben OOP für Javascript

    Autor: superduper 26.06.13 - 11:26

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Ich frage mich wie jQuery zu dieser Verbreitung gefunden hat,
    > meiner Meinung nach taugt es eher für Anfänger oder Leute die Javascript
    > nicht können und auch nicht lernen wollen.
    Ich denke damit hast du deine Frage schon ganz gut selbst beantwortet.

  13. Re: Wo bleiben OOP für Javascript

    Autor: GodsBoss 26.06.13 - 14:07

    > Warum wird OOP nicht nativ eingebaut? Das finde ich viel wichtiger als
    > Speed. Wer sich Sachen wie JQuery anschaut bekommt die Nackenhaare
    > aufgerichtet. Ein nativer OOP Support würden den Webapps sehr gut tun.

    Man sollte wenigstens rudimentäre Kenntnisse einer Sache haben, wenn man diese kritisiert. Wie schon in einigen anderen Kommentaren angemerkt, ist JavaScript objektorientiert. Die objektorientierte Programmierung (OOP) hingegen muss man schon selbst leisten. Wenn das bei deinem Code bisher nicht passiert ist, liegt das nicht an JavaScript. ;-)

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  14. Re: Wo bleiben OOP für Javascript

    Autor: Schnarchnase 26.06.13 - 14:46

    superduper schrieb:
    --------------------------------------------------------------------------------
    > Ich denke damit hast du deine Frage schon ganz gut selbst beantwortet.

    Joa, das mag sein, aber da ich in einer Agentur arbeite war das eher vor diesem Hintergrund gemeint, also warum auch so viele Profis jQuery einsetzen. Da sollte es ja nicht an der Kenntnis mangeln, sonst hat man eindeutig den falschen Beruf gewählt.

  15. Re: Wo bleiben OOP für Javascript

    Autor: Haxx 26.06.13 - 15:09

    Ich würde den Einsatz von jQuery nicht als unprofessionell bezeichnen, es gibt nur viele unprofessionelle Leute die das eben nutzen.

  16. Re: Wo bleiben OOP für Javascript

    Autor: zwangsregistrierter 26.06.13 - 15:19

    und was davon würdet Ihr Golemianer empfehlen, wenn man sich bisher noch mit keinem davon befasst hat? Und aus welchem Grund. Hat vlt. wer n Link der die drei "Sprachen" (naja eigentlich eher "Dialekte") miteinander vergleicht?

  17. Re: Wo bleiben OOP für Javascript

    Autor: Schnarchnase 26.06.13 - 15:36

    Haxx schrieb:
    --------------------------------------------------------------------------------
    > Ich würde den Einsatz von jQuery nicht als unprofessionell bezeichnen, es
    > gibt nur viele unprofessionelle Leute die das eben nutzen.

    Ich bezeichne jQuery nicht als unprofessionell. Ich wundere mich nur, dass Profis es einsetzen, da es im Funktionsumfang und mit seinen Schwächen in der API anderen Frameworks deutlich nachsteht.

  18. Re: Wo bleiben OOP für Javascript

    Autor: Haxx 26.06.13 - 15:36

    zwangsregistrierter schrieb:
    --------------------------------------------------------------------------------
    > und was davon würdet Ihr Golemianer empfehlen, wenn man sich bisher noch
    > mit keinem davon befasst hat? Und aus welchem Grund. Hat vlt. wer n Link
    > der die drei "Sprachen" (naja eigentlich eher "Dialekte") miteinander
    > vergleicht?

    Nun grundsätzlich solltest du javascript verstehen weil derzeit javascript die einzig Skriptsprache im Netz ist und solange die dartVM nicht im Browser ist werden alle anderen Sprachen zu javascript kompiliert werden.

    Ansonsten kommt es auf deine Vorkenntnis und was du machen willst. Kennst du Java/C#/C++ wird dir wohl dart am leichtesten fallen und du wirst keine negativen Überraschungen erleben die du man bei coffeescript/typescript erleben kann. Außerdem brauchst du deinen code nicht kompilieren um ihn zu testen (du kannst also sehr schnell interieren) und hast einen guten debugger, reflektionen und viele andere feature die man von einer Hochsprache erwartet. Dazu ist dein code optional zu Laufzeit typensicher.

    Der Coffeescript syntax gefällt dir vielleicht besser als python Nutzer.
    Typescript und Coffeescript arbeiten gut mit bestehenden javascript Bibliotheken zusammen. Dart tut sich da etwas schwerer da der Code eben auch auf einer eigenen VM laufen kann, aber dart hat schon eine ganze menge eigenen Bibliotheken ( http://pub.dartlang.org/packages ) und eine DOM Schnittstelle die wie jQuery einfacher zu nutzen ist, zudem werden Browserdifferenzen beim kompilieren zu javascript automatisch gefüllt/gepatcht.

    Das ist natürlich nur eine sehr sehr kleine Übersicht und über alle drei kann man noch viel mehr sagen.



    3 mal bearbeitet, zuletzt am 26.06.13 15:50 durch Haxx.

  19. Re: Wo bleiben OOP für Javascript

    Autor: zwangsregistrierter 26.06.13 - 15:50

    Vielen Dank für Deinen Beitrag. Dann werde ich mir Dart mal näher ansehen. Wobei der Punkt "arbeiten gut mit bestehenden javascript Bibliotheken zusammen" natürlich auch interessant wäre ;)

  20. Re: Wo bleiben OOP für Javascript

    Autor: Paykz0r 26.06.13 - 16:09

    Absolut richtig.

    Zusätzlich gibt es mit mixins z.b. die möglichkeit vererbung zu bekommen.
    Ist keine grosse Sache,
    und habe ich in mein ersten Jahr mit der Sprache selbst gemerkt.

    Zum Thema Jquery: für Klassische Webentwicklung sehr nett,
    für anwendungsentwicklung eher ein fail.
    Da würde man eher auf MVC-Paddern setzen,
    aber JQuery erlaubt den nutzer eben genau das zu umgehen.

    Also wer sich webanwendungsentwickler schimpft,
    und jquery nutzt, ist irgendwo kein Profi

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Schaeffler Technologies AG & Co. KG, Herzogenaurach
  2. medac Gesellschaft für klinische Spezialpräparate mbH, Wedel
  3. Awinta GmbH, Bietigheim-Bissingen
  4. Freie und Hansestadt Hamburg, Behörde für Inneres und Sport, Landesamt für Verfassungsschutz, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 337,00€
  2. 69,99€ (Release am 25. Oktober)
  3. 39,99€ (Release am 3. Dezember)
  4. (aktuell u. a. Corsair Glaive RGB Gaming-Maus für 32,99€, Microsoft Office 365 Home 1 Jahr für...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Telekom Smart Speaker im Test: Der smarte Lautsprecher, der mit zwei Zungen spricht
Telekom Smart Speaker im Test
Der smarte Lautsprecher, der mit zwei Zungen spricht

Die Deutsche Telekom bietet derzeit den einzigen smarten Lautsprecher an, mit dem sich parallel zwei digitale Assistenten nutzen lassen. Der Magenta-Assistent lässt einiges zu wünschen übrig, aber die Parallelnutzung von Alexa funktioniert schon fast zu gut.
Ein Test von Ingo Pakalski

  1. Smarte Lautsprecher Amazon liegt nicht nur in Deutschland vor Google
  2. Pure Discovr Schrumpfender Alexa-Lautsprecher mit Akku wird teurer
  3. Bose Portable Home Speaker Lautsprecher mit Akku, Airplay 2, Alexa und Google Assistant

Banken: Die Finanzbranche braucht eine neue Strategie für ihre IT
Banken
Die Finanzbranche braucht eine neue Strategie für ihre IT

Ob Deutsche Bank, Commerzbank oder DKB: Immer wieder wackeln Server und Anwendungen bei großen Finanzinstituten. Viele Kernbanksysteme sind zu alt für aktuelle Anforderungen. Die Branche sucht nach Auswegen.
Eine Analyse von Manuel Heckel

  1. Bafin Kunden beklagen mehr Störungen beim Online-Banking
  2. PSD2 Giropay soll bald nahezu allen Kunden zur Verfügung stehen
  3. Klarna Der Schrecken der traditionellen Banken

Linux-Kernel: Selbst Google ist unfähig, Android zu pflegen
Linux-Kernel
Selbst Google ist unfähig, Android zu pflegen

Bisher gilt Google als positive Ausnahme von der schlechten Update-Politik im Android-Ökosystem. Doch eine aktuelle Sicherheitslücke zeigt, dass auch Google die Updates nicht im Griff hat. Das ist selbst verschuldet und könnte vermieden werden.
Ein IMHO von Sebastian Grüner

  1. Kernel Linux bekommt Unterstützung für USB 4
  2. Kernel Vorschau auf Linux 5.4 bringt viele Security-Funktionen
  3. Linux Lockdown-Patches im Kernel aufgenommen

  1. Quartalsbericht: Netflix erneut mit rückläufigem Kundenwachstum
    Quartalsbericht
    Netflix erneut mit rückläufigem Kundenwachstum

    Netflix kann ein weiteres Mal die selbst gesteckten Ziele bei der Gewinnung neuer Abonnenten nicht ganz erreichen. Doch Gewinn und Umsatz legen stark zu.

  2. Ex-Mars Cube: LED-Zauberwürfel bringt Anfängern das Puzzle bei
    Ex-Mars Cube
    LED-Zauberwürfel bringt Anfängern das Puzzle bei

    Der Ex-Mars Cube hat wie ein herkömmlicher Zauberwürfel sechs Seiten mit je neun Farbkacheln - das System kann allerdings auch als Brettspielwürfel oder Dekolicht genutzt werden und Anfängern die Logik dahinter erklären.

  3. FWA: Huawei verspricht schnellen Glasfaserausbau ohne Spleißen
    FWA
    Huawei verspricht schnellen Glasfaserausbau ohne Spleißen

    Huawei hat Komponenten für den Glasfaserausbau entwickelt, die das Spleißen überflüssig machen sollen. Statt in 360 Minuten könne mit End-to-End-Plug-and-Play der Prozess in nur 36 Minuten erfolgen.


  1. 22:46

  2. 17:41

  3. 16:29

  4. 16:09

  5. 15:42

  6. 15:17

  7. 14:58

  8. 14:43