IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Conception Web Discussion :

Le Web a besoin de plus de langages de programmation pour rivaliser avec le « natif »


Sujet :

Conception Web

  1. #21
    Futur Membre du Club
    Profil pro
    Inscrit en
    février 2013
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : février 2013
    Messages : 16
    Points : 5
    Points
    5
    Par défaut
    Citation Envoyé par super_navide Voir le message
    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.

  2. #22
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 314
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 314
    Points : 13 067
    Points
    13 067
    Par défaut
    Citation Envoyé par Kdence Voir le message
    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.

    Citation Envoyé par Kdence Voir le message
    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.

  3. #23
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    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.

  4. #24
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par Kdence Voir le message
    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.

  5. #25
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 344
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 344
    Points : 9 866
    Points
    9 866
    Par défaut
    Citation Envoyé par Uther Voir le message
    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é.
    One Web to rule them all

  6. #26
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    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.

  7. #27
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 344
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 344
    Points : 9 866
    Points
    9 866
    Par défaut
    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.
    One Web to rule them all

  8. #28
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    4 314
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2002
    Messages : 4 314
    Points : 13 067
    Points
    13 067
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    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).

    Citation Envoyé par DonQuiche Voir le message
    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.

    Citation Envoyé par SylvainPV
    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

    Citation Envoyé par SylvainPV
    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.

    Citation Envoyé par SylvainPV Voir le message
    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

  9. #29
    Inactif  
    Profil pro
    Inscrit en
    février 2007
    Messages
    411
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : février 2007
    Messages : 411
    Points : 0
    Points
    0
    Par défaut
    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"

  10. #30
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2003
    Messages
    70
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 70
    Points : 160
    Points
    160
    Par défaut
    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.

  11. #31
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    449
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 449
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    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.

  12. #32
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 388
    Points
    2 388
    Par défaut
    Citation Envoyé par hunyka Voir le message
    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...

  13. #33
    Membre émérite
    Avatar de Alexandre T
    Homme Profil pro
    Chef de projets AMO
    Inscrit en
    mai 2002
    Messages
    1 213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projets AMO
    Secteur : Transports

    Informations forums :
    Inscription : mai 2002
    Messages : 1 213
    Points : 2 998
    Points
    2 998
    Par défaut
    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
    Alexandre Tranchant
    Chef de projet AMO pour le Cerema.
    Retrouvez mes articles sur PHP et Symfony

  14. #34
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 517
    Points : 10 146
    Points
    10 146
    Par défaut
    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
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  15. #35
    Membre expérimenté
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2003
    Messages : 610
    Points : 1 330
    Points
    1 330
    Par défaut
    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.

  16. #36
    Futur Membre du Club
    Inscrit en
    avril 2008
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : avril 2008
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    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

  17. #37
    Membre du Club

    Inscrit en
    janvier 2011
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 28
    Points : 55
    Points
    55
    Billets dans le blog
    1
    Par défaut Apologie dissumulée du cloud ?
    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 ?"

  18. #38
    Membre habitué
    Profil pro
    Travail non informatique
    Inscrit en
    décembre 2010
    Messages
    98
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Travail non informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 98
    Points : 167
    Points
    167
    Par défaut Quoi ?
    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).

  19. #39
    Candidat au Club
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juin 2012
    Messages : 5
    Points : 4
    Points
    4
    Par défaut
    Cependant, son inconvénient majeur est le fait qu’il ne fonctionne pas en absence de connexion réseau.
    Et Node-Webkit alors?

Discussions similaires

  1. Quel langage de programmation pour le Web est-il plus sécurisé ?
    Par Hinault Romaric dans le forum Général Conception Web
    Réponses: 17
    Dernier message: 30/12/2019, 08h39
  2. Quel langage de programmation pour le Web est-il plus sécurisé ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 14
    Dernier message: 25/04/2014, 12h38
  3. Quel langage de programmation pour des programmes simples ?
    Par Pierre.g dans le forum Langages de programmation
    Réponses: 18
    Dernier message: 22/11/2006, 15h22
  4. Aide sur choix de langage de programmation pour PC et Mac
    Par benouille69 dans le forum Langages de programmation
    Réponses: 4
    Dernier message: 11/11/2006, 19h30
  5. Choix d'un langage de programmation pour une application orientée web
    Par Mick DG dans le forum Général Conception Web
    Réponses: 10
    Dernier message: 12/07/2006, 14h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo