Werden bestehende JavaScript-Frameworks CommonJS einbinden?

Question

JavaScript-Frameworks wie Prototype, jQuery, YUI, MooTools, Dojo u. a. scheinen alle auf clientseitige Entwickler abzuzielen, wobei der Schwerpunkt darauf liegt, dass gängige Benutzerinteraktionsmuster effizienter und mit weniger Code umgesetzt werden können.

Beabsichtigen diese Frameworks mit dem Aufkommen von serverseitigem JavaScript, die CommonJS-Standards zu übernehmen, um die Wiederverwendung ihrer Bibliotheksfunktionen für serverseitiges JavaScript zu ermöglichen, oder werden sie alternativen Frameworks wie Node und Narwhal erlauben, den serverseitigen Anwendungsfall zu behandeln?

(Mir ist klar, dass diese Frage gefährlich nahe an eine Frage herankommt, die zwar diskutiert, aber nicht beantwortet werden kann, aber ich gehe davon aus, dass die Stack Overflow-Gemeinschaft die Frage tatsächlich mit spezifischen Referenzen beantworten kann).

Answer 1

Hier ist meine Meinung (ich bin ein YUI-Entwickler):

Es scheint, als gäbe es zwei Blickwinkel auf Ihre Frage.

In der einen geht es um die Paketierung von Modulen und Wiederverwendungsformate (CommonJS) und in der anderen um die allgemeine Idee der clientseitigen JS-Bibliotheken und ihre Anwendbarkeit auf die serverseitige Entwicklung.

Ich bin nicht wirklich die richtige Person, um die Frage nach der Verpackung zu beantworten, außer zu sagen, dass YUI 3 von Haus aus ein formales Modulsystem zur Kapselung und Bereitstellung von Code seit dem ersten Tag verwendet hat, und es war ein wesentlicher Bestandteil des Designs. Die Bereitstellung eines Adapters oder Build-Schrittes, um diese Module nach CommonJS zu liefern/übersetzen, ist etwas, das wir diskutiert haben. Andere Leute in der YUI-Community, die in diesem Bereich tätig waren, können hier vielleicht mehr wertvolle Informationen beisteuern.

Zum zweiten Aspekt kann ich Ihnen sagen, dass der Server eine erstklassige Zielumgebung für YUI ist. Es ist auf dem Server genauso einsetzbar wie auf dem Client. Es gibt natürlich eine Reihe von Modulen, die nur in der einen oder anderen Umgebung Sinn machen, aber ein großer Teil der Bibliothek kann auf beiden Seiten des Zauns verwendet werden, und es ist bewusst so gebaut, dies zu tun.

Ein großer Teil der YUI-Module bietet beispielsweise Infrastruktur und Hilfsprogramme, die für die App-Entwicklung auf dem Server genauso geeignet sind wie auf dem Client (Custom Event, Attribute, Base, Intl, Handlebars, IO, YQL, DataType, DataSchema, JSON etc...).

Das war von Anfang an das Ziel des Designs - es ist eine Bibliothek für die Anwendungsentwicklung im Web (in Ermangelung eines besseren Begriffs - ich beziehe mich auf den JS/HTML/CSS-Technologie-Stack), nicht nur eine DOM-Abstraktionsbibliothek oder eine Widget-Bibliothek.

Dav Glass hat einen Blogbeitrag mit großartigem Inhalt zu diesem Thema veröffentlicht:

http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/

Sie können sich auch die 3.5.0 PRs ansehen:

http://stage.yuilibrary.com/yui/docs/yui/nodejs.html

Answer 2

Die Art, wie ich sehe, was wir mit CommonJS tun, ist, dass wir in der Lage sein wollen, Module zu machen, die Teil von größeren Systemen sind, die sowohl clientseitig als auch serverseitig laufen. Ich habe bereits persönlich mit zwei verschiedenen clientseitigen CommonJS-Modul-Ladern gearbeitet, und es funktioniert sehr gut.

Im Browser können Sie jede beliebige DOM-Manipulationsbibliothek/jedes clientseitige Toolkit verwenden, und das beeinträchtigt nicht wirklich die Möglichkeit, auch CommonJS-Module vom Server wiederzuverwenden.

Die Wiederverwendung der client-seitigen Dienstprogramme auf dem Server kann auch noch funktionieren. CommonJS-Module haben alle ihren Code in einem Closure laufen, so dass jedes Modul ist etwas unabhängig von den anderen Modulen. Browser-basierte Bibliotheken neigen dazu, mit Namespaces zu arbeiten, die global bevölkert werden. Bislang kann jede CommonJS-Plattform auf dem Server Globals auf die eine oder andere Weise verwenden.

Solange die Bibliothek selbst so gestaltet ist, dass sie Umgebungen ohne DOM (wie Rhino) unterstützt, sollte es möglich sein, sie in einer typischen SSJS-Umgebung zu verwenden, wenn auch nicht in CommonJS-Modulen.

Answer 3

Da die meisten dieser Bibliotheken speziell auf das DOM abzielen und darauf ausgelegt sind, Browser-APIs und browserübergreifende Probleme zu vereinfachen, bin ich nicht sicher, welchen Vorteil dies bringen würde.

CommonJS-Unterstützung ist in jQuery 1.4 nicht vorgesehen. Sie ist auch nicht in der jQuery 1.5 Fahrplan .

Dojo ist bestrebt, allumfassend zu sein und hat ein offenes Thema über Hinzufügen von Unterstützung für CommonJS in Dojo aber sie ist markiert als Zukunft .

Im Allgemeinen würde ich mich nicht darauf verlassen.

Answer 4

Wie jeder bereits gesagt hat, sind die meisten JavaScript-Bibliotheken Wrapper auf das DOM zum größten Teil.

Cependant Ich würde CommonJS nicht nur für die Serverseite in Betracht ziehen. Ich denke, es wird einen Platz für sie auf der Client-Seite, vor allem als Javascript bewegt sich in Richtung einer verbesserten Sicherheitsmodell, das stark von einem CommonJS Ansatz zur Modularisierung profitieren würde.

Answer 5

Bei den meisten CommonJS-APIs handelt es sich um serverbasierte Funktionen, die in Browser-JS einfach nicht implementiert werden können. Von den aktuellen Modulen, io , fs , system , sockets y worker sowie JSGI und andere sind aufgrund ihrer grundlegenden Natur nicht implementierbar.

encodings würde riesige Datentabellen erfordern, die man nicht in eine Bibliothek einbauen möchte (abgesehen von den eingebauten Grundkodierungen, die man ohnehin schon recht gut handhaben kann). Andere Funktionen können nicht unterstützt werden, weil sie Sprachfunktionen wie Getter/Setter benötigen würden, die im Browser aufgrund der schlechten Unterstützung noch nicht verwendet werden können.

Nach all diesen Rabatten bin ich mir nicht sicher, ob wirklich noch etwas übrig ist. Die require Klempnerarbeiten?