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 :
Il est largement possible de faire des sites internets répondant a 60% des besoins du web sans javascript. CSS3 a apporté énormément.
Personnelement je navigue avec noscript et je n’active que pour le domaine courant si le site ne marche pas je passe au suivant c’est tout.
Le fait est que beaucoup de gens non juste pas la formation adéquate pour faire du travail correct. Être dev ne s’improvise pas.
Mon css-ui devrait t'intéresser, alors.Envoyé par Bardotj
Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre codede carte bancaire
Mon GitHub
Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
(Contributions bienvenues)
comaprer facebook sans et avec js. c'est indeniable que js pourri tout
Pas forcement une question de formation ou d'auto formation, mais d'expérience.
Tant qu'on a pas vraiment mis le nez dedans, on ne sais rien.
On peut très bien avoir des années d'expérience et être parfaitement incompétent si l'on travaille dans une techno qui n'incite pas à de bonnes pratiques.Pas forcement une question de formation ou d'auto formation, mais d'expérience.
Tant qu'on a pas vraiment mis le nez dedans, on ne sais rien.
Le nombre de "développeurs" JS qui sortent des non sens du genre "l'encapsulation et le typage strict ça ne sert à rien" par exemple est juste effrayant.
JS crée des armées de professionnels qui resteront des débutants en programmation une bonne partie de leur carrière.
Quand est-ce que tu vas accepter le fait indiscutable (et indiscuté à part par toi) que TypeScript n'est qu'une extension de JavaScript et pas un langage à part entière ?
Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.
"Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
Kenneth E. Boulding
"Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
Jean-Baptiste Say, Traité d'économie politique, 1803.
"/home/earth is 102% full ... please delete anyone you can."
Inconnu
Je n'ai rien à accepter du tout, TypeScript est un langage à part entière et je n'ai que faire de tes opinions du type "ça transpile en JavaScript donc autant faire du JavaScript".Quand est-ce que tu vas accepter le fait indiscutable (et indiscuté à part par toi) que TypeScript n'est qu'une extension de JavaScript et pas un langage à part entière ?
Je vais te redire la même chose que la dernière fois, tout langage termine en binaire, donc autant coder en binaire à ce moment là.
JavaScript est un langage dégueulasse, c'est pourquoi j'apprécie de pouvoir travailler en TypeScript. Après, ce que le transpileur de TypeScript fait du code ce n'est plus mon problème en tant que développeur tant que ça fonctionne et ne cause pas de problèmes de performances, tout comme ce n'est pas mon rôle de vérifier comment la machine virtuelle de PHP pré-compile le code avant interprétation.
Allez, juste pour rigoler :
https://www.destroyallsoftware.com/t...-of-javascript
js ou pas js le problème est ailleurs, les page sont blindé de code. Çà pourrait être un autre langage le problème serait le même.
Plus vite encore plus vite toujours plus vite.
Avec un autre langage on n'aurait pas le même problème car on n'aurait pas à lui greffer systématiquement 5mo de plugins, librairies et frameworks directs pour faire le moindre truc, un peu comme une créature de Frankenstein difforme et repoussante.
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++ ?
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.
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);
Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre codede carte bancaire
Mon GitHub
Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
(Contributions bienvenues)
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 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.
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.
Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre codede carte bancaire
Mon GitHub
Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
(Contributions bienvenues)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager