Discussion :

[Kdence]

Je pense qu'il faut pouvoir coder en java dans une page web(avec toute les règle de sécurité qu'il faut comme pas d’accès aux fichier locaux , pas de possibilité d’exécuter des programmes locaux ), javascript c pas typé donc très difficile à maintenir et moins puissant qu'un langage typé ( lien dynamiqe à l'execution ), en plus javascript n'est Multi-thread, a l'heure des
multicoeur c un défaut de taille

Je ne suis pas vraiment d'accord...

Le fait que Javascript ne soit pas typé, et de ce fait plus flexible, ne le rend en aucun cas moins puissant! Surtout que c'est faux!
En vérité, ce qu'offre Javascript, ce n'est ni un typage fort, ni un typage faible, mais un typage dynamique...

Plus difficile à maintenir? Si on code avec les pieds et que l'on est mal organisé, n'importe quel langage devient difficile à maintenir.

Les WebWorkers ont rendu le Multi-Threading possible.

Un peu de lecture -> JavaScript : un langage fortement typé
êtes-vous prêt à l'accepter ?

En ce qui concerne ce monsieur Bracha...

Je trouve ridicule cette façon de faire passer une pub incognito... Oui Dart c'est de toi dont je parle...

Le premier atout du développement Web par rapport au développement natif est le fait que les applications Web peuvent s’exécuter sur plusieurs plateformes et n’ont pas besoin d’être installées. Cependant, son inconvénient majeur est le fait qu’il ne fonctionne pas en absence de connexion réseau.

Zut alors... Et moi qui m'amusait si bien à créer des petits jeux offline... Ho wait... Mais en fait c'est possible... Et ça tient en un mot -> LocalStorage (bon ok, ça en fait deux)...

Actuellement, le Web repose essentiellement sur le langage de programmation JavaScript qui est cependant, selon Bracha, déficient dans plusieurs scénarios, notamment la possibilité d’utiliser l’application hors ligne. De plus, du fait que le langage soit normalisé, son évolution est lente. « JavaScript est basé sur la norme EcmaScript, qui peut prendre des années pour être mise à jour. Il devrait être plus facile de faire ces choses », regrette celui-ci.

Et dire qu'on gueulait tous sur IE à l'époque où il ne respectait aucun standard... Ils veut la même choses pour JS?

