Après lecture de l'article, je me rends compte que l'éco-système javascript est bien plus riche que ce que j'imaginais.
Moi qui hésitais encore à mettre "Javascript" sur mon CV, je pense que ça vaut définitivement la peine

Je vais m'orienter vers une solution PouchDB (avec, à terme, couchDB derrière) et AngularJS. Il reste à découvrir AngularsJS, mais vu le boulot insipide que je fais en journée, ça ne devrait pas prendre trop de temps

Un conseil en particulier pour débuter avec AngularJS ? Les tutoriels ne parlent pas beaucoup des "modules" que l'on peut faire, mais j'ai l'impression que c'est un peu indispensable vu ce que j'envisage de faire (essentiellement, 3 pages avec BEAUCOUP de dynamisme).

N'hésitez pas à poster des liens comme celui de Pom ou Fabe, je cherche à occuper mon cerveau en journée, ça ne me fait pas de mal et c'est intéressant

Ah, mais le JS, c'est juste ZE langage hype du moment. La grosse boutade depuis quelques années, c'est que si un truc peut être fait, alors il sera fait en js par au moins un couillon.

Si tu veux mettre une case sur un CV, c'est probablement plus intelligent de miser sur le JS que sur le brainfuck. Un bon développeur js, c'est recherché. Un bon. :)

A l'inverse de ce que tu cherches Guy, dans mon apprentissage jedi de JS (car plus tu creuses, plus tu vois que le sujet est énorme), je fuis les gros frameworks car j'ai peur d'apprendre du spécifique au framework et pas assez le coeur du langage et ses particularités (fonctionnelle, closure, évènements, asynchrone).

J'ai commencé à lire sérieusement eloquent javascript, où j'apprécie la partie sur les fonctions d'ordre supérieur et je commence à trouver l'intérêt et le côté élégant de la chose (ça commence à me gonfler quand je suis obligé de faire une boucle for donc j'évolue dans le bon sens ;)).

Je pense aussi à travailler sur Coffescript car ça contient des bonnes pratiques lors de la transformation. Et au passage l'écriture est plus sexy. En fait c'est la même personne qui a fait Backbone, Underscore et Coffescript et tout est assez cohérent et améliore la compréhension du javascript.

Et côté outillage, Sublime + Emmet c'est fun.

pomA l'inverse de ce que tu cherches Guy, dans mon apprentissage jedi de JS (car plus tu creuses, plus tu vois que le sujet est énorme), je fuis les gros frameworks car j'ai peur d'apprendre du spécifique au framework et pas assez le coeur du langage et ses particularités (fonctionnelle, closure, évènements, asynchrone).

Ce qui me tente surtout avec ce framework (AngularJS), c'est la possibilité de pouvoir faire une application complète qui tourne coté client. Je sais que je pourrai y parvenir avec du JS "pur" mais ce serait une grosse perte de temps.

Cela dit, je connais déjà bien JS, donc ça aide

pomJ'ai commencé à lire sérieusement eloquent javascript, où j'apprécie la partie sur les fonctions d'ordre supérieur et je commence à trouver l'intérêt et le côté élégant de la chose (ça commence à me gonfler quand je suis obligé de faire une boucle for donc j'évolue dans le bon sens ;)).

Je suis tombé sur Eloquent Javascript par hasard ce matin en cherchant justement un cours un peu plus approfondi. J'ai parcouru les chapitres, et j'ai appris peu de choses (sans doute parce que les closures, les fonctions partielles, etc. sont des concepts déjà existants en Python et que je connais bien).

J'ai par contre appris pas mal de choses sur "prototype", même si je ne suis pas du tout fan de ce qu'on peut en faire.

pomEt côté outillage, Sublime + Emmet c'est fun.

Je ne connais pas Emmet, je vais me renseigner.

GuybrushJe ne connais pas Emmet, je vais me renseigner.

Emmet, c'est juste le nouveau nom de Zen coding, plugin très connu pour énormément d'éditeurs de texte.

C'est un accélérateur d'écriture html, mais c'est pas non plus un truc révolutionnaire, surtout si tu fais peu de frontend. Ou alors j'ai loupé sa vraie utilité.

c'est genre tu fais : #main>ul>li*5>a puis tab et il te génère une div avec 5 liens dans une liste, et en tabbant tu entre les différents textes.

Ok !

J'ai commencé un prototype et... pff... un peu galère, quand même. Je découvre vite certaines limitations :
- AngularJS nécessite un plugin (ui-routing) pour faire des vues partielles/imbriquées. Autrement dit, sans ce plug-in et en utilisant juste ngRoute, impossible (ou difficile) de faire élégamment des "widgets-like".
- CouchDB/PouchDB n'a aucun support pour les collections. Une base contient directement les documents, contrairement à MongoDB où il y a un layer supplémentaire. Ce n'est pas capital (il suffit de typer manuellement les documents et de préparer des vues pour les récupérer), mais c'est un peu embêtant tout de même. Je me demande si on peut émuler les collections (en terme de performances) via une structure de document particulière (ex : {collection1: [....], collection2: [...]}.
- Je trouve tout et n'importe quoi concernant l'organisation d'une application AngularJS (folder, code, etc.). C'est assez difficile de s'y retrouver. Il y a des guides de bonnes pratiques, mais chaque guide a son approche différente, ce qui n'aide pas

GuybrushCe qui me tente surtout avec ce framework (AngularJS), c'est la possibilité de pouvoir faire une application complète qui tourne coté client. Je sais que je pourrai y parvenir avec du JS "pur" mais ce serait une grosse perte de temps.

Je suis tombé sur un diagramme récemment qui montrait la réaction qu'on avait sur angular au fur et à mesure du temps (mais je n'arrive pas à remettre la main dessus). Genre une suite de "C'est génial", puis "mais c'est de la merde", puis retour au point 1 ;)

