Ich habe eine allgemeine Frage zu SPA. Das heißt, ist SPA nur für die Dashboard-Art von Anwendungen geeignet? Oder können wir SPA für jede Größe der Anwendungsentwicklung auf Unternehmensebene verwenden (etwa für ERP-Lösungen)?
UPDATE:
Bitte überprüfen Sie den folgenden Link für GROSSE Diskussionen zu diesem Thema mit John Papa, Dan Wahlin und anderen ....
AngularJS ist ein sehr heißes Projekt, das ich auch benutzt habe, aber Sie kommen wieder mit der ganzen Logik von JavaScript, was Komplexität und Schmerz hinzufügt, wenn das Projekt riesig wird (es ist ein Unternehmen).
Die Faustregel lautet: Je komplexer / Unternehmen eine Softwarelösung sein sollte, desto mehr sollten Sie professionelle Werkzeuge und statische Sprachen (Java / C #) verwenden.
Wartung ist 80% des Lebens der Software. Dies in JavaScript zu implementieren, könnte sehr schwierig sein. Refactoring, Struktur und Entwicklerunabhängigkeit sind in Skriptsprachen etwas schwieriger.
Einige Anwendungsfälle, in denen SPAs ein guter Ansatz sind:
1. Wenn Sie eine leistungsstarke App für alle Arten von Mobilgeräten benötigen (wenn Sie sich keine native Entwicklung leisten können und wenn Sie keine Gebühren an Apple, Google, Microsoft zahlen, wenn Sie etwas verkaufen).
2. Nachrichtenseiten, auf denen Sie den Benutzer so gut wie möglich einbinden möchten (www.usatoday.com ist ein großartiges Beispiel).
3. Soziale Netzwerke, in denen Sie alles tun müssen, um den Benutzer aktiv zu halten (zB: Facebook ist meist SPA).
Fazit für SPAs = schnellste Web Performance & amp; beste Benutzererfahrung.
Gute Frage. Ich habe wirklich meine Zähne in SPA mit der Entwicklung einer Enterprise Mobile First Application geschnitten. Ich habe so viel von der Erfahrung gelernt. Die Anwendung hatte ungefähr 40 Module oder Apps, wenn Sie möchten. Jede App hatte etwa 3-6 Aufrufe. Ich erkannte früh, dass traditionelle Web-Architektur es nicht schneiden würde, erinnere mich, dass es ein mobiles erstes Projekt war, also fing ich an, ein Spa zu machen.
Es gibt so viel zu tun, und nicht genug oder hier zu artikulieren, aber es ist nicht wirklich so schwer. Hier sind einige Prinzipien, an die Sie glauben müssen:
Vermeide schwere Gerüste, sie kommen zu sehr in die Quere und sie kommen und gehen, also sei nicht mit ihnen verheiratet Vanilla JavaScript ist in vielerlei Hinsicht dein Freund. Alle Browser sind ziemlich konsistent mit den gleichen Standards, Apis usw. Nutzen Sie den lokalen Speicher zum Zwischenspeichern von Daten und Markup Laden Sie keine großen Markup-Brocken gleichzeitig herunter Erstellen Sie keine unnötig gesprächige Anwendung, localStorage und indexDB sind Ihre Freunde Erstellen Sie einen Mechanismus, mit dem bei jedem Laden der App nur geänderter Markup-Inhalt bereitgestellt wird Halten Sie Ihr DOM klein, zu viele Elemente, sogar versteckt erzeugt eine träge Maschine, die nach Speicher hungert. Verwenden Sie appcache für offline, aber verstehen Sie seine Macken
Allgemein gesagt, die meisten meiner Unternehmensanwendungen können mit 100 KB JavaScript oder weniger ausgeführt werden, das ist die gesamte Anwendung. Mein DOM ist in der Regel weniger als 100 Elemente, die eine lange Liste oder Tabelle in der Ansicht enthalten. Alle meine Apps werden in weniger als 1 Sekunde geladen und laden den Inhalt des Untermoduls im Hintergrund.
Eine definitive positive Antwort wird nur möglich sein, wenn jemand ein erfolgreiches ERP als einzelne Seite mit Angular erstellt.
Das zivile Web-Framework enthält eine ausführliche Stichprobe [1] [2], in der die Macher diese Richtung erkundeten. Dies scheint keine vollständige Lösung zu sein, aber geht wahrscheinlich ein paar Schritte näher an eine Architektur heran.
Google Dart + Polymer behauptet, dass es für die ERP-Entwicklung verwendet wird. Aber Google macht alles mit Dart, Flutter, Dartino und Just aufgegeben Polymer.Dart und der Dart Editor.
Tags und Links single-page-application