JavaScript mit Java kombinieren: So eher "eigentliche" Software-Entwicklung?

[Bienlein]

Hallo,

bin schon ein alter Hase mit 10 Jahren Smalltalk- und fast 20 Jahren Java-Entwicklung. Bin seit Jahren in der Backend-Entwicklung, habe mich von JavaScript und Web-Frameworks immer fern gehalten, weil ich mich auf Backend konzentrieren wollte. Jetzt ist es so, dass Backend mir langsam keinen Spaß mehr macht. Das ist nicht mehr Backend wie früher mit Threads, Concurrency, Multi-Threading, CPU-Last optimieren, Race Conditions, Deadlocks, etc. Heute ist es irgendwelche Streams mit einem Consumer verbinden. Der Consumer ist in Java und wird eigentlich nur mit ein paar Spring Boot Annotations versetzt und dann ist das meiste fast gemacht. Sonst gibt es viel Konfigurations-Arbeit für docker, Kubernetes, Maven/Grail, OSGi, etc.

Ich habe nicht mehr wirklich das Gefühl, dass ich Software-Entwicklung mache, weil es viel zu viel Konfigurationsarbeit gibt. Deswegen der Gedanke jetzt umzuschwenken auf Full-Stack-Entwickler. Vielleicht ist JavaScript und React.js/Angular/Node/etc. kombiniert mit Java Backend doch eher eingentliche Entwicklungsarbeit "wie früher". Was ich gehört habe ist Frontend mit JavaScript nicht immer so die Herausforderung. Das ist mir aber egal. Ich will einfach wieder entwickeln und nicht konfigurieren. Vielleicht kann man ja seinen Chef rumkriegen auf TypeScript umzuschwenken. Das wäre dann doch schon ganz nett.

Deswegen meine Frage ob Frontend-Entwicklung mit JavaScript/TypeScript und Backend mit Java schon eher sowas ist wie "eigentliche" Entwicklung? Dann würde ich gerne den Schwenk wegmachen von reiner Backend-Entwicklung.

Grüße, Bienlein

 

[kneitzel]

10 Jahren Smalltalk-

Geil. Wobei ich da unterstelle, dass Du nicht 10 Jahre studiert hast und halt 10 Jahre lang (lange zeit Vergeblich) den Schein in Objekt Orientierter Entwicklung zu bekommen

Smalltalk finde ich vom Aufbau her einfach gut und konsistent. Und gerade mit einer Implementierung wie squeak (aus meiner Sicht) einfach ideal, um OO Entwicklung Neulingen bei zu bringen. Ein Ansatz, um von Anfang an Objektorientiert zu arbeiten.

Aber das war ja gar nicht das Thema - aber irgendwie hat mich das sofort getriggert

Das Thema eigentliche Entwicklung. Also wirklich Code schreiben hast Du tatsächlich immer weniger. Das ist aber wirklich überall das Gleiche. Du hast in allen Bereichen, dass es immer bessere Grundlagen gibt und du daher immer weniger selbst entwickeln musst. Frontend wird da dann immer mehr Richtung UI/UX Design. Mach mal ein schönes HTML / CSS. Wie das dann angezeigt wird: Da hast Du kaum noch etwas zu entwickeln. Du hast da - so wie Du es beim Backend erlebt hast - einfache Reactive Designs, die sich mehr und mehr durchsetzen. Wäre doch auch Unsinn, da immer wieder das Rad neu zu erfinden. Vieles macht das Framework einfach und du füllst nur noch die Lücken. Und das ist dann halt ein reagieren auf Events und so. Also dann hast Du im Frontend halt auch nur so ein Zeug:

createOrder() {
    let headers = new HttpHeaders({'Content-Type': 'application/json'});
    let options = {headers: headers}
    this.http.post('http://localhost:8080/api/orders', this.form.value, options)
      .subscribe(
        (response) => {
          this.response = response
        },
        (error) => {
          this.error = error
        }
      )
}