Pour conclusionner...
Je pense que le Web est déjà suffisamment riche mais que la concurrence (et par conséquent, l'évolution) est toujours bonne à prendre.

[Uther]

Le fait que Javascript ne soit pas typé, et de ce fait plus flexible, ne le rend en aucun cas moins puissant! Surtout que c'est faux!
En vérité, ce qu'offre Javascript, ce n'est ni un typage fort, ni un typage faible, mais un typage dynamique...

Sauf que la notion de puissance d'un langage c'est un terme foutoir qui ne veut absolument rien dire.
Parle-on de la vitesse d’exécution du code? Des capacités à construire des abstractions poussées? De faire des opérations complexes en peu de ligne de code? De la capacité de contrôler précisément l'utilisation des ressources?...
Sachant que toutes ces notions qui peuvent faire la force d'un langage sont souvent contradictoires.

Donc je ne saurais dire si JavaScript est "puissant", mais il n'est clairement pas la meilleure solution à tous les besoins que peut avoir un programmeur.

Plus difficile à maintenir? Si on code avec les pieds et que l'on est mal organisé, n'importe quel langage devient difficile à maintenir.

Et si on a un coup de crayon sûr, on n'a pas besoin de règle pour tracer une ligne droite. Il n’empêche qu'avoir des outils qui vous aident à faire les choses bien c'est utile même aux meilleurs.

[DonQuiche]

Le web n'a pas besoin d'un langage de plus. En fait les standards du web ne devraient même pas contenir un langage comme JS selon moi, mais seulement fournir une base rapide sur laquelle chacun pourra bâtir n'importe quel langage.

Tout ce dont le web a besoin c'est d'un bytecode neutre et de bas-niveau, quelque chose entre l'assembleur et le bytecode Java. Les contraintes sont :
* Isolation mémoire. Si possible par la preuve plutôt que par le logiciel.
* Exposition de mécanismes de consommation des API du navigateur. Ce qui impose sans doute de définir un système de typage minimaliste que le langage devra pouvoir fournir et consommer.
* Efficacement compilable sur toute architecture matérielle, en prévoyant les évolutions matérielles à venir (très nombreux coeurs, coeurs spécialisés, différentes organisations du cache et modèles mémoires, ...)

Autant dire que PNaCl est un excellent candidat.

[DonQuiche]

Plus difficile à maintenir? Si on code avec les pieds et que l'on est mal organisé, n'importe quel langage devient difficile à maintenir.

Bien sûr ! Un code dynamiquement typé écrit par cent personnes sur dix ans est aussi facile à maintenir qu'un code statiquement typé dès lors que tu as :
* Écrit pour chaque fonction les tests unitaires vérifiant tous les problèmes de typage pouvant survenir avec chaque argument.
* Documenté le type de chaque argument en commentaire
* Ajouté à chaque argument et variable des préfixes permettant de connaître le type attendu.
* Augmenté le budget pour faire tout ça.

Comme quoi c'est pas plus compliqué que de simplement ajouter un identifiant de type devant chaque variable, c'est sûr.


Et encore... Parce que le vrai bon codeur (celui qui "ne code pas avec les pieds"), lui, a des pouvoirs psychiques. Donc il peut faire du code JS maintenable sans rien faire de tout cette liste. On le reconnaît au fait que cinq ans plus tard, quand il retombe sur son code, il s'est tellement amélioré entretemps qu'il préfère encore tout réécrire.

[SylvainPV]

asm.js a le mérite de se baser sur Javascript qui est déjà normalisé et permet d'avoir un code aussi optimal que possible avec un langage qui n'est pas du tout prévu pour cela. Cela dit, ça reste un affreux bricolage, inutilement lourd a télécharger et compiler et optimiser par rapport a un bytecode qui serait prévu pour.

Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html

L'idée d'un subset optimisé de JavaScript n'est pas un "affreux bricolage", je trouve ça au contraire très intelligent de ne pas jeter à la corbeille le travail de normalisation effectué sur JavaScript pour une bête question de performance. Etant donné que le langage a beaucoup évolué entre ses débuts et ES6, définir des subsets du langage permettrait de pousser à la modernisation du code ou de cerner un certain paradigme de développement. Et les progrès d'asm.js sont très impressionnants, la démo Unreal Engine 4 m'a soufflé.

[DonQuiche]

Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html

Ces arguments ne tiennent pas :

* L'auteur affirme qu'aucun bytecode n'est universel. Mais ce qui vaut pour le bytecode vaut pour JS. Car si les deux sont Turing-complet, tout ne peut pas être accompli aussi rapidement que possible dans les deux langages. Pour ça il faut se rapprocher de la logique de la machine, ce qui n'est pas possible avec JS. D'où mon insistance pour un bytecode de bas niveau.

* L'auteur affirme que JS est suffisamment bon comme ça, que les compilateurs sont de plus en plus optimisés ma bonne dame... Et bien non ils ne le sont pas, l'écart avec le C est de 1:5 à 1:10 (les ratios de 1:2 mis en avant le sont après optimisation spécifique pour tel benchmark ou tel site). Et ça stagne désormais. Le jour où un algorithme saura optimiser parfaitement le JS, un algorithme saura écrire un programme tout seul depuis les spécs. Le JS ne suffit pas et ne suffira pas, il faut revenir à un niveau inférieur. Le mieux qu'on a c'est asm.js, qui est un bytecode encodé en JS ! Plus lourd tu meurs, bonjour le surcoût au chargement.

* L'auteur affirme qu'il y aurait avec un bytecode des problèmes de versions, ce qui serait moins souvent le cas avec un langage. Je trouve ça difficile à accepter et il ne fournit aucun argument.

[SylvainPV]

Je ne voudrais pas faire dévier le sujet et relancer un débat qui date de plusieurs années. J'ai retrouvé le sujet HackerNews sur lequel j'étais tombé à l'époque : https://news.ycombinator.com/item?id=1893686 ; Il y a là à peu près tous les arguments pour ou contre. Sous réserve que ce soit faisable (ce que beaucoup de gens plus calés que moi semblent douter) ce qui m'embête le plus avec le bytecode, c'est le fait de ne plus pouvoir lire le code côté client. Renoncer à ça pour une question de performance alors qu'on voit Epic Citadel tourner à 60fps, ça me paraît être un mauvais choix.

[Uther]

Le web n'a pas besoin d'un langage de plus. En fait les standards du web ne devraient même pas contenir un langage comme JS selon moi, mais seulement fournir une base rapide sur laquelle chacun pourra bâtir n'importe quel langage.

C'est déjà le cas, Le W3C ne normalise absolument pas le JavaScript : c'est l'ECMA qui s'en occupe. Il définit juste des API standardisées (et typées contrairement a ce que beaucoup croient) qui sont utilisable par les langages de script.
Théoriquement rien n’empêche d'utiliser un autre langage. Dans la pratique, seul JavaScript s'est imposé et est devenu la norme de facto. Ça à ces avantages (compatibilité) et ces inconvénients (pas adapté a toutes les situations).

Tout ce dont le web a besoin c'est d'un bytecode neutre et de bas-niveau, quelque chose entre l'assembleur et le bytecode Java. Les contraintes sont :
* Isolation mémoire. Si possible par la preuve plutôt que par le logiciel.
* Exposition de mécanismes de consommation des API du navigateur. Ce qui impose sans doute de définir un système de typage minimaliste que le langage devra pouvoir fournir et consommer.
* Efficacement compilable sur toute architecture matérielle, en prévoyant les évolutions matérielles à venir (très nombreux coeurs, coeurs spécialisés, différentes organisations du cache et modèles mémoires, ...)

Autant dire que PNaCl est un excellent candidat.

Je suis assez d'accord sur le constat, mais pas sur la conclusion. pNaCl a beau partir d'une très bonne idée, il a pour moi des défauts rédhibitoires qui font qu'il ne pourra pas être utilisé de manière standard par tous en l'état :
- Au niveau du bytecode pNaCl s'appuie sur un sous-ensemble du LLVM IR qui n'est pas normalisé et que les gens de LLVM n'envisagent pas vraiment de le faire.
- Au niveau de l'interface pNaCl se repose sur la PPAPI de Google, là encore non normalisée, qui doublonne à presque tous les niveaux les API déjà existante définies par le W3C.

Un bytecode pour JavaScript a été de nombreuses fois envisagé, mais les inconvénients dépassent les avantages. Il y a cet article qui fait le tour du sujet : http://www.2ality.com/2012/01/bytecode-myth.html

Il y a énormément de choses à redire à cet arcticle, pour faire court:

There is no single bytecode to “rule all languages” :

C'est vrai, aucun bytecode n'est parfait et capable de couvrir de manière optimale tous les langages et toutes les architecture, même les gens qui travaillent sur LLVM en conviennent. Ceci dit, si on souhaite avoir un socle commun, un bytecode bien pensé sera bien évidement bien plus efficace.
On voit bien sur ce point que LLVM est beaucoup plus efficace que la JVM. Et qui sont eux même bien plus adaptés qu'un langage, qui n'a jamais été pensé pour servir en tant que tel.

There is no common ground between browsers:

Sans objet dans le cas présent. Le but est justement de parvenir à une représentation intermédiaire(IR) bien définie, Il peut ainsi tout à fait y avoir de la place pour divers compilateurs langage->IR et des moteur interprétant et/ou compilant l'IR en AOT ou JIT

Bytecode is inflexible:

Ni plus ni moins que le Javascript

L'idée d'un subset optimisé de JavaScript n'est pas un "affreux bricolage", je trouve ça au contraire très intelligent de ne pas jeter à la corbeille le travail de normalisation effectué sur JavaScript pour une bête question de performance. Etant donné que le langage a beaucoup évolué entre ses débuts et ES6, définir des subsets du langage permettrait de pousser à la modernisation du code ou de cerner un certain paradigme de développement. Et les progrès d'asm.js sont très impressionnants, la démo Unreal Engine 4 m'a soufflé.

asm.js repose sur une idée certes fort ingénieuse et ces performance sont étonnamment bonnes quand on sait sur quoi cela repose, mais ça reste quand même du bricolage, qui n'atteindra jamais le niveau d'un bytecode bien pensé pour cela.

ce qui m'embête le plus avec le bytecode, c'est le fait de ne plus pouvoir lire le code côté client. Renoncer à ça pour une question de performance alors qu'on voit Epic Citadel tourner à 60fps, ça me paraît être un mauvais choix.

Tu as essayé de regarder le condesource d'EpicCitadel?
Un bytecode décompilé sera certainement bien plus lisible que de l'asm.js

[GTSLASH]

celui-ci a affirmé que les applications Web pourraient un jour dépasser les applications Desktop (natives) en performance, en fonctionnalités et en facilité d’utilisation si les développeurs ont plus de choix dans les langages de programmation Web qu’ils peuvent utiliser.

J'en doute TRES fort. L'avantage du mode "in browser" est que c'est compatible avec tous. Et c'est justement cela qui freine la performance selon moi et que les performance natives seront toujours meilleur.

La ou je suis d'accord c'est que pour le moment on est plus productif a développer en natif qu'en HTML/JS. Ca c'est certain. Pourtant tout est OpenSource et il ne devrai donc plus qu'a...

A part Google avec AngularJS les autres (Microsoft, Apple, Oracle) préfère investir dans le natif car ca leur fera vendre leurs produits. Et quand on sait que Google est surtout actif sur le web et est donc sur un autre Business Model c'est compréhensible qu'il veuille que Html/Js se développe. Quel serait l'interet de Microsoft ou Apple de fournir des outils pour développez des applis compatible chez leurs concurrent ?

Encore un petit point faible de l'OpenSource. Je suis d'avis que vouloir faire quelque chose de compatible partout est un frein au performance et a la productivité. Mais comme dirai l'autre ____ de blonde "ce n'est que mon avis"

[iolco51]

Quand on voit a quel point les quelques moteurs de navigateurs (qui se comptent désormais sur les doigts d'une demi main) ont du mal a supporter un seul langage a peu près correctement et avec cohérence d'un navigateur a l'autre...
Google propose des idées stupides, <mode troll>mais contrairement a Apple avec leur remplaçant d'objective C </mode troll>, Google n'est pas stupide du tout.

Des nouveaux langages de Google, pour lesquels donc chome/webkit sera le premier exécuteur et la meilleure implémentation, avec en but non déclaré la mise a mort de Firefox et IE.

[super_navide]

Je comprend que le typage dynamique de javascript plait , c sur qu'au début on est plus productif,mais à la longue ils est pénible , il n'offre pas tous l'outil de refactoring de java.
Quand on développe de tres gros site en général on utilise pas directement javascript, je développe actuellement avec GRAILS, toutes les IHMS WEB sont refaite avec cette techno , et on fait pas bcp de dev en javascript on utilise en peut de jquery mais c tout.
De toute manière le non typé les plus lent car avant chaque opération il faut vérifier le type (ceux qui sont pas convaincu je leur laisse le soin d'implémenter leur propre langage non typé et ils verront par eux même ).
De toute façon java est le langage le plus répandu dans le monde (après cobol je pense ).
Sur la légo NXT on faire du java ( lejos ).
Donc il est claire que si les applis WEB veulent passer à la vitesse supérieur il faut que java s'intègre directement dans les pages web.

[Traroth2]

Dévorés par les galeries d’applications propriétaires dixit un employé de Google. Tu ne vois pas l'ironie ?

Si c'était Apple, je comprendrais l'ironie. Mais Google a toujours laissé la possibilité d'utiliser d'autres galeries d'application que Play, et même d'installer des applications sans passer par une galerie...

[Alexandre T]

Bonjour,

Ah bon, il y a encore des instants où on n'a pas de connexion Internet ?

Super native : c'est justement parce que java est très gourmand en mémoire et CPU que les sites web sont en majorité en PHP.

http://cppcms.com/wikipp/en/page/benchmarks_all

[sjrd]

Je ne dirai qu'une seule chose: il existe déjà des tas de langages que l'on peut utiliser pour développer des applications browser-based (aka Web App):
List of languages that compile to JS

[smarties]

Côté client, il faudrait un langage compilé (nativement ou en bytecode)... Je rejoins donc ce qui a été dit.

Il faudrait aussi un système d'autorisation comme quand on installe des application Android afin d'accéder à des fonctionnalités liées au PC utilisateur.

[Sergeobee]

Bah c'est pas compliqué!

Google essaie d'imposer son empreinte partout, y compris dans des domaines où il est très minoritaire. Avant Google, c'était de la recherche. Aujourd'hui ils sont partout. Côté web, regardez comment ils ont conditionné la structure du code, soi-disant pour le référencement et ils ont tenté d'imposer leur langage Go (échec et ils veulent). Maintenant, ils veulent détruire ce qui marche TRÈS bien en matière de langages web (serveur comme client) pour imposer par la puissance financière, publicitaire, voire via des contraintes sur leurs plateformes, afin de favoriser ses services.

J'en ai marre que dès qu'une entreprise a du succès, elle se mue en ogre privatif de l'essor des autres (Microsoft, Apple, Samsung sont aussi de la partie).
Pitoyable!

Participez à l'Open Internet Project
http://fr.openinternetproject.net

[hl037]

Bonjour,
Je ne me suis pas intéressé au titre " Le Web a besoin de plus de langages de programmation pour rivaliser avec le « natif » "... Mais plutôt aux justifications données qui me paraissent un poil aberrantes.
Tout d'abord quelqu'un peut-il me dire comment une application web peut-elle être plus performante qu'une application native et sans être installée ?
...C'est le même processeur qui exécute les deux de une, et de deux actuellement, ce sont bien des applications natives qui interprètent/exécutent du code/byte-code... Au mieux, les processeurs de demain auront une interface unifiée et standardisée leur permettant d'exécuter directement un langage machine unique (à l'instar de la JVM et de certains processeurs capables d'exécuter directement du JAVA), et quoi qu'il en soit, ces applications pourraient alors être qualifiées de "natives" puisque compilées pour la plate-forme (même si celle-ci était unique à l'avenir...).
Revenons au possibilités actuelles : avoir un langage compilé sur la machine. Il en existe énormément, pourquoi aller en inventer d'autres alors ? Mais après tout l'idée étant de les rendre disponibles par le web, savoir si il faut en inventer un ou pas est au-delà de la porté de mon commentaire. Quoi qu'il en soit, un tel langage nécessitera tout de même le téléchargement des sources pour les compiler (ce qui ne résout d'ailleurs pas la faiblesse du JS qui même minifié permet la rétro-ingénierie). Ce point engendre deux absurdités : la première, c'est que je ne vois pas trop de différences entre "compiler" et "installer"... Après tout, ou parle là de ce qu'on fait tout (enfin...) les jours : aller chercher une application, la télécharger et l'installer... Certes, le fait que ce soit fait automatiquement peut simplifier la vie de l'utilisateur, mais là encore, avec tous les stores et autres qui existent aujourd'hui, on y est déjà...

...On en arrive donc au sujet 'sensible' : en fait, le seul véritable argument là-dedans, c'est la non-persistance de l'application, et ÇA c'est magique : il faut se connecter à internet pour pouvoir l'utiliser. Et c'est ÇA le point clef. Mais pourquoi cela intéresse-t-il tant les industriels ces histoires de cloud et l'idée que l'utilisateur n'ait au final qu'une machine sans aucun moyen de stockage ?
Parce que les grosses firmes ont fait une énorme erreur dès le début de l'informatique : une fois une application achetée, il n'y a plus besoin de donner de l'argent à son éditeur, elle marche toute seule ad vitam æternam. À une époque, cela ne posait pas trop de problèmes grâce à la loi de Moore : les performances doublent toutes les X années, et il faut sans cesse renouveler toutes les machines et les programmes qui sont "outdated". Les entreprises pouvaient donc survivre en améliorant les performances et les possibilités de leurs produits.
Aujourd'hui, la loi de Moore s’essouffle un peu... Le développement devient plus complexe et les produits déjà très aboutis. Il suffit de regarder le premier programme que la plupart des gens installent s'il ne l'est pas déjà : Windows. Regardez le nombre d'entreprises qui ont hésité pour passer à Windows 7 / 8 car XP leur fournissait déjà tout ce dont ils avaient besoin... (ne pas partir hors sujet à ce propos, un changement s'impose aujourd'hui pour des raisons de sécurité) Et l'image de Microsoft s'est nettement dégradée en voulant encore innover pour toujours vendre leurs produits... Résultat ? Ils ont remis le menu "démarrer" dans Win 8.1 et se sont mis à faire aussi du matériel avec Surface.
Google et bien d'autres ne veulent pas faire la même erreur. Leur secret, c'est que ce n'est pas sur l'OS qu'ils vont faire du chiffre. Celui-ci, une fois stable et suffisamment portable pour s'adapter à la plupart des architectures n'a pas vraiment besoin d'être modifié. On mise donc sur les applications, et leurs stores.
L'idée derrière tout ça et qu'acheter l'application ne suffit pas. Si on pouvait les louer, on gagnerait vraiment beaucoup d'argent ! Seulement comment louer une application installée sur la machine et qui marche ad vitam æternam ? Plusieurs solutions existent :
- Faire en sorte qu'au bout d'un certain temps, il faut une nouvelle clef d'activation (à acheter biensîr). Cette solution a l’inconvénient que l'utilisateur est habitué aux programmes qu'on achète définitivement... La pilule aurait du mal à passer aujourd'hui. Outre l'avis de l'utilisateur, toute application achetée/louée est vulnérable au cracking, donc c'est un mauvais plan globalement. (Sauf pour les anti-virus et certains milieus se renouvelant très rapidement)
- L'utilisateur paye (ou pas) son application, mais si il veut du contenu supplémentaire (par exemple dans un jeu vidéo une arme plus puissante) il devra alors payer. C'est ce qui arrive en masse sur les réseaus sociaux et sur Android. Certaines familles se sont d’ailleurs faites piéger à ce "jeux"
Quoi qu'il en soit, ça reste des applications installées assujetties à la piraterie...
En fait, la solution (presque) idéale serait que l'application ne soit pas en local, mais qu'il faille se connecter au réseau et pour aller encore plus loin, qu'elle ne s'exécute même pas sur la machine du client qui serait en conséquence un simple écran qui sert juste pour les entrée/sortie. À partir de là, il faudrait payer un abonnement pour pouvoir utiliser l'application, et c'est le Jackpot !
L’ironie, dans l'histoire, c'est que cette solution va convenir à presque tout le monde (sauf certains comme moi) :
Toutes les entreprises y gagnent (beaucoup) car pour les hébergeurs de ces applications, ils font payer aux éditeur un droit pour qu'ils puissent les héberger. Les éditeurs font payer un abonnement aux utilisateurs, leur permettant de faire un bénéfice (là encore très important) par rapport à ce qu'il payeront à l'hébergeur. De plus, ils récolteront des données sur leurs utilisateurs, ce qui ravira les agences gouvernementales qui cette fois pourront vraiment obtenir toutes les informations et données que possède une personne. Ces informations pourront aussi être revendues à des agences de marketing qui seront elles aussi ravies. Et l'utilisateur au final ? Il sera aux anges (de la téléréalité ? [à méditer]) ! Car on lui fournira une super tablette pour quelques euros voir gratuite... Après tout, ce ne serait qu'une batterie, et un écran tactile avec un émetteur/récepteur Wifi, Il n'aura plus besoin de clef USB, les données sont dans le "nuage", il pourra se connecter partout (sauf pour appeler à l'aide au fond d'un gouffre... et encore), il n'aura plus peur qu'on lui vole son téléphone quisqu'il n'est pas cher... Et il ne payera alors que ce dont il aura besoin.
Une autre ironie est qu'il achète du coup sa prison et les caméras braquées sur lui...

Voilà ce que je comprend par " Le Web a besoin de plus de langages de programmation pour rivaliser avec le « natif » ". Par ailleurs, ce titre est lui-même est presque subliminal... Moi, ma question, c'est plutôt : "Faut-il que le web rivalise avec les applications natives ?"

[RedGuff]

Bonjour.
"JavaScript qui est cependant, selon Bracha, déficient dans plusieurs scénarios, notamment la possibilité d’utiliser l’application hors ligne. " : JavaScript fonctionne parfaitement hors ligne, c'est le PHP qui ne peut pas s'exécuter facilement hors ligne (il faut un serveur local, type EasyPHP ou Xamp).

[Invité]

Cependant, son inconvénient majeur est le fait qu’il ne fonctionne pas en absence de connexion réseau.

Et Node-Webkit alors?