comaprer facebook sans et avec js. c'est indeniable que js pourri tout
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 :
comaprer facebook sans et avec js. c'est indeniable que js pourri tout
La problématique réside principalement dans le fait que des tas de personnes ne connaissant rien a js ont voulu faire des applis en utilisant jquery par exemple...
Js a beaucoup évolué depuis 2015. aujourd'hui il y a les framework javascript comme Angular et ReactJS. Encore une fois, le probleme emergeant, ce sont des développeurs js qui veulent utiliser ces framework comme ils utilisaient js. Mais cela n a rien a voir !!!!! Certains vont essayer d y plugger du jquery ! Tandis que c'est tout a fait contre nature ! En angular tu ne programmes pas en javascript, mais en typescript.point barre.
Pour pouvoir utiliser correctement ces frameworks, je pense qu'il est quand meme nécéssaire d'avoir compris comment fonctionne toute la chaine de ces frameworks. ceci implique npm webpack typescript, rxjs...
De plus, l'utilisation correcte de ces framework vont permettre qu'effectivement l'on attendra pas devant votre page qu'une action se termine, puisque les requetes que vous effectuez ne bloqueront pas la partie interface.
Principalement grace aux "promises" .
ca fait beaucoup en effet, mais nécéssaire. Coder une appli web devient un jeu d enfant, ensuite. Avec maintenant un "cadre" pour que ce ne soit plus du code poubelle non reutilisable.
A ce jour, il faut noter que la France a un train de retard sur ces technologies.
Enfin, ces frameworks sont trés bien , a condition de savoir dans quel type d applications il faudra utiliser Angular ou ReactJS. Car les concepts sont foncierement différents et dans certains cas les performances ne pourront donc pas etre la.
Concernant typescript, beaucoup de développeurs me font un peu rire lorsqu'ils m annoncent qu'ils aiment pas le javascript, mais utilisent quotidiennement visual studio code .
Bah oui , Visual studio code est ecrit en typescript ! (https://github.com/Microsoft/vscode)
Le javascript et le web ont quand meme pour avantage d avoir des normes et spécifications.
A l'opposé, il y a ceux qui ne voient que par QML, bah qu est ce que c est ? Un framework JS ..... avec une grosse surcouche propriétaire dessus.
Et alors ? Que TypeScript soit une extension de JS ou carrément un autre langage, il est quand même différent de JS. Linux est codé en C et Windows en C++, et alors, il faut coder nos applis web en C/C++ ?Envoyé par sancelot
Le problème n'est pas JavaScript en soit, mais notre propension, à créer des usines à gaz.
https://idlewords.com/talks/website_obesity.htm
Au boulot, je suis tombé sur une application toute simple. L'objectif est de fournir une interface graphique qui affiche les informations d'un annuaire. Une page d'accueil toute simple, trois champs de recherche, le nom, le prénom, l'identifiant unique. Une page qui liste les résultats, paginés. Une dernière qui affiche le détails des informations. Pour développer l'application, le choix a été porté sur Angular, packagé en mode "non production", sur la machine de production. Une application qui nécessite de télécharger plusieurs Mo pour afficher les informations d'une personne.
Ce n'est pas Angular le problème mais le fait de l'avoir choisi, associé à l'incapacité de packager l'application correctement
Je lis ici les gens se plaindre de l'utilisation de framework. Mais n'est ce pas le propre de l'informaticien de ne pas reinventer la roue a chaque fois ?
qui envisagerait serieusement de ne pas utiliser de framework js aujourd'hui dans ses applis webs ? (ou alors si c'est pour refaire ce ne serait qu'un micro framework et quel interet ?) En 2018 le metier de developpeur c'est pour beaucoup de l'assemblage de composants. On n'a plus le temps de reecrire completement des frameworks from scracth.
On a une team qui a voulu le faire chez nous. 3 ans qu'ils sont dessus, ca nous a couté une blinde (soit disant codé dans l'etat de l'art). Et pourtant des barons du javascript (des ninjas du code comme ils aiment a le dire. Au final un framework js d'une rigidité sans nom, plein de manques; donc l'alternative est la fuite en avant ou alors utiliser des frameworks deja eprouvés, maintenus par une communauté.
Ca me semble plus le sens de l'histoire que ceux qui ont un ego surdimensionné et croient qu'ils vont revolutionner l'informatique en reecrivant tout. Bien le propre du dev de toujours critiquer le travail des precédents. Plus malin que les autres.
D'ailleurs au bout de 3 ans, il ne reste plus que 2 dev d'origine sur la 10aine. On se retrouve avec un framework difficilement maintenable et evolutif (malgré un code propre).
Tellement de choses absentes qu'on aurait deja eu dans des frameworks open source (ou du commerce) et là on rame comme c'est pas possible.
Quel gachis quand tout existe. Une selection des bonnes boites a outils suffit la plupart du temps a couvrir les 95% des besoins. Se focaliser sur les 5% me semble plus pertinent que refaire les 95%.
Ce débat est interminable et le pire c'est que tout à déjà été dit :
- Peut on faire une webapp performante en utilisant JavaScript : oui
- Peut on faire la même webapp non performante en utilisant JavaScript : oui
- A optimisation égale, est-ce qu'une webapp avec framework sera plus lourde que la même webapp sans framework : oui
- Est-ce que les quelques kB gagnés valent les dizaines (centaines?) d'heures nécessaires à tout recoder : probablement pas dans 99% des cas
Si tout le monde suit quelques notions très simples comme éviter les opérations du DOM inutiles (re-rendering, refreshing), ne pas faire d'appels réseau inutiles (throttling, caching), et utiliser gzip pour l'envoi initial des fichiers, ça va aller beaucoup mieux peu importe quel framework ou non vous utilisez.
Le seul vrai problème de mon point de vue c'est node_modules. C'est aujourd'hui impossible pour n'importe quelle petite/moyenne équipe de s'assurer qu'il n'y a pas une pile de daube là dedans tellement il y a de dépendances. J'ose espérer que quand le code JS pré ES6 sera mort et enterré on pourra revoir tout ça et se passer des dépendances qui ne font rien que ne peux pas faire le JS moderne. Je viens d'ouvrir mon node_modules d'un projet en court par curiosité et entre les modules qui font la même chose et ceux qui font des opérations sur une ligne. Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur(https://www.npmjs.com/package/arrify).
C'est toujours le même non argument : on peut coder a peu près n'importe quoi dans n'importe quel langage. Il n'y a pas si longtemps que ça, les gens faisaient encore des choses très complexes en assembleur.Concernant typescript, beaucoup de développeurs me font un peu rire lorsqu'ils m annoncent qu'ils aiment pas le javascript, mais utilisent quotidiennement visual studio code .
Bah oui , Visual studio code est ecrit en typescript ! (https://github.com/Microsoft/vscode)
Tant que ça marche on s'en fout, l'utilisateur final ne verra pas la différence.
Ce qui compte pour le développeur, c'est de pouvoir avoir un code propre, maintenable et sur lequel il sera facile d'intégrer de nouveaux développeurs. Et ça, je suis désolé mais en JavaScript ce n'est pas possible, rien que l'absence de typage fort oblige à multiplier les vérifications pour être sûr qu'une fonction reçoit bien des variables du type attendu, donc c'est du code plus long, moins lisible et avec plus de bugs potentiels.
Sur un autre topic, j'ai demandé aux inconditionnels de JS de me donner des exemples de code de qualité écrit en pur JavaScript, du code où l'on comprend immédiatement ce qui se passe avec le minimum de commentaires : je n'ai jamais obtenu de réponses, j'attends toujours.
Je suis assez d'accord avec cette remarque. Avec JS on peut utiliser un debugger + un linter + un outil de TU + ... Sauf qu'avec des langages fortement typés genre Elm, le compilateur fait automatiquement énormément de vérifications. Et quand on a utilisé un peu sérieusement ce genre de langage, on a vraiment du mal à refaire du JS.
Ben sur l'autre fil je parlais justement de la JSDoc que certains linter prennent en compte mais si pour toi "avec le minimum de commentaires" signifie pas de JSDoc ni de commentaires indiquant le type alors c'est vrai que personnellement (c'est-à-dire moi avec mon faible niveau mais peut-être que d'autres ont trouvé des solutions) je ne vois pas comment on pourrait faire (sans débogueur)... Comme déjà dit sur l'autre fil je suis passé par Java avant JS et c'est vrai qu'au début j'ai cherché à savoir si il existait un bon IDE fournissant une assistance en JS se rapprochant de l'assistance qu'on a en Java...
C'est vrai que parfois quand on essais de comprendre le code développé par quelqu'un d'autre cela peut être plus difficile et plus long, je ne parle pas des types primitifs (là ça passe encore) mais des objets (instances), quand une fonction reçoit en argument un objet eh bien pour comprendre on a besoin de savoir de quelle "class" cet objet est l'instance... Alors pour ça il y a les commentaires, la JSDoc ou encore le débogueur mais c'est sûr si un outil permettait d'aller à cette "class" juste en cliquant (go to definition) sur le nom de l'argument ce n'est pas moi qui serait contre... Parfois même en survolant le nom de l'argument on peut voir apparaitre une description de cette "class"...
Parfois cet objet peut contenir juste des méthodes et même si on a une liste de ces méthodes (obtenue par exemple avec le déboguer) cela peut être quand même difficile de comprendre ce qu'elles font car elles peuvent travailler sur des données dont on ne peut connaitre l'origine qu'en regardant la "class" dont cet objet est l'instance (le déboguer n'indique pas la provenance de ces données à moins que cela m'ait échappé ???)...
C'est sûr aussi que si je veux avoir une autocomplétion quand j'utilise cet objet à l'intérieur de la fonction eh bien il va bien falloir que l'IDE sache d'où provient cet objet...
Mais même avec tout ça on pourra avoir besoin d'une documentation la plus complète possible d'ailleurs en Java on a souvent une JavaDoc pour toutes les classes...
Enfin bref, ce n'est pas moi qui serait contre le fait d'avoir en JS le même genre d'assistance qu'on a en Java après cela ne veut pas dire qu'en JS pur on ne peut pas avoir un code propre et lisible, c'est possible de bien le structurer (par exemple en utilisant les modules ES6, les class ES6, ...), on peut aussi avoir un minimum d'assistance si on connait les outils qui la fournissent... Cela peut bien se passer au moins pour les petits projets après pour les gros projets sur lesquels plusieurs développeurs travaillent et qu'on doit maintenir je peux comprendre que l'on soit plus exigeant...
Le poids d'un projet ne devrait pas être relatif à ce qui est rendu. Personnellement, mon framework-maison PHP fait plus de 6.5Mo et je l'utilise même pour de tout petits projets tels que celui dont tu parles.
Pourquoi ? par souci d'uniformisation du process, de réutilisation de composants, faisant que chaque projet enrichit la base qui lui sert, ayant des besoins différents.
Dans mon framework, il y a
- un axe web service (privé) créé pour le projet de mes clients, sur lequel peuvent se greffer des serveurs de rendu, derrière lequel il y a toute l'intelligence logicielle
- un axe apis publiques, sur laquelle des sites web, des applications mobiles, des moteurs de recherche exploitant le JSON-LD, services tiers, etc. peuvent se greffer, sans avoir à rendre le web service public.
- un axe serveurs de rendu DOM, permettant de créer autant d'UI qu'on veut, avec différentes features/contraintes
- un axe serveur de fichiers
- et bientôt un axe webhooks
Évidemment, permettre de telles flexibilités, possibilité d'évolutions, possibilités de vente multiples d'un même développement sans risques de différences d'implémentations, ... ça demande une sacrée code base.
Mais si le besoin du client évolue et que ton développement s'est arrêté au besoin strict, il y a fort à parier qu'il faudra tout reprendre de zéro, augmentant les coûts et risquant les breaking changes.
C'est justement une des forces d'anticore, le traitement des noeuds se fait très facilement AVANT d'être ajoutés au document.
Cela me fait un peu penser à certains micro-utilitaires d'anticore, de minuscules modules ont pourtant parfois une réelle utilité, je pense notamment aux aspect suivants :Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeur
- améliorer la lisibilité
- simplifier un traitement/test
- uniformisation du process
- améliorer la possibilité de minification (par exemple, j'ai développé des utilitaires de détection avancées de types de variables qui ajoutent de la fonctionnalité, tout en évitant une répétition de typeof x === v non-minifiable, à plein d'endroits dans un gros projet)
Exemple, pour reprendre une astuce bien utile de SylvainPV, j'me suis fait un micro-module déclarant :
Alors, oui, c'est microscopique, mais pourquoi le répéter partout où j'en ai besoin ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part demethodize = Function.bind.bind(Function.call);
Sur le principe je suis tout à fait d'accord, ce genre de fonctions sont intéressantes surtout en JS où il y a des bouts de codes très verbeux (celui que tu cites est un bon exemple). Ce qui me dérange plus c'est que des projets aient ce genre de dépendances au lieu d'avoir ces fonctions en interne, comme tu le fais dans le cadre de Anticore. C'est une question de confiance au final, si Angular ou React utilisent un module externe pour faire ton "demethodize" ou utilisent Arrify je dois vérifier l'intégrité de 3 sources au lieu de une seule pour des bouts de code aussi simples et ça me fait chier.
Évidemment pour des fonctionnalités plus complexes c'est tout a fait normal d'avoir des dépendances mais je refuse de croire qu'un framework qui installe 200+ dépendances à l'installation soit nécessaire, et encore moins une bonne chose.
Je suis allé voir Anticore brièvement et c'est intéressant au moins pour le coté modulaire, j’essaierais de creuser un peu si j'ai le temps (probablement pas avant l’année prochaine).
Juste pour être sûr que ce soit bien compris, car je ne sais si tu parles d'anticore ou pas, là...
anticore a 200+ modules... internes. Le but étant d'avoir une base complète et évolutive, pour faciliter le développement, mais ces modules ne sont présents qu'en DEV, la lib pourrait même faire des To de données, ça n'alourdirait pas le dist.
Dans le cas où tu parles de vraies dépendances externes, en effet, niveau maintenabilité, c'est une horreur et représente un taff titanesque, pour ne serait-ce que vérifier le contenu des dépendances, notamment, à des fins de sécurité (c'est le strict minimum, non ?).
Super, j'espère que le concept te plaira, teste absolument le anticore.on(selector, middleware). Et si tu as des questions, je suis très régulièrement présent sur le chat.
Cherche volontaire
J'ai enfin trouvé le bon endroit pour trouver ce que je cherche ! Je dois en effet trouver quelqu'un capable de vendre la crème citron toute-faite de chez Metro pour tartes au citron à des restaurants gastronomiques.
Ne ré-inventez plus la roue! ou plustot la tarte au citron, laissez faire des industriels qui savent mieux que vous comment faire!
En plus cela permet d'uniformiser le gout et d'éviter des les disparités entre vos enseignes, cela permet de servir le client plus vite et moins cher, et soyez certains qu'il se fiche de ce qu'il y a dedans.
Les pâtissiers qui ne l'utilisent pas en ce siècle où nous sommes sont tout simplement des INCOMPÉTENTS! J'en connais qui a essayé lui même et il s'est mis du jus de citron dans l'oeuil et il en est mort!
En plus il y a pleins de crèmes et de sauces possibles, tu peux ajouter de la harissa ou de la sauce béarnaise pour couvrir tous les besoins!
Moi je bosse avec des vrais pros, on travaille sur des macs qu'on ne peux ni ouvrir ni réparer, et a midi on mange des repas tout fait dans des boites. Ca c'est des vrais pros!
Je ne suis qu'un débutant en programmation, mais je dois dire que j'ai beaucoup ri.Par exemple j'en ai une qui prend une valeur en entrée, si c'est un array ça retourne la valeur et si non ca retourne un array contenant la valeurJ'ai d'ailleurs fait partager le lien.
J'ai connu le meme probleme avec un framework python, les mecs des tronches , ok , mais ils avaient pas vu venir les erreurs de conceptions... au final aprés leur départ on paie encore la dette technique !
Aujourd'hui, j'entends également un discours pour les choix technologiques, vraiment affolant, par des mecs qui sont compétents mais que dans un domaine (du c++) . A propos d'un framework c++ : "Je suis persuadé que l'on fait le bon choix, de plus ce framework est utilisé par le fabricant No 1 de XXXX manufacturing". Et bien entendu , sans se soucier des autres technos, tu dois prendre en compte le fait que c'est acté et que l'on ne reviendra pas dessus ! Bref .....
Et les bibliothèques...
Je ne pense pas qu'en sois le JS soit derrière la lenteur et lourdeur des pages mais le mauvais usage de celui-ci l'est. Si pour une requête AJAX faut dix à vingt ligne, utiliser le jQuery, pour n'en citer que celle-ci, semble plus attrayant pour une majorité. Ou d'autres bibliothèques pour une ou deux animations sans compter les trackeurs etc.
Tiens d'ailleurs, quand on parle de web-application, on parle bien de web ... comme World wide web non ? Va falloir m'expliquer comment une application stand-alone offline qualifie à cette définition ...
La plus value de jQuery aujourd'hui est discutable.
Pour le JS, je n'ai jamais aimé ce langage. Rien que de créer ce que JS considère comme un objet me parait chelou. Pourtant sur tous les autres langages créer une classe et savoir l'instancier ne me pose pas de problème. Par ex, quel est le résultat d'un module.exports, comment il fonctionne, est-ce que je fait un import from ? Sans parler que quand on parle de modules JS tu as du commonJS, Asynchronus Module Definition etc... merde c'est complexe pour un seul et même langage non ?
Bordel Webpack 2 utilisait quasiment 100 % de mon CPU pour faire quoi ? Compiler du JS et CSS à la volée ?! Je lui demande pas de faire tourner un jeu 3D pointu là.
Alors oui certains outils JS resteront pour quelques temps, tel que Angular, Webpack mais avec quelle durée de vie sur des versions majeures ? 6 mois à un an ?
J'ai eu la discussion avec un collegue il y a quelques semaines et même lui reconnaissait que la communauté JS par dans tous les sens.
Il est où le framework complet backend en JS ? Express ? C'est un framework minimaliste. Ce n'est pas une critique d'Express, les frameworks comme celui ci peuvent très bien faire fonctionner un très gros projet, en revanche, il n'y a aucun framework backend JS qui soit au niveau d'une JVM ou d'yn framework comme Django et cie.
C'est une malédiction ce truc, mais je veux bien faire preuve d'ouverture d'esprit, si quelqu'un a de bonnes ressources pour faire de la POO en JS je l'écoute.
J'ai demandé une vingtaine de fois des exemples de bons codes JS et n'ai jamais obtenu de réponse
L'approche à base de prototypes est juste moins répandue que l'approche à base de classes. Mais si elle existe dans plusieurs langages (JavaScript, Lua, Perl 6...) c'est peut-être qu'elle a tout de même un intérêt.
sails.js ?
Ca doit peut-être être possible car, rien que chez O’Reilly, il y a au moins 4 livres qui abordent le sujet :
- Beautiful JavaScript: Leading Programmers Explain How They Think
- JavaScript: The Good Parts
- Learning JavaScript Design Patterns
- Functional JavaScript
Répondre avec citation
Partager