Geklaut von Baeldung - dort Teil eines einfachen Angular Frontends - der Blog Beitrag zeigt ein Reactive System - also Backend und Frontend und wie das zusammen hängt. Kannst Du Dir ja einmal anschauen um zu sehen, ob und wie Du für das Frontend "richtige Software Entwicklung" machen musst.

Somit sehe ich nicht den Unterschied, wenn Du von "eigentliche Entwicklung" schreibst. Das ist die generelle Entwicklung denke ich.

 

[mihe7]

Somit sehe ich nicht den Unterschied, wenn Du von "eigentliche Entwicklung" schreibst. Das ist die generelle Entwicklung denke ich.

Das sehe ich genauso. Die Frage ist m. E. weniger, ob Frontend oder Backend, sondern mit welchem Problem muss ich mich beschäftigen. Bei uns sind 95 % CRUD. Das ist halt einfach nicht besonders spannend. Allerdings gibt es daneben immer wieder mal Herausforderungen, wo man das Hirn einschalten muss. Das ist dann umso schöner

 

[M.L.]

TypeScript

Längerfristig ist aber auch hier damit zu rechnen, dass man "nur" Konfiguration betreibt (idS Sinn das man TS-Code eingibt und im Hintergrund (mehr oder weniger sinnvoller) JS-Code generiert wird. Mit dem Nebeneffekt, dass das Hintergrundwissen bzgl. (z.B.) JS verloren gehen kann). Zumindest kann man TypeScript als Framework für JavaScript-Entwicklung deuten, siehe auch "youtube.com @ thenativeweb". Weiteres Stichwort auch "Low Code Entwicklung".

 

[mrBrown]

Längerfristig ist aber auch hier damit zu rechnen, dass man "nur" Konfiguration betreibt (idS Sinn das man TS-Code eingibt und im Hintergrund (mehr oder weniger sinnvoller) JS-Code generiert wird. Mit dem Nebeneffekt, dass das Hintergrundwissen bzgl. (z.B.) JS verloren gehen kann). Zumindest kann man TypeScript als Framework für JavaScript-Entwicklung deuten, siehe auch "youtube.com @ thenativeweb". Weiteres Stichwort auch "Low Code Entwicklung".

Aus dem Winkel ist Java auch nur "Konfiguration" und ein Framework für Bytecode 🤔

 

[LimDul]

Das Problem ist, Software-Entwicklung entwickelt sich selbst auch weiter. Manche Dinge kann man zwar auch Hinterfragen - inwieweit es sinnvoll ist eine Anwendung aus 30 Frameworks und 70 Annotationen sich zusammen zu "konfigurieren" ohne Sinn und Verstand

Auf der anderen Seite - Das Ziel einer Software-Entwicklung ist nicht tolle technologische Probleme zu lösen, sondern eine Software zu entwickeln die einen Business-Value bringt. Und sich Threads, Deadlocks & Co zu beschäftigen generiert keinen Business-Value sondern ist reine Technologie. Und ist im Endeffekt an vielen Stellen auch immer wieder das gleiche. Welchen (aus Business-Sicht!) Sinn hat es sich in einem Projekt damit zu beschäftigen, wie z.B. Service Anfragen auf verschiedene Threads verteilt werden. Das ist ein Pattern, was immer wieder gleich ist und da muss man das Rad nicht neu erfinden. Wenn einem das ein Framework abnimmt spart man damit Zeit & Geld. Problematisch ist da zwar oft, dass man, wenn es mal nicht so funktioniert wie man will, man Probleme hat da einzugreifen und das das Wissen was da passiert auch nicht mehr vorhanden ist, sondern alles Black-Boxen sind.

Aber die Reise geht - vor allen bei größeren Business-Anwendungen - dahin, dass man im besten Fall nur noch den reinen Business-Code schreibt und der ganze Rest von den Frameworks abstrahiert wird. Und an der Stelle ist es egal ob Backend oder Frontend. Je nach Bereich & Firma in dem man unterwegs ist, ist das mehr oder weniger stark ausgeprägt, aber der Weg geht meines Erachtens dahin.

 

[temi]

