Reprise du message précédent :

 
Tu découvres l'IT en fait ?

Ça peut être du code spaghetti en PHP5 et Vanilla JS, ça n'empeche pas que si le code est propre, documenté, et logique, ça reste maintenable.
Maintenant je suis d'accord, on voit un peu de tout dans WP (malheureusement)

j'aime beaucoup cet article : https://blog.codinghorror.com/falli [...] f-success/
 

Mes derniers contacts avec WP ne m'ont pas laissé cette impression, mais j'ai probablement beaucoup à apprendre dessus

WP n'est pas fait pour faire des webapps comme ça, c'est sûr
Je fais du WP, j'aime bien pour la simplicité, et ça répond aux besoins de 80% de mes clients :
- Un thème avec quelques templates
- Un plugin sur mesure pour ajouter des fonctionnalités (espace privé, hooks, champs perso, editing de backoffice, etc)
Si c'est bien fait, tout est en surcouche, 0 soucis avec les autres plugins et MAJ

 
Dans quel language/environnement on voit le moins de tout ?
 
Perso, j’ai l’impression que n’importe quel code qui a plus de x années et vu passé plus de y développeurs est moisi si un effort n’a pas été fourni.

 
Pas besoin de revenir en arrière hein. Lors d'une mission, j'ai vu une appli angular sans components

Le SEO c'est vraiment un repère de croyances dans fondement
Le crawler Google interprète le JS : https://developers.google.com/searc [...] seo-basics grâce à un chromium headless

Donc ta page react sera indexée tant que tu déconnes pas sur le temps de chargement

Le crawler Google seulement, et encore. Donc tu écartes tous les autres moteurs de recherche. Par ailleurs, l'efficacité est très limitée, j'ai testé une de mes webapp justement, page blanche alors que le chargement est instantané.

Le seul "truc devops" de la liste, c'est docker. T'es vraiment sûr de savoir de quoi tu parles?... parce que t'es bien condescendant.

Webpack c'est aussi devops. Puis tant qu'à être précis, WP, il n'y a presque rien de frontend hormis le templating.

Je ne suis pas condescendant, je réponds aux gens qui insultent WP sous prétexte que ça ne correspond pas à leurs besoins ...

 
En partie, j’ai jamais bossé pour ce département    
 
J’ai fait que des éditeurs de logiciel personnellement et pas au service IT  

 
Le crawler JS de Google passe avec une fréquence et un débit bien moindre que le crawler standard.

Ça existe encore ?
(Celui de MS je l'ai installé pour avoir des points rewards, qui font des réductions sur les jeux xbox, mais c'est une plaie. Je suis systématiquement obligé de relancer ma recherche dans google)

 
Je confirme, pas besoin de remonter bien loin pour trouver des horreurs  
 
Je bosse sur une "webapp" ou chaque page est un "composant" React de 2000+ lignes blindé de jQuery
Une vraie oeuvre d'art, chaque framework / lib / outil est tordu au max pour faire ce qui est voulu sans se demander si l'outil est le bon    
Et un petit process "maison" par dessus tout ça où on a l'air d'être partis pour réinventer un SCRUM bancal  

Tu as l'air d'impliqué que faire du wordpress rend les gens captif, ce qui est un peu antinomique avec le fait que toutes les boites ont eu a un moment ou un autre a faire du wordpress...
 
Ce qui rend captif c'est au contraire de faire un dev spécifique sur un technologie de pointe, dans ma bousie t'auras plus de mal a te faire reprendre un projet avec vos technos de hipster, alors que les clients qui font le tour des agences avec leur wordpress existant, c'est monnaie courante !
 
NB: Ou alors j'ai rien compris a ce que tu voulais dire par sangsue...

Ho putain, le truc casse gueule et qui tue les perfs

Délicieux !

Ah oui pas mal.

Du coup je viens de vérifier la webapp sur laquelle je bosse, mon plus gros fichier (loin devant les autres) fait 1020 lignes.

C'est un composant Vue (un formulaire un peu complexe) qui contient HTML (438) + JS (410) + CSS (172).

Tout le reste est largement plus petit.

