Webapp entwickeln, wo anfangen? (JS, HTML, CSS, SQL)

[NuklearNudel]

Hiho,

würde gerne zweckes näherem Verständnis von Webtechnologien gerne einmal den kompletten Stack probeweise implementieren, sprich:
Webapp/Webseite programmieren mit klickevents und irgendwelchen Daten die in einer Datenbank abgelegt werden.

Fragen hierzu:
-Brauch ich hier Wissen zu Client/Server-Struktur? Eigentlich möchte ich nur Clientseitig eine Browserseite mit dem JavaScript ablaufen lassen.
-Welches Framework zur Entwicklung empfiehlt sich? Eclipse? Angular.js?
-Hat jemand ein gutes Basic Tutorial?

Hintergrund:
habe erste Programmiererfahrungen mit Java-APIs diverser SW-Systeme. Sprich nix mit plattformunabhängigen GUIs oder SW-Entwicklung, aber Grundprinzipien vorhanden.

 

[ducki]

folgendes video gibt einen guten überblick: https://www.youtube.com/watch?v=sBzRwzY7G-k
gibt sicherlich nicht 'den' weg den man nehmen muss.

ich persönlich würde empfehlen:

1. HTML, CSS grundlagen.
in sachen layout einfach nur flexbox lernen und sich die ganzen alten hacks nicht mehr antun. noch weniger aufwand ist ein framework ála Bootstrap zu nutzen, wenn dich der etwas ausgelutschte look nicht stört kann man damit sehr schnell responsive layouts und ordentliche seiten basteln.

2. (vanilla) JS
ich empfehle das hervorragende (kostenlose) Eloquent JavaScript. gibt auch ein gutes intro in die programmierung generell, wird deine kenntnisse gut auffrischen und dir vielleicht noch ein paar neue konzepte beibringen.
ohne JS geht im modernen web imo nichts mehr.

3./4. Node.js/Express fürs backend
wenn du was in einer datenbank abspeichern möchtest, kommst du um einen server nicht herum.
für das standard CRUD (Create, Read, Update, Delete) zeugs via einer REST API, die von deinem client konsumiert wird, ist Express bestens geeignet. und du schreibst dann front- und backend in der gleichen sprache, das ist ein großes plus.

3./4. ein JS-Framework deiner wahl fürs frontend
wenn du von einer web'app' redest meinst du damit wohl eine moderne SPA, und da ist ein framework sinnvoll.
jQuery wird zwar heute noch an jeder ecke genutzt, aber für alles was über ein wenig async daten nachladen hinausgeht würde ich es nicht empfehlen.
die beliebtesten frameworks sind heute wohl React, Angular und Vue. ich bin ein wenig biased weil ich zZ. mit React mein geld verdiene und halte es für ein extrem elegantes tool um moderne SPAs zu entwickeln, muss allerdings vor einer gewissen einstiegshürde warnen, gerade wenn man dann noch ES6 features nutzen möchte und sich mit Webpack, Babel und konsorten rumschlagen muss.
Vue scheint ganz ähnlich zu Angular 1 zu sein, mit dem ich früher auch gearbeitet habe, sicherlich keine schlechte wahl, auch wenn ich die 2-way-bindings nicht so elegant finde. von Angular 2 würde ich zZ. abraten, das schreibt man nämlich am besten in TypeScript und die API ist sehr volatil.

 

[skY]

Was ducki sagt ist sinnvoll. Ich finde direkt mit Angular/React/bla anfangen etwas uebertrieben, falls du vorher noch gar kein Webzeug gemacht hast. Da tut es erst mal ganz braves Vanilla JS und Formulare und sowas. Aber naja, im Endeffekt Ansichtssache. Wenn mans ernst meint muss man ein paar der Frameworks eh lernen und dann kann man auch direkt damit anfangen und hat eine hoehere Einstiegshuerde bis Verstaendnis einsetzt.
Wo wir schon bei Frameworks sind werfe ich mal https://www.polymer-project.org/ in den Raum.

