Javascript, Angular, Cordova - Mit welchen Tools professionell programmieren

[Unfug]

Hallo zusammen,

wie man an der Uhr sieht (gleich 2.10 AM) beschäftige ich mich noch mit den im Titel genannten Frameworks bzw. Javascript.

Nachdem ich 1 Stunde gebraucht hatte ein fehlendes " als Fehlerquelle zu identifizieren und 1 Stunde gebraucht habe, dass ein andere Javascript Framework schuld daran ist, dass Angular nicht richtig funktionierte - frage ich mich: Mit welchen Tools ist man in der Lage dieses Javascript Zeugs zu beherrschen.

Aktuell beschäftige ich mich mit einer App Programmierung und setze dafür Javascript ein. Cordova als Bindeglied. Zusätzlich binde ich noch ein UI Framework ein.

Ich bin es von C#, aber auch anderen Scriptsprachen, gewohnt, dass mir die Editoren eine gewisse Hilfestellung bieten. Sei es ein fehlendes " oder die Vervollständiung bis hin zu IntelliSense...aber auch, dass eine Sprache irgendwie immer ein gleiches "Muster" aufweist. Bisher bin ich hier ohne Erfolg.

Ich glaube ich habe diese ganzen Javascript Frameworks noch nicht durchschaut. Angular versucht so etwas wie ein MVC aufzubauen, was aber bei weiten nicht an eine Programmiersprache heranreicht. Die UI Frameworks definieren CSS Klassen und eigene HTML Tags, die von keinem Editor erkannt werden.

Bei Webseiten habe ich selber viel JQuery früher benutzt. Das war aber ja irgendwie..gerade heraus. Alle war Global, man hatte sein DOM und konnte irgendwelche DIVS abändern.
Die heutigen Frameworks haben alle ein anderes Paradigma. Machen alles besser und schöner und lassen sich auch noch anders programmieren.

Mich würde daher interessieren, welche Tools ihr verwendet. Speziell Editoren, die neben Syntaxhighl. vielleicht auch ein Syntaxcheck durchführen. Die Tatsache, dass Javascript ja keine statischen Typen hat, macht das Leben irgendwie nicht leichter.

[RattuS]

Mit welchen Tools ist man in der Lage dieses Javascript Zeugs zu beherrschen.
Ganz einfach: Diese ganzen Trend-Frameworks seinlassen. Lass Javascript, Javascript sein. jQuery ist hilfreich, diese ganzen zusätzliche Layer wie Angular hingegen nur Makeup, das früher oder später verschmiert.

Wenn du beim Strukturieren Schwierigkeiten hast, könnte CoffeeScript oder Dart etwas für dich sein. Wenn es nur um Syntax geht, ist JSHint dein Freund und Helfer.

[Trap]

Wenn du C# entwickelt hast liegt die Empfehlung http://www.typescriptlang.org/ nahe. Das wird auch in Angular2 verwendet werden, ist also nicht völlig exotisch.
Oder zumindest jsLint / jsHint wenn doch reines Javascript gefordert ist...

Bei den Frameworks ist es in Javascript so wie überall sonst:
Man sollte wissen wozu man sie verwendet. Einmal damit man Funktionalität des Framework nicht aus Versehen selbst baut und einmal damit weiß wieso man die Einschränkungen eingeht, die jedes Framework der Anwendung auferlegt.

[registrierter Gast]

Ganz einfach: Diese ganzen Trend-Frameworks seinlassen. Lass Javascript, Javascript sein. jQuery ist hilfreich, diese ganzen zusätzliche Layer wie Angular hingegen nur Makeup, das früher oder später verschmiert.

Lol, was? Wer möchte denn bitte noch, direkt mit jQuery arbeiten, wenn man einmal AngularJS eingesetzt hat.
jQuery ist wie eine Operation am offenen Herzen, viel unnützer Code, keine Struktur, aber Hauptsache ganz viel Animationen und DOM Geschuppse.

Angular bietet die Möglichkeit, all das Unnütze wegzuabstrahieren und sich auf den fachlich wichtigen Code zu konzentrieren, der allein durch die Nutzung von Services, Resourcen und Direktiven schon eine gewisse Grundstruktur erhält.

[Unfug]

Vielen Dank für die Antworten.
Ich werde mir JSHint direkt mal anschauen. Typescript hatte ich mir auch angeschaut als es noch ganz neu war. Das Problem damals war, dass es immer eine aktuelle Typescript Definitionsdatei geben musste. Und wenn ein Javascript Framework upgedatet wurde (damals war es hauptsächlich Jquery), dann dauerte es immer eine kleine Ewigkeit.
Weiterhin fand ich es ziemlich unschön, dass man dann z.B. Jquery als Typescript nutzen konnte, aber andere wiederum nicht. Der Code sah mehr nach KudelMudel aus.

