Clause de non-responsabilité : je suis le gars du Webbit
Il y a définitivement beaucoup de chevauchement entre les 3 projets. Lorsque j'ai construit Webbit, je n'étais pas au courant des deux autres - si je l'avais été, il n'existerait peut-être pas, ou j'aurais peut-être passé mon temps à contribuer aux autres.
Je peux parler un peu de Webbit...
Il ne s'agit pas d'un cadre d'entrée-sortie événementiel polyvalent. Ou une boîte à outils de protocole réseau. Ou une abstraction de système de fichiers. Webbit ne fait qu'une petite fraction de ce que font les autres.
Webbit n'est pas non plus un cadre Web complet. Comme Node.JS ou l'API Servlet, il fournit les blocs de construction de base pour construire des cadres de plus haut niveau, mais laisse cela à des projets externes (tels que Webbit-EasyRemote ou Webbit-REST ).
L'objectif de Webbit est d'être un serveur HTTP et WebSocket simple, intégrable et non bloquant.
Comme elle adopte l'approche "faire une chose et la faire bien", elle a également été conçue pour être utilisée en conjonction avec d'autres bibliothèques. Elle permet de passer des exécuteurs externes java.util.concurrent.Executors et évite les contextes de threads singletons, ce qui la rend particulièrement bien adaptée à l'intégration avec des bibliothèques de concurrence de type Actor telles que Jetlang y HeySync .
Vert.x et Deft apportent des cadres complets pour un développement de style Node prêt à l'emploi. Webbit est juste un petit outil qui peut aider à activer HTTP/WebSocket dans votre application. Ces deux outils sont nécessaires et c'est en fonction de vos besoins (et de votre style personnel) qu'il convient de choisir celui qui est le plus approprié.