Wenn du es einfacher haben willst gibt es coole kostenlose IDEs/Editors.
https://code.visualstudio.com/
https://atom.io/

Wobei auch hier viele wieder anderer Meinung sind und sagen, als Newb sollte man erst mal alles von Hand tippen und maximal so was wie Notepad++ benutzen

 

[NuklearNudel]

danke schon mal für die Tipps. Das Video ist vor allem nützlich. Habe das Gefühl als ob Webentwicklung in den letzten zwei Jahrzehnten extrem komplex geworden ist.

Also meine Intention ist es einfach einen guten Überblick zu haben und wenn notwendig auch selbst etwas implementieren zu können. Deshalb will ich bei HTML und CSS nur das notwendigste lernen und keine ultra hübschen Sachen machen. Bin gerade in einer Position wo man dann doch zu wenig Zeit hat, um nochmal komplett umzusatteln auf Webentwicklung.

3./4. Node.js/Express fürs backend
wenn du was in einer datenbank abspeichern möchtest, kommst du um einen server nicht herum.
für das standard CRUD (Create, Read, Update, Delete) zeugs via einer REST API, die von deinem client konsumiert wird, ist Express bestens geeignet. und du schreibst dann front- und backend in der gleichen sprache, das ist ein großes plus.

Wie REST praktisch umgesetzt wird, interessiert mich tatsächlich brennend. Falls jemand ein gutes Tutorial hat, her damit.

3./4. ein JS-Framework deiner wahl fürs frontend
wenn du von einer web'app' redest meinst du damit wohl eine moderne SPA, und da ist ein framework sinnvoll.
jQuery wird zwar heute noch an jeder ecke genutzt, aber für alles was über ein wenig async daten nachladen hinausgeht würde ich es nicht empfehlen.

Was geht denn so beispielsweise über async Datennachladen hinaus? also hatte für den Anfang vor mit jQuery zu arbeiten.
Was spricht gegen ein Eclipse-Plugin für JS? Mit Eclipse habe ich schon Erfahrung.

 

[BiBaButzemann]

react ist auch auch allgemein recht furchtbar. so standardmässig kann man damit noch nichtmal nen simples formular mit checkboxen (oder waren es radios? oder beides?) bauen, sondern brauch für jeden Mist nen eigenen Modul. Die man dann in nem komischen pseudo-html js Mischmatch einbaut.

Konnte letztens an irgendn son react-redux admin panel ran, musste eigentlich nur ne liste / tabelle + tyisches new / edit formular zu bauen und bekam das kotzen bei. 99% des codes war irgendnen mega overhead - irgendwelche promises, actions und was weiss ich noch dazu schreiben (teilweise mit so obskuren ecmascript6 add-ons wie dieses "{foo...}" Zeug) und dann scheitere das superframework daran, dass es wie gesagt nicht checkboxes rendern konnte und ich konnte erstmal nen nem modul suchen, was so ca die die verhaltensweise von dem wiederspiegelte.

Angular ist aber auch nicht viel besser, das interne datenhandling ist mal so richtig müll (zumindest bei 1, wie es bei 2 ausschaut, weiss ich nicht). Angular ist imho aber eher so für relativ übersichtliche singlepages gerdacht.

Allgemein drehen die Frontendler auch gerade ziemlich am Rad, schaffen Lösungen für Probleme, die es so eigentlich nicht gibt - bzw. die ich, der ja nun auch schon so das ein oder andere komplexe frontend mal gebaut hat, nie hatte.
Dazu kommt so fast jeden Tag irgendn neues halb gares NodeJs Modul aufn Markt + 5 neue quasi identische Templateengines - und naja, ich kanns ja verstehen: Frontends bauen ist zu 90% echt öder Scheiss, aber dass man sich damit die Langeweile vertreibt und auch simpelste Aufgaben (a la JSON wird geladen, stelle Daten in ner Liste dar) so überkompliziert - ich weiss ja nicht. Wenn man sich das Backlog an Bug-Tickets in ITs so anschaut, da muss ich mir teilweise echt an Kopf fassen, wie "behämmert" die sind.