Prinzipiell habe ich auch absolutes Verständnis für Entwicklungen wie AngularJS. Ich finde es ja auch gut. Das MVC Muster ist gut, wobei auch hier ich wieder die Denke von einer Programmiersprache habe. Ich habe wahrscheinlich einfach zuviel erwartet. Es ist ja auch noch relativ jung.

Die Tatsache, dass es aber eine unzählige Anzahl an Frameworks und vor allendingen Vorgehensweisen gibt, führt dazu, dass man teilweise den Überblick verliert.

Kombiniere ich mehrere Frameworks miteinander, so entstehen zum Teil Inkompatiblitäten die erst zur Laufzeit identifiziert werden. Ohne einen Compiler habe ich das Gefühl, dass die Anzahl möglicher Fehler um ein vielfaches höher sind. Auch weil es nicht "DIE" Vorgehensweise gibt.

Nun bin ich aber auch absolut bereit mich damit auseinander zu setzen und bin auch neuen /bzw. wegen Javascript / alten Dingen offen. Ich frage mich nur manchmal. Wie schaffen es die ganzen Entwickler diesem rotzigen Code Herr zu werden und trotzdem so nette Sachen zu entwickeln. Meiner Meinung nach hat Javascript mit Clean Code so gar nichts zu tun. Außer ich übersehe hier einfach etwas. Für mich ist das derzeit noch so viel Try and Error, dass ich mich frage: Mache ich hier einfach etwas falsch oder habe ich einfach nicht die richtigen Tools? Um es zu vergleichen. C# ohne Visual Studio wäre nur 10% so schön. Gleiches gilt natürlich auch für andere Programmiersprachen.

[Monger]

Ich frage mich nur manchmal. Wie schaffen es die ganzen Entwickler diesem rotzigen Code Herr zu werden und trotzdem so nette Sachen zu entwickeln.

Tun sie wohl nicht. Viele große Entwickler halten sich da ja relativ bedeckt, aber nativ in JavaScript entwickelt kaum jemand große Applikationen. Die meisten setzen wohl ihre eigene Metasprache oben drüber, eben wie TypeScript, CoffeeScript etc. pp. .

JavaScript ist quasi Assembler fürs Web: jeder Code wird letztendlich dorthin kompiliert, aber größere Dinge darin von Hand zu schreiben ist unnötig schmerzhaft.

Wir haben auf Arbeit diese Erfahrung auch erst auf die harte Tour gemacht. Frameworks kommen und gehen ständig, die Entwicklung in dem Bereich ist einfach absurd schnelllebig. Wir haben alles hier: eine ordentliche Testinfrastruktur, JSHint, ein ordentlicher Build Service der viele der Frameworks weg abstrahiert... Aber zumindest bei uns hat sich selbst bei den dynamischen Code Jüngern die Erkenntnis durchgesetzt, dass das alleine nicht reicht. Da muss irgendwann eine robustere Sprache her.

[Marscel]

1. Man kann mit Javascript total geistig gesunden Code schreiben. Mit wenigen Kniffen hat man etwas, das sich wie z.B. Klassen aus $NAMHAFTE_SPRACHE verwenden lässt. Können oder in die Tat umsetzen, tun das nicht immer alle.

2. Ich würde nicht wieder eines dieser Hipster-Frameworks anfassen. Einmal wurde ich in ein Projekt hineingezogen, das eig. recht billig war, aber eines dieser meta-stabilen JS-MVC-OS-Sachen einsetzt. Konsequenz war für jmd., der das im großen Rahmen schon oft und schmerzlos machen konnte:

