Sur le serveur, Swift est nettement plus rapide que Node.js
Swift, le nouveau langage de programmation d’Apple, n’est pas limité aux produits du constructeur. Conçu comme un langage à tout faire, depuis le noyau d’un système d’exploitation jusqu’aux scripts des utilisateurs, il peut aussi servir sur les serveurs. Apple fournit une version prête à emploi pour Ubuntu qui sert justement à exploiter le langage sur un serveur, où Linux domine largement.
Pour utiliser Swift sur un serveur, il faut tout développer soi-même toutefois, ce n’est pas un langage prêt à l’emploi comme peut l’être PHP. Néanmoins, plusieurs frameworks proposent tout le nécessaire pour créer des applications en Swift dédiées à un serveur, sans avoir à gérer soi-même les connexions entrantes et sortantes et tout le reste. Mais que valent-ils sur le plan des performances, et par extension, comment se positionne Swift sur le serveur en termes de vitesse ?
Pour le savoir, Ryan Collins a comparé ces frameworks à un poids lourd côté serveur, à savoir Node.js qui permet d’utiliser du JavaScript sur un serveur. Cet environnement est devenu extrêmement populaire et de nombreuses entreprises l’utilisent pour leurs services, de Netflix à Uber, en passant par eBay et des centaines d’autres. C’est un outil très populaire, mais qui n’a jamais été très rapide et la comparaison avec Swift est impitoyable : node.js est souvent bon dernier.
Les mesures ont été effectuées sur un Mac mini de 2012, où Ubuntu a été installé nativement (sans virtualisation). Deux applications minimales ont été créées, un blog et une autre qui génère un fichier JSON, pour simuler au mieux un usage réel de ces langages de programmation sur les serveurs. À l’exception de l’un des frameworks Swift qui avait un bug connu avec le JSON, Node.js a toujours terminé dernier sur les benchs qui mesuraient à la fois le nombre maximum de requêtes gérées correctement par seconde et le temps de réponse.
Naturellement, le choix d’un langage n’est pas lié uniquement aux performances. Dans le cas de Swift, l’intérêt pour les développeurs iOS et macOS est d’utiliser le même langage et pourquoi pas même les mêmes lignes de code pour leurs apps et pour le module serveur associé. C’est la même logique pour Node.js : les développeurs de sites web utilisaient déjà du JavaScript, ils pouvaient garder les mêmes compétences sur le serveur.
Si vous voulez commencer à utiliser Swift sur les serveurs, Perfect est un bon point de départ. Il est le plus rapide sur toutes les mesures effectuées par Ryan Collins et il semble plus avancé et complet que ses concurrents.
> ce qui pourrait nettement éviter d'apprendre aux développeurs iOS/OSX un autre langage.
Je vois pas en quoi réduire l'horizon visible aux développeurs iOS/OSX est une bonne chose. Pour eux, j'entends.
De la même manière que pour les dev C#, c'est pas dans l'intérêt à moyen terme d'être mono-techno.
Pour leurs employeurs, par contre, c'est tout autre chose.
Et évidement, pour les tenants des plateformes en concurrence, aussi.
Mais pour le développeur, je ne trouve pas que réduire la diversité soit une bonne chose.
Après, il lui appartient surtout à lui seul de ne pas se laisser enfermer volontairement.
Dans le cas de petits développeurs indépendants ou de PME, c'est peut-être intéressant qu'une seule personne puisse mettre rapidement les mains dans le cambouis.
Je ne dis qu'il faut rester enfermer volontairement dans un language/jeu d'API, il faut savoir évoluer.
Mais si on dév' sa p'tite app iOS et qu'on veut rapidement un p'tit serveur pour faire aller avec son app, c'est pratique.
Après, comme je considère que lorsqu'on change d'environnement, il y a 3 changements : language (Objective-C, JavaScript, etc.), problématiques lié à l'environnement (qu'est-ce qu'une connexion entrante, l'iPhone ne fait pas de NFC pour les dév's, etc.), et les frameworks (Cocoa, Node.js, etc.).
Le reste, c'est de l'algorithmie, c'est commun, il y a juste des approches différentes parfois.
Si on peut pallier le language pour tester, c'est plutôt pas mal...
Mais c'est quoi cet article ? Le benchmark a était fait par un développeur PHP ou quoi (joke) ?
Nous sommes spécialisés dans le développement à hautes performances avec NodeJS qui n'est pas un choix hasardeux, le benchmark est totalement bidon, la force de NodeJS sont les IO non bloquants, sans oublier le clustering... Bref ça c'est pour le bench (dont même le nombre de requests/s me semble bien faible). Mais en dehors de ça c'est la première fois que je lis "NodeJS connu pour sa lenteur" comment MacG peut nous sortir un truc aussi énorme que ça ? Pour confirmer l'absence de connaissance du rédacteur nous avons un bon passage qui nous explique que NPM cause une lenteur dans NodeJS qui en plus serait bien connue, NPM n'a strictement aucun lien dans l'exécution de NodeJS car c'est un gestionnaire de package (il a pleins de défauts mais pas celui là) c'est la même que pour composer en PHP, c'est comme dire que l'app store fait ralentir un mac/iphone, c'est absurde, encore si vous aviez parlé de CommonJS je me serais au moins posé la question mais là c'est un article grand délire les gars.
@maxbook59
Je n'ai jamais écrit que npm ralentissait node.js. ?
Mais je vois que le sujet est sensible et il se fait tard, alors disons que je n'y connais rien, ça ira plus vite.
C'est vrai mea culpa, c'est nodeJS et lenteur dans la même phrase ça m'a perturbé ^^
@maxbook59
Cela dit, la lenteur, c'était un peu un troll, c'est vrai. Mais c'est aussi que cette solution est lourde malgré tout, même si les progrès des versions en cours de développement semblent indéniables.
Et comme j'ai tenté de le dire, mais d'autres l'ont fait mieux que moi en commentaire, c'est surtout le besoin et le développeur qui fait la différence. Et c'est le résultat qui compte.
De fait le JS n'a jamais été conçu pour réaliser tout ce dont on lui demande aujourd'hui. Ce n'est pas un vrai langage mais un système pour créer quelques interactions à la base puis il a grossi et finit par faire plein de choses qu'on attendait pas de lui. Du coup il se retrouve à la ramasse par rapport à d'autres langages bien conçu dès le départ. À mon avis dans quelques années on n'en entendra plus parler car trop gourmant en ressources et une autre techno plus efficace prendra sa place.
Pages