nicht angemeldet
Hallo,
Ich wäre zum Beispiel bisher nicht auf die Idee gekommen node.js als Backend-Solution zu nutzen. Dafür ist mir das noch viel zu frisch.
Node.js ist auch keine generische Backend-Lösung, sondern für die Anwendungsfälle gedacht, wo das eventbasierte, asynchronone I/O auf Basis einer äußerst schnellen JIT-VM Vorteile bringt. Z.B. bei vielen parallelen Requests oder WebSockets-Verbindungen.
Auch würde ich mich nur selten für RubyOnRails entscheiden, wenn man ähnliches mit Grails auch im Enterprise-Sektor haben kann.
Ruby on Rails gehört eher schon zu den etablierten Frameworks und Ruby hat mit MRI, Rubinius und jRuby starke Interpreter. Welchen Vorteil bietet da Grails, eine noch bessere Einbindung in ein Java-Umfeld?
Auch weiß ich die No-SQL-Datenbanken noch nicht so recht zu deuten
Schemafreie dokumentbasierte Datenbanken, Key-Value- und In-Memory-Datenbanken schließen erst einmal eine Lücke, die SQL-Datenbanken vorher nur schlecht abdecken konnten. SQL-Datenbanken haben immer noch eigentümliche Vorteile, die NoSQL vor allem ergänzt.
Im Falle der SPA-Frameworks (Single Page Applications) bin ich zum Beispiel gut abgeschreckt, da sich grundlegende APIs selbst in Minor-Versionen geändert haben. Und ich habe den Eindruck, dass man zwar die Notwendigkeit solcher Frameworks erkannt hat, aber noch nicht so recht weiß, wohin genau die Entwicklung eigentlich gehen soll.
Man weiß es schon, die Ziele, Anforderungen und Geschmäcker sind allerdings sehr verschieden. Daher haben die SPA-Frameworks auch unterschiedliche Ausrichtungen und Schwerpunkte. Starke Bewegung und damit API-Brüche ist bei vielen dieser Frameworks zu beobachten, aber alle stabilisieren und differenzieren sich gerade.
Node.js. JavaScript auf dem Server. Als Web-Entwickler, der noch aus den Zeiten stammt, in denen es jQuery noch gar nicht gab - bereitet mir der Gedanke - wenn ich ehrlich bin - doch etwas das Bauchschmerzen.
Wieso?
Grüße,
Mathias