Vielleicht muss man dann an dieser Stelle in die Entwicklung der jeweiligen Frameworks einsteigen. Da kann man dann noch Probleme lösen.

 

[Bienlein]

Wow, so viele Antworten in kurzer Zeit . Gut zu wissen, dass es wo anders etwa gleich aussieht. Das war die Info, die ich brauchte. Danke.

Smalltalk finde ich vom Aufbau her einfach gut und konsistent. Und gerade mit einer Implementierung wie squeak (aus meiner Sicht) einfach ideal, um OO Entwicklung Neulingen bei zu bringen. Ein Ansatz, um von Anfang an Objektorientiert zu arbeiten.

Zum OO lernen ist Smalltalk tatsächlich sehr gut zu verwenden. Leider ist Smalltalk mittlerweile mausetot und junge Leute fragen sich, warum sie das noch lernen sollen. Neuerdings kommen die Go-Entwickler dazu, die jetzt der Meinung sind, dass OO ein falscher Weg gewesen wäre. Man würde ja an Go sehen, dass man Vererbung nicht braucht. Statt eine geerbte Methode zu überschreiben kann man viel einfacher Pointer swappen ... Rust ist was anders. Für reine System-Programmierung braucht man vielleicht wirklich keine Vererbung. Okay, ich schweife etwas ab ;-)

Vielleicht muss man dann an dieser Stelle in die Entwicklung der jeweiligen Frameworks einsteigen. Da kann man dann noch Probleme lösen.

Ja, das ist ein guter Punkt. Dann hat man in seiner Freizeit seinen Spaß. Bei den Firmen, bei denen sowas bei einer Bewerbung ein Pluspunkt ist, ist man dann auch eher bei den passenden Leuten. Wenn man mal so eine Firma gefunden hat ... ;-)

 

[M.L.]

Aus dem Winkel ist Java auch nur "Konfiguration" und ein Framework für Bytecode

Jedes elektronische Gerät wird auf menschlicher Seite durch Drücken auf Knöpfe oder Drehen an Schaltern bedient (in bel. Kombination). Mit dem Ziel ebendiesem eine oder mehrere optische/akustische/... wahrnehmbare Reaktionen zu entlocken und davon z.B. einen Business-Value zu generieren. Die physikalischen Hintergründe oder volle Ausnutzung der Möglichkeiten sind da eher zweitrangig.

 

[mrBrown]

Jedes elektronische Gerät wird auf menschlicher Seite durch Drücken auf Knöpfe oder Drehen an Schaltern bedient (in bel. Kombination). Mit dem Ziel ebendiesem eine oder mehrere optische/akustische/... wahrnehmbare Reaktionen zu entlocken und davon z.B. einen Business-Value zu generieren. Die physikalischen Hintergründe oder volle Ausnutzung der Möglichkeiten sind da eher zweitrangig.

Bist du professioneller Buzzword-Bingo-Spieler?

 

[Oneixee5]

Ich finde Frontend langweilig und öde. Die meiste Arbeit steckt in Benutzerführung, Validierung von Eingaben, irgendwelches langweiliges und komplexes CSS umbauen und viel Zeug, welches sich immer irgendwie wiederholt. Dann kommen noch die ganzen TypeScript-Heinis und wollen aus der eigentlich genialen Sprache JavaScript irgendwas langweilig voll typisiertes machen.

 

[Bienlein]

Ich finde Frontend langweilig und öde. Die meiste Arbeit steckt in Benutzerführung, Validierung von Eingaben, irgendwelches langweiliges und komplexes CSS umbauen und viel Zeug, welches sich immer irgendwie wiederholt. Dann kommen noch die ganzen TypeScript-Heinis und wollen aus der eigentlich genialen Sprache JavaScript irgendwas langweilig voll typisiertes machen.

Okay, interessant. Fürchte ich muss mich trotzdem mit Frontend-Entwicklung befassen. Wenn ich in 7 Jahren 60 bin, brauche ich mich wohl nicht mehr irgendwo bewerben. Und wenn dann keine Ahnung von JavaScript/Frontend sieht es noch schlechter aus ...