Zum Thema hier: Jo, fang mit HTML und CSS an.
HTML musst nicht alle tags lernen - mit "div", "a", "ul & li" und von mir aus "table" kannst schon fast 99% erschlagen, was du brauchst. Die anderen 100 tags sind dann eher so SEO relevant bzw dienen zum besseren Verständnis / Strukturierung des Markups.
CSS würde ich mir nur "float" und ".clearFix" (ist sone standard Klasse, einfach nach googlen) mal genauer anschauen. Der Rest ist dann fast nur "aufhübschen / Sachen bunt machen", was man immer nebenher kurz nachschlagen kann.

Dann such dir irgendne Backendsprache aus, die auf nem Server läuft, damit du mal an ne Datenbank oder Authing dich setzen kannst. Muss jetzt nicht NodeJS / Express sein, kann auch PHP (ist so am meisten verbreitet) oder Ruby sein.
Das Ding an JavaScript ist halt, dass die Sprache sehr "eklig / anders" ist, als so "normale" Sprachen. Das OOP und Typensicherheit ist sehr schräg (wobei mit ECMAScript6 gehts so langsam - aber sowas wie Interfaces gibt es afaik immer noch nicht), das Scoping ist - nun ja - etwas ganz besonderes (wobei da wieder mit ECMAScript6 mit "let" und "const" da son bisschen versucht wurde, was zu retten) und naja... ganz ehrlich, NodeJS + Mongo ist für so kleine Sachen ganz ok und manchmal auch richtig spassig (socket.io), aber "grössere" Webapplikationen kannst damit nicht bauen - dazu kann dann einfach MongoDB zu wenig und auch Node / Express stößt schnell an seine Grenzen - es wird halt zumeist nur als reiner Frontend Server eingesetzt, die Datenverarbeitung macht dann meist ne in PHP / Java / whatever geschriebene API.
Zumindest: Ob du jetzt dabei mit nem Framework direkt oder erstmal "plain" startest (gut bei NodeJS eher schwierig), würde ich davon abhängig machen, wie weit du schon Ahnung von Webservern, Routing, Datenbanken und so hast.

Erst danach würde ich dann ans frontendseitige JavaScript ran, ein wenig mit AJAX rumspielen und so - da reicht zum Anfang jQuery und später dann schauen, dass Vanilla JS auch verstanden wird. Und wenn du damit "fresh" bist, kannst dir dann auch so moderne Frontendsachen, wie SASS / LESS, Grunt, (und wenn du auch gerne Lösungen ohne Probleme magst: React ;-)) anschauen.

 

[BiBaButzemann]

Wie REST praktisch umgesetzt wird, interessiert mich tatsächlich brennend. Falls jemand ein gutes Tutorial hat, her damit.

Da gibts keine Magie zu. Das sind einfache http Server urls, die möglichst das tun sollten, was so REST als standard definiert (Also nen GET Aufruf auf ne ID sollte möglich den Datensatz anzeigen und nicht löschen). ;-)

Was geht denn so beispielsweise über async Datennachladen hinaus? also hatte für den Anfang vor mit jQuery zu arbeiten.
Was spricht gegen ein Eclipse-Plugin für JS? Mit Eclipse habe ich schon Erfahrung.[/QUOTE]

Eclipse ist ok, es gibt aber bessere Editoren, die aber meist dann auch kosten. Die ganze "storm" Familie (webstorm, phpstorm) ist z.B. ziemlich gut.

 

[ducki]

react ist auch auch allgemein recht furchtbar.

[citation needed]

so standardmässig kann man damit noch nichtmal nen simples formular mit checkboxen (oder waren es radios? oder beides?) bauen, sondern brauch für jeden Mist nen eigenen Modul.

äh, nein? 2 minuten, nur react: https://codepen.io/anon/pen/MpQbEe?editors=0010#0
input-elemente sind wegen internem state nicht sehr schön, aber ob das jetzt eine checkbox, ein radio oder sonst was ist spielt keine rolle. in anderen frameworks wird einem das händchen gehalten und man kriegt direkt 2-way-bindings die kehle runtergestopft, ist jetzt nicht unbedingt der bessere ansatz.

würde die seite ES6 korrekt umsetzen könnte man sich die

this.changeStyle.bind(this)

geschichte sparen und benutzt dann eine arrow-funktion

changeStyle = () =>

Die man dann in nem komischen pseudo-html js Mischmatch einbaut.

JSX muss man nicht nutzen. aber wenn man die anfängliche abneigung gegenüber neuem abstellt merkt man schnell, dass es sinnig ist und andere template-engines überflüssig macht.

Konnte letztens an irgendn son react-redux admin panel ran, musste eigentlich nur ne liste / tabelle + tyisches new / edit formular zu bauen und bekam das kotzen bei. 99% des codes war irgendnen mega overhead - irgendwelche promises, actions und was weiss ich noch dazu schreiben (teilweise mit so obskuren ecmascript6 add-ons wie dieses "{foo...}" Zeug) und dann scheitere das superframework daran, dass es wie gesagt nicht checkboxes rendern konnte und ich konnte erstmal nen nem modul suchen, was so ca die die verhaltensweise von dem wiederspiegelte.

ohne die codebase zu sehen kann man schlecht beurteilen ob das nur stinkender code war, aber das schreit nach fehlendem verständnis von react/redux kernkonzepten auf deiner seite.
die sache ist, react/redux ist sehr unopinionated. wenn man da eine müll-architektur mit bauen will, steht einem das framework nicht im wege.
an sich ist der one-way data flow mit redux actions super einfach zu verstehen und sehr elegant. ein app-weiter state, einkommende daten werden genau so gemerged wie man sich das mit seinen reducern vorstellt, alle änderungen passieren über selbst definierte aktionen mit streng begrenztem scope, jeglicher state ist immutable. man kann ab dem punkt, ab dem die app aufgerufen wurde, an jeden beliebigen punkt in der zeit zurückreisen und exakt den gleichen state haben. super geil zum debuggen und testen.

wenn da asynchrone geschichten hinzukommen muss man seinen gehirnschmalz natürlich ein wenig anstrengen, gibt über promises/async,await/thunks etc. aber genug tools um da eine elegante lösung zu bauen.
in meinem aktuellen projekt habe ich z.B. eine API middleware geschrieben, die actions mit einem meta feld in der gestalt {method: HTTP_GET, path: ['users', id]} auffängt, async daten nachlädt und bei success/failure actions mit der entsprechenden payload nachschickt. super elegant, nur paar zeilen code, sehr robust und erweiterbar.

bzgl. ES6 zeugs: das beste was JS passieren konnte. aber wenn man schon die spread-syntax für obskur hält, würde ich an der stelle ein wenig studium empfehlen, gibt einfach 0 gründe ES6 features nicht zu benutzen wenn man ein bisschen zeit fürs lernen und aufbauen der toolchain investieren kann.

Allgemein drehen die Frontendler auch gerade ziemlich am Rad

das stimmt schon, frontend ist sehr volatil und an jeder stelle wird das rad neu erfunden.
das heißt aber nicht, dass da keine guten sachen bei rumkommen würden.

Lösungen für Probleme, die es so eigentlich nicht gibt - bzw. die ich, der ja nun auch schon so das ein oder andere komplexe frontend mal gebaut hat, nie hatte.

was waren denn das für frontends?
man hat die gleichen probleme doch immer wieder; routing, internen state und DOM synchronisiert halten, ...
das für jedes größere projekt per hand nochmal zu basteln ist einfach nicht sinnvoll. zumal sich auch die frage stellt wie gut die eigene lösung dann tatsächlich wird, viel spaß dabei die performance des virtual DOM rendering von react zu schlagen.

Dazu kommt so fast jeden Tag irgendn neues halb gares NodeJs Modul aufn Markt + 5 neue quasi identische Templateengines

die aufgabe eines guten entwicklers ist es eben auch abzuschätzen, welche module man selbst entwickelt und welche nicht.

