Kurz gefasst
Die Wahl zwischen Ruby und Python für die Webentwicklung ist im Grunde eine Entscheidung zwischen zwei Frameworks: Ruby on Rails und Django. Beide sind ausgereift, beide sind sicher, und für eine einfache Webanwendung spielt die Entscheidung kaum eine Rolle.
- Sie bauen eine Webanwendung, die auch eine Webanwendung bleiben soll? Ruby on Rails ist eine solide Wahl. Es wird aktiv gepflegt (Rails 8.1, 2026), ermöglicht eine schnelle Entwicklung, und durch die schiere Menge an Wartungsarbeiten ist das entsprechende Fachwissen jederzeit verfügbar.
- Planen Sie, innerhalb der nächsten drei Jahre Machine Learning, Datenverarbeitung oder Analysen zu integrieren? Python und Django sind langfristig kostengünstiger, da die benötigten Bibliotheken (PyTorch, Hugging Face und andere) bereits in der Sprache vorhanden sind, in der Ihr Team ohnehin arbeitet.
- Die Entscheidung ist wie ein Mietvertrag auf drei Jahre, nicht wie der Kauf eines Werkzeugs. Es kommt nicht auf die Ausstattung am Einzugstag an. Entscheidend sind die Miete, die Verfügbarkeit von Fachkräften für die Instandhaltung und die Kosten für spätere Umbauten im dritten Jahr.
Die Wahl eines Technologie-Stacks ist weniger wie der Kauf eines Werkzeugs, sondern eher wie der Abschluss eines Mietvertrags. Sie binden sich für Jahre an ein Gebäude, und was zählt, ist nicht die Ausstattung am Tag des Einzugs. Entscheidend sind die Miete, die Verfügbarkeit von Personal für die Wartung und die Kosten für spätere bauliche Veränderungen im dritten Jahr.
Dieser Beitrag vergleicht daher beide Optionen anhand der Faktoren, die ein Projekt tatsächlich bestimmen: wie einfach Sie Personal finden und was dieses kostet, wie schnell ein Team die erste Version bereitstellt, welche Wartungslasten Sie übernehmen und wie stark Sie die Wahl einschränkt, wenn das Produkt neue Funktionen benötigt.
Er richtet sich an alle, die das Budget und die Roadmap verantworten. Wenn Erfahrungen von Entwicklern als Beleg angeführt werden, dann nur, weil sie Aufschluss über Einarbeitungszeiten oder Übergaberisiken geben – nicht, weil die Arbeit damit besonders viel Spaß macht.
Bei der Webentwicklung dreht sich der Vergleich fast ausschließlich um das jeweils dominierende Framework der Sprache. Daher konzentriert sich die Tabelle auf diese Ebene: Ruby mit Ruby on Rails und Python mit Django.
| Ruby | Python | |
|---|---|---|
| Web-Framework | Ruby on Rails | Django |
| Erscheinungsjahr der Sprache | 1995 | 1991 |
| Erscheinungsjahr des Frameworks | 2003 | 2005 |
| Betreut von | 37signals sowie der Rails Foundation | Django Software Foundation |
| Aktuelle Version (2026) | Rails 8.1 | Django 5.x |
| Architektur | Model-View-Controller (MVC) | Model-View-Template (MVT) |
| Anwendungsbereich | Webanwendungen | Webanwendungen, zusätzlich mit Brücke zu Data Science und KI |
| Entwicklermarkt | Seltener, teurer, stabil (Nachfrage vor allem durch Wartung) | Größerer Pool; Kandidaten, die auch Datenanalyse und ML beherrschen |
| Langlebigkeit | Gefördert, günstig im Betrieb, ausgeprägte Testkultur | Gefördert, günstig im Betrieb |
| Integration | Außerhalb des Webbereichs begrenzt | Das gesamte Python-Ökosystem ist nur einen Import entfernt |
| Bester Anwendungsfall | Die Roadmap bleibt rein auf die Webentwicklung beschränkt | Data Science, ML oder Analytics sind geplant |
Dies ist der Rahmen, den wir bei Imaginary Cloud verwenden, wenn ein Kunde uns bittet, zwischen zwei Stacks zu wählen. Vier Faktoren, in der Reihenfolge, in der sie normalerweise die Entscheidung bestimmen:
Gehen wir sie der Reihe nach durch. Das Fazit am Ende bewertet jeden Stack anhand aller vier Faktoren.
Ruby wurde von Yukihiro „Matz“ Matsumoto entwickelt und 1995 veröffentlicht. Die Sprache basiert auf Einflüssen von Perl, Eiffel, Ada und Lisp. Sie verbindet funktionale und imperative Programmierung mit dem erklärten Ziel, Code zu schreiben, der sich natürlich liest.
Zwei Funktionen tragen maßgeblich dazu bei: Blöcke gruppieren Anweisungen und führen diese bei Aufruf aus; Lambdas sind kleine anonyme Funktionen, die wie jeder andere Wert übergeben werden können. Heute wird Ruby fast ausschließlich im Rahmen von Ruby on Rails für die Webentwicklung eingesetzt – ein Framework, das die Nachfrage nach Ruby-Entwicklern stabil hält.
Python wurde von Guido van Rossum entwickelt und 1991 als Nachfolger der Sprache ABC veröffentlicht. Die Philosophie der Sprache ist Lesbarkeit, die durch verbindliche Einrückungen erzwungen wird.
Diese Vorgabe ist streng und gelegentlich auch irritierend. Sie sorgt jedoch dafür, dass selbst Neulinge den Code auf Anhieb verstehen. Der zweite entscheidende Faktor ist das breite Einsatzspektrum von Python: Data Science, maschinelles Lernen, wissenschaftliches Rechnen und akademische Forschung basieren heute fast vollständig darauf.
Die KI-Bibliotheken haben Python von einer populären Sprache zum Standard in der Unternehmenswelt gemacht. Im Jahr 2026 wird dieses Ökosystem angeführt von PyTorch, das heute die Grundlage für den Großteil der veröffentlichten Deep-Learning-Forschung sowie einen erheblichen Teil der Stellenanzeigen im Bereich ML bildet; TensorFlow, das in der Unternehmenspraxis weiterhin stark vertreten ist; und Hugging Face, dessen Modell-Hub und Transformers-Bibliothek zum praktischen Zentrum für angewandte KI geworden sind. (Die ältere Theano -Bibliothek, die diesen Bereich einst prägte, wurde bereits 2017 eingestellt – eine nützliche Erinnerung daran, dass man sich bei der Wahl eines Frameworks immer auch für dessen gesamtes Ökosystem entscheidet.)
Ruby und Python sind beides ernstzunehmende Optionen für die Webentwicklung. Ruby on Rails nutzt eine Model-View-Controller (MVC) -Architektur, eine Konvention zur Trennung der Logik in drei Bereiche. Das Model speichert und verarbeitet die Daten. Die View zeigt dem Benutzer die Oberfläche. Der Controller verarbeitet die Anfragen aus der View und nutzt die Daten des Models, um eine Antwort zu senden.
Django verwendet eine Variante: Model-View-Template (MVT). Dies ist dem MVC-Modell sehr ähnlich, mit dem Unterschied, dass das Framework das Routing übernimmt, sodass niemand in Ihrem Team diese Ebene selbst schreiben muss. Das Template kümmert sich um die Benutzeroberfläche; die View führt die Geschäftslogik aus, kommuniziert mit dem Model und rendert das Template. In der Praxis bedeutet das weniger Konfigurationsaufwand für Entwickler, allerdings auf Kosten der Flexibilität, da man sich an die Django-Vorgaben halten muss.
Rails wird von 37signals (dem Unternehmen hinter Basecamp und HEY) betreut und wurde 2003 veröffentlicht. Es revolutionierte den von Java (J2EE) und .NET dominierten Markt durch eine deutlich schnellere Bereitstellung. Sein Wachstum verdankt es der Startup-Welt, wo es von X (ehemals Twitter), Airbnb, GitHub und Shopify übernommen wurde. Es wird nach wie vor aktiv weiterentwickelt: Rails 8 führte die „Solid Trifecta“ ein, mit der sich Cache, Queues und Cables direkt über die Datenbank betreiben lassen, wodurch die starre Abhängigkeit von Redis entfällt. Es gibt mittlerweile eine Rails Foundation, die von Shopify, GitHub und anderen unterstützt wird und Dokumentation sowie Tools finanziert. Was sich jedoch geändert hat, ist die Häufigkeit, mit der es für neueProjekte gewählt wird: Die unten aufgeführten Trenddaten zeigen, dass das Entwicklerinteresse ab 2017 in Richtung Django gewandert ist. In unserer eigenen Arbeit mit Kunden taucht Rails heute häufiger als bestehendes System auf, das wir übernehmen, als als Ausgangspunkt für ein neues Projekt.
Das ist kein theoretisches Szenario. Als FlippedNormals, ein Marktplatz für Computergrafik mit rund 28.000 Produkten und Kunden auf fünf Kontinenten, von WordPress zu uns wechselte, behielten wir das bestehende Rails-Backend bei, migrierten die Infrastruktur auf AWS und bauten darauf auf. Eine zweimonatige Migration, die den Traffic steigerte, anstatt eine funktionierende Anwendung komplett neu zu schreiben. So sieht der Großteil der Arbeit mit Rails heute aus: bestehende Systeme, die sich bereits bewährt haben, zu erweitern und abzusichern. (Das Gleiche haben wir bei FundSpace und Invisible Homes getan.), beide Rails.)
Django ist ein Open-Source-Projekt, das von der Django Software Foundation unterstützt wird und 2005 veröffentlicht wurde. Es gewann an Bedeutung, weil es dynamisch, zugänglich und architektonisch jedem vertraut war, der bereits mit MVC gearbeitet hatte. Es wurde verwendet, um Instagram, Spotify, YouTube und Bitbucket zu entwickeln oder neu aufzubauen. Zudem fungiert es über das Django REST Framework – ein Toolkit, das Django-Modelle in HTTP-Endpunkte umwandelt – als reine API hinter einem JavaScript-Frontend.
Was den reinen Funktionsumfang für Webanwendungen betrifft, sind beide gleichauf. Sie unterscheiden sich erst in dem Moment, in dem die Anwendung Aufgaben übernehmen soll, die über das Web hinausgehen.
Für Budgetverantwortliche sind hier zwei Fragen entscheidend. Wie schnell lässt sich ein Team zusammenstellen und wie wirkt sich die Knappheit an Fachkräften auf die Kosten aus? Das Volumen der Fragen auf Stack Overflow ist ein guter Indikator für Ersteres, Stellenanzeigen für Letzteres.
Interesse an Frameworks. Rails lag bei Stack Overflow-Fragevolumen im ersten Jahrzehnt vor Django, bis Django Mitte 2017 vorbeizog und seitdem jedes Jahr seinen Vorsprung ausgebaut hat, während der Anteil von Rails kontinuierlich sinkt. Dieser Wendepunkt ist das wichtigste Datum in diesem Vergleich. Danach war es für Berufseinsteiger deutlich wahrscheinlicher, Django statt Rails zu lernen, und dieser Trend hat sich durch den Erfolg von Python noch verstärkt.
Nachfrage nach Sprachen. Auf Sprachebene ist die Kluft mittlerweile deutlich. Python beendete die Stack Overflow 2025 Developer Survey als eine der meistgenutzten Sprachen weltweit; etwa 58 % aller Entwickler gaben an, sie zu verwenden – ein Anteil, der dank des KI-Booms stetig wächst, während die Nachfrage nach Ruby auf die Webentwicklung beschränkt bleibt. Das ist kein Versagen von Rails, sondern das Wachstum von Python in Bereiche, die Ruby nie abgedeckt hat.
Der Haken bei der Einstellung von Rails-Entwicklern. Historische Daten zu Einstellungstrends (Hacker News „Who's Hiring“ und ähnliche Plattformen) zeigten lange Zeit, dass Rails vor Django bei der reinen Anzahl an Stellenanzeigen lag, was auf den ersten Blick widersprüchlich erscheint. Es handelt sich jedoch um ein Signal für Wartungsbedarf, nicht für Wachstum. Die Anzeigen konzentrieren sich auf den Betrieb bestehender Rails-Anwendungen. Genau deshalb bleibt die Nachfrage nach Rails-Entwicklern hoch, während die Zahl der neuen Rails-Projekte sinkt. Betrachten Sie eine einzelne Momentaufnahme eher als Richtungsanzeiger denn als aktuellen Marktstatus.
Bleibt eine entscheidende Frage für die Personalsuche: Wird das Team in den nächsten drei Jahren lediglich eine Webanwendung entwickeln und betreiben, oder soll es auch die Daten nutzen, die diese Anwendung sammelt? Im zweiten Fall bedeutet die Entscheidung für Python, dass Sie aus einem wesentlich größeren Pool schöpfen können und Mitarbeiter finden, die beides beherrschen. Im ersten Fall sind Rails-Kandidaten zwar schwerer zu finden, aber die Aufgaben sind klar definiert und die Projekte auf Langlebigkeit ausgelegt.
Bei der Langlebigkeit geht es nicht nur darum, ob ein Framework noch gepflegt wird. Es geht darum, was es kostet, das System über die gesamte Lebensdauer des Produkts sicher zu betreiben. Zurück zum Mietvergleich: Das ist die Miete, und die ist bei beiden Objekten erstaunlich ähnlich.
Beide liefern die Sicherheitsgrundlagen direkt mit, anstatt sie der Wahl einer Bibliothek zu überlassen: ein ORM, das Abfragen parametrisiert, Sitzungs- und Authentifizierungsverwaltung sowie Schutz gegen Cross-Site Request Forgery und Cross-Site Scripting. Ehrlich gesagt ist bei einem Sicherheitsvorfall meist nicht das Framework die Schwachstelle, sondern die Konfiguration drumherum.
Deployment und Hosting sehen bei beiden sehr ähnlich aus: ein Anwendungsserver hinter einem Proxy, eine relationale Datenbank, ein Cache und ein Hintergrund-Job-Runner auf der Plattform, für die Sie ohnehin schon zahlen. Die Hosting-Kosten hängen vom Traffic-Verlauf und der Datenbanklast ab, nicht von der Wahl zwischen Rails und Django. Die Skalierung verhält sich identisch: Keines der Frameworks stößt an eine Grenze, bevor nicht die Architektur selbst limitiert. In beiden Fällen lautet die Lösung: Caching, Read-Replicas, Auslagerung in Hintergrund-Jobs und Optimierung der Abfragen.
Beide befinden sich auf aktuellen, gut unterstützten Releases: Rails 8.1 und Django 5.x (Stand 2026), jeweils mit einem aktiven Sicherheits- und Release-Zyklus. Bei beiden setzen Sie nicht auf veraltete Software.
Wo sie sich wirklich unterscheiden, ist die Testkultur. Rails hat eine ungewöhnlich starke Testkultur, bei der Test-Tools als Standard vorausgesetzt werden, statt darüber zu diskutieren – ein Grund, warum große Rails-Codebasen über ein Jahrzehnt hinweg wartbar bleiben. Django liefert einen Test-Runner mit, der auf der Standardbibliothek von Python basiert, wobei die Disziplin hier stärker vom Team als von der Community-Norm abhängt. Bei einem langlebigen System, das Sie irgendwann übergeben möchten, schlägt sich dieser Unterschied in den Übergabekosten nieder, und das ist bares Geld wert.
Ruby und Python verfolgen dasselbe Ziel auf unterschiedlichen Wegen. Ruby ist auf Flexibilität und Ausdrucksstärke für Programmierer ausgelegt. Pythons Priorität liegt darauf, die Funktionsweise des Codes transparent zu machen – das kostet zwar etwas an Kürze, zahlt sich aber bei der Fehlersuche und der Einarbeitung neuer Teammitglieder aus.
Der eigentliche Unterschied liegt in der Community und den Einsatzgebieten. Ruby wird fast ausschließlich in Verbindung mit Rails verwendet. Die Webentwicklung ist bei Python nur eines von vielen Feldern. Sobald man den Bereich der Webentwicklung verlässt, ist der Vergleich daher nicht mehr ausgeglichen. Python ist in der Datenwissenschaft und im maschinellen Lernen führend, während Ruby dort kaum eine Rolle spielt.
In der Praxis ist dies der entscheidende Faktor für die meisten Entscheidungen. Eine Empfehlungs-Engine oder ein Prognosemodell in eine Django-Anwendung zu integrieren, erfordert lediglich einen Bibliotheksimport und eine Anpassung des Deployments. Dasselbe bei einer Rails-Anwendung umzusetzen, bedeutet meist, einen zweiten Dienst in einer anderen Sprache aufzusetzen – inklusive des Integrationsaufwands, des operativen Overheads und der dafür erforderlichen zusätzlichen Fachkenntnisse. Das ist der entscheidende Knackpunkt, der das Projekt schnell teuer werden lässt.
Wir erleben beide Seiten in unserer Arbeit mit Kunden. Für Python haben wir eine Django-Schnittstelle für Eurofound (die EU-Agentur) auf Basis einer bestehenden Forschungsdatenbank entwickelt – vom Prototyp bis zur vollständigen Anwendung in sechs Wochen, bereitgestellt auf Azure; sowie eine Python- und Flask-Analyseplattform für denselben Kunden. Genau das ist die Art von datenorientiertem Tool, bei dem es sich auszahlt, innerhalb des Python-Ökosystems zu bleiben. Bei einem neuen Projekt würden wir heute auf den aktuellen Stack setzen, wie bei GoodBarber Composer, das mit Django 5 auf Python 3.13 läuft. Das Fazit: Sobald Daten ins Spiel kommen, ist Python nicht mehr nur eine Frage der Vorliebe, sondern der wirtschaftlichere Weg.
Was die Laufzeit-Performance angeht, liegen beide Frameworks unter vergleichbaren Bedingungen und bei gleicher Projektgröße so nah beieinander, dass der Unterschied keine Rolle spielt. Die Entscheidung aufgrund von Benchmark-Geschwindigkeiten zu treffen, bedeutet, an der falschen Stellschraube zu drehen.
Was die Antwortzeiten wirklich bestimmt, sind der Request-Pfad, die Anwendungsarchitektur und vor allem die Optimierung der Datenbankabfragen und -strukturen. Genau hier ist die investierte Entwicklungszeit sinnvoll angelegt.
Die Feature-Kompatibilität ist die Performance-Frage, die wirtschaftlich wirklich zählt. Da Django in Python geschrieben ist, ist das Hinzufügen von KI-gestützter Datenverarbeitung oder einer spezifischen Python-Bibliothek Arbeit innerhalb der bestehenden Anwendung, anstatt Arbeit um sie herum.
Beide Stacks beginnen einfach und werden mit der Zeit komplexer. Tutorials führen schnell in die Werkzeuge ein, bevor das automatisierte Verhalten des Frameworks übernimmt: generische Views, vorgefertigte View-Klassen für Standardaufgaben oder generierte Modelle, die Endpunkte für Ihre Daten bereitstellen. Das ist praktisch, bis etwas kaputtgeht und niemand mehr den Fehler findet. Um das zu überwinden, muss man die Framework-Dokumentation gründlich lesen – und genau das ist der eigentliche Einarbeitungsaufwand bei beiden Stacks.
Unsere Erkenntnisse basieren auf zwei Projekten. Rails kam bei der Imaginary-Cloud-Website zum Einsatz: eine bereits bestehende, umfangreiche Codebasis, die wir durch Wartung und Erweiterung kennengelernt haben. Django nutzten wir für eine kleine interne Anwendung, die wir von Grund auf neu entwickelt haben – zunächst mit einem Vue.js-Frontend, später mit React.
Mit Python waren wir schneller produktiv, da die Syntax dem ähnelt, was die meisten Entwickler bereits kennen. Ruby brauchte länger, besonders wegen der Blöcke, las sich dann aber sehr natürlich. Doch das Framework war nie die größere Hürde – das war die Codebasis. Die Erweiterung einer ausgereiften Rails-Anwendung verlief schleppend, bis wir das Projekt als Ganzes verstanden hatten; danach ging es deutlich schneller. Die Entwicklung einer kleinen Django-Anwendung war von Anfang an schnell, lehrte uns aber weit weniger darüber, was wir bei einem bestehenden System zu erwarten hätten.
Das ist die Zahl, mit der Sie planen sollten. Die Schätzung für ein neues Projekt und die für ein bestehendes System unterscheiden sich grundlegend, egal für welchen der beiden Stacks Sie sich entscheiden – und dieser Unterschied ist weitaus größer als der zwischen Rails und Django.
Beide Frameworks eignen sich hervorragend für die Entwicklung von Webanwendungen. Die Unterschiede zeigen sich erst in den Randbereichen.
Zusammengefasst lässt sich sagen: Wenn sich die Roadmap auf die Webentwicklung beschränkt, ist Ruby on Rails eine solide Wahl. Wenn nicht, ist Python die sicherere Investition, da alles, was Sie als Nächstes bauen möchten, bereits in der Sprache vorhanden ist.
Keines von beiden ist pauschal besser. Sowohl Django als auch Ruby on Rails eignen sich hervorragend für die Entwicklung produktiver Webanwendungen. Python ist die bessere Wahl, wenn die Anwendung auch Data Science, Machine Learning oder Analysen abdecken soll, da diese Bibliotheken in derselben Sprache verfügbar sind. Für reine Webanwendungen sind beide vergleichbar.
Ja, für das richtige Projekt. Rails wird von 37signals und der Rails Foundation aktiv gepflegt, ist bei Version 8.1 angelangt und ermöglicht weiterhin eine schnelle Entwicklung. Der Haken ist, dass sich die meisten Stellenangebote für Rails heute auf die Wartung bestehender Anwendungen beziehen, weshalb neue Projekte seltener damit gestartet werden als noch vor einem Jahrzehnt.
Unter vergleichbaren Bedingungen liegen beide so nah beieinander, dass das Framework nicht der entscheidende Faktor ist. Die Antwortzeiten werden viel stärker vom Request-Pfad, der Architektur und der Optimierung der Datenbankabfragen bestimmt. Die Wahl zwischen beiden aufgrund der reinen Geschwindigkeit ist die Optimierung der falschen Variable.
Der Einstieg in Python ist einfacher, da die Syntax den Sprachen ähnelt, die den meisten aus dem Studium bekannt sind, und sie den Programmablauf gut sichtbar macht. Bei Ruby dauert es länger, bis es „Klick“ macht – insbesondere bei Blöcken –, aber sobald man es verstanden hat, liest sich der Code sehr natürlich. Beide Frameworks werden komplexer, sobald ihr automatisiertes Verhalten an Grenzen stößt.
Rails-Entwickler sind seltener, was sie schwerer zu finden und teurer in der Einstellung macht, obwohl der Pool aufgrund des Wartungsbedarfs stabil bleibt. Django greift auf die weitaus größere Python-Community zurück, was auch bedeutet, dass Kandidaten nicht nur an der Webanwendung, sondern auch an Daten- und KI-Funktionen arbeiten können.
Selten allein aus technologischen Gründen. Eine funktionierende Rails-Anwendung ist kein Nachteil, und eine Neuentwicklung verbraucht Budget, ohne neue Funktionen hinzuzufügen. Ein Migrationsgrund besteht nur dann, wenn die Roadmap von Python-spezifischen Funktionen abhängt und der Betrieb eines zweiten Dienstes neben Rails teurer wäre als der Umstieg.
Ja, das ist sein struktureller Vorteil. Da Django in Python geschrieben ist, steht das gesamte führende KI-Ökosystem (PyTorch, Hugging Face, TensorFlow, scikit-learn) direkt innerhalb derselben Codebasis zur Verfügung. Man fügt ein Modell oder eine Daten-Pipeline einfach als Bibliotheksimport hinzu, anstatt einen separaten Dienst aufsetzen zu müssen.
Die Wahl eines Tech-Stacks ist eine Entscheidung für drei Jahre, die man auf Basis von Informationen für ein Jahr trifft. Die Kosten einer Fehlentscheidung zeigen sich bei der Einstellung von Personal und der Wartung, lange bevor sie im Code sichtbar werden.
Wenn Sie also Ruby on Rails gegen Django für ein neues Projekt abwägen oder eine bestehende Rails-Anwendung haben und überlegen, wie es damit weitergehen soll, sprechen Sie mit unserem Team. Wir haben mit beiden gearbeitet, in beiden Situationen, und wir sagen Ihnen ganz direkt, wofür wir uns entscheiden würden.
Falls Ihre Frage über den Vergleich von Ruby und Python hinausgeht, deckt [unser Vergleich zwischen Python und Java](→ link para python-vs-java) die Vor- und Nachteile aus einer anderen Perspektive ab. Und falls Sie für dieses Projekt zu Python tendieren, ist der Aufbau einer REST-API mit Flask der nächste praktische Schritt, sobald die Sprachwahl feststeht.
Ich bin ein Webentwickler, der sich für Frameworks begeistert, die das Leben einfacher machen. Oft wird vergessen, dass Sie wahrscheinlich keine Semikolons mehr benötigen.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
