Ça dépend ce que fait le programme et comment il est codé.Envoyé par PatrickNice
De plus, rien n’empêche de faire du code "lent", quelque soit le langage.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Ça dépend ce que fait le programme et comment il est codé.
De plus, rien n’empêche de faire du code "lent", quelque soit le langage.
Ca veut dire qu'on aura accès au code source ???
Ca, ça serait une révolution... Où alors ils ont trouvé un bon moyen d'obfusquer le code...
Passons outre ce petit troll du dredi matin.s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation
Réécrire Office en javascript permet :
- de proposer le soft via le web
- de proposer la même version en soft (electron, etc)
- de décrire l'interface en html/CSS
On en dira ce qu'on veut, mais aujourd'hui pour faire des interfaces simplement, ce sont les moteurs de rendu web qui sont les plus pertinents : interface avec un design sur mesure, possibilité de dyamiser le tout, nombre de personnes connaissant le js, ...
Donc développer des softs en JS pour bureau ne me paraît pas étonnant.
Après, le JS reste un langage assez ignoble (mon humble avis), avec ses nombreux défauts. Les langages bas niveau (relativement) tels que C, C++, C# et autres Java vont rester majoritaires, notamment parce qu'ils permettent de créer des exécutables assez légers (avec Electron on se trimballe un moteur de rendu par logiciel), qui prennent beaucoup moins de place en mémoire (bon ça dépend, mais si mon éditeur de text pesait aussi lourd que Chrome pour éditer un fichier, je serais assez énervé) et sont plus rapides/réactifs.
Mais bon, parfois un programme écrit en JS peut être beaucoup plus rapide qu'un petit soft écrit en C-- (C avec des classes).
@Cxx-waves: ta réponse est assez subjective, à mon avis. Je me permets de te donner un point de vue légèrement différent
C'est déjà le cas, avec Office 365 ; mais je t'accorde que quitte à faire du web, c'est mieux d'être en full web.
Là par contre, je ne suis pas d'accord, quitte à faire du desktop, autant ne pas faire du web et utiliser une techno plus adaptée. Voulais-tu plutôt parler du cross-platform ?de proposer la même version en soft (electron, etc)
Ca, c'est un fait, pas un argument.de décrire l'interface en html/CSS
Bon, là, je ne vais pas discuter, c'est très subjectif et ça dépend beaucoup des compétences de chacun. Mais je connais pas mal de "vieux" développeurs qui regrettent le ... WinForms ! En effet, pour eux, c'est ce qu'il y a de plus simple et fiable pour développer des interfaces graphiques. Et honnêtement, suivant le niveau d'exigence que tu te fixes, ce n'est pas forcément faux.On en dira ce qu'on veut, mais aujourd'hui pour faire des interfaces simplement, ce sont les moteurs de rendu web qui sont les plus pertinents : interface avec un design sur mesure, possibilité de dyamiser le tout, nombre de personnes connaissant le js, ...
Donc développer des softs en JS pour bureau ne me paraît pas étonnant.
L'OBJET VAINCRA !!!!! (dixit un type qui fait aussi de la programmation fonctionnelleMais bon, parfois un programme écrit en JS peut être beaucoup plus rapide qu'un petit soft écrit en C-- (C avec des classes).)
Peros j'ai déjà eu à écrire des UI en :Que pensez-vous de l’approche adoptée par Microsoft ?
- HTML/CSS/JS
- QT
- MFC
- Swing
- JavaFx
- Android
et très clairement le combo html/css est le plus facile à mettre en oeuvre dès qu'on à besoin de personnaliser son UI. On peut aller très loin sans difficulté particulière , là ou d'autre demanderais des surcharge de classe et autre joyeuseté.
Pas étonnant donc que l'accent soit mit sur cette techno quand c'est possible pour réaliser des UI.
Je dirais qu'en QML est encore plus simple à écrire
Je suis tout à fait d'accord avec ça, dans les langages non typés c'est incontournable pour éviter des erreurs et ne pas mettre des try catch partout... Non ??!! Les humains ne codent pas tout sans jamais aucune erreur que je sache... même parmis une même entreprise, voire team.s'amuser à perdre inutilement plus de 20% de puissance pour des vérifications de types à l'exécution et se rajouter de potentiels ambiguïtés et bugs facilement évitables avec des vérifications de type à la compilation
Donc vérifications, donc plus de code, donc moins vite.
Mais bon Microsoft est une entreprise, et le but d'une entreprise en économie est de faire de l'argent, donc c'est normal. Tant qu'on ne voit pas la différence entre un clic droit en C++ à 0.02sec et un clic droit en js en 0.03sec...
Ce n'est pas qu'une question de robustesse du code, tu as aussi une question d'allocation mémoire, qui est bien plus efficace dans les langages typés.
Du PHP sous Symfony et de l'Angular 6 (en TypeScript) principalement.Je n'ai jamais vu un Troll pareil dans un forum informatique. Tu sors de quelle planète franchement ? Tu fais du cobol objet ? Du html 1.0 avec du ColdFusion ?
Et tu peux te tuer en voiture même en mettant la ceinture ... ce n'est pas un argument valable pour ne pas la mettre.Tu peux faire des choses dégueulasses avec n'importe quel langage !
Ce n'est pas impossible ... tant que l'application est très simple.C'est quoi cette idée que c'est impossible de faire du propre en procédurale ?
Amusant cette manie de vouloir refaire les IHM en language de script, que ce soit en Javascript ou autre.
Cela facilite grandement le hacking puisqu'une fois que l'on peut injecter du code dans le thread principal (ce qui est assez simple aujourd'hui), il n'y a plus de cloisonnement des processus et on pourra donc piloter tout Office via Javascript.
Déja que le fichiers offices sont des zip et que les mot de passe y sont en clair ^^
Ma page Developpez - Mon Blog Developpez
Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
Votre post est résolu ? Alors n'oubliez pas le Tag
Venez sur le Chat de Développez !
Tu m'étonnes, il suffit d'appuyer sur la touche F12 et de cliquer sur l'onglet "console", un vrai scandale !
C'est qui "on" ? Qui est l'attaquant et qui est la victime dans ton scénario ?
Autre question qu'est-ce que tu appelles le cloisonnement des processus et en quoi 2 processus Node seraient plus ou moins cloisonnés que des binaires .NET ou des jar exécutés sur la JVM ?
Pour la JVM, je ne connais pas les détails de la gestion mémoire. En .Net, en effet, chaque process a un pool de ressource dédié et cloisonné, non accessible par d'autres process (je simplifie, mais l'idée est là).
Je suppose que ddoumeche veut dire qu'en JS, la gestion de la mémoire et des process sera gérée par le navigateur / l'interpréteur JS, donc ce cloisonnement ne dépendra plus de la plateforme du langage (JVM, CLR, etc.), mais d'un acteur tiers qui sera potentiellement non sécurisé.
Avec un navigateur oui, mais c'est aussi faisable pour un exécutable lambda : une l'injection de DLL (ce qui n'est en réalité guère compliqué) permet d'obtenir une référence vers la librairie de l'interpréteur javaScript de l'exécutable cible : cette dll va alors pouvoir utiliser l'API pour injecter du code sous forme de chaîne de caractère via un executeScript(), avec des callback divers, ou redéfinir du code vu que tout est dynamique.Tu m'étonnes, il suffit d'appuyer sur la touche F12 et de cliquer sur l'onglet "console", un vrai scandale !
Ce qui n'est pas fondamentalement différent des virus de mail en Visual Basic que l'on a pu connaitre il y a fort longtemps. J'ai récemment vu le cas d'un malware utilisant LUA pour infecter un jeu en ligne, pourtant protégé. Sidérant.
"On" étant le hacker.
Je voulais dire que le cloisonnement entre modules, API et code ne devait pas exister en Javascript voir dans les langages de script en général.
Java et .Net (de mémoire) ont un Security Manager limitant entre autre l'accès au système de fichier.
De plus sur un serveur web (Tomcat par exemple), tu ne peux pas accéder au code et aux ressources d'autres applications, sauf éventuellement en passant par l'instrumentation (JMX) qui doit avoir été explicitement autorisée par l'administrateur système.
Et Java a implémenté les modules en version 9 pour remettre un peu d'ordre, sachant qu'auparavant tu pouvais (et tu peux encore) appeler du code non public des librairies standard.
J'imagine que .Net utilise des mécanismes de sécurisation similaires. Et il y a eu énormément de mise à jour de sécurité sur ces deux plateformes depuis quelques années.
Mais dans Nodejs, il y a beaucoup de failles et il n'y a aucune sécurité, car le security manager de V8 est désactivé. Certes la majorité de ces failles est inexploitable ... pour l'instant et tant que personne n'a trouvé moyen de les exploiter.
Et comme dit plus haut, on peut redéfinir les fonctions des modules voir les fonctions natives via un simple eval() (imaginez qu'un assaillant redéfinisse mysql.connect). Imaginez les dégats que risquent de faire un vers
Donc pour l'instant, il vaut mieux le savoir et faire tourner son Node.js dans un espace cloisonné comme un container, en le gardant à l’œil et sans lui donner trop de responsabilités.
Je suis un peu plus circonspect sur ces applications embarquant des moteurs de javascript de partout.
Répondre avec citation
Partager