avantages et les inconvénients de la mise en œuvre javascript côté serveur?

Question

Je viens de commencer à expérimenter avec Aptana Jaxer côté serveur moteur javascript pour mon prochain projet. Et j'ai quelques quesions à ce sujet

• En utilisant côté serveur JS, pouvons-nous mettre en œuvre l'ensemble de l'application web sans utiliser toutes les langues côté serveur (comme C #, java, etc.). Ou côté serveur JS se trouve entre le serveur Web et l'autre pile de langauge.

• Est-il vraiment une meilleure approche ??

• quels sont les advandages et disadvandages?

• comment cela fonctionne bien en termes de performance?

• est-il mise en œuvre en temps réel (sites web publics) en utilisant uniquement JS côté serveur (pas d'autres langues)?

• quelles sont les alternatives disponibles sur Aptana jaxer (open source) ??

• comment nous pouvons mettre en œuvre et maitain transactions db? pouvons-nous faire dans Serverside JS ..?

• est-il possible de développer des services et SOAP dans RESTFul Serverside JS .. ??

Je sais que cela est trop long (et des questions naïves). Je suis juste espère que quelqu'un a déjà rencontré tous ces JS en mettant en œuvre Serverside.

EDIT:

Selon les commentaires Matthew & Ken, j'ai ajouté un peu de clarté à la question Est-il vraiment une meilleure approche ??

est ce que je veux demander ..

Est-il vraiment une meilleure approche que l'utilisation des langues côté serveur (en présumant c #), comment nous pouvons comparer avec c # mise en œuvre d'un site Web (performance, les caractéristiques linguistiques) ?? Et que l'on est une meilleure approche, en utilisant seul JS dans Serverside ou JS dans la couche intermédiaire entre autre pile de langue et ?? serveur web

Answer 1

Je suis le développeur Myna (www.mynajs.org), un côté serveur JS Open Source plate-forme basée sur Rhino et Java. Je vais aborder les questions qui ont trait à Myna, mais beaucoup de ces points s'appliquent à côté serveur JS en général:

En utilisant côté serveur JS, pouvons-nous mettre en œuvre l'ensemble de l'application web sans utiliser toutes les langues côté serveur (comme C #, java, etc.). Ou côté serveur JS se trouve entre le serveur Web et d'autres pile langauge.

Dans Myna il est possible d'écrire votre application entière dans JS. Myna comprend déjà des API d'accès de base de données, Object Relational Mapping, crytogrophy, OpenID, etc.

Est-il vraiment une meilleure approche que c # / Java?

Avec un serveur basé sur Rhino, il est trivial de descendre à Java en cas de besoin. Vous pouvez facilement installer des bibliothèques open-source / commerciale / Java code à la main puis les script JS. Cela signifie que vous obtenez le développement rapide de JS mais maintenir les avantages de la plate-forme Java

Quels sont les avantages et les inconvénients?

avantages:

• Le développement rapide : Dans Myna vous suffit de créer des fichiers dans le Webroot avec une extension .sjs. Cela signifie que vous pouvez créer un cycle de navigateur modifier-save-refresh avec est très rapide pour le débogage / code peaufinage.

• facile JSON : Avoir le soutien JS côté serveur signifie le déplacement des structures complexes est très facile

• Code partagé : Si vous devez effectuer la même fonction sur le serveur et le navigateur, vous pouvez utiliser le même code

• Dynamic ORM : Les langages typés statiquement compilé font qu'il est difficile de modifier des objets à l'exécution. Cela signifie généralement que ORM doit être défini à l'avance. Dans Myna bâtiment ORM est aussi simple que

  var manager =new Myna.DataManager("DataSource name").getManager("table name");
  

  Vous obtenez un objet qui peut faire toutes les opérations CRUD de base sans jamais définir explicitement les tables DB. Comme autre exemple, vous pouvez insérer une ligne avec toutes les valeurs correspondantes d'une forme post:

  manager.create($req.data);
  

• fonctionnelle Programing : Si vous avez commencé à jouer avec JavaScript Fonctions avancées vous apprécierez la façon dont ils sont côté serveur utiles. En raison de l'environnement côté serveur compatible, il est sûr d'utiliser des fonctionnalités avancées telles que Extras Array générateurs et les itérateurs , missions de destructuration et E4X

contre:

• Outils : Les langages typés statiquement comme C # et Java ont d'excellents outils IDE et développeurs. Les langages dynamiques comme JS n'ont tout simplement pas encore le support d'outil. Personnellement, je trouve que la grande réduction du code et boilerplate coulée de type pointilleux fait pour cela, mais cela reste un gros désavantage si vous avez fait beaucoup de développement dans IDEs. Si vous utilisez actuellement un IDE, pensez à utiliser jedit pour les langages dynamiques

• Maturité / normalisation : Serverside JS est encore un nouveau paradigme, et il y a beaucoup de joueurs et pas gagnants. ECMA n'a pas de normes pour Serverside JS. Comme il est mentionné dans la réponse de Brandon, le groupe CommonJS tente de former une norme JS Serverside et Myna a CommonJS expérimentales support par l'intermédiaire Narwhal

comment cela fonctionne bien en termes de performance?

Dans la vitesse de calcul brute, quelques langages dynamiques peuvent correspondre statiquement typé langages compilés comme C # et Java. Cela dit, il n'a pas d'importance. Toute partie de votre application est intensive devrait probablement informatiquement être écrit en Java, ou utiliser une bibliothèque Java existante. Je ne dirais pas que tout le monde écrire une base de données de JS par exemple. Pour de vrai applications web du monde / services SOA, la principale cause de ralentissement n'est pas la vitesse de calcul brute, il est un code inefficace, en particulier l'accès aux bases de données. Myna aide à cela en faisant des choses comme:

• la mise en cache interne compilé des scripts JS
• En interne utilisant des requêtes préparées mises en cache pour les transactions de base de données
• Requête et la mise en cache des fragments de sortie
• regroupement de connexions de base de données
• Prise en charge de hachage automatique ETag
• outils de profilage
• Lazy chargement de métadonnées

comment nous pouvons mettre en œuvre et maintenir des transactions db? pouvons-nous faire dans Serverside JS ..?

Si vous voulez dire la transaction comme dans « un ensemble d'instructions SQL qui peuvent être infirmées ou engagés », alors Myna ne supporte pas encore les transactions. Je suis ouvert à mettre en œuvre ce s'il y a suffisamment d'intérêt.

Si vous voulez dire « quel type de soutien de base de données ne côté serveur JS ont? » alors la réponse est dépendant de la plateforme. La plate-forme de Myna offre les fonctionnalités de base de données suivantes:

• Une application d'administration basée sur le Web où vous pouvez définir des « sources de données », les informations de connexion de base de données i.e.. Vous pouvez alors interroger ces sources de données par son nom. Myna inclut les pilotes JDBC pour H2, MySQL, Microsoft SQL Server et Postgresql, mais une source de données JDBC ou ODBC peut être utilisé
• Myna.Database et < a href = "http://www.mynajs.org/shared/docs/js/libOO/files/Table-sjs.html" rel = "nofollow noreferrer"> Myna.Table fournir un accès METDATA base de données neutre ainsi que la création de la table et la modification.
• Recherche l'objet prend en charge maxRows , la pagination, les paramètres SQL, les gestionnaires de ligne personnalisés, requête de-requête, la mise en cache et plus
• l'objet de DataManager prend en charge l'exécution ORM création d'objets

est-il possible de développer des services et SOAP dans RESTFul Serverside JS .. ??

REST et SOAP support sont des caractéristiques spécifiques de la plate-forme. l'objet de WebService prend en charge les protocoles suivants:

• SOAP
• XML-RPC
• JSON-RPC
• Poste direct
• JSON-MYNA (Un protocole simple qui utilise les messages de forme normale et retourne JSON. Facile à utiliser à partir du navigateur)

Myna comprend également la PUT et DELETE méthodes de demande et présente demande d'accès à un contenu de corps dans le texte et sous forme binaire, de sorte qu'il est possible de gérer ces méthodes RESTful d'une manière spécifique à l'application.

Debugging

débogage traditionnel arrêt est un véritable défi Serverside. Bien que Rhino supporte crochets débogueur, en utilisant ces d'une application web sans état serait assez impliqué. Personnellement, je ne l'utilise même pas débogueurs même des points d'arrêt lorsqu'ils sont disponibles (par exemple Firebug). Au lieu de cela, je préfère l'exploitation forestière.

Myna,

 Myna.log(type,label,detail)

engendrera un fil de faible priorité pour écrire un message journal HTML à la base de données de journalisation de Myna. Ces journaux peuvent ensuite être searched par l'Administrateur Myna. Journaux enregistrent également l'horodatage et millisecondes écoulé à des fins de profilage. Myna.dump (obj) peut également être utilisé pour présenter une représentation de la table HTML de tout objet. Myna enregistre également toutes les exceptions ONU-traitées avec des traces de la pile, le contexte du code source et détails de la demande. Entre décharge (), log () et le gestionnaire d'erreurs par défaut je n'ai pas beaucoup de difficulté le débogage du code Myna

Answer 2

En utilisant côté serveur JS, pouvons-nous mettre en œuvre l'ensemble de l'application web sans utiliser toutes les langues côté serveur (comme C #, java, etc.).

Il ne devrait pas être nécessaire d'écrire du code dans toutes les autres langues, bien que beaucoup de cadres JavaScript côté serveur utilisent le moteur Rhino, ce qui vous permet d'appeler un code Java.

Est-il vraiment une meilleure approche ??

Je ne pense pas que JavaScript (comme langue) est vraiment une option meilleure ou pire que les langues côté serveur traditionnel. Il présente des avantages (ainsi que d'autres langages dynamiques comme Ruby et Python) comme la flexibilité, le prototypage rapide (sans jeu de mots), la flexibilité, etc. D'autre part, il n'a pas le soutien de la bibliothèque que Java et C # ont ou typage statique (Je ne vais pas entrer dans le débat sur ce qui est mieux ici, j'aime tant pour des raisons différentes).

Si vous voulez le meilleur des deux, vous pouvez utiliser JavaScript comme langage de script, intégré dans votre application. Rhino pour Java, et JScript.NET le rendent facile à manipuler des objets « natifs » en JavaScript. Vous pouvez, par exemple, écrire vos classes de domaine en Java ou C #, et les script avec JavaScript où vous voulez plus de flexibilité. Si vous êtes assez à l'aise avec JavaScript, écrit dans une seule langue peut être plus simple si.

Je ne l'ai jamais écrit une application côté serveur « réel » en utilisant JavaScript, donc je ne peux pas vraiment juger si son meilleur ou pire que .NET (je l'ai aussi jamais utilisé JScript.NET). Je l'ai joué avec quelques cadres pour le plaisir bien et je suis en cours de réécriture de mon site personnel à l'aide Helma NG. Jusqu'à présent, il a été une bonne expérience (beaucoup mieux que PHP, que je ne l'ai jamais vraiment aimé).

quels sont les advandages et disadvandages?

advantanges:

• Une seule langue nécessaire pour côté serveur et la programmation côté client.
• Possibilité de code partagé, pour des choses comme la validation du formulaire. Jaxer vous permet d'exécuter des scripts sur le client, serveur, ou les deux.
• Vous arrivez à programmer en JavaScript (en supposant comme la langue).

Inconvénients:

• De nombreux cadres sont expérimentaux / pas très mature.
• Vous devez programmer en JavaScript (en supposant que vous ne voulez pas la langue).

comment cela fonctionne bien en termes de performance?

La performance devrait être à peu près comparable à d'autres langages de script.

est-il une mise en œuvre en temps réel (sites web publics) utilisant uniquement côté serveur JS (pas d'autres langues)?

Je ne connais pas de grands sites Web en utilisant JavaScript, mais il peut y avoir quelques-uns.

quelles sont les alternatives disponibles sur Aptana jaxer (open source) ??

Wikipedia a une , mais il n'a pas beaucoup utile information. Il y a beaucoup d'options avec un large éventail de maturité et de la taille.

Voici quelques-unes que je connais (à des degrés divers)

• Helma -. Rhino (Java) Cadre base avec enregistrement actif
• Helma NG - Helma prochaine génération (rewrite expérimentale, en cours de développement).
• Phobos - A un bon soutien dans NetBeans .
• v8cgi - Petit et simple, utilise le moteur V8 de Google, sans doute pas prêt à la production encore .
• Jaxer - Fonctionne sur SpiderMonkey avec une implémentation DOM, de sorte que vous pouvez manipuler la page avec des cadres comme jQuery ou Prototype. A un bon support IDE dans Aptana Studio.

comment nous pouvons mettre en œuvre etmaintenir les transactions db? pouvons-nous faire dans Serverside JS ..?

cadres à base de Rhino vous permettent d'utiliser des classes Java, vous avez donc un support complet JDBC. Je ne l'ai pas utilisé les bibliothèques de base de données de Jaxer, donc je ne sais pas quoi que ce soit au sujet de ses capacités.

est-il possible de développer des services et SOAP dans RESTFul Serverside JS .. ??

API RESTful ne devrait pas être un problème. Je ne sais pas d'un soutien spécifique pour SOAP, mais il devrait être possible .

Answer 3

En tant que préface, j'utilise SSJS à mon travail de jour. Nous courons un site assez grand (en termes de complexité, ainsi que des vues de page) sur SpiderMonkey. Je vais ajouter à une excellente réponse où j'ai l'expérience de Matthew.

Est-il vraiment une meilleure approche que l'utilisation des langues côté serveur (en présumant c #)

"Mieux" dépend vraiment de ce que vous voulez faire. JavaScript a lui-même quelques fonctionnalités, ainsi que ceux assez horrible. Si vous êtes sérieux sur le développement JS (client ou serveur), je ne peux pas recommander assez fortement que vous regardez la présentation de Douglas Crockford, Javascript: The Good Parts si vous avez pas déjà. Il a fait un travail fantastique tri des cochonneries, et il est un excellent orateur pour démarrer.

La plus grande chose que je trouve le monde SSJS manque est en ce moment la maturité. Je ne suis pas familier avec C #, mais JavaScript n'a pas la bibliothèque standard mature, et aucun moyen de maturité distribution de paquets. Pour moi, c'est un gros morceau du casse-tête.

Cela dit, gardez l'œil sur le groupe CommonJS . Ils travaillent vers la définition des choses exactes. En outre, la documentation Jaxer Api énumère les Encastrements qui sont inclus dans ce cadre.

comment cela fonctionne bien en termes de performance?

JavaScript est lui-même pas une langue lente, ni un particulièrement rapide. Comme Matthew a souligné, il devrait être comparable à tout autre langage de script que vous utilisez. La guerre entre le navigateur fournisseurs pour voir qui peut construire le navigateur le plus rapide profitera à la foule SSJS aussi bien.

La collecte des ordures générationnelle que l'équipe V8 construire dans leur moteur est un excellent exemple. Enrayer la machine virtuelle pour libérer les objets inaccessibles à partir du tas et de récupérer leur mémoire peut être un peu lent, mais ils ont atténué que, en réduisant la quantité d'objets qui doivent être inspectés lorsque le garbage collector fonctionne.

comment nous pouvons mettre en œuvre et maintenir des transactions db? pouvons-nous faire dans Serverside JS ..?

Jaxer semble avoir des API de base de données MySQL et SQLite. Comme Matthieu mentionné, si vous utilisez Rhino, vous pouvez utiliser l'API JDBC.

Modifier : Ajout de liens