Générateur de site statique
Closed this issue · 26 comments
Quel système de générateur de site statique ?
De mon coté, j'ai un peu joué avec wintersmith, mais plusieurs trucs m'y dérange pour chtiJS :
- C'est écrit en Coffeescript
- ça s'installe bizarrement, je trouve (ça s'installe au global)
Du coup, je comptais regarder du coté de grunt-assemble, voir s'y on y retrouve les mêmes possibilités.
Je ne comprend pas le besoin de générateur de site statique puisque nous avons Grunt ? N'est-il pas possible simplement de faire une tâche de ce genre ?
{ tpl:
main: {
src: "/documents/pages/**/*.tpl",
dest: "/www/",
ext: '.html"
}
}Yep.
Testé et approuvé par @victordarras ce week-end pour son site perso ;) Je plussoie !
Je ne comprend pas le besoin de générateur de site statique puisque nous avons Grunt
Un générateur de site statique c'est juste ça, un plugin grunt en général, où une tâche perso. Au départ je posais juste la question d'utiliser un plugin grunt dédié.
J'ai une branche qui lit les fichiers markdown, les convertit en HTML et emballe le tout (via nunjucks, mais tout autre système est possible). Je la commite ce soir ?
Ça sera une base de départ, je suis pour.
+1 pour moi aussi
(perso j'utilise middleman pour faire la même chose mais c'est du ruby on rails)
👍
Hop, j'ai commité une branche hier soir ( feature/build ).
J'ai travaillé la génération html de fichiers markdown, le système de build et l'environnement de dev (avec livereload).
C'est assez brut de décoffrage (certaines parties devraient être plus "propres"), mais ça marche.
Testez de votre coté, et si c'est OK, je resynchroniserais et commiterais ce soir sur le master.
git checkout --track origin/feature/build pour rapatrier la branche et la déplier dans votre espace de travail.
grunt dev et grunt dist pour tester.
Pour la suite, j'aimerais gérer la partie "syntax highlighting " et une partie "metadata" dans les fichiers Markdown. ça nous permettra d'injecter différentes données au niveau de la page générée (auteur(s), titre, mots-clefs, feuille de style, fichier js, etc...), directement depuis le contenu. Il y a des plugins qui font celà (https://npmjs.org/package/markdown-extra ou https://npmjs.org/package/meta-marked par exemple), C'est aussi faisable à la mano (exemple en Coffeescript : https://github.com/jnordberg/wintersmith/blob/89d74509edaf8893a5de4a41bbfb8d29c7e93b49/src/plugins/markdown.coffee).
---
title: titre de l'article
author: Nicolas Froidure
date: 2012-12-12 12:12
---
# Exemple d'article
## Blah blah
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.
Si tu veux test avec du vrai contenu je me permet de mettre mon article ci dessous :
---
title: Revue de livre javascript
author: David Leuliette
date: 2013-11-02 13:46
---
# Javascript par nicolas froidure
Si vous suivez mon activité sur [twitter](http://twitter.com/_flexbox) vous avez surement remarqué que je lis énormément de livres sur l'industrie du développement web. Mon dernier livre ? Javascript™ rédigé intégralement en français par monsieur Nicolas Froidure himself.
Cet article présente ma revue de la version poche, ainsi que le contenu que j'ai retenu de ces 400 pages de code.
## Le format poche
Pour commencer, j'ai trouvé le format poche (ou tablette 9') génial. Il se glisse partout et vous pourrez facilement le sortir pour passer le temps.
Il m'a fallu un peu plus d'un mois pour parcourir l'intégralité des 12 chapitres consacré au langage Javascript : rappel des fondamentaux, travailler avec des objets, utiliser des tableaux, les API HTML5, nodeJS ...
Le fil rouge de l'ouvrage est la création d'un jeu de memory. Ce concept permet de présenter une utilisation concrète dans un environnement de développement contrairement à une présentation aléatoire de [snippet]() divers et variés. L'intégralité du code source est disponible sur [github](http://github.com/nfroidure). Vous pouvez aussi [tester directement](http://memory.insertafter.com) le rendu final du jeu.
## Contenu
L'objectif du livre est de guider pas à pas les lecteurs en expliquant chaque notion simplement.
- Structure d'un fichier Javascript : variables, instructions et expressions.
- L'appel aux fonction et leur effet de retour (callback).
- La gestion des erreurs.
- La notion d'objet avec une explication des concepts de constructeur, d'instance, de prototype, d'héritage ...
- La manipulation de chaîne de caractères et les [expressions régulières](regexp).
- Les calculs à l'aide de l'objet Math.
- Utilisation des tableaux.
- Les méthodes dates & les fonctions natives de Javascript.
- Coder dans le navigateur et comprendre le DOM.
- Le chargement de contenu distant avec XMLHttpRequest, et leur transport via JSON.
- Les API HTML5 (TouchEvent, Camera, appcache, ...)
- Créer des applications interactives et participatives avec NodeJS.
## Ce que le front-end dev a retenu
Le Web évolue rapidement. Les intégrateurs ont été majoritairement touchés par les changements récents dans les techniques et les approches de codage. En 2003, un intégrateur compétent maîtrisait HTML et CSS, avec un peu de copier-collé JavaScript. Nous avons construit des sites web qui étaient consultés sur des ordinateurs de bureau.
Mais nous sommes en 2013 ! Maintenant, un développeur Web front-end compétent baigne dans HTML et CSS, JavaScript et jQuery, les preprocessors CSS ..., la complexification des interfaces demande une certaine maîtrise de Javascript.
Comme expliqué dans l'introduction de ce livre j'ai appris Javascript plutôt par obligation, mais aussi par curiosité, sur le tas. Mon niveau est toujours proche du néant mais je me [débrouille mieux](http://pokemonbreakpoint.fr) Je me considère plus comme un utilisateur de Framework que développeur JS. Les 200 premières pages sont et resteront toujours obscures à mes yeux mais cela permet de connaître l'origine de certaines librairies qui sont -trop souvent- incluses sans forcément en avoir besoin (Les 250 Ko de jQuery par exemple)
J'ai découvert grâce à ce livre pas mal de notions :
- `console.trace()` pour dépiler toute votre stack JS
- `document.getElementByTagNames()` pour récupérer une liste d'élément ayant un nom de balisage précis. `.is()` en jQuery c'est tout de suite plus simple.
- Créer des applications web hors-ligne à l'aide d'un fichier .manifest
- Les Touch event mdn API HTML5 et son équivalent `pointerEvent` pour les technologies Microsoft.
- NodeJS : Créer un serveur et utiliser `npm`
## Pour le prochain Tome
> Javascript c'est un peu comme les échecs. Dès que l'on maîtrise les règles, on se rend compte qu'on ne sait pas jouer
>
> David Leuliette
Ce livre permet de vous enseigner/de revoir les bases de ce langage mais je trouve qu'il manque certains chapitre entièrement dédiés concernant :
- Les conventions de codes
- La performance qui devient vite critique sur les grosses applications
Mais ces 2 sujets méritent des livres entiers rien que pour eux. Il existe aussi une version normale du livre avec des bonus comme
- La performance
- Les design patterns
- Les frameworks
- La boite à outils du développer Javascript
J'attends avec impatience la version 2 !
Si Javascript vous interesse rapprochez vous de l'initiative FranceJS qui regroupe de nombreux développeurs talentueux à travers toute la France.
Dans ch'nord nous avons [@chtijs](http://twitter.com/chtijs) qui organise régulièrement des rencontres. N'hésitez pas à venir rencontrer les fondateurs [@nfroidure](http://twitter.com/nfroidure) et moi même.
Cool ! Je t'invite à commiter le fichier sur la branche (dans documents/contenu/) et à tester un petit peu (notamment l'ajout d'image via le markdown)
Pour définir des metadatas dans le markdown, il y a pas mal de solutions. Je n'ai pas eu le temps de regarder et d'analyser. J'ai ouvrir une "issue" sur le sujet.
Au fait, question con : HappyPlan (ce que les gars de putaindecode ont écrit et utilisé pour leur site) n'était pas une option envisageable ? Pourquoi ?
Toutes les options étaient envisageables :). Moi j'aime bien l'idée de se faire un truc custom pour pouvoir justement creuser le sujet. Un truc complètement packagé nous aurait rien appris finalement.
OK, c'est une excellente raison :) Ils ont probablement eu la même réflexion d'ailleurs !
Par contre, si on résume, la solution de @0gust1 semble bien. Il nous reste quoi à faire à part les textes et le design pour avoir un truc potable ?
Du contenu incroyable :)
J'ai 2 questions con :
Ca fonctionne les fichiers de settings en .yml ?
du genre
https://github.com/flexbox/webcitation/blob/master/data/settings.yml
Ce serait beaucoup plus simple pour gérer le contenu dans des fichiers
team.yml, social.yml une simple boucle et hop notre contenu est généré :)
- .less c'est obligé ?
J'ai essayé de refactor un peu ... mais compliqué j'ai plus l'habitude du
sass / scss ça vous dis pas de changer de crèmerie ?
Le 6 décembre 2013 15:21, Nicolas Froidure notifications@github.com a
écrit :
Par contre, si on résume, la solution de @0gust1https://github.com/0gust1semble bien. Il nous reste quoi à faire à part les textes et le design pour
avoir un truc potable ?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-29997394
.
David Leuliette
Front end Developer
Perso je préfère le LESS (et oui, je compte participer !) ; si vraiment c'est gênant pour certains, Stylus peut être un bon compromis avec sa syntaxe souple :)
@flexbox : pour les fichiers yaml, c'est carrément possible je pense ;) => http://gruntjs.com/api/grunt.file#grunt.file.readyaml
Je suis plutôt pour, c'est moins lourd à éditer, plus sympa pour les yeux que du pur objet JS ou du JSON. On pourrait facilement gérer l'annuaire des membres comme ça.
@flexbox, @neemzy : Héhé, de mon coté, je ne souhaiterais pas trop partir direct sur du LESS ou du SASS. J'aimerai garder un fichier CSS "classique" aussi.
On pourrait concatèner la sortie du compilateur LESS ou SASS à ce fichier CSS classique et on passer le tout à la moulinette de la minification.
Et une fois ce fichier CSS un peu étoffé, vous pourriez nous faire une micro présentation / atelier sur "comment factoriser / migrer du CSS avec LESS/SASS" ;-) héhé. Et @flexbox pourrait nous SASSiser la génération des icônes SVG de Nico \o/
Enfin, en tout cas ça m’intéresserait.
En fait il y a déjà LESS dans le projet :) Mais après du pur CSS me va aussi très bien, personnellement ; pour le peu de styles qu'il y aura, ça n'empêchera pas d'avoir quelque chose de facilement maintenable. Si de plus on peut mêler fichiers "natifs" et fichiers "à préprocesser" (c'est le matin), tout le monde devrait y trouver à peu près son compte !
Je suis pour les préprocesseurs car ça permet de voir l'essence des CSS plus facilement. Si je prend l'exemple du rythme vertical, une fois qu'on sait qu'il faut être multiple de @vrythm pour toutes les hauteurs, on ne risque plus d'e faire des erreurs. Par contre, cela manque de commentaires pour diminuer le gap avec les newcomers et éventuellement, on pourrait peut-être aussi indiquer un ordre dans lequel consulter les fichiers pour mieux les comprendre.
Après entre less et sass, le souci de sass est qu'il crée une dépendance à Ruby et j'aurai vraiment aimé avoir un repo pur JS. J'avais essayé libsass au travers de grunt-sass qui est en pur C&JS, mais là c'est au niveau des options que ça pêche (notamment au niveau des arrondis).
Je pense que c'est ceux qui contribueront aux CSS qui doivent choisir les outils vu que c'est le principal intéressé. Pour ma part, le seul truc qui me tient à coeur est de rester sur full JS.
Humm je ne savais pas que sass était obligatoirement marié à ruby.
Tu as raison nicolas full stack JS sinon rien :)
/***************************/
- David Leuliette
- Front-end Developer
- blog.davidleuliette.com
/***************************/
Le 7 déc. 2013 à 10:37, Nicolas Froidure notifications@github.com a écrit :
Je suis pour les préprocesseurs car ça permet de voir l'essence des CSS plus facilement. Si je prend l'exemple du rythme vertical, une fois qu'on sait qu'il faut être multiple de @vrythm pour toutes les hauteurs, on ne risque plus d'e faire des erreurs. Par contre, cela manque de commentaires pour diminuer le gap avec les newcomers et éventuellement, on pourrait peut-être aussi indiquer un ordre dans lequel consulter les fichiers pour mieux les comprendre.
Après entre less et sass, le souci de sass est qu'il crée une dépendance à Ruby et j'aurai vraiment aimé avoir un repo pur JS. J'avais essayé libsass au travers de grunt-sass qui est en pur C&JS, mais là c'est au niveau des options que ça pêche (notamment au niveau des arrondis).
Je pense que c'est ceux qui contribueront aux CSS qui doivent choisir les outils vu que c'est le principal intéressé. Pour ma part, le seul truc qui me tient à coeur est de rester sur full JS.
—
Reply to this email directly or view it on GitHub.
On reste sur cette config au moins pour la V1 et on voit après que le site est op pour la prod ?
👍
Cool. Juste pour info, je suis parti sur l'unité rem car c'est le plus simple à utiliser que em et je transforme la feuille de style en px pour ie<8.
on ferme l'issue ?
👍
hopla