Reprise du message précédent :
Je sais pas pour Bootstrap, mais Foundation permet de ne garder que les parties que tu utilises (que ce soit directement au dl ou via la version Sass). Du coup pas de code superflu en prod

 
dans Bootstrap tu as et le responsive et les plugins donc la question est large. c'est comme demander si c'est bien d'utiliser jquery.
 
Les avantages evidents de bootstrap/semantic/foundation... c'est la toolbox js et l'UI/UX stock qui demande un faible effort d'adaptation de l'utilisateur (un site bs ou foundation ca se grille assez souvent). Le corrolaire c'est que tu es aiguillé sur des paradigmes UX et que si tu as envie de changer un fonctionnement cela semble restrictif. ca l'est, mais c'est pas forcement un mal, je trouve ca ultra chiant par exemple quand on me mets des checkbox deguisé en radio  'parce que ca fait plus mieux'
 
Si un proj utilise 10% du code ben t'as qu'a packager que ces 10%. Le chargement a la demande c'est bon on sait faire maintenant.
La maintenance c'est justement l'inverse. un proj basé sur un framework qui suit les guidelines est plus facilement maintenable qu'un proj en mode c0wb0yZ one shot et ce n'est pas qu'une question d'equipe. Si tu dois reprendre un code homemade quelques mois plus tard ou reutiliser des bouts c'est pratique par exemple. Quand a dire que c'est overkill pour un proj perso ou de petite envergure c'est bon ca va, faut copier 2 repertoires et avoir un boilerplate, vla l'effort.
concernant l'indexation je vois pas le probleme. tu balances ta base CSS en debut de page et tu load tes requires en async a la fin. google aime beaucoup, mais ca a rien a voir avec bootstrap.
 

+1

Je repartirais absolument pas from scratch, même pour un petit projet.
Faut également rappeler que le framework gère l'essentiel des problématique cross-browser, et ça .. c'est juste essentiel quand on fais du dev crossplatform (surtout si IE8 à gérer par exemple)

Après je dissocie les fonctionnalités des frameworks css en 2 :
- les resets, classes utilitaires, système de grid
- les élements d'UX (avec leur JS dédié)

