Java Script für das Vorhaben das richtige?

[frankygotgame]

Hallo zusammen,

ich möchte ein Ernährungsplan Tool bauen:

- Datenbank mit Lebensmitteln und deren Nährwerte
- Aus den Lebensmitteln Gerichte bauen, bei denen berechnet wird wie die Nährwerte für das gesamte Gericht aussehen
- Aus den Gerichten, Pläne bauen
- Die Gerichte und Pläne in anpassbare Designs in Form einer PDF Datei exportieren
- Ich möchte das Tool irgendwann so haben, dass Kunden es benutzen können, aber auch Ernährungsberater
- Jedes Gericht soll auch ein Bild haben und sobald man das Gericht in einen Plan einträgt, soll das passende Bild ebenfalls eingefügt werden

Hintergrund ist, dass ich selbst in dem Bereich tätig bin und es aktuell mit Excel bzw. jetzt Google Sheets mache.
Dies dauert aber immer sehr lange und ist mühselig und zeitaufwendig.

Ich möchte mir daher selbst eine passende Programmiersprache beibringen um mir dieses Tool zu bauen. Ich habe keinen zeitlichen Druck und möchte ein weiteres Hobby mit einem Mehrwert für meinen Beruf verbinden. Ich habe früher mit HTML und PHP Webseiten gebaut und mir ist programmieren nicht ganz fremd.

Das ganze würde ich gerne als Webanwendung bauen und ggf. irgendwann mal als App. Daher die Frage: Ist Java Script hier die richtige Wahl oder gibt es eine bessere Lösung für mein Vorhaben?

Vielen Dank im Voraus und beste Grüße
Franky

 

[LimDul]

JavaScript und Java haben erst mal nix miteinander zu tun, daher ist die Frage in dem Forum eigentlich falsch.

Meine persönliche Meinung ist: JavaScript ist nie die richtige Wahl 😉

Etwas ernsthafter
JavaScript ist eine Sprache, die hauptsächlich fürs Frontend, im Browser gedacht ist und weniger als Sprache die auf dem Server im Backend läuft (auch wenn es da mittlerweile auch Implementierungen gibt).

Grundsätzlich würde ich aber im Backend - also die Stelle, die dann wirklich mit der Datenbank kommuniziert, wo die ganze Logik sitzt, auf eine Sprache setzen, die dafür eher gedacht ist. Ich persönlich würde es in java bauen - z.B. als Spring Boot Anwendung. Je nach dem was man da als Webfront-End nimmt, kommt man allerdings mehr oder weniger mit JavaScript in Kontakt.

Alternativ kann man als Backend auch PHP nehmen, aber prinzipiell empfinde ich Java da als "Vollwertiger". (Gut, ist hier auch ein Java-Forum, daher nicht ganz unerwartet diese Aussage, denke ich).

 

[httpdigest]

Die Programmiersprache "Java Script" gibt es nicht.
Es gibt Java (womit sich das Forum hier hauptsächlich beschäftigt)
und es gibt die nur namentlich verwandte Programmiersprache JavaScript.
Sowohl Java als auch JavaScript sind für Webanwendungen als Sprache geeignet.
Java ist aber nur eine serverseitige Sprache (läuft ohne weiteres (z.B. Transpilation) nicht im Browser) und JavaScript kann sowohl im Browser als auch im Backend/Server laufen.

Wie aber @LimDul schon richtig sagt: JavaScript als _reines_ JavaScript ist z.B. aufgrund fehlender statischer Typisierung nicht für komplexere Projekte geeignet. Hier gibt es Sprachen wie TypeScript (JavaScript aber statisch typisiert). Damit kann man sehr gut auch komplexere Backendservices statisch typsicher bauen.

 

[frankygotgame]

Danke für die schnellen Antworten. Also komplex wird mein Vorhaben nicht sein denke ich, da ich es aktuell ja auch soweit mit Excel realisiert bekomme 🙂

 

[httpdigest]

Unterschätze niemals Excel. 🙂

 

[Oneixee5]

Unterschätze niemals Excel. 🙂

never: use Excel as a database or Word processor

 

[httpdigest]

never: use Excel as a database or Word processor

Waaas? Möchtest du damit sagen, es ist nicht okay, wenn mein gesamtes Business auf einem einzelnen 500MB Excel Spreadsheet basiert, mit dem wir jeden Warenverkehr/Einkauf/Verkauf und das gesamte Customer Relationship Management abbilden und welches nur ein Mitarbeiter zur Zeit bedienen kann und sich deshalb Mitarbeiter per Zettel und Stift aufschreiben, was sie am Sheet anpassen wollen, bis es von einem anderen Mitarbeiter, der das Sheet gerade bei sich geöffnet hat, wieder freigegeben wurde?
Das sollte man _nicht_ machen??? 🙂

 

[Oneixee5]

Prinzipiell kommt JavaScript im Backend für die beschriebene Aufgabe in Frage.
Mit Node.js(Javascript) erhält man automatisch alle Vorteile der Full-Stack-JavaScript-Entwicklung, wie z. B.:

• hohe Effizienz und allgemeine Entwicklerproduktivität
• gemeinsame Nutzung und Wiederverwendung von Code
• Geschwindigkeit und Leistung
• einfacher Wissensaustausch innerhalb eines Teams
• eine große Anzahl von kostenlosen Tools

Man handelt sich aber auch Nachteile ein:

• Der größte Nachteil von Node.js ist auch jetzt noch seine Unfähigkeit, CPU-gebundene Aufgaben zu verarbeiten. Das Problem wurde mit Worker-Threads zwar etwas gemildert. Es wird aber trotzdem ein CPU von einem Thread blockiert.
• Problem der Callback-Hölle
• Unreife der Werkzeuge und ein wahnsinniges Tempo an (Ver-) Änderungen

Ich würde auch eher zu Java im Backend tendieren, da ich dort die besten Entwicklungsmöglichkeiten für so ein Projekt sehe. Natürlich kenne ich mich mit Java ein wenig aus, deshalb könnte ich da etwas voreingenommen sein.
Im Frontend würde sich hier React und entsprechend React Native für die App anbieten. Man hätte quasi die gleiche Codebasis fürs Web und die App. Mit Apps habe ich aber ganz wenig Erfahrung, evtl. fragst du mal erfahrene App-Entwickler.

React

React is the library for web and native user interfaces. Build user interfaces out of individual pieces called components written in JavaScript. React is designed to let you seamlessly combine components written by independent people, teams, and organizations.

reactjs.org

React Native · Learn once, write anywhere

A framework for building native apps for Android, iOS, and more using React

reactnative.dev

Die viel zitierte Typsicherheit (statische Typisierung) halte ich bestenfalls für ein untergeordnetes Problem. JavaScript ist eben wie es ist. Man muss es einfach nur richtig umsetzen. Viele andere Sprachen sind ebenfalls nicht typsicher und darüber gibt es komischerweise kaum Beschwerden. Aus der Sicht von JavaScript ist Java relativ unbequem, geschwätzig, statisch, Boilerplate, eben konservativ.

 

[thecain]

Problem der Callback-Hölle

Unterstützt node immer noch kein async/await

 

[httpdigest]

Doch doch. Und für die meisten Libraries gibt es auch promisifizierte APIs.
Also callback hell ist heutzutage nicht mehr das Problem.