CSS würde ich mir nur "float" und ".clearFix" (ist sone standard Klasse, einfach nach googlen) mal genauer anschauen.

halte ich für obsolet, niemand hat bock drauf irgendeine legacy-IE-8 scheiße zu unterstützen. gerade wenn man das nur so als hobby macht würde ich einfach flexbox lernen.

Das Ding an JavaScript ist halt, dass die Sprache sehr "eklig / anders" ist, als so "normale" Sprachen. Das OOP und Typensicherheit ist sehr schräg (wobei mit ECMAScript6 gehts so langsam - aber sowas wie Interfaces gibt es afaik immer noch nicht), das Scoping ist - nun ja - etwas ganz besonderes (wobei da wieder mit ECMAScript6 mit "let" und "const" da son bisschen versucht wurde, was zu retten)

OO sicherlich sinnvoll für gewisse projekte, aber nicht der heilige grahl der softwareentwicklung, sofern man nicht auf EnterpriseQualityCoding besteht. Inheritance kann durchaus auch zu schlechtem code mit zu viele abhängigkeiten von modulen untereinander führen; in react kommt man mit komposition und HOC zum gleichen ziel, ohne irgendwelche interfaces zu definieren.
typensicherheit gibt es in react mit proptypes zur runtime, wenn man flow nutzt auch zur compiletime.
ES5 hoisting ist natürlich bullshit, aber deswegen nutzt man einfach let/const. die haben das scoping nicht nur versucht zu fixen, sondern haben es geschafft.

und naja... ganz ehrlich, NodeJS + Mongo ist für so kleine Sachen ganz ok und manchmal auch richtig spassig (socket.io), aber "grössere" Webapplikationen kannst damit nicht bauen - dazu kann dann einfach MongoDB zu wenig und auch Node / Express stößt schnell an seine Grenzen - es wird halt zumeist nur als reiner Frontend Server eingesetzt, die Datenverarbeitung macht dann meist ne in PHP / Java / whatever geschriebene API.

ruf mal besser bei Netflix an, die haben das noch gar nicht mitbekommen und lassen ihr consumer backend immer noch auf NodeJS/Express laufen. wenn die nur wüssten dass das für größere sachen gar nicht geht!
würde mich auch interessieren, inwiefern MongoDB 'zu wenig kann'. war bisher ja immer der überzeugung dass man mit SQL im prinzip nur vertikal skalieren kann und ab einer gewissen größenordnung nichts über horizontales scaling einer noSQL datenbank hinausgeht, aber vielleicht bin ich da auch nicht mehr auf dem neusten stand?

 

[BiBaButzemann]

Ich denke mal, dass NetFlix nicht komplett alles über Node laufen lässt. Da werden die Controller vermutlich auch nur Minimalaufgaben erledigen und mit ner API kommunizieren.
Dass die damit alle Cachings, Cronjobs etc. erschlagen, kann ich mir nicht vorstellen.

NoSQL Datenbanken + Big Data ist auch son Thema: Dadurch dass du für jeden Datensatz auch noch immer extra die Keys speichern musst, werden die Dinger mal ganz schnell viel zu groß. Und irgendwann brauchst du auch mal die ganzen Funktionen, die relationale Datenbanken bieten.

Und nochmal zu react: Naja, vielleicht mal tiefer ausholen: Ich finde den API-basierten Ansatz für Admin Panels an sich schon Quatsch. Es gibt da in der Regel nur 1 Frontend und Responsezeiten, Skalierung und Responsive Design und irgendwelches SinglePage Verhalten sind da mehr als nebensächlich. Und sowas dann mit React aufzuziehen ist einfach null effizient. Man braucht 3 mal so lange für, die Chance ist viel höher damit Fehler zu machen. Und checkboxes gingen zumindest bei der Installation echt nicht. Es mussten immer irgendwelche react-redux Module sein, die man verwenden konnte. Auch nervig war, dass bei neu angelegten Datensätzen die immer ans Ende der Liste einsortiert wurden (gut, das kann man evtl. auch irgendwo umbauen), Ajax im Form selber war nen Krampf (wieder das komplette Gelöt mit promises etc bauen - nur für nen simples Autocomplete) und wähh - ich meine, werdet glücklich mit. Ich bin so ausm Frontend raus, habe meinen FWA Award - muss da nix mehr reissen.

 