Le premier est indispensable à n'importe quel site pour partir sur de bonnes bases.
Le second on peux s'en passer, surtout si on veux pas avoir ce feeling "bootstrap" pouvant être reconnaissable, il est vrai. Et si on en a besoin c'est juste tiptop. Avec en bonus des modules angular (et surement d'autres technos aussi) qui intègrent ces fonctionnalités the-angular-way (directives : angular-bootstrap par exemple, et ya la même chose pour foundation, etc)

Après ya peut etre des framework plus light que d'autres, mais comme déjà dit maintenant tout se configure à la compilation LESS/SASS pour ne garder que ce dont on a besoin

Je suis en train d'ajaxifier un site.
 
Il fonctionne bien sans ça mais pour avoir une expérience utilisateur plus agréable (menu animé, transition sur les contenus, pas de rechargement), je modifies mes liens de menu par des appels de contenu et un History.pushState();
 
J'aurais des question de best practice pour ce contenu, histoire de ne pas avoir de leak de tout les cotés :
- sur la page contact y'a un gmap, je l'instancie une 1ere fois puis je l'attach / detach du DOM ?
- sur la page contact y'a aussi une vérification de formulaire en JS, pareil qu'au dessus ?
- sur la page galerie j'ai des modales, le mieux c'est que je mette un écouteur click sur mon bloc conteneur et que je dispatch ?

 
Le problème en faisant comme cela, c'est que tu finis par perdre tes connaissances au niveau des problèmes de CSS justement.  
 
Avec les framework qui font le café à ta place, tu finis par ne plus savoir faire du café simplement avec un filtre.
 
Certes, le gout est meilleur, mais si la machine tombe en panne, ca marche plus.
 
Et je trouve que le gout du café original fait à la main est aussi bon que celui fait à la machine. Maintenant, c'est sûr que si tu as 10 clients à servir  en  même temps, la machine est indispensable.    
 
La problématique est un peu la même avec tous les frameworks. Je suis pour les frameworks bien sûr, mais je suis aussi pour le retour aux sources de temps en temps pour s'assurer que tu peux toujours faire les choses à la main et que tu ne perds pas les notions de bases.

Ouais enfin t'as toujours les 10/30/50% de codes spécifiques qui t'obligent de toute façon à mettre les mains dans le cambouis.. C'est pas "magique" non plus les frameworks css...
Après oui ca ouvre la porte à des pseudo-dev qui prennent pas le temps d'apprendre les bases et qui viennent pleurer

Ca marche dans les deux sens et ca depend de la curiosité de tout un chacun.
 
En depiautant des frameworks on apprend plein de choses interessantes et ca force a faire des choix.  
 
Un dev qui s'interesse un minimum a ce qu'il fait va evaluer la pertinence d'un fw par rapport a un autre et ce faisant va forcement etre sensibilisé a certaines approches.
 
Les petits projets c'est justement parfait pour ca. Ca laisse le temps d'analyser plus en detail les implémentations et de jauger in-situ. (i.e le modal dialog de bootstrap c'est resté bien trop longtemps de la crotte.)
 
Dans le meme temps autant ca ne m'a jamais gené d'etudier certaines implémentations, autant des qu'on me parle d'ASM ou de C ca me saoule des le départ parce que justement j'ai *choisi* de dropper ces compétences.

 
- s'il existe pas tu le cree, s'il existe tu le centre. vu que tu handle les changements de contenu tu peux decider de fare un cleanup apres un nombre de contenu différents prédéfini.
- si la verif de formulaire est en js, pas de raison de la degager puisque par definition elle sert quand il y a une erreur.
- vaut mieux preparer un listener sur ton conteneur et lier le click aux elements galerie, 2 raisons : la premiere c'est que tu peux identifier directement ton element sans avoir a gerer la position de l'event et le fait que l'etat du conteneur puisse changer (sort, chargement ajax ), la seconde c'est que du coup tu peux attaquer les siblings pour les previous/next.
 
en best practive tu fais en sorte que la page sans JS passe. l'ajax c'est du progressive enhancement.

 
C'est beau ce que tu dis.

J'ai apache qui est tombé pour je ne sais quelle raison. Un restart a résolu l'affaire, mais j'aimerai savoir pourquoi il s'est arrêté. Les logs d'apache ne donnent rien, où est-ce que je peux avoir plus d'infos sous debian ?

 
Le syslog ne dit rien ? Error log d'apache ? Ta l'access log qui dit plus rien à partir d'une certaine heure ?

J'ai tenté  grep apache /var/log/dmesg et  grep apache /var/log/syslog, rien. Le error.log n'est pas suspect et dans le access.log, le access.log.1 fini le 21/Feb/2015:20:28:10 et le access.log courant commence le 23/Feb/2015:13:43:31.

C'est pas forcémement lié directement à Apache : il ne faut présager de rien, prend le temps de lire les journaux sans filtres aux alentours du 21/Feb/2015:20:28:10
 
Je suppose que le 23/Feb/2015:13:43:31 c'est quand tu as restarté ?

 
Tu aurais pas fait une mise à jour, ou tu es sûr qu'il n'y a pas de MAJ auto ? parce que s'il n'y a strictement rien dans les logs, ca peut-être qu'apache a été arrêté et non redémarré.
 
D'habitude, les OOM déclenche l'OM killer et tu dois avoir au minimum une ligne dans le syslog. Si tu as un crash d'apache, tu devrais avoir une stacktrace ou quelque chose...  

 
 
Thanks pour vos retours.
En fait j'utilise systématiquement du framework CSS/JS pour les back-office car là du coup c'est vraiment idéal et un temps gagné très important pour un résultat ultra propre et bien pensé.  
Mais quand tu es dans un front office, imaginons vous devez faire la nouvelle version d'allociné avec des tonnes de formats différents, du contenus multimedia, un nombre important de type de pages différents, et une charte graphique précise, etc.  
Là parfois tu te demandes si devoir tout repersonnaliser et modifier pour que ça corresponde à ce qu etu veux, n'est pas plus long et plus pénible que de refaire un truc from scratch
 
Par exemple je trouve que les systèmes de grilles sont souvent case-noisettes et pas très adaptés à des sites qui ont des mises en page complexes et où rentrer dans le moule de la grille n'est pas forcément possible ou arrangeant, etc.  
 
Et IE8 c'est moins de 3% en Janvier 2015 au niveau mondial, donc bon On l'a exclu des navigateurs à supporter dans le cadre du projet.
 
D'ailleurs Angular c'est bien ? On m'en parle de plus en plus, j'ai vaguement survolé le truc, j'ai l'impression que c'est un Jquery-like mais il semble que non  
J'ai pas vraiment compris les cas concrets où c'était utile/pertinent de le mettre en place.

les mise en pages complexe c'est particulier.
soit l'UX designer a fait son taff avec le créa et les blocs récurrents sont identifiés avec leurs declis, auquel cas ca s'apparente a un jeu de construction.
soit le taff est pas fait et la c'est la fete a la saucisse. J'ai deja eu le cas ou une equipe de "créa/IU/UX/intégrateur" m'ont fourni des templates ou il y avait une css différente pour chaque page et aucune construction semantique, ben je peux te garantir que c'est la loose et qu'il vaut mieux refuser de bosser sur ce type de projets.
 
la grille c'est au couple crea/UX de la gerer et de définir des comportements. des qu'il y a plus de 4-5 type d'interactions possibles tu sais que c'est mal parti.
 
le paradigme d'angular c'est grosso merdo de lier dynamiquement des vues et des modeles. c'est interessant si un meme modele peut presenter des vues différentes et/ou concurrentes. un cas concret ce serait d'avoir une description produit ou les elements affichés sont liés au modele. si tu charge un nouveau produit (en ajax), tu modifie le modèle et du coup les elements sont mis a jour automatiquement.

 
Mais tu peux déjà faire tout ça uniquement en ajax non ?
Du coup je comprends pas ce que ça apporte de plus

Nan mais je crois que tu n'as rien compris, l'ajax c'est juste charger une ressource sans recharger la page, et ensuite la traiter.
Donc faire de l'ajax et recevoir du HTML fourni par le serveur et le cracher directement, ouais ça tout le monde sait faire.
 
Mais là on est au delà de l'ajax, là on parle d'un modèle de données que tu mets à jour, donc tu peux le mettre à jour via différentes sources (action utilisateur, ajax ou whatever) et là ce qui est intéressant c'est que la vu se mets à jour sans que tu aies à faire quoi que ce soit (ou très peu)

Ignorer 3% de ses clients potentiels c'est pas rien quand même

 
en effet je n'ai rien compris car mettre à jour le modèle via différentes sources en allant chercher les données j'ai l'impression qu'on le fait depuis longtemps avec javascript sans avoir besoin de librairy
 

 
Là je te parlais du chiffre monde, dans le cas du projet, la version actuelle qui supporte IE8, reçoit 1.55% de visiteurs tournant sous cette version en Janvier 2015 et c'est en constante diminution, en Janvier 2014 c'était 3.8% et en Janvier 2013 c'était 7.2%.
A priori quand la nouvelle version sera lancée on sera sous la barre des 1%. On va donc pousser les derniers utilisateurs IE8 via un bandeau à se mettre à jour mais on ne va pas s'embéter à consacrer du temps à IE8 alors que depuis des années ils divisent par 2 ses utilisateurs et qu'il risque d'être pas loin des 0.5% l'année prochaine Au contraire c'est en ne soutenant plus IE8 qu'on accélère sa mort.

Sauf que tu le fais à la main et ça t'oblige à un paquet de lignes de code, et là angular te propose simplement de faire du templating dans ton HTML et c'est lui qui gère toutes ces lignes de code fastidieuses.

 
Je me suis cru Vendredi.

bah tu fais comme d'hab. "Bonjour, pour ces 3% potentiels il faut debloquer 50% de budget en plus et reduire la voilure du projet global. On est bon ?"

Ouaip je sais que c'est chiant et cher de supporter les vieux navigateurs
 
Mais derrière ces 3%, ou 1%, y'a 3 personnes sur 100 qui vont se pointer sur le site et avoir encore une
emmerde avec leur ordinateur, un truc qui marche pas, encore un messages cryptique qui les détournent
de leur tâche initiale, un message qui les éduque à faire confiance à un site qui leur demande d'installer
un logiciel alors qu'ils se sont déjà fait engueuler 10x parce qu'ils "installent n'importe quoi".
 
Une part du boulot c'est d'être spécialiste de notre domaine et d'utiliser cette connaissance pour fabriquer
un truc qui marche, même si des fois c'est pas très marrant. Je suis pas super fan de limiter notre boulot
à un truc cool qui ne fonctionne que dans des conditions idéales et de laisser fuir les problèmes et guerres
techniques internes à notre domaine pour les imposer aux utilisateurs.
 
Y'a forcément un moment où il faut faire un compromis (peut-être 1%, 0.5%, j'en sais rien...), mais
de fois je vois monter ce chiffre un peu haut et des devs oublier les utilisateurs au passage.Ça empire vite
quand c'est combiné à un site qui marche mal avec une connection médiocre, avec des gens à la vue
réduite, etc. Parfois ça finit par faire beaucoup de monde pour qui on a pas fait notre boulot correctement.
 
(Après y'a aussi le risque, pour un site suffisamment gros, de perdre vachement plus de thunes en ventes
manquées que le coût du temps de devs, manque à gagner pas forcément facile à observer si on ne fait
qu'un site "moderne" et qu'on a aucun point de comparaison).

 
Sur la version actuelle du site qui supporte IE8, on peut voir le gain pour chaque utilisateur en recoupant avecp lein de critères. Pour une raison que j'ignore ceux qui utilisent IE8 sont ceux qui nous font gagner le moins de $$$$ (peut-être qu'en plus d'utiliser IE8, ils ont pas flash d'installer dessus ou que leur écran est en 800x600 et n'affiche pas tout correctement ou je ne sais quoi ).
C'est un site de contenus, les gens viennent par google, lisent une page ou 2 et se cassent. Comme on le fait tous.

Ouep mais ce n'est pas la responsabilité du dev de choisir si on traite. On expose le probleme et les metriques, les decideurs decident en fonction des infos qu'on leur donne.
Apres on peut proposer des alternatives en fonction de l'objectif et c'est ca le taff.

Yo! petite question de logique en PHP, je teste si mes variables (Post Meta Values sous Wordpress) sont renseignées, auquel cas je les affiche. Comme indiqué sur la doc je fais un:
 

<?php if( get_field('field_name') ): ?>
    <p>My field value: <?php the_field('field_name'); ?></p>
<?php endif; ?>

 
ça marche bien, mais je voudrais savoir pourquoi le if renvoie TRUE lorsqu'une chaine existe mais qu'elle est vide...  j'ai bien la confirmation en faisant un var_dump

<?php if( get_field('field_name') ): ?>
    <p>My field value: <?php the_field('field_name'); ?></p>
<?php endif; ?>

M'étonnerait ça : http://3v4l.org/aSBbf

 
c'est vrai, j'ai testé.. ça renvoie bien un false.. ça doit venir de cette fonction get_field() alors  
 
Merci
 
edit: pourtant quand je fais un var_dump(get_field('field_name')) j'obtiens un String(0) ""..  

C'est un problème qui existe depuis la nuit des cartes perforées ou presque, mais pas dans les même proportions, notamment à cause la montée de version qui peut-être freinée par divers facteurs. Le web c'est probablement la plateforme actuelle la plus chaotique qui soit.
Avant de dégager le support ou d'ajouter X merdes pour pallier le manque d'API et un support médiocre de telle ou telle feature, pourquoi ne pas faire une version dégradée, ça serait pas un bon compromis?

Au final ce dont on parle c'est de l'accessibilité : est-ce que je dois rendre mon site accessible aux personnes sous IE8 ? Tout comme il faut se poser la question pour les clients avec handicap, les clients avec une connexion réseau pourrie, les crawlers pour le SEO, les clients avec des devices avec plein de résolutions.
C'est ensuite un choix stratégique de voir ce qu'on décide de supporter, soit en fonction d'un ROI purement financier (genre 2% de mon chiffres d'affaires je m'en cogne par rapport au coût des développements pour assurer la compatibilité).
Ca peut également être un choix lié aux valeurs qu'on décide de porter ("je veux que mon site soit le + accessible possible" ).
Et accessible ne veut pas dire que ce soit iso-fonctionnel et iso-design pour tous les clients. Là aussi c'est un choix à faire.

ça peut être aussi un choix de devis, genre compatibilité IE8 -> xxx €.
et pour justifier le cout au client, tu dis que microsoft a officiellement abandonné IE8 depuis avril 2014.

 
Je vois pas bien ce que l'accessibilité vient faire la dedans.  
Mon site est crossplatform (android / ios et PC) et compatible IE8.  
IE fait globalement chier au niveau du JS et du CSS, mais niveau accessibilité les techno sont pas trop mal implémentés (exemple : http://caniuse.com/#feat=wai-aria) et j'ai aucun soucis à rendre mon un site sous IE8 autant accessible que le même sous chrome.
 
Et en mode Bootstrap + angular + autoprefixer, de mon coté, IOS (ou browser stock samsung) me fait souvent beaucoup plus chier que IE8

 
Voilà
 
Le support d'un vieux navigateur implique d'ajouter des polyfills pour tout le monde,surtout si on souhaite avoir un rendu identiques sur les vieux navigateur
Tu te retrouves avec des packages de js/css qui gonflent et des persf qui s'écroulent.
 
 
Au final, après pas mal d'essai dans des directions différentes, je trouve que ce qui me convient le mieux c'est une app adaptative IE10+  et un rendu serveur avec une navigation à l'ancienne. La compatibilité IE9 est possible, mais les perfs sont moins bonne qu'avec un rendu serveur.
Ca découple bien les choses, ça règle complètement les questions d'accessibilité et la surcharge de taf n'est pas insupportable. D'ailleurs je pense même que la prochaine génération de mes dev poussera un peu plus loin la démarche avec un rendu serveur immédiat, puis un démarrage de l'app coté client (si c'est possible avec le navigateur ) : backbone ou react se prêtent assez bien à ce fonctionnement
 
Pour rappel , je construit des application de gestion métier, ppas des sites de com.

pour faire de jolies captures de vos app, le tout gratuitement et en HD : http://magicmockups.com/ et http://mockdrop.io/

Z'avez déjà essayé atom (c'est un éditeur) ?
Dans ce qui a l'air d'être le même esprit, j'aime bien brackets.io aussi.

Atom les opticiens ?

 
J'ai essayé, ainsi que sublime ainsi que brackets et au début j'ai bien accroché, mais au final, c'est moins efficace que de garder le même IDE pour tout. Et je reste habitué à netbeans
 
Ya toujours un plugin qui fait ce que je veux et pour le reste je suis un inconditionnel de la ligne de commande.

Atom est pas mal, mais à l'époque où testé, encore inférieur à Sublime (moins rapide que celui ci surtout)
Idem pour Brackets.

par curiosité y'a des frameworks JS server-side qui permettent de coder en ES6 ?
 
côté client si j'ai bien compris on peut passer par un convertisseur qui prend le code ES6 pour en faire du ES5...
 
disons que j'ai du mal avec ES5, y manque quand meme pas mal de trucs par rapport à Python par ex

https://babeljs.io avec Gulp chez nous