Java Script Frameworks
- Ersteller diggeeier
- Erstellt am
J4CK50N
Lt. Junior Grade
- Registriert
- Aug. 2008
- Beiträge
- 317
Das kommt darauf an was du tun willst.
Du kannst z.B. JQuery nicht mit NodsJS vergleichen und diese beiden wiederum nicht mit knockoutJS.
Worauf möchtest du dich, denn spezialisieren?
Rein Frontend oder interessiert dich auch die Datenübertragung AJAX und Backend?
Du kannst z.B. JQuery nicht mit NodsJS vergleichen und diese beiden wiederum nicht mit knockoutJS.
Worauf möchtest du dich, denn spezialisieren?
Rein Frontend oder interessiert dich auch die Datenübertragung AJAX und Backend?
Von welchem Zeitraum redest du? Das Web ist sehr kurzlebig.
Die nächsten 1-3 Jahre? Dann bist du mit Angular.js im Frontend und Node.js im Backend vielleicht auf einer guten Spur. Vielleicht aber auch nicht.
Ab 2-5 Jahre? Das kann kaum jemand sagen, wie es bis dahin aussieht. Native WebComponents? EcmaScript 6? Oder wird jeder seine Lieblings-Programmiersprache verwenden und es einfach zu asm.js complilieren? Oder irgendetwas, was heute noch niemand auf dem Schirm hat?
So oder so, du musst dich einfach zu etwas entscheiden und das dann ernsthaft durchziehen. Du kannst ja mal auf GitHub die Frameworks suchen und einfach mal vergleichen wieviele Sterne sie haben und wie regelmäßig sie gepflegt werden. Und die Google Trends befragen: https://www.google.de/trends/explore#q=angular.js, backbone.js, ember.js, react.js&cmpt=q
Welches Framework das richtige ist, hängt auch natürlich von deinem Anwendungsfall ab. Backbone.js ist z.B. wesentlich "leichtgewichtiger" und "meinungsloser" als Angular.js, dass gleich eine ganze Philosophie mit sich bringt.
Auf jeden Fall mal viel Erfolg! (von jemanden der schon unzählige Frameworks durch hat...)
Simon
Nachtrag: Also ich bin jetzt einfach mal davon ausgegangen dass du mit Framework auch Frameworks meinst und keine Libraries, wie jQuery
Die nächsten 1-3 Jahre? Dann bist du mit Angular.js im Frontend und Node.js im Backend vielleicht auf einer guten Spur. Vielleicht aber auch nicht.
Ab 2-5 Jahre? Das kann kaum jemand sagen, wie es bis dahin aussieht. Native WebComponents? EcmaScript 6? Oder wird jeder seine Lieblings-Programmiersprache verwenden und es einfach zu asm.js complilieren? Oder irgendetwas, was heute noch niemand auf dem Schirm hat?
So oder so, du musst dich einfach zu etwas entscheiden und das dann ernsthaft durchziehen. Du kannst ja mal auf GitHub die Frameworks suchen und einfach mal vergleichen wieviele Sterne sie haben und wie regelmäßig sie gepflegt werden. Und die Google Trends befragen: https://www.google.de/trends/explore#q=angular.js, backbone.js, ember.js, react.js&cmpt=q
Welches Framework das richtige ist, hängt auch natürlich von deinem Anwendungsfall ab. Backbone.js ist z.B. wesentlich "leichtgewichtiger" und "meinungsloser" als Angular.js, dass gleich eine ganze Philosophie mit sich bringt.
Auf jeden Fall mal viel Erfolg! (von jemanden der schon unzählige Frameworks durch hat...)
Simon
Ergänzung ()
Nachtrag: Also ich bin jetzt einfach mal davon ausgegangen dass du mit Framework auch Frameworks meinst und keine Libraries, wie jQuery
Zuletzt bearbeitet:
SymA
Captain
- Registriert
- Apr. 2006
- Beiträge
- 3.347
Welche Art von Framework? Reden wir von Application Frameworks wie AngularJS? @J4CK50N bei dir ließt es sich so als ob NodeJS ein Framework wäre.
Ansonsten muss ich zustimmen - es kommt darauf an was du machen möchtest. Grob gesehen ist das wie mit den Programmiersprachen kannst du eine -> kannst du theoretisch alle bis auf die speziellen Eigenheiten
jQuery ist imho in den meisten Fällen sogar zuviel des Guten für ein paar kleinere Dinge und ich persönlich finde in letzter Zeit geht der Trend Richtung nativem JavaScript unter Verwendung wie underscore.js oder lo-dash
Ansonsten muss ich zustimmen - es kommt darauf an was du machen möchtest. Grob gesehen ist das wie mit den Programmiersprachen kannst du eine -> kannst du theoretisch alle bis auf die speziellen Eigenheiten
jQuery ist imho in den meisten Fällen sogar zuviel des Guten für ein paar kleinere Dinge und ich persönlich finde in letzter Zeit geht der Trend Richtung nativem JavaScript unter Verwendung wie underscore.js oder lo-dash
blöderidiot
Captain
- Registriert
- Juni 2004
- Beiträge
- 3.878
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
diggeeier schrieb:
Kurz: Keins...
Schau dir doch einfach mal an wie weit das Web in den letzen 5 Jahren gekommen ist. Es wird nicht DAS Framework geben dafür gibt es einfach zu viele Entwickler der eine sagt A der andere B und ein anderer sagt wieder F.
Ich sage mal die big Player in sachen JS sind:
JQuery
Node.js
Angular.js (dies dürfte es recht lang geben da Google mit dabei ist).
und sicherlich noch ein paar mehr.
Ich persönlich muss aber sagen ich bin kein Freund von JS. Es wird so viel misst mit JS gemacht obwohl man es gar nicht benötigt vieles kann man ohne Probleme mit CSS erreichen und man sollte nicht für alles die JS Keule auspacken.
blöderidiot
Captain
- Registriert
- Juni 2004
- Beiträge
- 3.878
Cool Master schrieb:
Na ja, die Zukunft werden die JS-basierten UI-Frameworks sein. Als Fuhrunternehmer kaufst Du ja auch keinen Dieselmotor.
Es spielt nur eine Rolle, ob man gute Sachen damit machen kann.
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
blöderidiot schrieb:
Seh ich nicht so
Es kommt immer auch auf die Performance an was bringt mir ein Framework das alles super kann wenn es auf dem Mobilen Geräten die CPU zum überhitzen bringt? Wie gesagt vieles kann man mit CSS machen und zur not mit JS verändern wobei vieles gar nicht mehr benötigt wird dank responsive design.
trialgod
Lt. Commander
- Registriert
- Feb. 2008
- Beiträge
- 1.547
Cool Master schrieb:Seh ich nicht so
Ich behaupte jetzt einfach mal, dass du gar nicht weißt, was man mit JS alles machen kann. Zumindest lassen deine Aussagen darauf schließen.
Serverseitiges Rendering war schon immer Schwachsinn. Und endlich gibt es auch im Web Möglichkeiten dieses zu umgehen.
Javascript hat nichts mit Anpassung vom Aussehen zutun. Es waren lediglich Workarounds, um die Entwicklung voran zu treiben. Dass es sich noch immer nicht rumgesprochen hat, dass man Behavior und Styles voneinander kapselt.. dafür kann JS nun wahrlich nichts.
Zuletzt bearbeitet:
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
@trialgod
Ich bin Webentickler... Wie gesagt, Design technisch, löse ich praktisch alles per CSS weil dies auf jedem Gerät läuft - auch mit Noscript oder ausgeschaltetem js.
Warum sollte Serverseitiges Rendering Schwachsinn sein? Es ist doch deutlich Sinvoller den Server, der die stärke CPU, mehr RAM, mehr HDD/SSD, sprich einfach mehr Leistung hat alles berechnen zu lassen und diese dem Client auszugeben. Da kann man dann sogar mit einem Raspberry Pi sehr viele moderne Browser Features nutzen. Genau dafür gibt es ja AJAX
Ich bin Webentickler... Wie gesagt, Design technisch, löse ich praktisch alles per CSS weil dies auf jedem Gerät läuft - auch mit Noscript oder ausgeschaltetem js.
Warum sollte Serverseitiges Rendering Schwachsinn sein? Es ist doch deutlich Sinvoller den Server, der die stärke CPU, mehr RAM, mehr HDD/SSD, sprich einfach mehr Leistung hat alles berechnen zu lassen und diese dem Client auszugeben. Da kann man dann sogar mit einem Raspberry Pi sehr viele moderne Browser Features nutzen. Genau dafür gibt es ja AJAX
trialgod
Lt. Commander
- Registriert
- Feb. 2008
- Beiträge
- 1.547
Cool Master schrieb:
Ganz einfach: Das HTTP Protokoll ist Stateless. Und da wir ohne States im Web aber nicht leben können, mussten wir irgendwelche weiteren Workarounds finden (Session, Cookie, etc.), die diesen State simulieren. Dies ist aber absolut fehleranfällig und -ich sage es leger- kacke. Die Krönung dieser Verschandelung lieferte Microsoft mit ASP.NET (WebForms).
Zudem hat ein Server eben nicht mehr Leistung, wenn er x-tausend Anfragen bearbeiten muss. Jedes Endgerät hat heutzutage allerdings mehr als genug Leistung um das Rendering zu übernehmen. Eventuell müssen hier und da ein paar Anpassungen gemacht werden um die Performance zu verbessern, allerdings muss man das auf dem Server -wenn auch ggf. an anderer Stelle- ebenfalls tun.
Cool Master schrieb:Genau dafür gibt es ja AJAX
Du weißt schon, dass AJAX "Asynchronous JavaScript and XML" heißt?
Das Problem ist, dass AJAX immer nur Teile einer Seite aktualisiert. Wenn man aber Abhängigkeiten in seiner Applikation hat (z.B. Breadcrumbs), muss man wieder ein Gefrickel drumrum bauen. Dieses Gefrickel, sowie der AJAX Call per se ist mit den meisten Libraries bzw. mit plainem JS voller Abhängigkeiten (UI zu Code) und damit untestbar, unübersichtlich, kurz schlecht.
Das obere Beispiel ist übrigens ein simuliertes State Management für das Workaround State Management auf dem Server.
Übrigens:
Bitte nimm das nicht persönlich. Ich kenne dich nicht und kann dich nicht einschätzen.
Aber heute nennt sich jeder Hansel Webentwickler, der mal ein Plugin in Wordpress installiert hat. Dieses Siegel lässt heutzutage leider kaum noch auf Kenntnisse schließen.
@Topic
Ich kann jedem Webentwickler unbedingt empfehlen sich mit JavaScript und dessen Eigenheiten auseinander zu setzen. Vorallem zu verstehen was JavaScript ist und was nicht. Es geht weit über die DOM Manipulation und das Scriptkiddietum hinaus.
Ich kann jetzt nicht behaupten ich sei Profi darin, allerdings merkte ich vor 4 Jahren, dass ich zu unfit bin und habe meine Kenntnisse derweil stets erweitert. Es hat sich als richitg erwiesen, die Vergangenheit hat gezeigt, dass immer mehr vom Server auf den Client geschoben wurde. Einfach weil es unsinnig war für eine Formularvalidierung einen Seitenreload zu machen und auch hier wieder den kompletten State simulieren und wiederherstellen zu müssen. Genauso unsinnig ist es für den Rest des verbliebenen Statemanagements.
Für mich geht die Entwicklung, wie auch für "blöderidiot" ganz klar in Richtung Frontend-UI-Frameworks. Ich denke mit AngularJS macht man hier am wenigsten falsch, einfach weil Google dahinter steht.
Setzt euch mit NodeJS, Grunt, Bower auseinander. Und schaut euch dann AngularJS an. Es lohnt sich!
Es gibt noch diverse andere Vorteile, z.B. dass Backend Services auch für andere Applikationen wiederverwendbar sind. Dass man aus einer AngularJS Webseite ebenfalls plattformunabhängige Apps bauen kann. Die Liste ist ewig erweiterbar.
Zuletzt bearbeitet:
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
trialgod schrieb:
Ok, ich seh kein problem mit Cookies oder Sessions
Ganz im Gegenteil damit wird vieles erleichtert.trialgod schrieb:
Deswegen nutzt man auch ein Cache. Keine Ahnung was du Beruflich machst aber ich hoffe du haust nicht für jede Anfrage nen SQL Query raus oder? Man setzt auf ein gutes Framework sei es z.B. Drupal oder Django und das kümmert sich wunderbar um das Caching.
trialgod schrieb:
Ist mir bekannt trotzdem wird es auf dem Server ausgeführt.
trialgod schrieb:
Genau deshalb setzt man auf Frameworks die das alles für einen Übernehmen.
trialgod schrieb:
Nicht persönlich genommen
Wordpress? Das isn Blog System und nichts anderes. Ich bin seit neustem Drupaler und davor wars Django sprich voher Python und jetzt PHP. Dazu kommt ich bau Flash Applikationen in HTML5 um. Zugegeben ich bin eher im Frontend zuständig aber trotzdem habe ich keine Angst vorm Backend oder der MySQL DB.
trialgod
Lt. Commander
- Registriert
- Feb. 2008
- Beiträge
- 1.547
Es tut mir leid, aber spätestens mit der Aussage zeigst du, dass du gar nicht verstanden hast um was es geht. Du hast wahrscheinlich immer im Web mit denen dir vertrauten Vorgehensweisen gearbeitet (dabei ist es belanglos ob Python, PHP oder Wurstsuppe). Wenn du gar nichts anderes kennst, ist es auch kein Wunder und dann sind deine Aussagen nicht viel wert. Entwickel mal an einer Desktopanwendung mit DB, Application Server (oder Service, wie du es nennen magst) und Frontend. Oder nimm gleich Angular, das Prinzip ist fast das gleiche.Cool Master schrieb:Ok, ich seh kein problem mit Cookies oder Sessions
Ja, es geht auch "old fashioned" auf dem Server. Es geht aber meistens besser mit einem gekapselten Frontend.
Welche Art von Cache kommt wann in Frage? Pagecache, Datacache? Weiterhin In-Memory, File oder DB Cache? Und dein Framework entscheidet für dich welche Art und Kombination von Caches für deinen Anwendungsfall in Frage kommt? Also wenn Django oder Drupal das können, dann bin ich wohl bald meinen Job los.Cool Master schrieb:
Meine berufliche Laufbahn spielt hier keine Rolle. Um es kurz anzureißen: PHP mit ZendFramework, derzeit leider ASP.NET. Ich experimentiere privat aber viel rum (z.B. WPF, Angular mit WebApi, etc.).
Die Aufbereitung und Auslieferung der Daten wird IMMER auf dem Server bzw. im Backend von statten gehen. Das geht gar nicht anders. Es geht lediglich um die Darstellung.Cool Master schrieb:Ist mir bekannt trotzdem wird es auf dem Server ausgeführt.
Kein Framework übernimmt für einen jede Art von Anwendungsfall. Auch nicht, wenn es wie in deinem Fall ein CMS ist.Cool Master schrieb:
Wordpress ist eigentlich mehr ein CMS. Drupal übrigens auch. Ich kenne beide sehr wenig, es sollte nur als überspitztes Beispiel dienen.Cool Master schrieb:Nicht persönlich genommen
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
trialgod schrieb:
Dafür nutze ich TideSDK. Vorteil davon ist, dass es automatisch auf allen OS läuft. Kannst dir auch mal genauer anschauen evtl. ist es ja was für dich
trialgod schrieb:
Nein nicht automatisch. Das muss man natürlich selber einstellen/entscheiden.
trialgod schrieb:
Klar jede Art nicht - ist klar. Man sieht aber du kennst dich mit Drupal nicht aus. Drupal ist weit mehr als "ein CMS". Ja, man kann es als CMS nutzen und dafür wird es auch in 90% der Fälle benutzt aber Drupal kann noch vieles vieles mehr. Vor allem von der neuen Version 8 erhoffe ich mir sehr viel.
trialgod schrieb:
Wordpress ist kein CMS. Wordpress wird zwar gerne als CMS bezeichnet aber ist, wie ich schon schrieb, ein Blog System. Ist meine Meinung zu dem System, sprich ich mag es nicht
Ganz blödes Beispiel, weil dafür nicht einmal JS notwendig ist. Lediglich ein HTML5-Browser tut not. Andererseits ein blödes Beispiel, weil du TROTZDEM deine Validierung im BE schreiben musst, für all die Leute, die so gern NoScript & Co verwenden.trialgod schrieb:
Was Sessions & Cookies als State-Lagerplatz angeht:
KANN man machen, ist aber ne Qual. Schmeißt man allen möglichen Ramsch in die Session, wird selbige auf dem Server exorbitant groß und entsprechend unperformant. Schmeißt man Daten in Kekse, dann wird die Verbindung an sich lahmarschig, weil jedes Mal freudiges Cookie-Schubsen angesagt ist.
Eine moderne zustandsbehaftete Webanwendung (z.B. n Webmailer) kann man einfach nicht anständig & performant auf klassischem Wege serverlastig umsetzen.
Schick dem Client nur kurze JSON/XML-Happen und die Erklärung, wie er mit dem jeweiligen Happen umgehen soll. Das ist viel sinnvoller und performanter.
trialgod
Lt. Commander
- Registriert
- Feb. 2008
- Beiträge
- 1.547
Daaron schrieb:
Naja Jaein. In der Theorie ja, in der Praxis reichen aber HTML5 Elemente nicht aus. Entweder aus Inkompatibilitäten, oder aus weil sie zu wenig Möglichkeiten bieten. Ich wüsste jedenfalls auf Anhieb nicht, wie ich z.B. eine IBAN Nummer mit einem HTML5 Element validieren sollte.
Dass man im Backend ebenfalls validieren sollte, ist natürlich korrekt. Das habe ich jetzt mal als gegeben vorausgesetzt
Allerdings muss ich den State nicht mehr beachten (sofern ich nicht komplettes HTML rumschicke). Ich sende einfach die Daten hin und bekomme dann eine JSON Antwort mit Validierungsergebnis ODER einem neuen Html (eingebettet in JSON). So habe ich das jedenfalls die letzten Jahre gehandhabt. Auch hier zeigt sich schon, dass die Vorgehensweise nicht wirklich optimal ist.Wer kein JavaScript hat, hat für mich Pech gehabt. Ich entwickel zum Glück keine Consumerwebsites, da hab ich das Problem nicht (mehr). Wenn ich AngularJS oder was ähnliches einsetze, ist man ohne JS auch verloren.
Cool Master schrieb:Dafür nutze ich TideSDK. Vorteil davon ist, dass es automatisch auf allen OS läuft. Kannst dir auch mal genauer anschauen evtl. ist es ja was für dich
Ich werde es mir mal anschauen, aber spielt für mich keine wirkliche Rolle. Es sieht nicht aus wie eine native App und fällt daher für mich aus. .NET liefert mir einfach die beste Programmiererfahrung, daher bleibe ich dabei.
Hast du denn dort Session und Cookies? Läuft das auch über einen Apache oder ähnlichen Webserver?
Ich meinte wirklich so ein 3 Layeriges System, wie in meinem letzten Post beschrieben. Und noch ein entscheidender Vorteil, den ich bisher gar nicht explizit genannt habe kommt noch hinzu. Das Databinding. Tu dir den gefallen und mach mal dieses Tutorial: http://learn.knockoutjs.com/, sofern du es nicht kennst.
Genau darum geht es doch. Für manche Anwendungen kann man nicht oder nur schlecht cachen. Alles was mit Interaktion zutun hat z.B.. Man investiert ggf. viel Zeit in Cachingmechanismen, die überhaupt nicht nötig wären. Ein guter Restserver skaliert wahnsinnig gut.Cool Master schrieb:
Naja sogesehen ist ein Blogsystem auch ein CMSCool Master schrieb:Wordpress ist kein CMS. Wordpress wird zwar gerne als CMS bezeichnet aber ist, wie ich schon schrieb, ein Blog System. Ist meine Meinung zu dem System, sprich ich mag es nicht
Aus technischer Sicht finde ich Wordpress auch schrecklich. Aber ich seh das eher pragmatisch: Was will ich erreichen, wie schnell kann ich es erreichen und was kostet es mich. Da ist Wordpress für sein Anwendungsgebiet ziemlich optimal.Nachtrag:
Ich habe übrigens gerade gelesen, dass Drupal8 auf Symfony aufgebaut wird. Das war vor 5 Jahren modern
Zuletzt bearbeitet:
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 37.470
trialgod schrieb:
Mag ich überhaupt nicht da nur unter Win lauffähig aber gut wenn man es damit machen muss gehts halt nicht anders.
trialgod schrieb:
Kommt drauf an wie du es willst. Du kannst alles lokal mit geben oder du lässt auf einen Server connecten. Kommt halt auf die Anwendung an was besser ist.
trialgod schrieb:
Schau ich mir mal an wenn ich Zeit hab.
trialgod schrieb:Ich habe übrigens gerade gelesen, dass Drupal8 auf Symfony aufgebaut wird. Das war vor 5 Jahren modern
Juckt doch nicht obs modern ist oder nicht. Wenn es gepflegt wird passt es doch.
![[ChAoZ]](https://pics.computerbase.de/forum/avatars/s/491/491529.jpg?1618073566){kind=avatar}