GuybrushJe suis tombé sur Eloquent Javascript par hasard ce matin en cherchant justement un cours un peu plus approfondi. J'ai parcouru les chapitres, et j'ai appris peu de choses (sans doute parce que les closures, les fonctions partielles, etc. sont des concepts déjà existants en Python et que je connais bien).
J'ai par contre appris pas mal de choses sur "prototype", même si je ne suis pas du tout fan de ce qu'on peut en faire.

Eloquent part du début, à savoir expliquer ce qu'est la programmation et ce qu'est une fonction, et il va assez loin (dans les derniers chapitres). Tu n'es donc pas dans le cœur de cible! Mais il a l'avantage de poser les concepts importants, qui sont ignorés par la plupart des gens qui commencent à bosser le langage (et la plupart des tutoriels).

TchouEmmet, c'est juste le nouveau nom de Zen coding, plugin très connu pour énormément d'éditeurs de texte.

C'est un accélérateur d'écriture html, mais c'est pas non plus un truc révolutionnaire, surtout si tu fais peu de frontend. Ou alors j'ai loupé sa vraie utilité.

Pas révolutionnaire mais assez génial dans son concept puisque c'est un outil d'automatisation du dev qui se base sur les conventions HTML/CSS (tout comme est génial le sélecteur jQuery pour les mêmes raisons).
Ca te force à penser à ta structure et aux différentes classes/attributs dont tu auras besoin.

Ca va assez loin. Petits ex :
- table.clients[data-name=toto]>.pair>(.test$)*3^.impair>(.test$)*3
- lorem : ajoute un lorem ipsum
- ! : construit un squelette HTML
- m10px20 : margin: 10px 20px; // CSS

Pour le 1er exemple, note que je me contente de mettre .pair et pas tr.pair. Il se débrouille en fonction du contexte.
Dans un contexte normal, tu mets .toto, il va te faire un <div class="toto">
Mais si tu es en display:inline, il est assez malin pour te faire un <span class="toto">

Voir toutes les possibilités dans le cheat sheet
Il intègre même un pseudo livereload maintenant.

Il faut se forcer un peu à l'intégrer dans son workflow mais on peut vraiment y gagner par la suite (c'est comme Sublime, y a un coût d'entrée ;)).

Je galère un peu trop à me convaincre qu'une flat database pourrait faire l'affaire, à part pour des raisons techniques, ce qui est insuffisant comme argument

Je vais donc probablement repartir sur mon approche initiale :
- Une API Rest servie par Django et servant d'intermédiaire avec la db relationnelle (comme ça, je garde la main sur les données) ;
- Une page d'authentification gérée par Django, et qui permet d'initialiser une session autorisant la connexion à l'API.
- Le reste en AngularJS, afin de proposer une webapp dynamique.

Je vais commencer par écrire l'API Rest (j'ai déjà une grosse partie, mais je vais recommencer proprement, notamment parce que j'ai inversé PUT/POST, et que depuis, j'ai aussi lu un très bon guide décrivant comment définir l'interface).

Octo a récemment publié une cheatsheet sur la construction d'API.
Ça n'invente rien, mais ça permet de rester cohérent.

Je prends

Mon principal souci, c'est les relations d'association. Par exemple, si tu as A et C qui sont reliés par B, j'hésite à :
- Exposer B directement ;
- Intégrer B comme élément fils de A ou C.
- Intégrer B comme élément fils de A ET C.

Dans certains cas, c'est simple (par exemple, on accèdera aux olives via la pizza, pas l'inverse à priori), mais dans d'autres cas (dont le mien), j'ai un intérêt à avoir B via A et C. Si je ne l'ai pas, cela veut dire que je vais devoir faire du filter/map à tout va coté client (en gros, faire une sorte de requête locale), ce que je ne trouve pas élégant quand la db peut le faire efficacement coté serveur. Mais en intégrant B comme élément fils de A ou C, cela nécessite un travail supplémentaire au niveau de l'API (et si c'est A ET C, pas "ou", c'est encore pire vu que c'est potentiellement partiellement redondant). Or, "there must be one and only one way to do it" (idiome Python ). D'où l'idée d'exposer directement B, et de proposer un "filter" dessus. Par ex : /api/B/list?A=[ma_pk_pour_A]

Any retour ?

La relation n'est navigable que dans un sens ?
L'objet A ne donne pas le lien vers les objets B associés ?

Sinon le principe du filtre semble valide mais il est moins "auto-découvrable" que de simplement naviguer entre les ressources de l'API.

Par contre dans une API REST, il faut éviter d'avoir des verbes d'actions comme "list" dans les chemins de l'API : /api/B doit lister toutes les entités "B", "/api/B/3" doit retourner uniquement celle d'identifiant 3.
Le principe du REST est d'utiliser exclusivement les verbes fournis par HTTP.