Webanwendung 2017 - weiterhin js und CSS?

[Unfug]

Hallo,
Ich habe demnächst ein neues Projekt in dem es um eine Webanwendung geht. Meine Frage in die Runde ist: ist ein js Framework (angular, jquery, ..) in Kombination mit HTML und CSS weiterhin empfehlenswert bzw state of the Art? Oder gibt es inzwischen neue Technologien, um eine vernünftige Webanwendung zu bauen
Danke

[registrierter Gast]

Im Grunde ja. Statt Angular würde ich heutzutage Vue.js (https://vuejs.org/) verwenden.

[konkretor]

Im letzten großen Projekt wo ich dieses Jahr unterwegs war, wurde angular in Verbindung mit sass verwendet http://sass-lang.com/ was ja dann nur css Dateien generiert.

[Ganon]

Ich bin in der Hinsicht sehr konservativ und würde mir die Verwendung von größeren JavaScript-Frameworks sehr gut überlegen. "State-of-the-Art Web-Development"-JavaScript wechselt gefühlt jedes Wochenende. Man steht schneller mit einem nicht mehr weiterentwickelten JavaScript-Framework da als einem lieb ist.

[Unfug]

Ja das Problem kenne ich sehr gut. Mein letztes katastrophales Erlebnis war mit Knockout.
Eingesetzt in einem Unterprojekt. Aufgrund der Anforderungen passte es zunächst sehr gut - bis sich die Anforderungen dann etwas geändert hatten.
Dann gings los. Knockout unterstützte das alles nicht und ich musste eigene Routinen hinzufügen. Eigene Module und und und. Die Hilfe, die man sich von so einem Framework wünscht hat sich in das Gegenteil verwandelt. Es ging sogar so weit, dass das Team hinterher Knockout komplett rausgeschmissen hat und 1 Monat lang die Logik in Plain JS umgesetzt hat.
Seitdem gibt es keine Probleme mehr bei Änderungen etc.

Genau das ist auch mein Problem. vue, Angular,Knockout und und und sind alles Frameworks, die sobald es doch individueller wird wesentlich mehr Zeit (und somit auch Kosten) verursachen als wenn man sich auf Stackoverflow die ganzen Plain JS zusammenklickt.

Dann kommt hinzu, dass ich aber auch kein großer Freund von JS,HTML,(s)css bin.
Ich wäre froh, wenn es ein Framework gibt was mir sagt: "Du brauchst kein Javascript, du brauchst kein html, kein css". Programmier alles in einer ordentlichen Sprache und wir bauen dir alles zusammen, bieten Support und Co an. Dafür kostet es aber meinetwegen auch etwas mehr.

Ich dachte nur, dass es vielleicht inzwischen (aufgrund von großen Firmen wie Facebook, Twitter, Google, Netflix) inzwischen nettere Tools/Frameworks gibt - die das Umsetzen von Webanwendungen wesentlich erleichtern.
JS, HTML, CSS macht sowas von kein Spaß

[Ganon]

Es gibt auch einige Tools/Programme/Frameworks die dir z.B. erlauben deine Webseite mit einer Programmiersprache wie Java zu erstellen und dir dann daraus das HTML generieren. GWT z.B. Sowas gibt's afaik auch für Python, C# usw.

Aber damit machst du dich im Endeffekt auch sehr stark abhängig von genau diesem Framework. Long-Term kann (nicht muss) man dann genau in die von dir beschriebenen Probleme rennen. Plötzlich ändern sich die Anforderungen und schon ist das Framework ein großer Klotz der im Weg steht.

Ich mach z.B. auch noch sehr viel Kram Server-Side. Das ist zwar nicht mehr State-of-the-Art, aber dafür muss ich mich nicht mit 5 Browsern rumärgern, die alle unterschiedliche JavaScript-Interpreter haben. Dann macht die Seite eben einen kompletten Refresh wenn man einen Beitrag postet... das stört hier niemanden.

Selbst eine große Seite wie Reddit kriegt's nicht ordentlich hin, warum sollte ich mir das also antun?

[Exxtreme]

Die Frage ist halt erstmal was das für eine "Webanwendung" sei soll. Ist das ein ERP-System oder ein Bildbetrachter oder ...?

[Marscel]

Ein Kollege meinte, die letzte Woche wären TypeScript, ReactNative mit Brunch gemanaged cool gewesen. Wie es diese Woche aussieht, hab ich noch nicht gehört. Und zieh dir nur noch npm-Modules, die nicht das Package `if' verwenden. Nächste Woche müsse er noch alle Dependencies aktualisieren, weil in drei Woche sonst Ende die der Anwendung ist.

Nein, das ist so gut wie keine Satire, sondern die traurige Realität des Wegwerf-Markts im Bereich JS. Die Frage ist tatsächlich ganz knallhart, was du vorhast und auf wie viel Hipsterheit du zugunsten von Ruhe verzichten kannst.

[Ganon]

React war doch auch der Kram, wo man bei Nutzung quasi alle seine Patente an Facebook übergibt, oder?

[Marscel]

Aber der Coolness-Faktor!!!1^¹111

Besser nicht ansprechen, ich hab es einmal gemacht und wurde damit zum Querulanten.

[Exxtreme]

React war doch auch der Kram, wo man bei Nutzung quasi alle seine Patente an Facebook übergibt, oder?
Korrekt. Die ASF trennt sich deshalb von React und restlicher Facebook-Software, die unter dieser Lizenz steht.

https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16088663&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16088663

[Monger]

Das Problem in JS ist ja nicht der Mangel an neuen Technologien, sondern die Schwemme davon die sich jedes Jahr über einen ergießt, ohne dass sich mal irgendwo ein Platzhirsch mit passablen Qualitätsstandards kristallisieren würde.

Ich dachte ja immer, die C/C++ Landschaft wäre unerträglicher Wildwuchs, aber bei JS kann man sich ja nichtmal darauf einigen wie innerhalb eines Projektes gelinkt werden soll...
Kurzum: Die Frage der richtigen Technologien muss man für jedes neue Stück Code neu stellen.

[Unfug]

Oh wow mit so vielen Antworten habe ich gar nicht gerechnet.

Also irgendwie scheinen wir ja alle die selbe Meinung von JS Frameworks zu haben und trotzdem werden sie massig produziert.

Die Webanwendung wird für den Endkomsumenten sein. Login, aktueller Content, ggfs mal ein Video hier, vielleicht eine Anmiation da.....es ist eine lebende Page dessen Umfang eigentlich nicht abgeschätzt werden kann. Auch von der Komplexität kann sich die Anforderung in 1-2 Jahren enorm steigern.

Serverseitig habe ich auch schon überlegt (C#) Aber trotzdem muss ich ja mit Javascript und Html arbeiten. Allein nur um etwas mehr "Leben" in die Page zu kriegen. Das heisst hier wäre ja auf jedenfall wieder JS und ggfs ein Framework notwendig.


Bin aber auch offen zu sagen (in einer anderen Sprache ist auch ok) ich baue es komplett serverseitig auf.
Welche serverseitigen Frameworks sind denn empfehlenswert derzeit bzw nutzt ihr? Je weniger ich mit JS, html und co in Kontakt kommen muss desto besser

[RattuS]

Keine Antwort, die du hören willst, aber einen Gefallen tust du dir und deinen (zukünftigen) Kollegen nur, wenn du dich mit JS/HTML/CSS auseinandersetzt und weißt, was du tust, statt den Weg der geringsten Widerstands zu nehmen und ausschließlich auf die Umsetzung anderer baust.

JS
Wenn du dich um Browser-Kompatbilität nicht kümmern möchtest, nimm jQuery (https://jquery.com/). Es nimmt dir das unbequeme Handling mit AJAX und dem DOM ab. jQuery hat mittlerweile auch schlankere Versionen, die nicht so bloated sind wie die 1er.

CSS
Präprozessoren für CSS (wie das erwähnte Sass) sind meiner Meinung nach nicht unbedingt erforderlich. CSS wächst naturgemäß etwas wild mit der Zeit, ganz besonders, wenn jede Woche neue Dinge hinzukommen oder abgeändert werden. Den regressiven Anteil nimmt dir der Präprozessor da nicht ab. Es kann bei der Übersicht helfen, aber das tut strukturiertes Vorgehen und etwas UI-Konzept auch.

HTML
Serverseitig rendern ist seit den letzten Jahren vielleicht aus der Mode, aber nach wie vor effizient. Massives clientseitiges Rendern (wie z.B. bei AngularJS) kommt mit diversen Nachteilen, u.a. träger initiale Aufbau der Website (synchroner Download des JS-Frameworks), Ausführungsgeschwindigkeit bei schwächeren Geräten (Mobile), flickerndes/ploppendes Drawing, weil das DOM nicht auf Schlag gezeichnet werden kann etc. Die ideale Ansatz ist von beiden Methoden etwas mitzunehmen. Render die Website initial serverseitig und schieb den below-the-fold-Content via AJAX nach. Es spricht nichts dagegen, sich ein minimales Konzept zu überlegen, wie man Content bequem nachschiebt (data attributes (https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes)). Das ist einer der Disziplinen, die die o.g. Frameworks letztendlich auch nur machen.

Übrigens: Wenn wir hier von 100% Hipster-Tech sprechen, muss der Begriff Microservices noch fallen, ihr Banausen! ;D

[Marscel]

Als ob heutzutage das alles einfacher geworden wäre. :freak:

Nunja, am einen Ende steht good-old Server-Rendering, das dir für nahezu jeden HTTP-Request eine fertige Seite ausgibt.

Am ganz anderen Ende stehen isomorphe JS-Frameworks, d.h. der Server kann einmal komplett das Vorrendern und statisch ausspucken, was sonst der Client mit $FRAMEWORK_DER_WOCHE.js sich selbst zusammensteckt. Das macht man z.B. dann, wenn einem SEO oder schnelle Initialausgabe noch wichtig ist.

Alles andere wird komplett von einem Daten-Endpunkt gemanaged, d. h. der HTTP-API-Server hat überhaupt nichts mehr mit der Darstellung zu tun, nicht einmal das Laden des Frontends. Je mehr man fancige Single-Site-Applications mag (also man hat den Eindruck des herkömmlichen Browsens, aber eigentlich tut das JS-Framework alles in Eigenregie), desto sinnvoller ist dieser Ansatz.

Graduell natürlich auch Mischformen dazwischen. Daher: Use-Case. Wenn das nicht absehbar ist, dann erstmal das mit der geringsten Hemmschwelle, also z. B. klassisches SSR, jQuery im Frontend.


Server-seitig ist auch für alle Erfahrungsstufen und Nachhaltigkeit was dabei.

Mit Ruby/Rails hast du z.B. viel an Board, das ist aber extrem träge im Vergleich zu anderen Sachen.

ASP.NET hat sich erst kürzlich von Windows weg bewegt, und ein paar gängige Libraries hatten beim letzten Testen noch ein paar Hiccups. Müsste man ausprobieren, fand ich aber persönlich auf Windows recht gut handhabbar.

Java EE/Servlets: Kann man wenig mit falsch machen, könnte aber etwas over-engineered sein für den Anfang.

NodeJS: Geht auch und ist ziemlich flott, man landet aber wieder im JS-Dep-Getümmel.

Und sonst: PHP hat etliches im Angebot, Python mit Django.

[Unfug]

Danke nochmal.

Dann bleib ich wohl erstmal beim Plain JS.

Ich hab nur wenig Lust auf JS, CSS, HTML. Aber dann muss ich da jetzt (wieder) mal durch.:frown:

Echt schade, dass es nichts Vernünftiges als Alternative gibt. Das Gefrickel ist schon nervig. Im Prinzip echte Programme fürs Web. Da gab es doch mal Bestrebungen seitens Google.

@Rattus
Microservice? gääähhhnn .. serverless function! :-D

[Exxtreme]

Im Prinzip echte Programme fürs Web. Da gab es doch mal Bestrebungen seitens Google.

Das nennt man Webassembly und ist noch nicht so weit. Und Webassembly ist der Programmiersprache C ähnlich. Und gegen C ist JavaScript ein Segen. :freak:

[Ganon]

Und Webassembly ist der Programmiersprache C ähnlich.

Huh? WebAssembly ist ein Bytecode und nicht an eine gewählte Programmiersprache gebunden.

[Ben Carter]

Danke nochmal.

Dann bleib ich wohl erstmal beim Plain JS.

Ich hab nur wenig Lust auf JS, CSS, HTML. Aber dann muss ich da jetzt (wieder) mal durch.:frown:

jQuery würde ich noch mitnehmen, das kann einem schon viel Arbeit und vor allem Browserinkompatibilitäten abnehmen.

lg Ben

[twodoublethree]

Da es noch keiner erwähnt hat: Sieh Dir TypeScript (http://typescriptlang.org) mal an.

Kurz gesagt, TypeScript ist JavaScript mit static typing und kommt, vom Gefühl her, C# sehr nahe. Wenn Du im Backend sowieso C# einsetzt wirst Du vermutlich auch Visual Studio nutzen, TypeScript klappt damit fast ohne extra Konfiguration, im Wesentlichen reicht Dir die Einstellung, den gesamten TypeScript Code als bundle.js zu kompilieren.

Ganz unabhängig vom Framework erleichtert TypeScript die Handhabung von großen Projekten ungemein, einfach schon weil vieles vom Compiler abgefangen wird und die Unterstützung von IntelliSense schon fast mit der, die man von C# gewohnt ist, mithalten kann.

[Ectoplasma]

Mit jQuery machst du absolut nichts falsch. Die Seiten würde ich, so weit es sinnvoll ist, im Server vorrendern. Also schön Old-School. Kennt jeder und hat sich bewährt.

[RMC]

Die Frage ist halt erstmal was das für eine "Webanwendung" sei soll. Ist das ein ERP-System oder ein Bildbetrachter oder ...?

Im Endeffekt sind alle Webanwendungen immer nur Datenbanken mit seinem Skin dran.

Jeden Tag kommen 20 JS Frameworks dazu und 10 werden obsolete, alle tun nur das gleiche nur ein bisschen anders - für dieselbe Problemstellung, die meistens unverändert bleibt.