De temps en temps, je recherche de l'aide en JavaScript et je tombe sur le terme "JavaScript côté serveur". Quand utiliseriez-vous JavaScript côté serveur ? Et comment ?
Mes expériences avec JavaScript ont été dans le navigateur. Y a-t-il une version compilée de JS ?
Il ne s'agit pas d'AJAX, à moins que les gens utilisent mal le terme. Comme son nom l'indique, SSJS est du JavaScript qui s'exécute côté serveur, interprété par un moteur JavaScript autonome (c'est-à-dire indépendant du navigateur), tel que SpiderMonkey.
Pourquoi se donner la peine ? Eh bien, un domaine où je le vois actuellement sous-utilisé est la validation des données. Avec SSJS, vous écrivez un seul morceau de code qui est ensuite utilisé à la fois côté serveur et côté client. Ainsi, vous obtenez un retour immédiat de l'utilisateur à partir du JS côté client qui correspond automatiquement à la vérification des données effectuée côté serveur.
Un jour, j'aimerais générer automatiquement du JavaScript à partir des contraintes de VERIFICATION de la base de données de cette manière. (Je me demande si pgsql a des liaisons JS?)
Il y a le projet Phobos, qui est un framework JavaScript côté serveur.
À l'époque, le serveur web Netscape offrait également du java script côté serveur.
Dans ces deux cas, JavaScript est utilisé comme n'importe quel autre langage côté serveur. Généralement pour gérer les requêtes HTTP et générer du contenu.
Rhino, qui est le système JavaScript de Mozilla pour Java, compile le JavaScript en octets Java, que la JVM peut choisir de JIT. D'autres systèmes utilisent d'autres moyens pour exécuter le java script, au point que certains JIT compilent leur code interne javascript.
Je prévois qu'il y aura de plus en plus de JavaScript côté serveur. Lorsque vous écrivez des applications "épaisses" en JavaScript côté client, vous pouvez également écrire votre logique en JavaScript côté serveur afin de ne pas avoir à faire des sauts cognitifs d'un langage à un autre. Les environnements seront différents, mais une grande partie de votre code et de vos connaissances pourront être partagées.
Enfin, JavaScript est probablement le langage unique qui bénéficie actuellement du plus de financement en termes d'implémentations. De la part d'Apple, Mozilla, Google, et même Microsoft ainsi que des efforts pour en faire un langage encore plus avancé (c'est-à-dire essentiellement un Scheme avec une syntaxe Algol sans macros).
La plupart de ces implémentations sont enfouies dans le navigateur, mais cela ne veut pas dire qu'il n'y a pas de valeur côté serveur également.
Les outils sont le plus gros point faible de JavaScript, surtout côté serveur, mais si vous considérez quelque chose comme Phobos, où vous pouvez déboguer votre JavaScript côté serveur dans l'IDE, c'est une grande avancée.
Personnellement, j'utilise JavaScript dans mes applications comme de la peinture blanche. Il offre une extensibilité bon marché pour très peu de coût et est un excellent facilitateur.
Notez qu'il y a un effort pour améliorer l'interopérabilité et les bibliothèques disponibles pour le JS côté serveur wiki.commonjs.org/wiki/CommonJS
Node.js (voir aussi l'article de Wikipédia) est un succès, et sa communauté est en croissance !
MongoDB (au serveur), Chrome (au client), et Node.js (au serveur) utilisent le moteur JavaScript V8.
PS : vous pouvez n'utiliser qu'un seul langage, Javascript, pour tous les modules de votre projet : APIs client, interface client, "centre serveur", et base de données serveur (ex. procédures stockées). Tous les programmeurs "codent une seule fois" !
La principale distinction entre les langages "Serveur-Javascript" et "Client-Javascript" est expliquée sur http://www.commonJS.org/ , la bibliothèque standard pour le Javascript serveur.
CommonJS existe depuis 2009, et aujourd'hui (2013) est un standard mature, utilisé à la fois par MongoDB et Node.js.
NOTE HISTORIQUE : le package open source le plus ancien de "Javascript client+serveur" (incluant l'utilisation de PostgreSQL) est toujours actif !
Sorti en 2001 et en développement continu depuis, Whitebeam est une technologie Javascript (et DOM) mature. La dernière mise à jour date de janvier 2016.
Node.js continue d'évoluer en tant que moteur d'exécution construit sur le V8 JavaScript de Chrome... Et est maintenant, en fait, un succès consolidé ! Les dernières versions sont v7.0 et v6.8 LTS.
JSON, en tant que format d'échange de données, suscite un intérêt croissant depuis les dernières années, ayant dépassé en 2016 l'intérêt pour XML (voir aussi dans le contexte scientifique, où il a dépassé en 2011). En tant que format natif de Javascript, il est également un bon indicateur de tendance linguistique.
Le (plus rapide) moteur V8 est également le plus utilisé depuis 2014 : dans les navigateurs client les plus populaires (Chrome sur ordinateurs de bureau et WebView sur Android) et populaire sur les serveurs — Node.js en tant que moteur d'exécution et PostgreSQL avec PL/V8 pour le SQL et les procédures stockées.
...Peut-être la contribution la plus importante côté serveur en 2016 a été le support rapide et robuste des bases de données pour le JSON et Javascript : avec PostgreSQL 9.1+ (2016-10) vous pouvez charger PL/V8 (et des dialectes comme Coffeshop) via une simple commande CREATE EXTENSION ; avec PostgreSQL 9.5+ (2016-10) le plus important, un ensemble complet et orthogonal de fonctions et opérateurs JSON et JSONb.
Ainsi, il y a, en fait, un ensemble de développement JavaScript unifié rapide, résilient et fiable.
Re "JSON .. En tant que format natif de Javascript, c'est aussi un bon indicateur des tendances du langage." Non, la popularité du JSON explose car il s'est avéré tout aussi utile dans d'autres langages, chaque fois que de petits paquets de paires clés-valeurs doivent être envoyés entre les appareils (téléphones, ordinateurs de bureau, serveurs). Il est plus facile à manipuler que le XML pour des besoins de données simples. En particulier, à la fois Apple et Google utilisent JSON pour les notifications push. Cela seul serait suffisant pour une explosion de l'utilisation!
À propos du "développement unifié", il est également intéressant de conserver une certaine isomorphie client/serveur dans le modèle MVC utilisé à la fois par le client et le serveur. Voir l'article isomorphic-universal-javascript ou l'article git.
... Gros problème en 2019 dû au litige sur les brevets entre Oracle et Google, voir github.com/plv8/plv8/issues/364
Classic ASP pouvait utiliser JavaScript côté serveur, bien que la plupart des gens utilisaient VBScript.
Une utilisation convaincante de JavaScript côté serveur est comme complément à la validation des données côté client. Par exemple, vous pourriez utiliser la même bibliothèque de validation JavaScript côté client et côté serveur. Cela garantit que vous utilisez la même logique côté client que côté serveur, mais en évitant éventuellement un aller-retour inutile en pré-validant côté client.
Wikipedia répertorie un certain nombre de implementations de JavaScript côté serveur ici.
Nous avons utilisé JScript avec ASP dans ma dernière entreprise. Le bonus est moins de langages (nous avions des développeurs front-end écrivant certains appels de données côté serveur) et la réutilisation du code, car vous utiliseriez presque exactement le même code pour valider de chaque côté. Bonnes choses, mais maintenant j'ai du mal à trouver de bonnes façons de le mettre dans Apache.
Il pourrait s'agir de l'utilisation de javascript pour envoyer des messages à un serveur Web sans recharger la page : en d'autres termes, AJAX.
Mais je pense plus probablement que cela signifie quelque chose comme Aptana/Jaxer (ou, aujourd'hui, Node.js), qui utilise javascript comme langage côté serveur. Dans ce cas, rappelez-vous que javascript est juste un langage : le DOM utilisé dans un navigateur Web est une sorte d'API. Les moteurs javascript côté serveur fourniraient leurs propres objets API, orientés vers des tâches côté serveur telles que l'accès à la base de données et au système de fichiers.
Le javascript côté serveur est une idée intéressante en raison du problème de la validation côté client : vous voulez effectuer la validation côté client pour éviter d'envoyer des requêtes inutiles à votre serveur. Cela améliore les performances du serveur et réduit la latence sur le client. Mais vous devez également effectuer la validation côté serveur car vous ne pouvez pas faire confiance au client. Cela entraîne beaucoup de code en double entre le client et le serveur.
La théorie veut que si vos langages côté client et serveur correspondent, vous n'aurez plus besoin de deux implémentations de la même logique. En pratique, cela ne fonctionne pas si bien, car les vues côté client et serveur d'une requête de page sont très différentes et parce que vous ne contrôlez pas le moteur javascript utilisé par le client.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
8 votes
Question intéressante
0 votes
Voir cette question sur Jaxer : stackoverflow.com/questions/98915/…
0 votes
Et aussi lié: stackoverflow.com/questions/109762/…
0 votes
Je pensais que cela pourrait être utile ici - Wikipedia sur la comparaison des solutions JavaScript côté serveur: fr.wikipedia.org/wiki/…
0 votes
Cette question est presque équivalente à "Quand et comment unifiez-vous les langages dans la pile de développement ?". Javascript est le langage standard côté client, JSON pour le transport... Ainsi, avec Javascript côté serveur, vous pouvez unifier le développement. Voir la réponse ici.
0 votes
@PeterKrauss - Je sais que ce n'est pas le lieu pour discuter de cela, mais de toutes les langues disponibles aujourd'hui, c'est le javascript qui est devenu commun .. me horrifie. D'autre part, cela signifie peut-être que le comité WWW, la prochaine fois, pourra convenir d'améliorations substantielles de la langue, qu'ils n'ont pas pu accepter pour HTML5. (Sur la base des transcriptions de la réunion, en lisant entre les lignes, n'ont pas réussi à s'entendre en grande partie parce que le faire signifiait aider soit Adobe soit Microsoft, puisque ce sont les deux entreprises ayant des langues substantielles qui auraient pu être utilisées comme base pour de nouvelles fonctionnalités.)