[ducki]

Ich denke mal, dass NetFlix nicht komplett alles über Node laufen lässt. Da werden die Controller vermutlich auch nur Minimalaufgaben erledigen und mit ner API kommunizieren.
Dass die damit alle Cachings, Cronjobs etc. erschlagen, kann ich mir nicht vorstellen.

jo alles läuft da nicht drüber bei denen. das consumer-backend halt. aber das wird auch einige zigtausend views die minute ertragen müssen.
für wirklich performancekritische sachen nimmt man kein node, sondern am besten irgendwas kompliliertes; Go hat in letzter zeit ziemlich an fahrt aufgenommen. aber das heißt nicht dass node nur für kleine projekte und spielerei tauglich wär, darum ging es mir

NoSQL Datenbanken + Big Data ist auch son Thema: Dadurch dass du für jeden Datensatz auch noch immer extra die Keys speichern musst, werden die Dinger mal ganz schnell viel zu groß. Und irgendwann brauchst du auch mal die ganzen Funktionen, die relationale Datenbanken bieten.

ich hab ja überhaupt nichts gegen relationale datenbanken. ganz im gegenteil, finde so ein schönes normalisiertes datenbankschema eleganter als einfach den ganzen inhalt in ein großes objet zu packen.
aber rel. db skalieren nicht so gut; es ist ab einem gewissen punkt einfach besser einen neuen kleinen server hinzuzufügen anstatt einen einzelnen server immer leistungsfähiger zu machen, ergo noSQL.
auf die features von rel. db muss man dann leider verzichten und sich eigene effziente algorithmen überlegen.

Und nochmal zu react: Naja, vielleicht mal tiefer ausholen: Ich finde den API-basierten Ansatz für Admin Panels an sich schon Quatsch. Es gibt da in der Regel nur 1 Frontend und Responsezeiten, Skalierung und Responsive Design und irgendwelches SinglePage Verhalten sind da mehr als nebensächlich. Und sowas dann mit React aufzuziehen ist einfach null effizient.

so völlig eigenständig von der app ein admin-panel mit react zu machen fände ich auch dämlich, da bin ich bei dir.
aber wenn man in der app sowieso schon auf react setzt kann das eigentlich eine sehr schöne geschichte werden. was mit wenig aufwand möglich wäre:

sagen wir es gibt eine <Item /> komponente, die irgendwas im frontend für den user darstellt.
wir könnten eine HOC (Higher Order Component) withEdit() implementieren, die als argument eine komponente nimmt und statt deren render()-methode auszufüren die props dieser komponente ausliest und mit form-elementen bearbeitbar macht. also withEdit(Item) stellt im admin-panel dann entsprechend felder zum bearbeiten von einer Item-Komponente dar.
dann stellen wir zusätzlich noch einen speichern button dar, der eine FORM_SAVE action triggert, welche von unserer API middleware aufgefangen wird und ein entsprechender API request wird ausgelöst. die antworten vom server triggern neue actions FORM_SAVE_SUCCESS/*_FAILURE, die von unseren reducern ausgelesen und in den app state gemerged werden.

wir schreiben also eine einmal eine abstraktion des bearbeiten und jeweils implementierung für die verschiedenen form-elemente und können dann mit withEdit() jede beliebige komponente für den admin bearbeitbar machen, ohne irgendwas an den komponenten selbst ändern zu müssen.
ich finde das ziemlich elegant und geil ehrlich gesagt ¯\_(ツ)_/¯

Man braucht 3 mal so lange für, die Chance ist viel höher damit Fehler zu machen. Und checkboxes gingen zumindest bei der Installation echt nicht. Es mussten immer irgendwelche react-redux Module sein, die man verwenden konnte. Auch nervig war, dass bei neu angelegten Datensätzen die immer ans Ende der Liste einsortiert wurden (gut, das kann man evtl. auch irgendwo umbauen), Ajax im Form selber war nen Krampf (wieder das komplette Gelöt mit promises etc bauen - nur für nen simples Autocomplete) und wähh - ich meine, werdet glücklich mit. Ich bin so ausm Frontend raus, habe meinen FWA Award - muss da nix mehr reissen.

wollte zu keinem punkt deine kompetenzen als entwickler anzweifeln.
finde so eine allaussage wie 'react ist allgemein scheiße' nur schwierig, v.a. wenn die probleme die du damit hattest augenscheinlich erstmal nichts mit react selbst zu tun hatten.
es hat auf jeden fall eine steile lernkurve am anfang. es ist eben aber auch sehr mächtig und man kann elegante anwendungen damit entwickeln, bin froh dass jQuery & Angular nicht das ende waren

 

[parats']

Witzig wie hier nun der Glaubenskrieg im Frontend-Bereich ausbricht. Ein Glück gibt es sowas bei mir nicht.

 

[NuklearNudel]

jo keine Ahnung was Frontend und Backend ist, aber hey das wollte ich auch gar nicht wissen
ok, eigentlich dachte ich HTML und CSS wird mittlerweile einfach übers klicken in einem Framework automatisch erstellt und ich müsst keinen einzigen Tag lernen.
Also ihr empfehlt das schon? kk

€: gerade ein stylesheet für meine xml-datei gemacht. boa, ist das befriedigend
Wieso hab ich nicht viel früher damit angefangen?

 

[skY]

Mal noch zum Thema Frontend und Frameworks: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.1y84jw45p

 

[BiBaButzemann]

Der Artikel trifft es auf dem Kopf .

Gestern Arbeitstag (Projektwechsel innerhalb der Firma, wo ich gerade freelance, bin da auch erst seit ner Woche drin):
Ich: "Ok API und SDK laufen, nun also Frontend ... npm install erstmal denke ich mal?"
Kollege 1 (auch so eher backendseitig unterwegs): "Jo"
Ich: *mache npm install*: "wirft Fehler, u.a. react-bootstrap-date-picker findet er nicht"
Kollege 1: "Hmm, welche npm Version hast denn?"
Ich: "5.irgendwas gerade"
Kollege 1: "Glaube für das Ding brauchst du 6"
Ich: *nvm install 6 - npm install*
- Ausgabe: "SASS muss neu installiert werden"
Ich: *npm rebuild node-sass* - "Immer noch Fehler"
Kollege 1: "Hm strange, dabei ist das Ding doch so schon live"
Ich: *schaue in package.json*: "Ja ne, da steht auch nix vom date-picker" *google das Ding für die Versionsinfo, trags ein* - *npm install* - *Immer noch Fehler*
Kollege 1: "Hmm, lösch nochmal die ganzen node modules"
Ich: *rm -rf node_modules* - *npm install*
Ich: "Ok läuft - und nun?"
Kollege 1: "Ja normal gulp, wie im anderen Projekt"
Ich: *gulp* - Ausgabe: "Gulp nicht installiert... blabla" - "Ne, ist nicht. Sagt gulp nicht installiert"
Kollege 1: (leicht arrogant)"Ja, musst es natürlich auch installieren..."
Ich: "Hab ich, aber soweit ich das sehe, gibts hier auch keine gulpfile"
Kollege 1: "Echt???" - *schaut selber nach* - "Hm, dann weiss ich auch nicht. Musst auf Kollege 2 warten"
Kollege 2: (als er ausm meeting kommt, hat mehr Ahnung von dem Ganzen): "Ja hm... warte" *schaut selber rein* - "Ach so das läuft mit webpack - da musst machen - öh Moment" - *5 Minuten suchen* - "npm run start-webpackserver-dev"
Ich: "npm run start-webpackserver-dev" - Ausgabe: *irgendwelche Fehler oder das Ding lief immer noch nicht - weiss nicht mehr*
Kollege 2: "Hmmm... " - weitere 2 Minuten - "npm run build-production evtl.?"
Ich: "npm run build-production" - Ausgabe: "Fehler: let und const dürfen nur innerhalb von use-strict verwendet werden"
Kollege 2: "Uhm ... ja ich erinnere mich an das ... öh Moment, muss mal Kollege 3 fragen"
Kollege 3: (nachdem er Zeit hatte): "Ja, das ist son Fehler, der irgendwie nur auf Mac kommt, keine Ahnung wie zu beheben"
Ich: "Ja cool..." *schreibe mal spassenshalber "use-strict" in die Datei rein* - *npm run build-production* - Wohoo läuft!!! *magic*
Ich: "Ok, und nen watcher?"
Kollege 2: "Ja ne, hat das Ding nicht, musst jedes mal npm run build-production laufen lassen fürn neuen built"
Ich: *am abfeiern* - ein built braucht so 20 Sekunden


TL;DR: Ich brauchte mehr als nen halben Tag, um nen Frontend laufen zu lassen. Kann zum Testen einer Änderung immer 20 Sekunden auf nen built warten. Die haben doch alle Aluhüte auf...

Ist jetzt zugegebenermaßen auch nicht die beste IT, wo ich bisher gearbeitet habe (bei anderen gabs nen watcher und auch diesen Browserrefresh ;-)). Die haben da auch noch ganz andere Probleme, aber das Beispiel oben ist schon recht symbolisch...


Ansonsten:

jo keine Ahnung was Frontend und Backend ist, aber hey das wollte ich auch gar nicht wissen

Backend: Zeug was auf dem (Web)Server passiert (Datenbank, routing, auth, ...)
Frontend: Eigentlich Zeug was im Browser passiert: Früher einfach nur Daten schick darstellen und allgemein das GUI per HTML/CSS/JS basteln, heutzutage haben die Frontends oft ein eigenes Backend in nodeJS, welches meist nur das routing und evtl. auth übernimmt und mit dem anderen Backend, dass dann als API dient, kommuniziert (wobei auch das browserseitige Frontend die API direkt ansprechen kann). Da dies auch in JS geschrieben und zum Teil eng mit dem Frontend verknüpft ist, wird dies dann auch von den Frontendlern übernommen.
Jetzt weisst du's!

ok, eigentlich dachte ich HTML und CSS wird mittlerweile einfach übers klicken in einem Framework automatisch erstellt und ich müsst keinen einzigen Tag lernen.
Also ihr empfehlt das schon? kk

Naja das "framework" nennt sich dann dreamweaver (gibts den eigentlich noch?). Damit klickst du dir den Kram zusammen, ohne nen Plan zu haben, was du da eigentlich tust. Aber wie gesagt: Du musst da dir jetzt nicht alle tags und CSS Dinger reinpulen. Form-Elemente evtl. noch, ansonsten reicht das, was ich oben schrieb fürn Anfang. Das sind dann so die Basics. Danach kannst dich dann an nodeJS, Express und Jade versuchen. (das war glaube ich noch recht easy zum Laufen zu bringen)

€: gerade ein stylesheet für meine xml-datei gemacht. boa, ist das befriedigend
Wieso hab ich nicht viel früher damit angefangen?

Weil xml eigentlich nen reines Datenformat ist, was man nicht styled, sondern nur für Datenübertragungen nutzt, ausliest / parsed und dann in HTML darstellt.

 

[ducki]

naja.
wieder klassischer fall von 'fehler sitzt vor dem bildschirm' ¯\_(ツ)_/¯

webpack muss man halt auch richtig bedienen können, dann hat man so späße wie hot module reloading (app state bleibt erhalten, module mit änderungen werden über sockets nachgeladen).
bessere dev-erfahrung gibt es im frontend-bereich nicht.

 

[Horst Schlemmer]

Im Prinzip kann man dem was Ducki sagt zustimmen. Wenn du an JS gefallen finden solltest, kannst du dir auch mal TypeScript angucken. Das macht die JS Entwicklung imho wesentlich angenehmer. Anfangen sollte man aber wohl trotzdem nicht direkt damit.