(edit: Par contre pas de jQuery hein, 'videmment )

 
Oh t'en fait pas, je maitrise plutôt pas mal ^^ J'adore fonctionne en petits composants.
 
Là c'est un peu particulier, il y a certes beaucoup de code, mais rien d'anormal. Je ne verrais pas trop l'intérêt de découper ce formulaire en plusieurs composants, ça ne s'y prête pas du tout et ça rajouterait en complexité au niveau de la validation.
 

 
Si, mais je préfère justement fonctionner avec des Single File Components.
 
Je trouve que c'est un très gros avantage d'avoir tout dans le même fichier, surtout avec les scoped styles (après, tout est compilé lors du build).
 
https://fr.vuejs.org/v2/guide/singl [...] nents.html
 
Si tu as une modif à faire sur un composant... il te suffit d'ouvrir son fichier et tu as directement accès à tout le nécessaire.

Je vous ai parlé de l'implémentation Redux? Le pattern habituel pour fetch de la data est bien folklo aussi
 

// composant
getInitalState() {
  return {
    MachinId: this.props.MachinId,
  };
},
 
componentDidMount() {
  const self = this;
  store.dispatch({ type: 'FETCH_MACHIN', id: self.state.MachinId });
}
 
// reducer
case 'FETCH_MACHIN':
  MachinAPI.fetchMachin(action.id);
  return state;
case 'UPDATE_MACHIN':
  let stateCopy = { ...state };
  stateCopy.machin = action.json;
  return stateCopy;
 
// api
// je vous passe la validation
function listMachins(MachinId) {
  // const url = ...; const options = ...;
  fetch(url, options)
    .then(function(response) {
      return response.json();
    })
    .then(function(json) {
       store.dispatch(type: 'UPDATE_MACHIN', json: json);
    });
}

// composant
getInitalState() {
  return {
    MachinId: this.props.MachinId,
  };
},
 
componentDidMount() {
  const self = this;
  store.dispatch({ type: 'FETCH_MACHIN', id: self.state.MachinId });
}
 
// reducer
case 'FETCH_MACHIN':
  MachinAPI.fetchMachin(action.id);
  return state;
case 'UPDATE_MACHIN':
  let stateCopy = { ...state };
  stateCopy.machin = action.json;
  return stateCopy;
 
// api
// je vous passe la validation
function listMachins(MachinId) {
  // const url = ...; const options = ...;
  fetch(url, options)
    .then(function(response) {
      return response.json();
    })
    .then(function(json) {
       store.dispatch(type: 'UPDATE_MACHIN', json: json);
    });
}

 
avec les hooks react et le context + usestate dans le context je me fais 10x moins chier à écrire.
Idem pour fetch de la data, j'enrobe le fetch d'un hook et hop magie

 
Le mono fichier je suis fan, ca force les équipes a pas faire des composants qui font tout mal, mais qui sont plus spécialisés. Par contre le scoped styles j'ai toujours entendu que niveau perf c'était a bannir...

 
J'aimerais bien voir un vrai benchmark pour ça, parce que j'ai un gros doute sur le fait que ce soit suffisamment significatif pour ne pas l'utiliser.

C'est genre... Dans la doc
 

 
https://vue-loader.vuejs.org/guide/ [...] -selectors
 
Apres le lien est broken... Mais quand j'ai lu ca perso j'ai juste dit "ok les scopes CSS sont banni", ben au final ca pose 0 soucis, c'est juste être plus que flemmard de pas prendre 2sec pour prendre un nom jamais utilisé

Nan mais je sais que c'est dans la doc Et déjà lu ce débat par-ci, par-là.
 
Ce que je veux dire, c'est que je n'ai jamais vu personne arriver avec une vraie raison concrète d'arrêter d'utiliser scoped. Dire "c'est moins bon pour les perfs", OK... mais je n'ai pas trop envie de me prendre la tête à ne pas utiliser les scoped et trouver des noms uniques à chaque fois pour avoir le loisir de me masturber le soir en me disant "ouaiiiis j'ai gagné 2 millisecooonndes hummmm"

C'est pas 2ms, c'est environ 3x plus lent, et ca peut viter grimper.
 
Maintenant je t'invite a voir le fonctionnement interne de PostCSS (puisque Vue base son scoped style dessus) pour voir que non, c'est pas transparent, pas du tout meme:
 
https://github.com/postcss/postcss/tree/master/lib
 
Enfin si c'était 3 lignes de code je dirais que oui, la je dirais plutot que tu as de la chance que les PCs soient pas encore des vieux 486 .
 
Apres chacun place la barre ou il veut, mais perso perdre du temps de rendu pour un truc si facile (enfin trouver un nom c'est pas la fin du monde hein), clairement marqué dans le doc -en plus-, et qui n'apporte vraiment pas grand chose au final, ben simplement non, trouve un nom, tu peux mettre un truc purement random ca me va, mais au moins tu declenches pas tout ce code pour rien...

En fait je ne suis pas sûr qu'on parle de la même chose.
 
Dans la doc, ils expliquent que (en scoped), un p { color: red } sera beaucoup plus lent qu'un .example { color: red }.
 
Et ils disent bien que "If you use classes or ids instead, such as in .example { color: red }, then you virtually eliminate that performance hit"... et non pas qu'il faut arrêter d'utiliser scoped.
 
Enfin c'est ce que je comprends.
 
Pour moi, il faut juste éviter d'utiliser un p {} (ou div {} ou whatever{}) mais plutôt utiliser des noms de classe.

Je pense que tu fais un malentendu sur la doc :

Pour moi tu as oublié la deuxième partie de la phrase. Parce que dans le contexte de VueJS, le fait d'être "scoped", ça veut dire que PostCSS te rajoute automatiquement à ton élément HTML, dans le DOM, un data attribute aléatoire, qui va également aussi être ajouté à ton sélecteur CSS. Et c'est le fait d'avoir ce sélecteur attribut dans le CSS qui rend ça plus lent.

Non, je ne pense pas

Moi ce que je comprends c'est que p[data-v-xxxx] c'est beaucoup plus lent que p.toto, mais p.toto[data-v-xxxx] c'est aussi rapide que p.toto

Parce que "c'est aussi rapide" est parfaitement faux.
Peut etre ton pc est suffisamment rapide pour que ca t'apparaisse avoir la même vitesse, mais c'est absolument et strictement impossible que ce soit la même vitesse, parce que p[whatever] c'est pas magique, tu dois:
 
  - généré un id unique (et donc prendre de la ram pour savoir si tu as déjà vu ou non cet id)
  - Parser le CSS a la rechercher de tous les éléments "root", et leur coler ca juste apres (que p { } devienne p[data...] {}). MAIS tu peux pas juste partir du principe que le premier sera le bon, vu que le scoped CSS demande que tous les roots soient scoped, et le CSS t'autorise a mettre autant de root que tu veux dans ton doc. Ce qui veut dire que tu dois te tapper TOUT le CSS, t'a pas le choix.
  - Faire la même chose sur le document HTML, et lui coller les attributes qui vont bien. Mais pour l'HTML c'est rapide car tu peux construire le DOM en ram et juste coller au root de ce DOM l'attribut.
 
Tout ça en pure JS car plein de navigateurs ne supportent pas (d'ailleurs je crois que le CSS scoped a été retiré du standard).
 
Et tout ca, c'est purement inexistant si tu te mets pas en scoped et trouve un nom assez unique pour passer le tout en CSS global
 
Maintenant je pense qu'ils disent que c'est aussi rapide car avec Vue, quand tu arrives en prod, tu vas build tes fichiers en statiques, et donc en fait tu vas te tapper toutes ces étapes a ce moment, donc en gros ton build sera plus lent, mais le résultat pareil car pré-buildé (PS: j'ai check des vieux codes Vue, c'est le cas il pré-build ca).
Sur de petits projets ca le fait easy, sur de gros ca peut commencer a avoir un impact...
 
 
Et concernant le pourquoi du comment p[data...] vs p.toto, on va pas trop rentrer dans les détails, et en plus ca change tout le temps, mais en gros habituellement un moteur de rendu HTML va construire trois choses:
  - un index btree pour les classes => sert a trouver les éléments a partir du nom d'une classe (tres rapide)
  - un index btree pour les ids => sert a trouver les éléments a partir d'un ID (théoriquement encore un peu plus rapide que les classes)
  - un tree classique pour le DOM => le reste quand il sait pas comment chercher (lent car tu dois te tapper tout le dom)
 
Sachant qu'il peut construire ce qu'il veut. Il peut bien sur construire un Btree des node types (a, li, p, ...) s'il veut, mais plus c'est varié, plus l'index est efficace donc pas sur qu'ils s'emmerdent avec les node types...
 
Et donc, ben s'il veut applique p.toto, il va partir dans le btree des classes chercher les éléments "toto", ensuite filtrer les "p", et coller le CSS a ce qu'il a trouvé.
Cad au lieu de se tapper tout le DOM en descendant, il va directement tapper aux 5 objets en ram qui ont cette classe et ensuite voir si ca colle ou pas avec le "p" qu'il reste a tester.
De l'autre coté, ils ont pas d'index sur les attributs que je sache, donc il va se tapper tout le dom a la recherche de l'élément perdu...
 
Sachant que le DOM est construit de telle sorte qu'un noeud connait son parent, et ses fils, il peut facilement ensuite descendre ou remonter au besoin dans tous les cas (et donc appliquer les autres points CSS).
 
Bref c'est qu'une implémentation possible, mais de souvenir c'était encore en vigueur chez Gecko (l'ancien moteur de rendu de FF). Et bien sur prend pas ca comme sainte vérité car c'est de l'algo pur, tu peux en faire ce que tu veux (et je me doute qu'il a des techniques plus rapides en vigueur aujourd'hui)...
 
Un article grosso merdo sur le sujet
https://hacks.mozilla.org/2017/08/i [...] aka-stylo/

Salut,
 
Il est autorisé de poser des questions sur quelques lignes de code ici ?  
 
Je sèche sur une bannière et un pied de page    
 
Merci  

 
Avec plaisir

Merci

Le lieu du drame : http://ekasilicium.net/

Edit : le miss clic m'a fait posté de manière prématurée ... j'édite

La bannière :

Actuellement une photo de voiture pour l'exemple, ce sera plus tard une image autre.
Image que j'aurais aimé voir sur les 10 à 20 % de la partie haute de la page. Avec au premier plan, dessus, le nom de site, cliquable pour revenir sur la page principale. J'aurais espéré qu'elle se redimensionne à peu près en "largeur" pour coller aux affichages de résolution différentes.

Mais je n'arrive pas à la mettre en haut. J'ai essayé tout plein de trucs sans franchement les maîtriser.

Et j'ai un pied de page, qui ne veux pas aller en pied de page.

Petite image explicative :

Je sens que j'ai un problème de ?parent? avec les flexbox's.

S'il faut plus d'infos ne pas hésiter.

Même une toute petite aide en une phrase me conviens. Je serais bien gêné de piquer trop de temps pour un truc de "base". Je ne suis pas bien claire j'en conviens.

Merci et A+ !

Pour moi, tu devrais déjà sortir <nav> du <header>. Ensuite il suffit juste de mettre Sommaire et Contenu dans un wrapper que tu vas gérer.

Dans ta configuration actuelle (<nav> dans <header), il va être très bizarre d'arriver à ton résultat car le conteneur de l'image devant être en display: block par exemple, garder le Sommaire et le Contenu sur la même ligne va t'obliger à jouer avec de l'absolute.

Salut,
 
J'ai appliqué t'es conseils et ça marche drôlement fort merci beaucoup !
 
Désormais j'ai un autre soucis, faire en sorte de l'image (qui sera la bannière) ne dépasse pas. Qu'elle ne fasse pas plus de 100% de largeur de l'écran utilisateur. Mais max-width et autres lignes du genre ne fonctionnement pas.    
 
Le lieu du drame : http://ekasilicium.net/  
 
 

il faut appliquer le max-width à l'image  
 
en plus , c'est louche, mais ta ekasiliciumbanner fait 100px de large

Avec le max-width: 100% sur le tag img de la bannière cela devrait fonctionner

Deux choix:

- Tu l'as met en tant que background-image et ensuite en background-size: cover pour qu'elle s'adapte à la <div>. Tu dois gérer la height manuellement mais ça te permet de rogner si jamais tu le veux.

- Tu fixes la width à 100% sur l'image et sur <div class="ekasiliciumbanner"> (comme @flo850 et @David Boring l'ont dit)

Après dans ton contexte, la deuxième est la meilleure solution, je pense.

Par contre, j'ai vite fait regarder le reste et quelques trucs :

- #banniere n'a pas besoin d'être en flex, laisse la en block, rajoute position: relative et mets top: 0 sur #ekasiliciumtitle pour bien caler en haut. C'est plus propre.
- #titrepage pareil, pas besoin de flex, tu peux le laisser en block, supprimer align-items et justify-content, suffit de mettre text-align: center

Flex c'est vraiment à utiliser quand tu as des blocs dans un bloc et que tu veux gérer leurs positionnement, pour les blocs avec seulement du texte, on peut s'en passer.

Salut à tous,
 
Et bien y a pas à dire, dev web, c'est un métier.
 
J'ai fait exactement ce que vous avez dit et tout est rentré dans l'ordre.
 
Je me rends compte que, à plusieurs reprise, j'ai fait des choses qui se mordent la queue. J'ai vu que le W3C propose un "validator" mais j'ai peur
 
J'espère arriver à solutionner mes prochaine problèmes tout seul pour ne pas trop vous solliciter.
 
À plus

Le dev web, c'est un métier mais aussi de l'entraide. Aucun soucis, tu peux poser tes questions et je pense que les gens essayeront d'y répondre avec plaisir.

Par contre n'hésites pas à mettre ça sur CodePen par exemple, qu'on puisse débuger rapidement.