- Faktor 3 der Zeit nötig gewesen. Daran Schuld waren z.T. unglaublich schlechte, veraltete Dokumentationen, die bereits von dir erfahrernen Imkompatiblitäten, ein ständiges "Wer zum Henker denkt sich sowas bloß aus? Man könnte doch einfach ... NOPE".
- Dieses ganze JS-Ökosystem ist unglaublich instabil. Weil dann irgendein Plug-In für irgendeine Tool-Chain in irgendeinem Package-System, `make' ist ja uncool, mit Framework v1.12.17 streikt, und der Autor seit zwei Monaten (ja, zwei Monate und der Mist ist veraltetet!) sich verabschiedet hat. Wir können da eine Anwendung nicht sinnvoll weiterschreiben ohne massiv nochmal durchzugraben. Habe ich den Chefentwickler vor gewarnt, und Recht behalten.

3. Man kann mit jQuery wunderbar frontendseitigen Kram, ganz nüchtern, total gut kapseln und verwenden. Gerade diese MVC-Renderkomponenten beißen auf schwächeren, meist mobilen Geräten, performancetechnisch sehr ins Gras. iPad 2 ausprobiert und am liebsten wieder weggeworfen, was auf einem normalen Rechner noch lief.

4. Was du da für einen Dialekt drüber setzt, TS/CS/ESx/..., ist eigentlich egal und sollte selten zu Problemen führen. Nichtsdestotrotz würde ich aus Kompatiblitätsgründen und ohne die Notewendigkeit, Compiler- und Normalisierungsakrobatik zu machen, davon abraten. Nicht lange her, dass ein Kollege meinte, dass etwas beim Setup lokal bei sich nicht lief. Billiges Amalgamieren von JS und es wäre alles gut gewesen. Ein Transpiler war mittlerweile zu neu.

[Demirug]

JavaScript ist quasi Assembler fürs Web: jeder Code wird letztendlich dorthin kompiliert, aber größere Dinge darin von Hand zu schreiben ist unnötig schmerzhaft.

Deswegen kommt ja jetzt auch Webassembly.

Wir haben auf Arbeit diese Erfahrung auch erst auf die harte Tour gemacht. Frameworks kommen und gehen ständig, die Entwicklung in dem Bereich ist einfach absurd schnelllebig. Wir haben alles hier: eine ordentliche Testinfrastruktur, JSHint, ein ordentlicher Build Service der viele der Frameworks weg abstrahiert... Aber zumindest bei uns hat sich selbst bei den dynamischen Code Jüngern die Erkenntnis durchgesetzt, dass das alleine nicht reicht. Da muss irgendwann eine robustere Sprache her.

Das Problem kenne ich. Wir haben dann angefangen Teile des Codes durch den Toolchain C# -> CIL -> JS zu ersetzen. Das hat die Runtime Fehler massiv reduziert. Vieles wird jetzt schon wegen den statischen Checks von C# gefunden bevor es überhaupt zum ersten Mal den Browser sieht.

[Trap]

Weiterhin fand ich es ziemlich unschön, dass man dann z.B. Jquery als Typescript nutzen konnte, aber andere wiederum nicht.
Man kann immer
var foo: any;
machen, dann hat man das gleiche Verhalten wie Javascript.

Welche IDE hast du bis jetzt für Javascript benutzt? Mal WebStorm ausprobiert? Das ist die übliche Empfehlung dafür und kann schon ziemlich viel an intelligenten Hilfen ähnliche Intellisense.

Ich würde nicht wieder eines dieser Hipster-Frameworks anfassen.
Die ganzen Websachen werden halt von Leuten geschrieben, die vor der Webentwicklung keine andere Software entwickelt haben.

Das hat den Vorteil, dass sie im Web funktionieren. Und den Nachteil, dass sie schlechte Software sind. Wahrscheinlich ist es so herum besser als umgekehrt :freak:

[Unfug]

Hallo,

sind ja einige Antworten dazu gekommen. Im Prinzip teilt sich das Lager ja nicht einmal. Alle sind sich einig, dass Javascript und Co. nicht so einfach ist wie bei statischen Programmiersprachen.
Ich habe aktuell Visual Studio Code im Einsatz - jetzt auch mit JSHint.

Ich finde prinzipiell alles ein wenig verwirrend. Teilweise denkt man sich: Wer hat sich diese Vorgehensweise oder Syntax ausgedacht. Das macht doch gar kein Sinn. Zumindest wenn man wie ich aus der Programmierwelt kommt. Ich habe das Problem auch bisher nur so stark bei Javascript erlebt. Wenn man ein Buch schreiben würde: Best Practice JavaScript, dann wäre das Buch unendlich lang. So wie Marscel schon sagte, alle 2 Monate kommt eine neue Version, die nicht nur einfach neue Methoden mitbringt. Nein sondern auch eine komplett neuen Ablauf der Befehle und (es sieht so aus) Syntax.

Naja genug gemeckert über Javascript und Co. Hoffentlich wird alles bald besser :D. Aufjedenfall versuche ich derzeit mein Glück mit dem oben genannten Editor.
Webstrom hatte ich auch schon getestet in der Trial Version und es sieht auch recht vielversprechend aus.
Da aber auch die Logik nicht wirklich abgefragt wird, sondern nur die Syntax ist es nach wie vor viel try and error.
Aufjedenfall werde ich nicht aufgeben und bin froh, dass ich noch weitere Leidensgenossen gefunden habe. Mein nächster Schritt ist, nach dem aktuellen Projekt, dass ich mich an Typescript ranwage. Wenn es wirklich schon so weit fortgeschritten ist...vielleicht ist das eine Lösung für mich. Zumindest für einen Teil.

[Trap]

Ich finde prinzipiell alles ein wenig verwirrend. Teilweise denkt man sich: Wer hat sich diese Vorgehensweise oder Syntax ausgedacht. Das macht doch gar kein Sinn. Zumindest wenn man wie ich aus der Programmierwelt kommt.
Netscape hat halt einen frischen Uni-Absolventen geholt um den Browser programmierbar zu machen, der wollte was Lisp-mäßiges schreiben, hat aber die Vorgabe "soll aussehen wie Java und du hast 1-2 Wochen Zeit dafür" bekommen. Am Ende kam Javascript raus.


Wenn man ein Buch schreiben würde: Best Practice JavaScript, dann wäre das Buch unendlich lang.
Es gibt "Javascript the good parts" ;D

[Shink]

Hoffentlich wird alles bald besser
Jaja, das wird es schon seit Jahrzehnten.
"Besser" als kaputt ist immer noch nicht super.

[][immy]

Tun sie wohl nicht. Viele große Entwickler halten sich da ja relativ bedeckt, aber nativ in JavaScript entwickelt kaum jemand große Applikationen. Die meisten setzen wohl ihre eigene Metasprache oben drüber, eben wie TypeScript, CoffeeScript etc. pp. .

JavaScript ist quasi Assembler fürs Web: jeder Code wird letztendlich dorthin kompiliert, aber größere Dinge darin von Hand zu schreiben ist unnötig schmerzhaft.

Wir haben auf Arbeit diese Erfahrung auch erst auf die harte Tour gemacht. Frameworks kommen und gehen ständig, die Entwicklung in dem Bereich ist einfach absurd schnelllebig. Wir haben alles hier: eine ordentliche Testinfrastruktur, JSHint, ein ordentlicher Build Service der viele der Frameworks weg abstrahiert... Aber zumindest bei uns hat sich selbst bei den dynamischen Code Jüngern die Erkenntnis durchgesetzt, dass das alleine nicht reicht. Da muss irgendwann eine robustere Sprache her.
Das kann ich so unterschreiben. aber auch z.B. Typescript hat seine Tücken. Wenn z.B.
- von einem Type-script Update zum nächsten alter code nicht mehr läuft
- Alte codestände gepflegt werden müssen
- ...

Je größer ein Projekt, desto mehr nervt Javascript einfach. Selbst mit Typescript.
Fremdbibliotheken sind zwar gut und schön, wenn die aber eines Tages nicht mehr gepflegt werden (das kommt bei Javascript extrem häufig vor) wars das und man darf mit hoher Wahrscheinlichkeit später große Teile neu schreiben, einfach weil die Bibliothek zu alt ist.

Das ist inzwischen aber nicht nur bei Javascript der Fall. Diese ganze Open-Source Mentaltität (hier eine bib, dort eine Bib ...) macht massiv Probleme wenn eine Software über längere Zeit laufen und gepflegt werden soll.

Ganz nebenbei hat Javascript häufig einen heftigen Nachteil den kaum jemand mehr beachtet. Der Speicherverbrauch ist immens und Speicherlecks in Browsern gibt es leider massenhaft, wenn man da nicht genau aufpasst läuft einem einfach mal der Browserspeicher voll. Teilweise obwohl man schon die Seite gewechselt hat. Multithreading-fähig ist Javascript leider auch nicht so wirklich bzw. zumindest nicht mit gleichzeitiger Dom-Manipulation, was doch sehr schade ist.

[Marscel]

[immy;10819566']Ganz nebenbei hat Javascript häufig einen heftigen Nachteil den kaum jemand mehr beachtet. Der Speicherverbrauch ist immens und Speicherlecks in Browsern gibt es leider massenhaft, wenn man da nicht genau aufpasst läuft einem einfach mal der Browserspeicher voll. Teilweise obwohl man schon die Seite gewechselt hat. Multithreading-fähig ist Javascript leider auch nicht so wirklich bzw. zumindest nicht mit gleichzeitiger Dom-Manipulation, was doch sehr schade ist.

Das kann man nicht so stehen lassen. Zum Einen lassen sich JS und Browser heutzutage ziemlich gut voneinander getrennt betrachten, siehe z.B. V8 in der NodeJS-Umgebung. Leakenden Speicher kannst du als Programmierer unter JS genauso selbst verantworten, insbesondere wenn man den Umgang mit Closures nicht richtig hinkriegt. Kann man mit Profilern, oder Valgrind, sich anschauen. Wenn es mit DOM-Genudel Probleme gibt: den Devs des Browser-Kits Bescheid geben.

Ansonsten ist Mozilla Servo z.B. ein Projekt, das solche Beschränkungen aus der Welt schaffen möchte.

[Monger]

Das kann man nicht so stehen lassen. Zum Einen lassen sich JS und Browser heutzutage ziemlich gut voneinander getrennt betrachten, siehe z.B. V8 in der NodeJS-Umgebung.

Mein Eindruck ist eh: serverside und clientside JavaScript driften in enormem Tempo auseinander.
In NodeJS zu programmieren fühlt sich schon jetzt deutlich anders an als im Browser.

[Marscel]

Mein Eindruck ist eh: serverside und clientside JavaScript driften in enormem Tempo auseinander.
In NodeJS zu programmieren fühlt sich schon jetzt deutlich anders an als im Browser.

Das ohnehin. Und in dem Bereich auch gar nicht so schlecht - anders als bei den genannten Websachen: Brauchten einmal einen Server, der genau X macht, überall und schnell deploybar, und effizient und sicher in kleinstmöglicher Zeit zu entwickeln. Das war mit NodeJS das straight-forwardste, solideste Netzwerkprojekt, an das ich mich erinnern kann.

Wenn es nach mir ginge, könnte das gerne alles auf noch sicheren Füßen stehen und noch mehr Bindings mitbringen.

[The_Invisible]

Nutze derzeit auch maximal jQuery + Bootstrap (JS) um wenigstens die ganzen "if/else Browser" Schwierigkeiten abzufangen. Bin irgendwie noch mit keinem JS Framework so richtig warm geworden, schreibe meist meine eigenen kleinen Frameworks um die Daten zu kapseln.

Am liebsten wäre mir wenn mein derzeitiges PHP Framework (Yii) gleich auch ein passendes JS Framework mitliefern würde.

[Ectoplasma]

Unsere Tool Chain sieht seit Jahren wie folgt aus:

Database: Oracle mit Hibernate für Java
Server: Java mit Spring Framework (bietet z.B. JSON Views)
Client: jQuery

Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung.

Das Data-Binding mit Spring <---> JavaScript läuft fast automatisch. Was will man mehr? Das "fast" meint, dass man es selber triggern muss, was kein Nachteil ist, sondern ein riesen Vorteil. FrameWorks die soetwas automatisch machen, sind für Performace und Fehlernalysen die reinste Pest und kosten nur unendlich viel Zeit und Geld.

[Demirug]

Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung.

Nicht jeder Client ist ein einfaches DB Frontend das mit reiner View Logik auskommt..

[Trap]

Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung.
Wie machst du https://pixlr.com/editor/ ohne Business-Logik im Client? Oder https://office.live.com/start/Word.aspx?omkt=de-DE ?

[Marscel]

Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung..

Validierungsunkritisches Zeug, das nur Serverlast kosten würde, kann man heute meist ohne allzu viel Zusatzaufwand den Client selbst machen lassen, wie z.B. den Bildeditor oder Office Anwendungen.

[Monger]

Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung.

Wie kommst du denn darauf?
Schau dir doch mal große moderne Web Applikationen an: GMail, Word Online, die ganzen Bildbearbeitungsprogramme... glaubst du ernsthaft die sind serverseitig implementiert?

Wir hatten auf Arbeit tatsächlich beide Varianten: Business Logik vorwiegend serverseitig, und Businesslogik zumindest mal zur Hälfte im Web. Usability war beim ersten nahezu unbrauchbar. Ist ja auch logisch dass die Applikation träge ist, wenn wegen jedem Furz nach Hause gefunkt werden muss. Zweiteres fühlte sich wie ne Desktop Applikation an.

Der Server ist dann im wesentlichen noch dazu da um die Daten zu persistieren.

[Ectoplasma]

Schau dir doch mal große moderne Web Applikationen an: ..., die ganzen Bildbearbeitungsprogramme... glaubst du ernsthaft die sind serverseitig implementiert?

Bildbearbeitungsprogramme sind nun wirklich eine ganz andere Geschichte, die würde ich niemals serverseitig implementieren.

Wir hatten auf Arbeit tatsächlich beide Varianten: Business Logik vorwiegend serverseitig, und Businesslogik zumindest mal zur Hälfte im Web. Usability war beim ersten nahezu unbrauchbar. Ist ja auch logisch dass die Applikation träge ist, wenn wegen jedem Furz nach Hause gefunkt werden muss.

Wie du schon selber sagtest, kommt es auf den Anwendungsfall an. Klar kann man viele Dinge, beispielsweise Validierungen, bereits im Client machen (machen wir selbstverständlich auch). Es kommt aber auch darauf an, wieviele Anwender zu erwarten sind. Bei wenigen hundert Anwendern, kann man die Validierung auch im Server machen, ohne das es jemanden juckt. Programme wie GMail und Word Online sind hier ganz anders positioniert. Willst du mir sagen, dass ihr solche Software anbietet? Falls ja, dann stimme ich dir zu, dass man viel Businesslogik im Client auslagern muss.

Zum Thema unbrauchbare Usability, die du ansprichst, kann ich nur sagen, dass mir das viel zu pauschal ist. Meinst du Usability, oder die Performance?

[Monger]

Willst du mir sagen, dass ihr solche Software anbietet? Falls ja, dann stimme ich dir zu, dass man viel Businesslogik im Client auslagern muss.

Wir haben ziemlich viel mit grafischen und textuellen Editoren zu tun, ja. Unsere früheren Versionen waren Desktopanwendungen, der Kunde erwartet halt den Komfort mit Autocomplete, Copy & Paste etc. auch im Web.


Zum Thema unbrauchbare Usability, die du ansprichst, kann ich nur sagen, dass mir das viel zu pauschal ist. Meinst du Usability, oder die Performance?
Usability im Sinne von Latenz. Ab 200ms Verzögerung fangen bestimmte Operationen halt allmählich an sich zäh wie Kaugummi anzufühlen. Rein von der Last her langweilen sich sowohl Server als auch Client, aber sobald das Ping-Pong Spiel über die Leitung komplexer wird, machen Benutzerinteraktionen keinen Spaß mehr.

[z3ck3]

Ich entwickel AngularJS mit Netbeans als IDE. Das funktioniert auch sehr gut.

Normalerweise entwickel ich nur Webanwendungen die im Browser laufen, habe aber einmal darauf geachtet das das ganze auch offline funktioniert, bzw. das wirklich alle Daten die man braucht auch per json Request geholt werden. Das ganze dann testweise mal in Phonegap rein geschmissen, wo es dann auch out of the box lief.

Als Paketverwaltung nutze ich dabei bower und "compiliere" mit eigenen gulp scripts (ich füge schon wärend der Entwicklung alle Scripte automatisch zusammen, beim deployen wird dann noch zusätzlich minimiert)

P.s: AngularJS und co. sind kein neumodischer Schnickschnack. Seit ich Angular kennen gelernt habe würde ich es am liebsten bei jedem Projekt ensetzen. Die Trennung von DOM und Javascript ist Gott und macht das ganze strukturiert und übersichtlich. Auch die DI ist nice. Bei jQuery muss der DOM idR. dem entsprechen wie man es im Javascript Code vorgesehen hat. Bei Angular ist das scheiß egal. Du kannst einen Controller auch in einem komplett anderen DOM Kontext nutzen als ursprünglich vorgesehen. Man kann das gesamte Design und den DOM umwerfen und anders aufbauen ohne die Javascript Logik und das Datenhandling anzupassen. So wie man es auch von z.b. PHP MVC Frameworks kennt.

Unsere Tool Chain sieht seit Jahren wie folgt aus:
Database: Oracle mit Hibernate für Java
Server: Java mit Spring Framework (bietet z.B. JSON Views)
Client: jQuery
Ich frage mich manchmal, was denn im Client mit JavaScript alles erschlagen werden soll, ausser reine View-Logik zu implementieren? Wer im Client Business-Logik implementiert, hat selber schuld, nach meiner Meinung

In dem Fall musst du dann ja quasi per Javascript nur noch das Json abrufen. Wie die Daten dargestellt werden sollen amchst du direkt im DOM. Gerade in dem Fall würde ich mir lieber ins Bein schießen lassen als jquery benutzen zu müssen.

[Ectoplasma]

Gerade in dem Fall würde ich mir lieber ins Bein schießen lassen als jquery benutzen zu müssen.

Würde ich mir auch, wenn wir alles damit rendern würden. Den meisten Kram machen wir wie üblich mit JSPs. Den Rest, z.B. das Nachladen von Tables, kann man sehr wohl auch mit diversen jQuery plug-ins erledigen. Wir rendern nur sehr selten im Client direkt mit jQuery. Das ist in der Tat nervig.

[Unfug]

Guten Morgen,

jetzt melde ich mich auch nochmal zurück.
Ich habe eure Tipps zu Herzen genommen. Gerade JSHint war nützlich.

Die Editoren: ich habe Webstorm, VS Code, Sublime und Notepad++, ausprobiert. Zu guter letzt kam noch Visual Studio. Interessante Weise bin ich mit Visual Studio am Besten zurecht gekommen. Da ich VS schon seit Jahren nutze, kenne ich die ganzen ShortCuts und das Interface ist auf mich angepasst. Ich vermute, dass dies ausschlaggebend war. Ich dachte vorher, es gibt einen Editor, der gewissermaßen das für Javascript ist, was VS für C# ist. Gibt es aber nicht.

Debuggen auf PC oder Android wird dann immer mit Chrome gemacht. (Bei Chrome kann man sein Handy inspecten und so auch live Javascript Debugen vornehmen)

Angular: Man muss umdenken. Man darf nicht das alte Denken von Javascript mit ein paar JQuery Methoden nutzen. Angular ist meiner Meinung nach komplett anders. Der Aufbau, die Befehle, die Verkettungen von Asynchronen Methoden, dieses Scope, this..et cetera. Wenn man das Verstanden hat, kommt man "relativ" gut klar mit der Entwicklung. Ich bin auch jetzt schon fast fertig.

Für kleinere Projekte würde ich es vielleicht wieder alles nehmen. Für große professionelle Projekte dagegen nicht. Wieso? Allein das Debuggen/Testen ist eine Qual. Zur Laufzeit passieren aufgrund der dynamischen Datentypen soviele Variationen, die kann man nicht alle testen. Auch habe ich das Gefühl an manchen Stellen, dass das Framework (auch Angular) stetig erweitert wurde, aber alte Zöpfe nicht abgeschnitten. Die JShint Hinweise sind nützlich, wenn man mal eine klammer vergessen hat, aber ohne statische Datentypen haut mir die App trotzdem noch um die Ohren, ab und zu :D.

Und das alle schlimmste.. Der Code sieht unsauber aus. Ich kann da gar nichts für. Es liegt einfach an den vielen verschachtelten Callbacks.
Wenn ich mir das Projekt in 6 Monate nochmal anschaue...Hoffentlich finde ich etwas wieder.

Mein nächstes Projekt wird eine kleine Webseite sein. Gedacht hatte ich zunächst an angular. Jetzt habe ich den Tip bekommen mich mal mit Ember.js ausseinander zu setzen. Hat das jemand von euch? Und hat gute Erfahrung damit?

[Gast_]

Hi,

ich beschäftige mich gerade mit der Frage. Welches Framework für eine RIA WebApp. Aktuell existiert eine Anwendung, die serverseitigen Code mit Informationen füttert und dadurch ein Prozess ausführt.
Von granularen Benutzereinstellungen bis hin zu Settings für den ausführenden Prozess. Ich habe für diesen Post mal die Webseiten gezählt, die angezeigt werden können. Es sind ca. 60 unterschiedliche Seiten, die wiederum irgendwelche Plugins (von Charts bis hin zu komplexen Tabellen) beinhalten.
Das Ganze ist schon sehr sehr aufwendig und ist auch seit Jahren in Entwicklung. Ein riesen Problem ist Jquery meiner Meinung nach. Ich habe gerade im Hintergrund eine Webseite auf, die 3000 Codezeilen hat. Ja richtig. 3000. Von diesen 3000 Zeilen sind 160 Zeilen HTML. Der Rest sind DOM Operationen mittels Jquery. Je nachdem was geklickt wurde, welche Daten nochmal per Ajax abgerufen wurden u.s.w

Im Prinzip ist das gar nicht wirklich wartbar. Allein diese Strings überall. $('#MeinDiv').TueEtwas...das kann doch nicht der ernst sein. Ändere ich auch nur eine ID...wird der komplette Code fehlschlagen. Die Verwendung von Strings im Code als eine Art Identifier lässt mich aufschrecken. Meine Frage daher.

Welche Alternative zu Jquery/JqueryUI und co gibt es, damit man so etwas nicht nochmal macht. Bzw. welche sollte man von den hier genannten schlussendlich für eine RIA App nehmen? Idealerweise ist es ein Framework, welches einen viel Arbeit abnimmt (ähnlich wie bei normalen Programmiersprachen). Darf auch gerne was kosten.
Ich möchte unbedingt Jquery vermeiden. Das ist in der Größenordnung einfach nicht sinnvoll einsetzbar.
Danke

[z3ck3]

Genau für sowas ist AngularJS perfekt geeignet. Die Daten die man vom Server holt sind reine JSON Daten, im Javascript arbeitest du nur mit Objekten, und im HTML machst du nichts als die Daten anzuzeigen und je nach Daten Funktionen und Elemente ein- und auszublenden.

Im Javascript ist es so gut wie scheiß egal was du im HTML Part machst. Gerade diese Wüste an DOM verändernden jQuery aufrufen spart man sich komplett. Du kannst die gesamte HTML Struktur austauschen ohne auch nur eine Zeile Javascript zu schreiben.

[Demirug]

Welche Alternative zu Jquery/JqueryUI und co gibt es, damit man so etwas nicht nochmal macht. Bzw. welche sollte man von den hier genannten schlussendlich für eine RIA App nehmen? Idealerweise ist es ein Framework, welches einen viel Arbeit abnimmt (ähnlich wie bei normalen Programmiersprachen). Darf auch gerne was kosten.
Ich möchte unbedingt Jquery vermeiden. Das ist in der Größenordnung einfach nicht sinnvoll einsetzbar.
Danke

Wir haben für unsere Websachen qooxdoo [http://qooxdoo.org/] benutzt. Das ganze ist aber primär für einen Single Page no HTML RIA Ansatz gedacht.

[Gast_]

Danke. Also SPA ist leider nicht möglich, da die Seiten zu unterschiedlich wären. Also auch von der UI her.
Jede Seite hat wiederum Unterseiten, die wiederum Unterseiten, mit komplett anderen Layout. Zudem kann man die Darstellung selbst einstellen anhand von eigenen Einstellungen.

Ich finde die Demos von qooxdoo allerdings nett. Es stellt sehr schicke UI Komponenten bereit.

Macht es Sinn bei Angular direkt auf 2.0 jetzt zu setzen? Bei Jquery kann man zudem aus z.B. irgendwelchen HTML Tabellen nette Grids oder Charts generieren. Auch Animationen sind ja über JqueryUI möglich. Ist https://angular-ui.github.io/ hierfür der richtige Ansprechpartner?

Danke euch zwei nochmal.

[Trunk]

Hoffe es ist noch nicht zu spät:
Aptana Studio ist der Eclipse-Abklatsch für Web-Sachen:
http://www.aptana.com/

(Dass die Entwickler an ihr Projekt glauben, sieht man daran, dass es als komplette Software angeboten wird, nicht einfach als Eclipse PlugIn :D )

[Unfug]

Nein, ist nicht zu spät. Aptana hatte ich mir auch schonmal angeschaut. Niemals aber richtig. Ich mag das Eclipse Backend irgendwie nicht. Werde die neuste Version aber mal in einer VM ausprobieren.

[z3ck3]

@Gast_: Vieles lässt sich ja bereits schon mit AngularJS selbst lösen. Für "Shiny" Elemente gibts nantürllich auch UI Module. Ein Paar stellt z.b. auch Foundation Apps (http://foundation.zurb.com/apps/docs/) bereit. Und natßürlich kann man auch AngularJS mit jQuery kombinieren. Es lassen sich also auch jQuery Plugins integrieren (z.b. Datatables).

Animationen kann AngularJS indirekt. Machst du über CSS3, Angular Animations (https://docs.angularjs.org/guide/animations) passt dann den Ablauf entsprechend an und fügt Klassen an die Elemente die ein-/ausgeblentet werden und entfernt z.b. die Elemente erst wenn die Animation vorbei ist. Hat das Element keine CSS Animation, dann ist es direkt ausgeblenet bzw. eingeblendet. Das ist meiner Meinung nach auch der einzig logische und richtige Weg. Denn den Javascript Code soll sich ja nicht um das aussehen der Seite kümmern sondern nur um die Datenverarbeitung.

[Unfug]

Kleines Update.
Habe mir als Editor LightTable und Brackets angeschaut. Ersteres fand ich einfach nicht ausgreift und auch relativ langsam. Das LightTable basiert irgendwie auch auf dieser Atom Engine..Gefällt mir nicht.
Brackets dagegen finde ich bisher gut. Es macht Spaß damit Sachen auszuprobieren und es gibt auch nette Plugins, die man einfach über die UI installieren kann.
Ich habe jetzt auch das erste mal bisschen mehr mit Typescript unter Brackets ausprobiert. Gar nicht mal so schlecht. Das ein oder andere ist noch verwirrend und man braucht mehr Zeit um etwas umzusetzen. Durch Brackets habe ich mir auch vieles mit NPM und Grunt angeschaut, was wirklich hilfreich ist.