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

Affichage des résultats du sondage: Les développeurs devraient-ils tous apprendre JavaScript ?

Votants
44. Vous ne pouvez pas participer à ce sondage.
  • Oui, les développeurs devraient tous apprendre JavaScript

    12 27,27%
  • Non, il n'est pas nécessaire pour tous les développeurs d'apprendre JS

    31 70,45%
  • Je n'ai pas d'avis

    1 2,27%
  1. #21
    Membre éprouvé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    474
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 474
    Points : 1 095
    Points
    1 095
    Par défaut
    Citation Envoyé par Iradrille Voir le message
    Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.
    Exactement

  2. #22
    Membre éprouvé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    474
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 474
    Points : 1 095
    Points
    1 095
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Dans la plupart des cas, oui, malheureusement.

    Non pas parce que c'est un langage globalement bon (il a des aspects très mauvais et d'autres meilleurs) mais parce qu'il est

    • Omniprésent
    • Suffisamment éloigné des autres dans son approche pour que quelqu'un qui a seulement été formé aux langages orienté objet "classiques" fasse plus de mal que de bien en essayant de l'utiliser.
    Plus 1000 ;-)

  3. #23
    Invité
    Invité(e)
    Par défaut
    Je ne connais rien à Javascript mais j'ai bien ri en lisant ce commentaire sur la page originale :

    Your thesis can be summarized as follows: “eat shit, millions of flies can’t be wrong”.

  4. #24
    Rédacteur/Modérateur
    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 297
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 297
    Points : 9 638
    Points
    9 638
    Par défaut
    Vu que quasiment tous les langages peuvent être compilés en JS, ce n'est pas tant le langage qui importe. Si le projet WebAssembly se concrétise, on va sans doute voir encore plus de diversité.

    Pour ceux qui ne l'ont pas encore vu, cette vidéo donne un paysage assez comique des 20 prochaines années et de la fin de JS: https://www.destroyallsoftware.com/t...-of-javascript
    One Web to rule them all

  5. #25
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 614
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 614
    Points : 3 616
    Points
    3 616
    Par défaut Oui car Node.js (et Electron)
    J'ai répondu "oui" à cause de Node.js. Node.js est principalement un interpréteur JavaScript, et ce bien avant d'être une technologie pour du Web côté serveur. De ce fait il permet à JavaScript de sortir du Web, et en particulier du Web côté client. Les modules de base de Node.js étendent également les possibilités de base du JS, lui dont les fonctions de base sont si limitées dans nos navigateurs. Des frameworks comme Electron (anciennement Atom Shell) basés sur Node.js lui permettent même d'être utilisé pour des applications classiques.

    Par conséquent, connaître JS permet très souvent de faire un bout de programme utile dans un domaine de programmation donné (sauf cas particuliers genre systèmes embarqués). D'où l'utilité de le connaître. Ce sera rarement la meilleure techno, mais au pire on aura toujours JS dans sa panoplie de développeur pour pouvoir faire des choses. Après c'est sûr qu'il y a d'autres technos plus indiquées pour faire mieux, mais ces technos là vont souvent être spécifique au domaine.

    Le "non" était de mise il y a quelques années, quand le JS était cantonné au Web côté client. Mais la donne a changé depuis. Les technologies autour de JS ont tellement évolué autour de lui et cela en fait désormais un langage passe-partout. Python pourrait faire la même chose que JS en mieux mais il n'est pas utilisable pour du Web côté client. Donc c'est oui pour JS.

    Citation Envoyé par grunk Voir le message
    La quantité d'alternative à javascript (typescript , coffeescript, Dart , asm , AtScript et j'en passe) est symptomatique de l'état de JS. Si le langage était si bon il n'y aurait pas besoin de passer par une alternative (qui au final génère du JS , mais abstrait tous les truc chiant de JS).
    Un non initié qui débarque la dedans va vite avoir du mal à comprendre pourquoi.
    C'est pourtant simple. Les bien-pensants du Web ont décidé que les plugins Web c'était le Mal (pour des raisons valables, mais ceci n'est pas le débat ici). Le problème est que le seul langage qui reste accepté pour du Web côté client est le seul qui soit interprété par les moteurs Web, et c'est JavaScript. Une solution pourrait consister à faire interpréter d'autres langages par nos moteurs Web mais personne ne cherche à le faire. Google a essayé avec Dart mais les autres ont préféré soutenir leurs solutions pas optimales.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  6. #26
    Membre chevronné

    Homme Profil pro
    Développeur .NET
    Inscrit en
    juillet 2009
    Messages
    966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : juillet 2009
    Messages : 966
    Points : 1 835
    Points
    1 835
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Ce n'est pas une approche par prototype comme l'entend frfancha, c'est de l'orienté objet classique transpilé en prototype donc effectivement immonde.


    Tu veux dire celle qui arrive dans ECMAScript 6 ? Car sinon le langage n'offre pas de support explicite des modules.

    Ceci dit je suis d'accord, "il n'y a pas grand chose à lui reprocher" est quand même assez exagéré.
    Oui ECMAScript 6 va résoudre beaucoup de problème mais le temps que ça soit réellement actif chez tous le monde, notamment au prêt du grand publique, il va avoir quelque année encore. (y'a cas voir le nombre de PC sous XP pour s'en convaincre)


    Citation Envoyé par Iradrille Voir le message
    Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.
    Pas de soucie avec ce que tu dis mais pour moi c'est justement le problème. Ce n'es pas un langage objet alors que l'on cherche a faire de l’objet avec, se qui montre qu'il y a bien un problème.


    [Troll] en plus même sans la notion d'objet je trouve la syntaxe degeu [/Troll]
    un jour, quelqu'un a dit quelque chose...

  7. #27
    Membre éprouvé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    474
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 474
    Points : 1 095
    Points
    1 095
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Vu que quasiment [URL="https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js"]cette vidéo donne un paysage assez comique des 20 prochaines années et de la fin de JS: https://www.destroyallsoftware.com/t...-of-javascript
    Sympa, mais je ne suis pas d'accord avec la raison qu'il donne de l'essor de javascript en 2006 comme étant le livre "The good parts". Bien sûr un excellent livre, mais la vraie raison de l'essor en 2006 c'est AJAX.

  8. #28
    Membre averti Avatar de goldbergg
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2014
    Messages
    122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2014
    Messages : 122
    Points : 408
    Points
    408
    Par défaut
    L'inconvénient avec les langages comme TypeScript, c'est qu'un peux a la façon de jQuery, il incite a faire de la m#rde et surtout, a moins de s’être bien documenté, se qui avouons le peux de personne fait, on se retrouve a a ne pas savoir se qu'on code...

    Le Js n'est pas de la POO par class mais par prototype et tans qu'on essayera de vouloir contourner sa, c'est sur que le langage ne sera jamais utilisé a bonne escient et correctement et bien évidement les devs qui n'on pas envie de s’embêter apprendre de nouveaux concepts passeront leurs temps a se plaindre.

    Comme je l'ai dit dans mon précédent post, le JS est un langage simple (je le penses vraiment), mais uniquement a partir du moment ou l'on a chercher a le comprendre, pas a le simplifier ni a tenter de contourner ses fondements.

    Pour les certaines problématique évoqué précédemment sur les namespace et l'héritage, il n'est aujourd'hui pas possible de faire de "using" en js, les deux solution sont sois de tous charger dans le html via les balise script, sois d'utilisé le DSL ou l'AJAX.

    Pour créer un namespace en JS affin d'isoler différentes portions de code, c'est aussi simple que ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    var MonNamespace = MonNamespace  || {};//Déclaration d'un namespace, la condition permet de réutiliser le namespace dans plusieurs fichier sans se soucier de l'ordre de l'inclusion des fichiers.
     
    MonNamespace.UnePseudoClass = function (){//Je déclare une "class" dans mon namespace
    	this.MaFonction = function(){
    		console.log('Je suis dans UnePseudoClass');
    	}
    };
    Pour simplifier l'héritage, il suffit de créer une fonction:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    function inherit (base, parent){  
    	function F() { this.constructor = base; }  
    	parent.call(base);  
    	F.prototype = parent.prototype;;  
    	base.prototype = new F();  
    	return base;  
    };
    et de l'utiliser :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    MonNamespace.MaPseudoClassEnfant = function (){
    	inherit(this, MonNamespace.UnePseudoClass);//On fait l"héritage
    	//On pourait aussi faire sa, mais l'usage en direct du "__proto__" n'est pas conseillé.
    	//this.__proto__ = new MonNamespace.UnePseudoClass();
    };
    et sa donne sa:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    var monObj = new MonNamespace.MaPseudoClassEnfant();
    monObj.MaFonction();//j'appel ma fonction hérité
    (Code pondu a la va vite, y a surement moyen de faire mieux sans forcement pondre plus de ligne)

    Fin voila, tous sa pour dire qu'il n'y a pas besoin de passer par des surcouche pour résoudre des problématiques au final pas si compliqué, sans compter que des site comme codepen et jsfidlle propose pas mal d'exemple pour toute sorte de problématique (et y a jsperf qui permet de sensibilisé sur les techno a utiliser ou pas )

    Le code complet pour ceux qui veulent tester (fonctionne sur IE):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    "use strict";
    var MonNamespace = MonNamespace  || {};//Déclaration d'un namespace
     
    MonNamespace.UnePseudoClass = function (){//Je déclare une "class" dans mon namespace
    	this.MaFonction = function(){
    		console.log('Je suis dans UnePseudoClass');
    	}
    };
    function inherit (base, parent){  
    	function F() { this.constructor = base; }  
    	parent.call(base);  
    	F.prototype = parent.prototype;;  
    	base.prototype = new F();  
    	return base;  
    };
    MonNamespace.MaPseudoClassEnfant = function (){
    	inherit(this, MonNamespace.UnePseudoClass);//On fait l"héritage
    }
    var monObj = new MonNamespace.MaPseudoClassEnfant();
    monObj.MaFonction();//j'appel ma fonction hérité

  9. #29
    Membre éprouvé

    Homme Profil pro
    non
    Inscrit en
    mai 2008
    Messages
    395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : non

    Informations forums :
    Inscription : mai 2008
    Messages : 395
    Points : 1 108
    Points
    1 108
    Par défaut
    Citation Envoyé par air-dex Voir le message
    Par conséquent, connaître JS permet très souvent de faire un bout de programme utile dans un domaine de programmation donné (sauf cas particuliers genre systèmes embarqués). D'où l'utilité de le connaître. Ce sera rarement la meilleure techno, mais au pire on aura toujours JS dans sa panoplie de développeur pour pouvoir faire des choses. Après c'est sûr qu'il y a d'autres technos plus indiquées pour faire mieux, mais ces technos là vont souvent être spécifique au domaine.
    Le même argumentaire existe avec java (pour l'exemple) : « autant connaitre java, au pire on peut tout faire, les autres technos sont spécifiques ». Admettons, pour un débutant c'est effectivement intéressant d'avoir une boite à outils passe partout à valoriser pour ses premiers jobs (java, js, autre...). Mais on arrive souvent à être spécifique au domaine et donc à utiliser des technos « moins généralistes » (ce qui en fait est quasi tout le temps faux...).

    Le même raisonnement sur le java (encore une fois j'ai rien contre le java) couplé à une demande de l'industrie a donné une recrudescence de l'enseignement du java très tôt dans les écoles/universités et parfois on voit des formations qui laissent tomber les autres langages. Les étudiants sortent sans avoir appris à penser hors de ce cadre. Conseiller à tout le monde de faire du js c'est du même niveau.
    [|]

  10. #30
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par Iradrille Voir le message
    Justement, JS n'est PAS un langage objet "classique" (type C++ / Java / C# / autre..), l'approche est différente. Beaucoup de gens voient le JS comme un langage objet avec une syntaxe dégueu pour les classes; alors que le concept de classes n’existe tout simplement pas.
    A ce sujet, je recommande Io, un petit langage très épuré qui est idéal si on veut comprendre le mécanisme des prototypes. C'est Javascript sans l'océan d'accolades et la syntaxe verbeuse, sans les comportements bizarroïdes (égalité...) et avec des concepts de concurrence et d'asynchronisme très simples déjà intégrés (acteurs, futures, coroutines...)

  11. #31
    Membre expert
    Inscrit en
    juin 2009
    Messages
    997
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 997
    Points : 3 013
    Points
    3 013
    Par défaut
    Citation Envoyé par goldbergg Voir le message
    le JS est un langage simple (je le penses vraiment), mais uniquement a partir du moment ou l'on a chercher a le comprendre
    La mécanique quantique c'est simple, mais uniquement à partir du moment ou l'on cherche à la comprendre

    Ta phrase me rappelle celle là : "Il comprend vide mais il faut lui expliquer longtemps"

    je comprends bien qu'il y a un paradigme majeur dans le javascript que peu de personnes exploitent. Mais pourquoi? Ne serai-ce pas justement parce que ce paradigme est moins naturel et plus alambiqué que les autres ?
    Auquel cas ce n'est plus le JS qui est compliqué, mais son pradigme principal.

    Concrètement ça change quoi vis-à-vis du développeur? Il y a toujours une marche relativement grosse à franchir pour ne pas faire du travail moisi en Javascript (ou VanillaJS si vous préférez )

  12. #32
    Rédacteur/Modérateur
    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 297
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 297
    Points : 9 638
    Points
    9 638
    Par défaut
    Citation Envoyé par AoCannaille Voir le message
    je comprends bien qu'il y a un paradigme majeur dans le javascript que peu de personnes exploitent. Mais pourquoi? Ne serai-ce pas justement parce que ce paradigme est moins naturel et plus alambiqué que les autres ?
    J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

    Pourquoi son manque de popularité ? J'ai quelques hypothèses :
    - le fait qu'il ne soit pas ou très rarement enseigné en école ou dans les cours en ligne, où la POO par classe est souvent le seul paradigme enseigné en matière de POO ; au point que pour beaucoup, POO = classes
    - le fait qu'il soit sous-représenté dans les langages dominants (Java, C++, C#, PHP, Python, Ruby etc... utilisent tous des classes)
    - le fait que son seul représentant vraiment populaire, JavaScript, a été détourné dans sa conception originelle pour mieux coller au "style Java" (on peut remercier Sun pour ça, qui au passage a changé le nom d'origine "LiveScript") ; les constructeurs, l'opérateur instanceof et les ""classes"" ES6 témoignent encore de cet état de fait
    - 20 ans de POO par classes qui ont ancré de profondes habitudes chez les développeurs, avec des réflexes et des façons de penser qui ne peuvent pas s'appliquer directement avec des prototypes. Il faut réapprendre les bases et ce n'est pas facile, beaucoup ont essayé les prototypes mais ne parvenaient pas à sortir de leurs patterns classiques, ce qui se soldait par un échec et donc une mauvaise impression de la POO par prototype.

    Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.
    One Web to rule them all

  13. #33
    Membre éprouvé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    474
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 474
    Points : 1 095
    Points
    1 095
    Par défaut Merci
    Citation Envoyé par SylvainPV Voir le message
    J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

    Pourquoi son manque de popularité ? J'ai quelques hypothèses :
    - le fait qu'il ne soit pas ou très rarement enseigné en école ou dans les cours en ligne, où la POO par classe est souvent le seul paradigme enseigné en matière de POO ; au point que pour beaucoup, POO = classes
    - le fait qu'il soit sous-représenté dans les langages dominants (Java, C++, C#, PHP, Python, Ruby etc... utilisent tous des classes)
    - le fait que son seul représentant vraiment populaire, JavaScript, a été détourné dans sa conception originelle pour mieux coller au "style Java" (on peut remercier Sun pour ça, qui au passage a changé le nom d'origine "LiveScript") ; les constructeurs, l'opérateur instanceof et les ""classes"" ES6 témoignent encore de cet état de fait
    - 20 ans de POO par classes qui ont ancré de profondes habitudes chez les développeurs, avec des réflexes et des façons de penser qui ne peuvent pas s'appliquer directement avec des prototypes. Il faut réapprendre les bases et ce n'est pas facile, beaucoup ont essayé les prototypes mais ne parvenaient pas à sortir de leurs patterns classiques, ce qui se soldait par un échec et donc une mauvaise impression de la POO par prototype.

    Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.
    Merci pour ce post plein de sagesse

  14. #34
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    J'ai appris la POO par prototype plusieurs années après avoir pratiqué la POO par classes, surtout en Java et C#. Si on se concentre sur les différences fondamentales, sans parler de syntaxe ou de fonctions avancées, je trouve la POO par prototype plus simple car les concepts d'instance et de classe sont regroupés en un seul et même concept, celui de l'objet (prototypé). Il paraît également plus "naturel" car expose un niveau d'abstraction inférieur à celui des classes (une classe seule ne sert à rien, on utilise les instances d'une classe, tandis qu'on peut toujours utiliser un objet prototypé sans se préoccuper de savoir s'il est le prototype d'autres objets ou pas)

    Pourquoi son manque de popularité ?
    ....

    Dans tous les cas je pense qu'il faut aller plus loin que le raisonnement "si c'est pas connu, c'est que ça doit pas être bien". Plutôt que faire des assomptions, je vous encourage à apprendre et à expérimenter d'autres paradigmes, pour voir leurs avantages et inconvénients. Cela permet de prendre du recul sur son style de développement, et de s'améliorer en tant que développeur même sans changer de techno/langage.
    Sur le fond, je suis d'accord avec toi mais quand même, tu déplores que la beauté intrinsèque du modèle objet de javascript n'est pas reconnue à sa juste valeur alors que javascript a percé principalement grâce à l'opportunité "web côté client". C'est quand même un peu l'hôpital qui se fout de la charité...
    Dernière modification par Invité ; 19/11/2015 à 21h24.

  15. #35
    Membre éprouvé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    474
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 474
    Points : 1 095
    Points
    1 095
    Par défaut
    Citation Envoyé par nokomprendo Voir le message
    Sur le fond, je suis d'accord avec toi mais quand même, tu déplores que la beauté intrinsèque du modèle objet de javascript n'est pas reconnu à sa juste valeur alors que javascript a percé principalement grâce à l'opportunité "web côté client". C'est quand même un peu l'hôpital qui se fout de la charité...
    Je n'ai pas compris où se trouve la contradiction que tu sembles relever?

  16. #36
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par frfancha Voir le message
    Je n'ai pas compris où se trouve la contradiction que tu sembles relever?
    En d'autres termes : le langage est connu parce qu'on peut l'utiliser facilement mais mochement, mais c'est dommage qu'il soit utilisé mochement mais si on ne pouvait pas l'utiliser mochement il n'aurait peut-être pas été aussi connu.
    Ce qui fait beaucoup de mais pour un mois de novembre...

  17. #37
    Invité
    Invité(e)
    Par défaut
    Js sans le Framework AngularJs, c'est vraiment pas terrible.
    Par contre AngularJs+NoSql , c'est l'avenir pour le web, car pour le REST, il n'y a pas besoin de créer des champs comme en base de données relationelle, tout se fait automatiquement .
    Js ne devrait être utilisé qu'avec le framework AngularJs. JQuery ? On ne s'en sert plus quand on passe sous Angular.

    Java ? J'ai téléchargé android studio, rien que lors de la première install, ça plante déjà avec des messages d'erreur incompréhensibles et ça rame à donf.
    Php ? C'était cool au début des années 2000, mais ça c'était y'a 16 ans .... Du temps des ordinosaures. Quand à Java qui date de 1994, une renault Clio de l'époque est bien différente d'une clio de 2015, et les variables typées, c'est long à écrire et désagréable, mais j'aime bien quand même, surtout quand je vois des mecs vendre des apps compilées.. Je me demande comment ils font pour créer leurs apps, vu comme ça parait archaique et difficile avec Spring par exemple de ne créer ne serait-ce qu'un bouton, mais c'est peut être moi qui exagère.

    Ne pas oublier que JSON veut dire Javascript object Notation, et que tous les autres langages sont en train de suivre comme des petits moutons pour dialoguer avec Json... Sauf que c'est orginellement du Javascript... Moi je préfère l'origine.
    Dernière modification par Invité ; 19/11/2015 à 22h39.

  18. #38
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 711
    Points : 4 405
    Points
    4 405
    Par défaut
    Citation Envoyé par MoumouteMasters Voir le message
    Par contre AngularJs+NoSql , c'est l'avenir pour le web
    Le NoSQL pour tout et n'importe quoi c'est vraiment à la mode.
    Quand c'est justifié c'est très bien; mais comme tout il y a des compromis à faire.

    Très souvent une base relationnelle fera le job aussi bien, si ce n'est mieux qu'une base NoSQL.

    Le pire argument que j'ai entendu pour NoSQL (mongoDB) était : "c'est trop bien, ya pas de schémas à faire : donc pas de migrations. Pas non plus de problèmes d'ordres d'insertion dans les tables : il suffit de dupliquer les données."

    Ton post me laisse penser que tu es dans le même état d'esprit. Oui, c'est lourd / chiant de faire un schéma correct. Oui, les migrations c'est pas toujours simple.

    Mais derrière une base relationnelle ("classique") apporte un grand nombre d'avantages dont les 2 principaux sont :
    * la cohérence des données (respect d'un schéma / transactions) -> pas besoin de vérifier les données, si elle sont dans la base elles sont valides et sous le bon format (sinon l'insertion passe pas); toute la logique de vérification des données est liée à la base et non à l'application qui l'utilise.
    Les transactions permettent de s'assurer que la base est toujours dans un état valide.
    On récupère toujours un état à jour des données contrairement à la majorité des bases NoSQL qui préfèrent ne pas fournir cette garantie pour permettre un meilleur scaling. Hors cette garantie est souvent plus importante que le scaling.

    * l'unicité des données (en cas de schéma normalisé) -> mise à jour des données plus simple; taille réduite.

    A partir du moment où on peut définir un schéma et que le volume de données n'est pas immense une base relationnelle EST la meilleure solution.

  19. #39
    Invité
    Invité(e)
    Par défaut
    Concernant le message de MoumouteMasters : je ne vois pas trop le rapport avec la tournure "POO façon javascript" qu'a pris la discussion mais j'imagine que c'est plutôt en rapport avec l'article initial.
    Dernière modification par vermine ; 20/11/2015 à 07h49.

  20. #40
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 614
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 614
    Points : 3 616
    Points
    3 616
    Par défaut
    Citation Envoyé par maske Voir le message
    Le même argumentaire existe avec java (pour l'exemple) : « autant connaitre java, au pire on peut tout faire, les autres technos sont spécifiques ». Admettons, pour un débutant c'est effectivement intéressant d'avoir une boite à outils passe partout à valoriser pour ses premiers jobs (java, js, autre...). Mais on arrive souvent à être spécifique au domaine et donc à utiliser des technos « moins généralistes » (ce qui en fait est quasi tout le temps faux...).
    C'est ce que je dis. Le JS est un outil passe-partout pour tout faire. Mais dès que tu es dans un domaine et que tu veux y faire des choses plus sérieuses, alors tu passes à quelque chose de plus spécifique et qui n'est pas JS.

    Java est bien trouvé pour ton exemple. Il pourrait même être cité en exemple comme JS. Mais Java est désormais un paria pour le Web côté client, les bien-pensants du Web ne voulant plus de plugins Web, dont Java et ses appliquettes côté client.

    Citation Envoyé par maske Voir le message
    Le même raisonnement sur le java (encore une fois j'ai rien contre le java) couplé à une demande de l'industrie a donné une recrudescence de l'enseignement du java très tôt dans les écoles/universités et parfois on voit des formations qui laissent tomber les autres langages. Les étudiants sortent sans avoir appris à penser hors de ce cadre. Conseiller à tout le monde de faire du js c'est du même niveau.
    Je te rejoins sur le fait qu'il n'est pas sain de se limiter dans les langages appris et par conséquent dans les philosophies qui vont avec. Java a même des circonstances aggravantes avec sa philosophie du tout objet. Mais contrairement à Java, JS est plus ouvert sur les philosophies de programmation. Il en a plusieurs parmi lequel l'impératif (comme le C) et la POO par prototypes.

    Citation Envoyé par MoumouteMasters Voir le message
    Ne pas oublier que JSON veut dire Javascript object Notation, et que tous les autres langages sont en train de suivre comme des petits moutons pour dialoguer avec Json... Sauf que c'est orginellement du Javascript... Moi je préfère l'origine.
    Dans JSON il y a aussi "Notation". Le JSON permet surtout de noter des données, et ce de manière moins verbeuse et plus lisible que XML. C'est à mon avis plus indiqué que le XML si tu n'as pas de vérifications à faire sur tes données (à l'aide d'un DTD pour XML par exemple). Je m'arrête là avant de m'égarer dans un débat "XML vs. JSON (vs. YAML)" qui est ici hors sujet.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

Discussions similaires

  1. sécurité sur front-end et back-end
    Par Philippe PONS dans le forum Sécurité
    Réponses: 7
    Dernier message: 18/11/2007, 11h43
  2. [1.x] Cherche framework léger orienté "interfaces back-end"
    Par gb-ch dans le forum Symfony
    Réponses: 2
    Dernier message: 18/03/2007, 14h18
  3. Securiser le Back end
    Par romBJ dans le forum Sécurité
    Réponses: 3
    Dernier message: 21/12/2006, 09h15

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