me[code].Java(Script)
hi.
eure meinung würde mich interessieren: was würdet ihr den vorzug geben – js-frameworks wie jquery und dojo oder vanilla javascript?
meine ansicht zu diesem thema ist relativ eindeutig: wann immer möglich vanilla js. nachfolgend die begründung für meine ansicht.
1)
vanilla js
vanilla js ist nicht nur sehr viel schneller als jedes framework, es bietet zudem die größte kontrolle über das verhalten des codes, erzeugt weniger (teils massiv!) overhead und macht mich nicht abhängig von code, den jemand anderes schreibt, pflegt und wartet. dazu kommt, dass das verständnis von "echtem" javascript massiv einfluss darauf hat, wie effinzient ich code mit hilfe eines frameworks schreibe und ich kann, falls mir das preferierte framework das was ich brauche nicht bietet, es selbst einbauen.
nachteilig an vanilla js ist sicherlich, dass mein code länger ist und ich selbst mögliche fehlerquellen vermeiden/ausmerzen muss. ich denke da beispielsweise spontan an das auffinden von dom-knoten, das registrieren von eventlistenern und ein nicht einheitliches event-object bei den verschiedenen browserherstellern. das sollten die häufigsten auftreten probleme bei den meisten sein.
sicherlich sind für diese "problembereiche" lösungen in sicht und es wird besser werden. beispielsweise mit den aufkommen von querySelectorAll, dem IE-seitigen einbinden von w3c-standardmethoden wie addEventListener usw. dennoch muss ich – wie gesagt – für ältere browser immer noch einen workaround basteln (wahnsinn übrigens, wie weit verbreitet der IE7 noch ist!).
2)
jQuery
jQuery nimmt mir definitiv viel arbeit ab, da ich mich nicht mit fehlerquellenvermeidung herumschlagen muss. mein code wird auch tatsächlich kürzer, was i. d. R. zu einer einfacheren lesbarkeit führt – allerdings nur, weil die größe des codes geringer ist. jQuery implementiert zudem dinge, die es so in vanilla js gar nicht gibt wie beispielsweise animationen und cross-browser ajax-methoden.
nachteilig an jQuery ist allerdings definitiv, dass es ein vergleichsweise "schwergewichtiges" framework ist (~ 200kb!), viele dinge wie beispielsweise die angesprochenen animationen hohen overhead erzeugen und ich bei der nutzung von jQuery abhängig bin von den jQuery-entwicklern und nicht mehr agieren, sondern eig. nur noch re-agieren kann. sofern ich die jQuery-JS auf meinen eigenen server schmeiße, kann ich mir die abhängigkeit natürlich sparen, mir gehen aber auch sämtliche vorteile eines cdn-hostings verloren. zwar gibt es extrem viele jQuery plugins, finde ich aber kein passendes oder nicht eines, dass mir den umfang bietet den ich benötige, müsste ich es selbst anpassen – was nach meiner erfahrung oft viel mehr arbeit ist, als das ganze selbst zu schreiben (ein m. E. nach guter mittelweg ist hier, das plugin nicht in $.fn einzubinden sondern als "normale" constructor-function. aber das nur nebenbei). abgesehen davon, mache ich mich mit der nutzung von jQuery plugins nicht von von den jQuery entwicklern abhängig, sondern zusätlich von jedem einzelnen plugin entwickler.
als größten nachteil sehe ich persönlich aber, dass jQuery mich extrem weit von vanilla js entfernt. durch das lernen von jQuery lerne ich so gut wie keinerlei verständnis von normalem javascript sondern nur von jQuery. kurz gesagt: jQuery === javascript, aber javascript !== jQuery.
3)
Dojo
Dojo ist zwar an und für sich auch ein "schwergewicht", es biete mir aber im gegensatz zu jQuery den vorteil, dass ich nur wirklich benötigte dinge laden kann. bei jQuery lade ich oft locker 80% an funktionen, die ich nirgends in meinem script brauche. Dojo ist ebenfalls cross-browser kompatibel, lässt mich näher an vanilla js als die meisten anderen frameworks, verzichtet auf das prototype-basierte erweitern von nativen objekten (anders als beispielsweise mootools!), ist extrem schnell und bietet ebenfalls funktionen wie animationen, cross-browser ajax uvm.
bei Dojo treten natürlich teilweise die gleichen nachteile auf wie bei jQuery: ich bin abhängig von den entwicklern, einige dinge erzeugen einen hohen overhead (meiner erfahrung nach allerdings oft weniger als bei jQuery!) und das lernen von Dojo bringt mich eig. nicht unbedingt weiter darin, vanilla js zu lernen (allerdings eher als das bei jQuery der fall ist, da wie gesagt näher an "echtem" javascript). dennoch auch hier: Dojo === javascript, aber javascript !== Dojo.
Fazit:
m. E. nach ist es für jeden(!) sinnvoller, zunächst vanilla js zu lernen anstatt irgend ein framework. falls das framework an seine grenzen stößt (ja, das kommt definitiv vor – stichwort css3-animationen verwenden sofern möglich oder touch-events nutzen ohne zusätliche plugins), kann man sich selbst behelfen, man ist nicht abhängig von dem/den frameworks bzw. den entwicklern selbiger, zusammenhänge werden klarer und der code läuft schneller ab als mit framework => einsparen von overhead. die pages werden außerdem schneller geladen.
werden in der applikation dinge wie animationen, ajax oder beispielsweise eine mvc architektur gebraucht, dann eher zu Dojo als zu jQuery greifen. aus den oben genannten gründen. und trotzdem versuchen, soviel wie irgend möglich ohne das framework umzusetzen.
wie gesagt, das ist meine meinung. ich bin gespannt auf eure
eure meinung würde mich interessieren: was würdet ihr den vorzug geben – js-frameworks wie jquery und dojo oder vanilla javascript?
meine ansicht zu diesem thema ist relativ eindeutig: wann immer möglich vanilla js. nachfolgend die begründung für meine ansicht.
1)
vanilla js
vanilla js ist nicht nur sehr viel schneller als jedes framework, es bietet zudem die größte kontrolle über das verhalten des codes, erzeugt weniger (teils massiv!) overhead und macht mich nicht abhängig von code, den jemand anderes schreibt, pflegt und wartet. dazu kommt, dass das verständnis von "echtem" javascript massiv einfluss darauf hat, wie effinzient ich code mit hilfe eines frameworks schreibe und ich kann, falls mir das preferierte framework das was ich brauche nicht bietet, es selbst einbauen.
nachteilig an vanilla js ist sicherlich, dass mein code länger ist und ich selbst mögliche fehlerquellen vermeiden/ausmerzen muss. ich denke da beispielsweise spontan an das auffinden von dom-knoten, das registrieren von eventlistenern und ein nicht einheitliches event-object bei den verschiedenen browserherstellern. das sollten die häufigsten auftreten probleme bei den meisten sein.
sicherlich sind für diese "problembereiche" lösungen in sicht und es wird besser werden. beispielsweise mit den aufkommen von querySelectorAll, dem IE-seitigen einbinden von w3c-standardmethoden wie addEventListener usw. dennoch muss ich – wie gesagt – für ältere browser immer noch einen workaround basteln (wahnsinn übrigens, wie weit verbreitet der IE7 noch ist!).
2)
jQuery
jQuery nimmt mir definitiv viel arbeit ab, da ich mich nicht mit fehlerquellenvermeidung herumschlagen muss. mein code wird auch tatsächlich kürzer, was i. d. R. zu einer einfacheren lesbarkeit führt – allerdings nur, weil die größe des codes geringer ist. jQuery implementiert zudem dinge, die es so in vanilla js gar nicht gibt wie beispielsweise animationen und cross-browser ajax-methoden.
nachteilig an jQuery ist allerdings definitiv, dass es ein vergleichsweise "schwergewichtiges" framework ist (~ 200kb!), viele dinge wie beispielsweise die angesprochenen animationen hohen overhead erzeugen und ich bei der nutzung von jQuery abhängig bin von den jQuery-entwicklern und nicht mehr agieren, sondern eig. nur noch re-agieren kann. sofern ich die jQuery-JS auf meinen eigenen server schmeiße, kann ich mir die abhängigkeit natürlich sparen, mir gehen aber auch sämtliche vorteile eines cdn-hostings verloren. zwar gibt es extrem viele jQuery plugins, finde ich aber kein passendes oder nicht eines, dass mir den umfang bietet den ich benötige, müsste ich es selbst anpassen – was nach meiner erfahrung oft viel mehr arbeit ist, als das ganze selbst zu schreiben (ein m. E. nach guter mittelweg ist hier, das plugin nicht in $.fn einzubinden sondern als "normale" constructor-function. aber das nur nebenbei). abgesehen davon, mache ich mich mit der nutzung von jQuery plugins nicht von von den jQuery entwicklern abhängig, sondern zusätlich von jedem einzelnen plugin entwickler.
als größten nachteil sehe ich persönlich aber, dass jQuery mich extrem weit von vanilla js entfernt. durch das lernen von jQuery lerne ich so gut wie keinerlei verständnis von normalem javascript sondern nur von jQuery. kurz gesagt: jQuery === javascript, aber javascript !== jQuery.
3)
Dojo
Dojo ist zwar an und für sich auch ein "schwergewicht", es biete mir aber im gegensatz zu jQuery den vorteil, dass ich nur wirklich benötigte dinge laden kann. bei jQuery lade ich oft locker 80% an funktionen, die ich nirgends in meinem script brauche. Dojo ist ebenfalls cross-browser kompatibel, lässt mich näher an vanilla js als die meisten anderen frameworks, verzichtet auf das prototype-basierte erweitern von nativen objekten (anders als beispielsweise mootools!), ist extrem schnell und bietet ebenfalls funktionen wie animationen, cross-browser ajax uvm.
bei Dojo treten natürlich teilweise die gleichen nachteile auf wie bei jQuery: ich bin abhängig von den entwicklern, einige dinge erzeugen einen hohen overhead (meiner erfahrung nach allerdings oft weniger als bei jQuery!) und das lernen von Dojo bringt mich eig. nicht unbedingt weiter darin, vanilla js zu lernen (allerdings eher als das bei jQuery der fall ist, da wie gesagt näher an "echtem" javascript). dennoch auch hier: Dojo === javascript, aber javascript !== Dojo.
Fazit:
m. E. nach ist es für jeden(!) sinnvoller, zunächst vanilla js zu lernen anstatt irgend ein framework. falls das framework an seine grenzen stößt (ja, das kommt definitiv vor – stichwort css3-animationen verwenden sofern möglich oder touch-events nutzen ohne zusätliche plugins), kann man sich selbst behelfen, man ist nicht abhängig von dem/den frameworks bzw. den entwicklern selbiger, zusammenhänge werden klarer und der code läuft schneller ab als mit framework => einsparen von overhead. die pages werden außerdem schneller geladen.
werden in der applikation dinge wie animationen, ajax oder beispielsweise eine mvc architektur gebraucht, dann eher zu Dojo als zu jQuery greifen. aus den oben genannten gründen. und trotzdem versuchen, soviel wie irgend möglich ohne das framework umzusetzen.
wie gesagt, das ist meine meinung. ich bin gespannt auf eure
