nicht angemeldet
Der Martin
Matti Mäkitalo
dedlfix
Matthias Apsel
Matthias Apsel
Gunnar Bittersmann
Hallo!
Ich würde gern die Diskussion, die ich hier so ungehalten angestoßen habe, auskapseln.
Mich hat die Ablehnung jQuery gegenüber doch sehr überrascht und deshalb würde ich gern wissen was ihr allgemein zu Frameworks sagt.
Gibt es überhaupt welche die man nutzen sollte oder zumindest empfehlenswert sind für einen durchschnittlichen Entwickler?
Oder ist es ein Vorteil mit aktuellen Frameworks zu arbeiten um schneller zu Ergebnissen zu kommen ohne, dass man sich viel mit Code rumschlagen muss?
Gibt es einen Mittelweg? Welche Frameworks würdet ihr empfehlen?
Ich würde einfach mal ein paar überspitzte Beispiele in den Raum werfen und gern eure Meinung dazu hören.
WYSIWYG vs HTML (z.B.)
jQuery vs JavaScript
QT vs C++
GUI vs Konsole
Meine Meinung dazu ist, dass ich gern die Vorteile jedes Frameworks "mitnehme" solange ich auch die zugrundeliegende Technik weiter uneingeschränkt nutzen kann. Ich glaube auch nicht, dass sie die Entwickler in ihrem Lernprozess bremsen solange dieser Punkt erfüllt ist. Schwieriger wird es da schon bei solchen Sachen wie dem HTML-Export wie ihn MS-Word für den HTML-Sektor seinerzeit einführte. Null Code sehen und dann friss oder stirb wäre mir auch nichts.
Grüße, Matze
Hallo Matze,
Mich hat die Ablehnung jQuery gegenüber doch sehr überrascht und deshalb würde ich gern wissen was ihr allgemein zu Frameworks sagt.
ganz allgemein: Wenn ich ein Framework, eine Klassenbibliothek oder irgendwas in der Art sinnvoll und effizient einsetzen möchte, muss ich mich in dieses System einarbeiten. Ich muss mich schlau machen, wie man es in eigene Projekte einbindet, welche Möglichkeiten es bietet und wie ich sie nutze. Und diese Einarbeitung kostet Zeit.
Deshalb verzichte ich liebend gern auf solche Frameworks, wenn die geschätzte Einarbeitung deutlich länger ist als die Zeit, die ich brauche, um den für das aktuelle Projekt nötigen Funktionsumfang selbst zu implementieren. Meine Software- und Webprojekte sind meist so klein, dass "zu Fuß" da zeitlich besser abschneidet.
Bei größeren Projekten, wo eine Lernphase von zwei, drei Tagen am Anfang nicht ins Gewicht fällt, mag das anders aussehen.
Es gibt noch ein weiteres Argument fürs Selbermachen: Wenn ich meinen Code komplett selbst entwickle, kenne ich jedes Stück genau und weiß, wo ich anfassen muss, um bestimmte Ergebnisse zu erzielen - oder um das Gesamtsystem später zu erweitern und zu ergänzen.
QT vs C++
GUI vs Konsole
Diese beiden Paare passen nicht in die Reihe, weil sie Elefanten mit Nüssen vergleichen. QT ist ein GUI-Framework, C++ eine Programmiersprache; GUI und Konsole sind zwei Konzepte für Applikationen, die je nach Anforderung beide ihre Daseinsberechtigung haben.
Ciao,
Martin
Hallo!
Diese beiden Paare passen nicht in die Reihe, weil sie Elefanten mit Nüssen vergleichen. QT ist ein GUI-Framework, C++ eine Programmiersprache;
Ich habe bewusst dazu geschrieben, dass die Beispiele überspitzt sind. Aber QT ist weit mehr als ein GUI-Framework. Die eigenen Klassen leisten schon sehr viel auch abseits von reiner GUI-Programmierung.(...und wenn man eh schon mit QT arbeitet, bietet es sich an die auch zu nutzen).
GUI und Konsole sind zwei Konzepte für Applikationen, die je nach Anforderung beide ihre Daseinsberechtigung haben.
Man kann ein GUI aber unbestritten als Framework einsetzen um Konsolenarbeiten zu vereinfachen.
Oder meintest du etwas anderes?
Grüße, Matze
Hi,
QT ist weit mehr als ein GUI-Framework.
ich kenne es nur, weil viele GUI-Applikationen für Linux wahlweise als in einer Variante QT- oder GTK+ angeboten werden, die sich in der Regel nur in Details der Bedienoberfläche unterscheiden - im Wesentlichen etwas anders gestaltete Window Controls. Daher meine Annahme, es sei nur ein GUI-Framework.
GUI und Konsole sind zwei Konzepte für Applikationen, die je nach Anforderung beide ihre Daseinsberechtigung haben.
Man kann ein GUI aber unbestritten als Framework einsetzen um Konsolenarbeiten zu vereinfachen.
Oder meintest du etwas anderes?
Ja, ganz anders. Typische, "echte" Konsolen-Anwendungen lesen ihre Eingaben von stdin, tun irgendwas damit und schreiben ihre Ausgabe nach stdout. Sie sind damit nicht wirklich "interaktiv". GUI ist ein völlig anderes Konzept: Das Programm läuft nicht einfach linear ab und erledigt seine Aufgabe, sondern da findet eine Interaktion mit dem Anwender statt.
Konsolen-Anwendungen mit textbasierten Oberflächen wie etwa ncurses stehen als Hybride irgendwo dazwischen, sind aber doch eher den GUI-Anwendungen zuzuordnen.
Ciao,
Martin
Hi,
ganz allgemein: Wenn ich ein Framework, eine Klassenbibliothek oder irgendwas in der Art sinnvoll und effizient einsetzen möchte, muss ich mich in dieses System einarbeiten. Ich muss mich schlau machen, wie man es in eigene Projekte einbindet, welche Möglichkeiten es bietet und wie ich sie nutze. Und diese Einarbeitung kostet Zeit.
Deshalb verzichte ich liebend gern auf solche Frameworks, wenn die geschätzte Einarbeitung deutlich länger ist als die Zeit, die ich brauche, um den für das aktuelle Projekt nötigen Funktionsumfang selbst zu implementieren. Meine Software- und Webprojekte sind meist so klein, dass "zu Fuß" da zeitlich besser abschneidet.
Aber das macht man i.d.R. nur einmal (mehrmals, wenn man ein schlechtes Gedächtnis hat). Die längere Lernphase hat man bei vielen Frameworks doch bei einem zweiten/dritten Projekt recht schnell ausgeglichen und in der Folge hat man nur noch Zeit-Vorteile.
Umso mehr, weil viele Frameworks darauf ausgelegt sind, Code wiederverwendbar zu machen. (Als Beispiel nenne ich mal Symfony mit den vielen Bundles oder AngularJS, wo Code auch sehr modular gestaltet ist). Dies erlaubt es, Code, den man für ein Projekt schreibt, u.U. wiederzuverwenden (und das ohne C&P). Als Beispiel nenne ich mal eine angular-Direktive, die Drag&Drop-File-Upload erlaubt. Einmal ordentlich geschrieben (wobei angular mir das sehr einfach macht) und schwupps kann ich die Funktionalität überall einbauen.
Was in dem Zusammenhang auch noch erwähnt werden sollte, aber nicht deckungsgleich mit der Frage "Framework ja oder nein" ist: eine gute Toolchain hilft ebenfalls. Ich bin gerade dabei, bower in meinen Arbeitsfluss aufzunehmen, als nächstes steht dann grunt.js an (und in ferner Zukunft dann yeoman, wo noch Project-Scaffolding hinzukommt). Mit bower erhoffe ich mir, meine Abhängigkeiten zu (anderen) Bibliotheken (und das können ja auch eigene sein) gut verwalten zu können.
Bis die Tage,
Matti
Hallo,
Deshalb verzichte ich liebend gern auf solche Frameworks, wenn die geschätzte Einarbeitung deutlich länger ist als die Zeit, die ich brauche, um den für das aktuelle Projekt nötigen Funktionsumfang selbst zu implementieren. Meine Software- und Webprojekte sind meist so klein, dass "zu Fuß" da zeitlich besser abschneidet.
Aber das macht man i.d.R. nur einmal (mehrmals, wenn man ein schlechtes Gedächtnis hat).
ja, aber bei selbstgeschriebenen Modulen ist das doch genauso. Man entwickelt sie im Kontext eines bestimmten Projekts, wo man einen spezifischen Funktionsumfang braucht. Macht man das gleich richtig[tm], kann man den Code mit minimalen Ergänzungen in einem der nächsten Projekte wiederverwenden und hat so eine stetig wachsende Zahl fertig einsetzbarer, ausgereifter Module.
Die längere Lernphase hat man bei vielen Frameworks doch bei einem zweiten/dritten Projekt recht schnell ausgeglichen und in der Folge hat man nur noch Zeit-Vorteile.
Das sehe ich nicht so, denn ich bin jemand, der nicht gern ein großes, vielseitiges, vielfach verstricktes System haben möchte, sondern im Idealfall eine Menge kleiner, gekapselter Einheiten, die man flexibel und fast beliebig kombinieren kann. Etliche Frameworks, die ich bisher kennengelernt habe, waren aber nur nach dem Prinzip "ganz oder gar nicht" zu gebrauchen, und das liegt mir überhaupt nicht.
Unter Windows bin ich daher nie überhaupt in Versuchung gekommen, große Frameworks oder Bibliotheken wie MFC oder .NET zu verwenden, oder Borlands OWL. Der einzige Bereich, wo ich überhaupt mal drüber nachgedacht habe, war das GUI. Aber selbst da bin ich schließlich zu der Erkenntnis gelangt, dass ich ohne zusätzliche Bibliotheken, also ausschließlich mit der Windows-API, am schnellsten und am effizientesten zum Ziel komme. Angenehmer Nebeneffekt: Der Nutzer hat das von Windows gewohnte Look & Feel anstatt phantasievoller alternativer Controls und Fensterdekorationen, und das Programm bleibt schlank und wenig ressourcenhunrig.
Unter Linux mag das anders aussehen, weil es da wegen der Vielfalt unterschiedlicher Desktop Environments und Window Managers nichts gibt, was mit der GDI-Schnittstelle von Windows vergleichbar wäre. Da bin ich noch in einer "Selbstfindungsphase" - aber da ich sowieso häufiger Konsolen-Anwendungen oder Hintergrundprogramme ohne GUI schreibe, kann sich das noch eine Weile hinziehen. ;-)
Was in dem Zusammenhang auch noch erwähnt werden sollte, aber nicht deckungsgleich mit der Frage "Framework ja oder nein" ist: eine gute Toolchain hilft ebenfalls.
Es ist IMO nicht nur "nicht deckungsgleich", sondern ein völlig anderer Aspekt. Ebenfalls sehr bedeutsam, aber eben was ganz anderes.
Ciao,
Martin
Hallo,
… ich bin jemand, der nicht gern ein großes, vielseitiges, vielfach verstricktes System haben möchte, sondern im Idealfall eine Menge kleiner, gekapselter Einheiten, die man flexibel und fast beliebig kombinieren kann. Etliche Frameworks, die ich bisher kennengelernt habe, waren aber nur nach dem Prinzip "ganz oder gar nicht" zu gebrauchen, und das liegt mir überhaupt nicht.
Die meisten aktuellen JavaScript-Frameworks sind stark modular, z.B. Ender, YUI, Dojo, ExtJS/Sencha, Mootools, jQuery UI. Auch jQuery ist eingeschränkt modular. Mit Build-Scripts sowie Modulformaten wie AMD, CommonJS und ähnlichen Systemen ist es möglich, nur die benötigten Features bzw. nur den benötigten Code einzubinden.
Grüße,
Mathias
Tach!
Mich hat die Ablehnung jQuery gegenüber doch sehr überrascht
Das kann auch nur ein mehr oder weniger ausgeprägtes NIH sein.
Gibt es überhaupt welche die man nutzen sollte oder zumindest empfehlenswert sind für einen durchschnittlichen Entwickler?
Oder ist es ein Vorteil mit aktuellen Frameworks zu arbeiten um schneller zu Ergebnissen zu kommen ohne, dass man sich viel mit Code rumschlagen muss?
Gibt es einen Mittelweg? Welche Frameworks würdet ihr empfehlen?
All diese Fragen kann man nicht direkt beantworten. It depends - wie der Angelsachse sagt. Es gibt Frameworks mit einer langen Einarbeitungszeit, es gibt welche, die sehr gut dokumentiert sind und deren Einstieg schnell geht, und es gibt welche, an denen man nicht vorbeikommt (z.B. wenn man Anwendungen für Windows oder ein anderes GUI-System schreibt).
Meine Meinung dazu ist, dass ich gern die Vorteile jedes Frameworks "mitnehme" solange ich auch die zugrundeliegende Technik weiter uneingeschränkt nutzen kann.
Manchmal will man das gar nicht, weil die Abstraktion des Frameworks einen schneller einen Kreis zeichnen lässt, als jeden Pixel einzeln zu betätscheln - inklusive der vom Kreis nicht betroffenen.
Ich glaube auch nicht, dass sie die Entwickler in ihrem Lernprozess bremsen solange dieser Punkt erfüllt ist.
Er sollte mehr als die Grundlagen der Sprache beherrschen, bevor er sich an aufgesetzte Dinge wagt. Auch andersrum kann man das betrachten: bevor er in die Tiefen eines Systems einsteigt, muss er das Werkzeug dafür einigermaßen beherrschen.
Es nützt ja nichts, ein Framework links liegen zu lassen, und einen Webserver selbst zu programmieren, wenn man HTTP nicht mal in Grundzügen kennt. Da kann einem das Framework helfen, wenn man nur ein System braucht, das ein/zwei Dateien ausliefern soll.
dedlfix.
Hallo!
Manchmal will man das gar nicht, weil die Abstraktion des Frameworks einen schneller einen Kreis zeichnen lässt, als jeden Pixel einzeln zu betätscheln - inklusive der vom Kreis nicht betroffenen.
Naja, mein Gedanke dazu ist immer "zur Not kann ich immernoch was dran ändern" oder hier und da haben frameworks ja auch gern Fehler die man selbst umgehen kann oder wo eigene Lösungen eleganter sind. Ich mag es schon wenn ich am besten jeden Bit einzeln setzen kann ;)
Grüße, Matze
Weil Wochenende ist,
Gibt es überhaupt welche [Frameworks ]die man nutzen sollte oder zumindest empfehlenswert sind für einen durchschnittlichen Entwickler?
Das hängt vom Anwendungsfall ab – und von der Definition, was ein »Framework« ist. Die C-Standard-Bibliothek kannst du auch als Framework auffassen, und ohne macht es gar keinen Spaß. Der durchschnittliche Java-Programmierer hingegen braucht sich nicht unbedingt mit C zu beschäftigen.
Oder ist es ein Vorteil mit aktuellen Frameworks zu arbeiten um schneller zu Ergebnissen zu kommen ohne, dass man sich viel mit Code rumschlagen muss?
Die C-Standard-Bibliothekt ist ein schon recht altes Framework, aber trotzdem top-aktuell. So gut wie kein C-Programm kommt ohne sie aus. Ein anderes Beispiel sind die Frameworks von Mac OS X. Diese haben ihre Ursprünge in NeXTStep, sind also auch schon etwas älter, aber jedes Programm für diese Plattform nutzt sie. Der Programmierer selbst braucht nicht viel Code schreiben, schleppt aber in den Frameworks schon jede Menge Code mit sich herum. Es kommt also nicht nur darauf an, wie viel/wenig Code ich schreiben muss, sondern auch, wie viel/wenig Code das Framework schon mitbringt. Modularisierung ist hierbei wichtig. Und ich denke, dass sich genau hieran die Kritik an jQuery richtet. Dieses Framework ist aktuell 32 kiB groß – wie viel der Funktionalität braucht der Durchschnitts-Webworker?
Ich würde einfach mal ein paar überspitzte Beispiele in den Raum werfen und gern eure Meinung dazu hören.
WYSIWYG vs HTML (z.B.)
Das sind zwei ganz unterschiedliche Konzepte, Äpfel und Birnen, kann man zwar vergleichen, aber wozu?
jQuery vs JavaScript
jQuery ist JavaScript ;-) Ansonsten siehe oben.
QT vs C++
QT ist C++ ;-) Wenn du dir mal anschaust, wie der Low-Level-Code zur Programmierung von GUIs ausschaut, dann willst du das nicht wirklich von Hand. QT hat ja noch den Vorteil, Plattform-übergreifend zu sein. Aber allein die Win32-API-Funktionen für eine GUI (auch ein Framework) sind schon komplex genug.
GUI vs Konsole
Auch das sind zwei ganz unterschiedliche Konzepte. Versuch doch mal, den Firefox im Terminal zu benutzen ;-) Ansonsten kommt es auf die Aufgabe an.
Ich arbeite sehr gerne auf Linuxen bzw. Unixen, weil ich da beides habe, GUI und gescheite Shells.
Schönen Abend,
Robert
Hallo!
Peace.
Gibt es einen Mittelweg? Welche Frameworks würdet ihr empfehlen?
Ich empfehle defintiv bootstrap, jquery und zum entwickeln von web sachen schmale frameworks wie sinatra oder (mein favourit) ramaze (KISS ruby mvc frameworks).
Ich hatte halbwegs erfahrungen mit javascript als ich zu jquery gekommen bin aber seitdem hat mir js programmierung (mit jquery) richtig spass gemacht. Über jquery an sich kann ich nichts negatives sagen; mit plugins sieht das aber wieder anders aus. Man neigt schnell dazu, plugins runterzuladen und schnell mal auszuprobieren. Viele davon müssen angepasst werden, man muss sich durch endlose api docs graben um das zu finden was man eigentlich braucht... Dann sind sie nicht selten verbuggt. Das ist alles die natur der sache. Ich bin faul und andere haben sich schon mühe gegeben. Am ende ist es eventuell ein grösserer time-sink als wenn man es selbst gemacht hätte.
Es ist einfach wie bei vielen dingen auf diesem gebiet. Es sind tools. Diese tools muss man einzusetzen wissen damit sie einem die arbeit erleichtern. Und natürlich, muss man immer den kosten nutzen faktor im auge behalten wenn man sich in ein neues framework einarbeiten möchte. Ich mach das meist unabhängig von der arbeit zum spass.
Meine Meinung dazu ist, dass ich gern die Vorteile jedes Frameworks "mitnehme" solange ich auch die zugrundeliegende Technik weiter uneingeschränkt nutzen kann. Ich glaube auch nicht, dass sie die Entwickler in ihrem Lernprozess bremsen solange dieser Punkt erfüllt ist.
Ich bring mal Rails mit rein. Ich habe rails anwendungen geschrieben, die erste vor ein paar jahren mit 0.8 oder sowas in der art. Rails hat gerade die 3er mayjor überwunden und ist nach wie vor gehyped und fast schon ein buzword.
Rails ist super mächtig, das steht ausser frage. Aber um es *richtig* zu benutzen bedarf es sehr viel erfahrung und know-how, und dann wird man immernoch probleme haben die einem die nacht versauen. Eventuell ist das in ordnung, weil man unmengen von zeit gespart hat bei diesen ganzen standard-entwicklungsprozeduren, aber es ist nervig.
Ich habe unlängst rails 2 und 3 beruflich nutzen müssen und mit erfahrungsschatz (mehr 10 jahre (web)entwicklung mit ruby, davon auch ein grundverständins von rails pre version 1) war ich nur frustriert.
Wenn ein framework mir zu wenig freiheiten lässt kann ich nicht ordentlich arbeiten ;)
Für das was ich mache benutze ich mittlerweile eine kombintation aus ramaze und einem aufsatz von mir. Ich habe mir eine verwaltungssoftware geschrieben, die mehrere apps verwaltet, ihnen entsprechende module/plugins und erweiterungen der standardbibliothek zu verfügung stellt, und letztendlich auch den deploy prozess übernimmt. Jedes app ist ein git submodule und kann auf unterschiedlichen servern landen.
Apps per knopfdruck anzulegen, die (optional) alles enthalten um eine anwendung zu "bootstrappen".
Für meinen workflow passt das perfekt. Und ich bin froh ohne mehraufwand (abgesehen vom einstieg) auf JQuery und Bootstrap zurückgreifen zu können.
Mfg entropie
Hallo,
Ich habe unlängst rails 2 und 3 beruflich nutzen müssen und mit erfahrungsschatz (mehr 10 jahre (web)entwicklung mit ruby, davon auch ein grundverständins von rails pre version 1) war ich nur frustriert.
Du hat 10 Jahre Websites in Ruby geschrieben und bist gänzlich um Rails, Merb usw. herumgekommen? Wow.
Wenn ein framework mir zu wenig freiheiten lässt kann ich nicht ordentlich arbeiten ;)
Ich hätte das Argument anders herum akzeptiert – Rails ist ungefähr auf jedem Level erweiterbar, dass man gar nicht weiß, wo sich Plugins hineinhängen.
Für das was ich mache benutze ich mittlerweile eine kombintation aus ramaze und einem aufsatz von mir.
Mit einem Wort, das kann kein anderer verstehen und warten. ;)
Ich habe mir eine verwaltungssoftware geschrieben, die mehrere apps verwaltet, ihnen entsprechende module/plugins und erweiterungen der standardbibliothek zu verfügung stellt, und letztendlich auch den deploy prozess übernimmt. Apps per knopfdruck anzulegen, die (optional) alles enthalten um eine anwendung zu "bootstrappen".
Rails Generators? RubyGems? Bundler? Capistrano? Rails Engines? – Warum das alles nutzen, wenn man es auch neu erfinden kann. ;)
Grüße,
Mathias
Hallo,
Ich habe unlängst rails 2 und 3 beruflich nutzen müssen und mit erfahrungsschatz (mehr 10 jahre (web)entwicklung mit ruby, davon auch ein grundverständins von rails pre version 1) war ich nur frustriert.
Du hat 10 Jahre Websites in Ruby geschrieben und bist gänzlich um Rails, Merb usw. herumgekommen? Wow.
Exakt.
Wenn ein framework mir zu wenig freiheiten lässt kann ich nicht ordentlich arbeiten ;)
Ich hätte das Argument anders herum akzeptiert – Rails ist ungefähr auf jedem Level erweiterbar, dass man gar nicht weiß, wo sich Plugins hineinhängen.
Das ist eines der probleme. Rails ist erweiterbar, in *jeder* hinsicht. Aber ohne die internals zu verstehen versucht man das besser gar nicht erst.
Für das was ich mache benutze ich mittlerweile eine kombintation aus ramaze und einem aufsatz von mir.
Mit einem Wort, das kann kein anderer verstehen und warten. ;)
Naja, würde ich nicht sagen. Zumindest nicht wenn man ramaze kennt (20 minuten, tbh). Die angelegte struktur ist relativ einfach zu verstehen. Ist mir aber am ende auch egal wer das versteht. Der aufsatz von mir ist opensource, die apps und module nicht.
Ich habe mir eine verwaltungssoftware geschrieben, die mehrere apps verwaltet, ihnen entsprechende module/plugins und erweiterungen der standardbibliothek zu verfügung stellt, und letztendlich auch den deploy prozess übernimmt. Apps per knopfdruck anzulegen, die (optional) alles enthalten um eine anwendung zu "bootstrappen".
Rails Generators? RubyGems? Bundler? Capistrano? Rails Engines? – Warum das alles nutzen, wenn man es auch neu erfinden kann. ;)
Genau das ist der punkt. Ich picke mir das was andere frameworks haben raus. Capistrano ist der hammer, damit deploy ich. Bundler... Klar. Generatoren - nein danke, scaffolding bringt nicht wirklich was, irgendwann schreibt man es eh. Ich erfinde nichts neu, ich binde es nur so minimalistisch wie möglich ein. Ich benutze sequel, bootstrap, capistrano, rake, ramaze, bundler (+x gems). Ich hab echt nichts gegen rails, ich kann nur sagen das wir beide keine freunde werden.
Klar, das kannst du alles mit rails machen. Aber das geht auch einfacher (sinatra, ramaze). Beide frameworks lernt man an einem tag. Nur basics. Den rest mach ich selber.
Grüße,
Mathias
Mfg entropie
Hallo,
Mich hat die Ablehnung jQuery gegenüber doch sehr überrascht
Ja, so ist dieses Forum eben. Haters gonna hate.
Gibt es überhaupt welche die man nutzen sollte oder zumindest empfehlenswert sind für einen durchschnittlichen Entwickler?
Alle sind empfehlenswert, wenn sie einem Produktivitätsgewinn bringen, der sich eventuellen Nachteilen in Waage hält. Ob sie das tun, steht in der Regel im Beipackzettel bzw. du musst es selbst für dich herausfinden.
Frameworks bringen immer verschiedene positive und negative Effekte mit sich, sei es automatisiert getesteter Code, Abstraktion, Patterns, Performance, Kompatibilität, Komfort.
Fakt ist, niemand entwickelt ernsthaft größere Software-Projekte, Websites und v.a. JavaScript-Anwendungen ohne einen Haufen von Tools, Bibliotheken und Frameworks, ob selbst entwickelt, lizensiert oder Open Source.
Für den durchschnittlichen Entwickler gilt die Regel der Schwarm-Intelligenz: Abertausende Entwickler, die eine Open-Source-Bibliothek in tausenden Projekten verwenden und zu ihr beitragen, erzeugen bessere Software, als es eine Person kann. Außerdem sorgen für Stabilität, Weiterentwicklung und Kontinuität, Dokumentation und Beispiele.
Oder ist es ein Vorteil mit aktuellen Frameworks zu arbeiten um schneller zu Ergebnissen zu kommen ohne, dass man sich viel mit Code rumschlagen muss?
Mit viel Code musst du dich immer herumschlagen. Durch Frameworks wird dein Code bestenfalls geringer, dafür schlägst du dich früher oder später mit fremdem Code herum. So ist das in der Software-Entwicklung, man baut i.d.R. auf einem riesigen Software-Stack auf. Damit solltest du dich einfach vertraut machen.
Zu JavaScript-Frameworks:
http://blog.selfhtml.org/2007/10/20/javascript-bibliotheken/
http://aktuell.de.selfhtml.org/artikel/javascript/organisation/#ausblick
http://molily.de/weblog/javascript-standards
http://molily.de/js/bibliotheken.html
Grüße,
Mathias
Om nah hoo pez nyeetz, molily!
Ja, so ist dieses Forum eben. Haters gonna hate.
Warum wieder so verallgemeinernd? Es gibt sicher gute Gründe sowohl für den Einsatz von JQuery als auch dagegen.
Matthias
Hallo!
Warum wieder so verallgemeinernd?
Warum mir wieder Verallgemeinerung vorwerfen? Wenn hier mehrheitlich und prominent Ablehnung herrscht, so ist das ein schlichter Fakt. Leuten fällt auf: »Mich hat die Ablehnung hier sehr überrascht«. Das sollte doch zu denken geben.
Es gibt sicher gute Gründe sowohl für den Einsatz von JQuery als auch dagegen.
Das wurde bereits 2006 kritisch diskutiert. Danach hat sich jQuery als Industriestandard etabliert. Selbst wo jQuery nicht selbst verwendet wird, existieren kompatible APIs (Ender, Zepto, DOMAssistant, Glow, xui…). Keine brauchbare DOM-/Ajax-Bibliothek arbeitet intern anders als jQuery es tut. Was auch immer man im Browser tut, früher oder später wird man Funktionalität von jQuery nachbauen. Und zwar schlechter als sie in jQuery implementiert ist.
Allgemein gesprochen schreibt man Code nicht gegen den Compiler/Interpreter, sondern für den nächsten Programmier. Ein nicht-triviales JavaScript-Projekt, das nicht – soweit möglich – mit gängigen, gut gepflegten Open-Source-Bibliotheken umgesetzt ist, ist eine wirtschaftliche Katastrophe. Welchen Umfang diese Bibliotheken haben, ist dabei gleich; es gibt auch verschiedene, kleinere jQuery-Alternativen, die ich oben genannt habe.
Grüße,
Mathias
Om nah hoo pez nyeetz, molily!
Warum wieder so verallgemeinernd?
Warum mir wieder Verallgemeinerung vorwerfen? Wenn hier mehrheitlich und prominent Ablehnung herrscht, so ist das ein schlichter Fakt. Leuten fällt auf: »Mich hat die Ablehnung hier sehr überrascht«. Das sollte doch zu denken geben.
In besagtem Thread lehnen 3 Poster JQuery ab: Jörg, Steel und Kai. 5 Poster (Matze, entropie, Matti, dedlfix und ich) sprechen sich für die Verwendung von Frameworks aus. Martin hält sich aus der Diskussion um jQuery raus.
Du erläuterst aus Expertensicht in diesem Thread hier ausführlich mMn das Gleiche, was ich versucht habe, mit Kopfrechnen vs. Taschenrechner zu umschreiben. Meinen Argumenten konnten auch Steel und Kai zumindest teilweise folgen. Deinen Beitrag finde ich wertvoll, weil er den Blick in die Richtung der professionellen Softwareentwicklung lenkt.
In "Haters gonna hate" kann sehr viel hineininterpretiert werden, wie ich mir heute angelesen habe. Du bist auch Teil dieses Forums und in diesem prominent. Viele (unter anderem auch ich) lesen deine Beiträge sehr aufmerksam (lesen != überfliegen) und wertschätzen sowohl deine Beiträge als auch deine Meinung.
Matthias
Hallo!
Leuten fällt auf: »Mich hat die Ablehnung hier sehr überrascht«. Das sollte doch zu denken geben.
Ja aber ich verstehe schon wenn man vielleicht sagt "hier und da ganz nett aber insgesamt überflüssig". Nur, dass es als "Geschwuchtel" bezeichnet wird, kam mir schon sehr "gefestigt in einer ablehnenden Haltung" vor, die ich so nicht ganz teilen kann.
Ich oute mich auch gern als Benutzer des Dreamweavers (und meine Elemte heißen nicht "checkbox_1" o.ä. ;)). Ich finde es ist ein fantastisches Werkzeug wenn man damit umgehen kann und will. "Allgemein" wird der allerdings hier auch des öfteren verteufelt.
Vielleicht sollte man einfach davon weggehen die Werkzeuge zu verteufeln und stattdessen auf die zugrunde liegende Technik verweisen wenn trotzdem noch Probleme auftreten. Mittlerweile sind die Werkzeuge, meiner Meinung nach, nämlich sehr gut. Es gibt z.B. kaum noch WYSIWYG-Editoren die fehlerhaftes Html produzieren. Warum sollte man sie also nicht nutzen?
Am Ende leuchtet mir einfach nicht ein wieso man ein bestimmtes Framework, sei es jQuery oder der Dreamweaver als Beispiele, so grundsätzlich verurteilen kann.
Mich hat in dem Sinne also weniger die "allgemeine Ablehnung", sondern eher die "vollständige Abneigung" so überrascht. So als würde man von einem Frameset-Layout sprechen...^^
Grüße, Matze
@@Matze:
nuqneH
Vielleicht sollte man einfach davon weggehen die Werkzeuge zu verteufeln
https://twitter.com/g16n/status/270488844116312064
Qapla'
Moin!
Ja aber ich verstehe schon wenn man vielleicht sagt "hier und da ganz nett aber insgesamt überflüssig". Nur, dass es als "Geschwuchtel" bezeichnet wird, kam mir schon sehr "gefestigt in einer ablehnenden Haltung" vor, die ich so nicht ganz teilen kann.
Aber, aber. Machst Du jetzt das Wort "Geschwuchtel" schlecht? "hier und da ganz nett aber insgesamt überflüssig" ist doch z.B. _eine_ Umschreibung fuer dieses schoene Wort.
Es geht dabei doch eher um den Umgang mit jquery. Sollte man jetzt wirklich nicht lernen wie man einen HTTP Request in JS absetzt, weils ja jquery gibt?
"Guten Tag. Ich moechte gern mobil telefonieren und suche ein Telefon."
"Haaach ja! Da hab ich hier ganz was tolles. Das neue SamsTC 3000, mit 8 GB Ram, 4 TB SDD Wechselfstplatte und 2fach LTE. Super dieses 20" display. Da koennen sie filme gucken... Wie - im - Kino, sag ich ihnen! Gaaanz tolles Design und SO ein schones Betriebsystem. Schaun sie mal wie stylisch! Genau das richtig fuer uns Schwestern. Und tooolle Programme koennen sie dafuer downloaden unglaaublich! ..."
Manchen Leuten fehlt bei sowas dann vielleicht einfach das Taktgefuehl um alle gluecklich zu machen. Da zaehle ich mich durchaus dazu. Meine Antwort im obigen Gespraech waere dann sowas wie "Ey, du Lappen. Ich hab telefonieren gesagt, nicht ueberteuerten PC-Ersatz. Jetzt pass mal auf Du Dackel: Komm runter und zeig mir was vernuenftiges oder schaff jemanden ran der Ahnung hat."
Sicher waer er wohl beleidigt. Ja und?
In meinem "jquery Geschwuchtelpost" habe ich ja auch erwaehnt, dass jquery, wie Dreamweaver, seine Berechtigung hat. Ich habe aber nicht Dreamweaver und damit jquery schlecht gemacht. Das Wort "Massentierhaltung" mag da durchaus einen negativen Touch reingebracht haben. Aber das liegt ja nun wiederum am ungeneigten und unreflektierendem Leser. Der geneigte und unreflektierende Leser wuerde da tatsaechlich seine absolute Abneigung drin wiedererkennen. Nicht so ganz unbeabsichtigt, gebe ich zu.
Klar und nuechtern steht da aber lediglich eine Aufzaehlung von 3 Dingen deren Daseinsberechtigung sich in meinen Augen plausibel erklaeren laesst - solange man nicht polarisiert. Dazu neigen die meisten Menschen allerdings. Nehm ich nur keine Ruecksicht drauf.
Mir entzieht sich hier auch grad minimal der Sinn dieses Threads. Nein nicht die Grundsatzfrage nach Frameworks. Das ist durchaus interessant und jeder sollte da seine Position finden und dafuer auch Fragen durfen, um andere Sichtweisen kennenzulernen. (die eigen Position sollte aber irgendwo in der Mitte liegen, damit sie nicht zu schwuchtelig is... ;)) Aber in Verbindung zu "jquerygeschwuchtel" sehe ich gar keine Diskussionsgrundlage. In besagtem Post war der Begriff meiner(!) Meinung(!) nach sehr passend.
Also: Nun mal nicht so zart besaitet und losgeschwuchtelt. (oder auch nicht) ;)
@@Steel:
nuqneH
Es geht dabei doch eher um den Umgang mit jquery. Sollte man jetzt wirklich nicht lernen wie man einen HTTP Request in JS absetzt, weils ja jquery gibt?
Mit der gleichen Logok könnte man auch fragen: Sollte man jetzt wirklich nicht lernen, wie man eine Schleife in Maschinencode (Assembler sei erlaubt) schreibt, weil’s ja höhere Programmiersprachen gibt?
Welches Framework oder gar keins hängt immer vom jeweiligen Anwendungsfall ab. Was Lea Verou sagte, aber auch Greg Smith’ Antwort.
Qapla'
Hoi!
Es geht dabei doch eher um den Umgang mit jquery. Sollte man jetzt wirklich nicht lernen wie man einen HTTP Request in JS absetzt, weils ja jquery gibt?
Mit der gleichen Logok könnte man auch fragen: Sollte man jetzt wirklich nicht lernen, wie man eine Schleife in Maschinencode (Assembler sei erlaubt) schreibt, weil’s ja höhere Programmiersprachen gibt?
Ist das wirklich so? In meinem Verstaendnis gibts da gewisse essentielle Unterschiede. Dreamwaever steht im Verhaeltnis zu HTML aehnlich wie jquery zu Javascript, aber sicher nicht wie z.B. Javascript zu Assembler.
Hallo!
Aber, aber. Machst Du jetzt das Wort "Geschwuchtel" schlecht?
In dem Kontext scheint es mir kaum einen positiven Sinn vermitteln zu wollen. Insofern, ja.
Es geht dabei doch eher um den Umgang mit jquery. Sollte man jetzt wirklich nicht lernen wie man einen HTTP Request in JS absetzt, weils ja jquery gibt?
Die Frage ist ja, ob ich jQuery verteufeln muss nur weil es ein Framework ist oder ob ich es verteufeln muss weil es erhebliche Nachteile liefert. Das wäre allerdings paradox wo ein Framework doch Vorteile bieten soll und in der Regel auch tut. jQuery eigneschlossen.
Ich habe aber nicht Dreamweaver und damit jquery schlecht gemacht.[..]Der geneigte und unreflektierende Leser wuerde da tatsaechlich seine absolute Abneigung drin wiedererkennen. Nicht so ganz unbeabsichtigt, gebe ich zu.
Warum nicht Klartext? Was denn nun? Nicht "schlecht gemacht" aber eine "nicht ganz unbeabsichtigt wiedererkennbare Abneigung". Wenn du so klar und deutlich in deiner Meinung bist wie du sagst, dann widersprichst du dir irgendwie selbst.
Aber in Verbindung zu "jquerygeschwuchtel" sehe ich gar keine Diskussionsgrundlage. In besagtem Post war der Begriff meiner(!) Meinung(!) nach sehr passend.
Vielleicht fasst einer den Begriff "Geschwuchtel" auch einfach anders auf als der andere und interpretiert da mehr "Abneigung" rein als vorgesehen.
Dreamwaever steht im Verhaeltnis zu HTML aehnlich wie jquery zu Javascript, aber sicher nicht wie z.B. Javascript zu Assembler.
Wie siehst du denn das "Verhältnis" von jQuery zu JavaScript und von JavaScript zu Assembler? Nur so könnte ich einschätzen wie du den Dreamweaver siehst (der für mich persönlich ein fantastisches Werkzeug darstellt).
Grüße, Matze
Moin!
Aber, aber. Machst Du jetzt das Wort "Geschwuchtel" schlecht?
In dem Kontext scheint es mir kaum einen positiven Sinn vermitteln zu wollen. Insofern, ja.
Positiv. Negativ. Sicher nicht uneingeschränkt positiv. Aber auch nicht generell verachtenswert. Aber ganz sicher ein schoenes Wort.
Es geht dabei doch eher um den Umgang mit jquery. Sollte man jetzt wirklich nicht lernen wie man einen HTTP Request in JS absetzt, weils ja jquery gibt?
Die Frage ist ja, ob ich jQuery verteufeln muss nur weil es ein Framework ist oder ob ich es verteufeln muss weil es erhebliche Nachteile liefert. Das wäre allerdings paradox wo ein Framework doch Vorteile bieten soll und in der Regel auch tut. jQuery eigneschlossen.
Sag ich doch: Massentierhaltung bietet erhebliche Vorteile.
Ich habe aber nicht Dreamweaver und damit jquery schlecht gemacht.[..]Der geneigte und unreflektierende Leser wuerde da tatsaechlich seine absolute Abneigung drin wiedererkennen. Nicht so ganz unbeabsichtigt, gebe ich zu.
Warum nicht Klartext? Was denn nun? Nicht "schlecht gemacht" aber eine "nicht ganz unbeabsichtigt wiedererkennbare Abneigung". Wenn du so klar und deutlich in deiner Meinung bist wie du sagst, dann widersprichst du dir irgendwie selbst.
Klartext? Was gabs daran nicht zu verstehen? Ich bin kein Fan davon, Frameworks für jeden Scheiß ranzuziehen. Sollte doch klar geworden sein? Ich geb mir auch keine große Mühe da irgendwie neutral zu wirken. Kann aber natürlich sehen wo der Sinn darin besteht. Genauso wie z.b. in der Massentierhaltung, die interesanterweise aber gern massiv verteufelt wird (bin ich übrigens auch kein Fan von). Dabei gibt es für beides gute Gründe die ich verstehe und aktzeptiere, weil ich unter gegebenen Parametern keine bessere Lösung nennen kann. Ich drücke mich eigentlich klar und deutlich aus.
Weil ich ein Arschloch bin, lasse ich aber gern Spielraum für Interpretationen. Die liest man da aber eigentlich nur rein, wenn man das gern will. Die meisten Leute springen auch drauf an und geben Pro oder Kontra (geht mir selbst ja auch immer wieder mal so). Ich bin nur dafür verantwortlich was ich schreibe (sage), nicht dafür, was Die Leute verstehen (wollen). Ich erlebe es eher selten, daß Leute wirklich darüber nachdenken was ich sage, das analysieren, dann auf mich eingehen und mir mehr oder weniger exakt sagen was meine Meinung ist. Ich bin dann normalerweise sehr überrascht, wenn jemand mich korrekt analysiert. Aber nur weil es normalerweise keiner tut. Schwierig ist das eigentlich nicht. Mal kurz an der Oberfläche gekratzt und schon ist alles offensichtlich.
Ganz vielleicht habe ich aber auch keinen Bock, jeden Scheiss ins Detail erklären zu müssen. (was ich hier grad irgendwie tue)
Aber in Verbindung zu "jquerygeschwuchtel" sehe ich gar keine Diskussionsgrundlage. In besagtem Post war der Begriff meiner(!) Meinung(!) nach sehr passend.
Vielleicht fasst einer den Begriff "Geschwuchtel" auch einfach anders auf als der andere und interpretiert da mehr "Abneigung" rein als vorgesehen.
Jaja. Kennt man schon. Gibt glaub ich sogar eine Southparkfolge die sich mit dieser Thematik auseinandersetzt. In der bezeichnen die Kids Rocker als Schwuchteln, wenn ich nicht irre, was die gar nicht verstehen können, schliesslich sind sie ja harte Kerle. Es gibt sogar Ärger weil den Kids Schwulenfeindlichkeit unterstellt wird, wobei das Wort Schwuchtel in keinerlei Zusammenhang damit steht. Ich hatte mal einen ähnlichen Fall in einer Blood Bowl Liga in der ich ein Waldelfenteam Waldschwuchteln genannt habe. Aus irgendeinem Grund fühlte sich der Spieler dadurch gemobbt. War aber auch der einzige der das so empfand. Wär mir auch neu, daß dort ein Zusammenhang zwischen Spieler und Team steht.
Dreamwaever steht im Verhaeltnis zu HTML aehnlich wie jquery zu Javascript, aber sicher nicht wie z.B. Javascript zu Assembler.
Wie siehst du denn das "Verhältnis" von jQuery zu JavaScript und von JavaScript zu Assembler? Nur so könnte ich einschätzen wie du den Dreamweaver siehst (der für mich persönlich ein fantastisches Werkzeug darstellt).
Ich muss doch jetzt nicht wirklich erklären warum Javascript zu Assembler nicht so steht, wie jquery zu JS? Aber du kannst ja z.B. mal ne Webseite clientseitig mit Assembler programmieren. Vielleicht hab ich da auch nur was verpasst und Browser können das? Ich bezweifle allerdings nicht, daß Du im Allgmeinen jquery dafuer benutzen kannst. (Ich bezweifle übrigens auch nicht, daß man Dreamweaver dafür benutzen kann, HTML zu erstellen)
hi Matze,
Mich hat die Ablehnung jQuery gegenüber doch sehr überrascht und deshalb würde ich gern wissen was ihr allgemein zu Frameworks sagt.
jQuery habe ich früher auch abgelehnt. Dafür gab es zwei Gründe:
1 Eine Seite muss prinzipiell ohne JavaScript funktionieren,
2 das bischen JS schreibe ich selbst.
Heute stehe ich nach wie vor zu Punkt 1. Was Punkt 2 betrifft, ist aus 'bischen' ein bischen mehr geworden. Beispiel: Tabelle sortieren. Der Aufwand serverseitig ist immens, je nach Herkunft der Daten ist eine Sortierfunktion erforderlich, wenn die Herkunft eine DB ist, ist das noch einfach. Dazu gesellt sich eine Kontrollstruktur über die dazugehörigen HTTP Parameter. Ggf. sind bisherige, funktional bedingte Parameter mitzuschleifen und die Struktur der Schlüsselparameter muss gut durchdacht sein.
Ergo: Mit jQuery tablesorter fällt das alles weg mit 'g' wie ganz weg. Fertisch ;)
Horst
