Rigole pas, ce Framework a l'air énorme. C'est une manière de concevoir des applications web assez radicalement nouvelle. Polymer est d'ailleurs basé sur le standard web component développé au W3C.

j’ai été regarder un peu, j’ai rien pigé. Je ne vois pas du tout l’apport par rapport à un modèle MVC, ça mélange le front et le back selon les briques, c’est le foutoir.
Et puis un framework dont l’un des principaux composants est :
“Go (composantes Google Web) qui constitue les composantes des APIs et Services Google”.
je vais même pas commencer à essayer de faire l’effort de voir comment je pourrais envisager de m’en servir ^^

j’ai été regarder un peu, j’ai rien pigé. Je ne vois pas du tout l’apport par rapport à un modèle MVC, ça mélange le front et le back selon les briques, c’est le foutoir.

En fait, c'est justement, au coutraire plus propre. Ça correspond plus à ce qu'on retrouve en programmation classique avec l'idée de faire des petites briques logicielles réutilisables. De ce que j'en ai compris, l'idée de base des web components, c'est de laisser la possibilité de créer des balises HTML custom pour créer des widgets réutilisables.

En fait, le fait d'avoir 3 langages pour faire du web (HTML, CSS et JS), c'est plus une bizarrerie historique qu'autre chose. Lorsque HTML est apparu, le but était juste d'échanger des informations scientifiques. C'est un peu plus tard, lorsque les blogs sont apparus et, avec eux, la nécessité de mettre en forme du contenu, que CSS a été créé. Et, un peu après, JS, pour pouvoir faire des sites web qui soient des vitrines commerciales.

Si tu regardes comment est foutu LaTeX, par exemple, il n'y a pas de séparation entre la structure du contenu et sa mise en forme. Les deux sont intrinsèquement liés. Et ça le rend beaucoup plus clair puisqu'il n'y a qu'un seul langage à apprendre.

Les widgets en web dev, c'est quelque chose qui commence à dater. Au départ, ça prenait juste la forme de code snipets qui s'échangaient sur le web. Plus tard, jQuery a commencé à empacter tout ça dans des biblios (jQ UI) et, à côté, se développaient les frameworks CSS (Bootstrap et d'autres). Les web-components, ça n'est qu'une formalisation de cette tendance.

L'apport, par rapport à un MVC classique, c'est la simplification. Tout projet de développement tend vers ça. C'est pour ça qu'on fait des biblio et qu'on les jette dans Github.

Et puis c'est dévloppé par Google et standardisé par le W3C. De manière générale, ce sont deux organismes qui font les choses plutôt bien. Donc on peut quand-même leur faire confiance sur le fait que cete techno va plutôt dans la bonne voie.

Bah les widgets ou équivalents, c'est correct pour le front (et c'est les exemples que tu me cite), mais faire du front et du back avec des briques, je ne vois pas l'intérêt. J'irai jeter un oeil quand ça aura pris un peu forme.

En ce qui concerne le sérieux des projets Google, ils ont des milliers de projets en cours de dev, du plus intéressant (Angular) au plus inutiles (il y a au moins 3 générateurs de code HTML tout pouraves qui traînent en ligne, je n'ai plus les adresses sous la main).

Les intérêts de Google ne sont pas toujours ceux des dev, voir l'exemple de Google Code qui était pas mal fichu mais a été fermé. Et je le répète, aucun framework n'a besoin des API de connexion à des produits en natif et là c'est le cas, ça en limite quand même beaucoup la crédibilité ^^

mais faire du front et du back avec des briques

Pourquoi tu parles du back ?
Et à propos, front, back, c'est une distinction assez biaisée. Généralement, quand on parle de front et back, on parle de client et serveur mais, en vrai, on peut faire un site web entièrement sans serveur (j'en ai fait un pour l'école y'a à peine 2 semaines) avec des biblios comme Backbone. Tout se passe chez le client en JS, y compris la navigation et le routing. C'est pas spécialement stupide de voiloir unififer ça. D'autant que je pense que Google te laisse quand-même le choix d'utiliser ou pas leur biblio en Go.

Après, en ce qui concerne les intérêts de Google, qu'ils divergent de ceux du public ou des devs, oui, mais ça ne change rien à la grande qualité générale de leurs produits (comme tu le cite, l'example de Google code). C'est tout ce que je dis, moi. C'est que quand ils s'y mettent, ils font les choses sérieusement et bien. Même si ça sert pas toujours l'intérêt général.

Je pense qu'il faut plus voir Polymer comme une biblio qui rassemblerait des biblios classiquement utilisés en web (Bootstrap, Backbon, Python & Django, etc.) dans un ensemble cohérant mais modulaire. Après, si tu veux utiliser certain modules et pas d'autres, je pense que ça doit être possible. Mais si tu veux un outil clef en main pour faire un gros site web pro et que t'as pas envie de te faire chier à composer toi-même ta boîte à outils et à apprendre les bonne pratiques de chaque outil, bah là, t'as le tout en unifié.

bah t'as déjà Symphony pour ça, suffit de taper dans les bundles ^^

Non front et back ce n'est pas l'architecture client serveur. Le front, c'est ce qui est présenté à ton utilisateur (html, css, jquery, Angular, backbone, etc) et le back c'est le traitement de tes données, la définition de ton api pour les architectures REST (PHP, nodejs , python, JAVA ou ce que tu veux ^^).

Quand tu dis "on peut faire un site web entièrement sans serveur" Tu veux dire sans traitement de des données en base de données donc un site statiques, En fait on peut faire des sites webs statiques depuis la création du HTML, on ne faisait même que ça au début.

Si, bien sûr que si, avec traitement des données. Backbone est un framework MVC en JS. Tubas aussi des modèles. diaspora lui-même utilise les modèles de Backbone pour stocker et traiter des données côté client.

Encore une fois, différencier front et back, c'est une vue de l'esprit. Et il n'y a qu'en web que cette distinction s'effectue. Je n'ai jamais vu de framework qui ne fasse que du VC et pas de M du tout ailleurs.

Et puis Symphony et les bundles, ok, mais c'est pas parce qu'il y a déjà un outil existant qu'on va se priver d'en créer un autre. Si on avait réfléchi comme ça l'informatique en serai resté à l'âge de pierre.

Et puis petit point bloquant tout con : et si j'ai pas envie de faire de PHP parce que je trouve que PHP, c'est sale ?

Bah aucun langage n'est sale ou propre, c'est absurde. Il peut plus ou moins te correspondre ou bien s'imposer pour des questions de performance ou par goût.

Regarde ce qu'est en train de devenir javascript le pauvre lanceur de popup d'il y a 10 ans dont tout le monde se moquait.

Je suis d'accord avec toi, la diversité des outils est une richesse mais pas le temps de tout voir / utiliser, du coup je vais zapper celui-là ^^

PHP n'est pas forcément beau à dev, mais... Si les autres type python ou Ruby était d'une, aussi simple d'utilisation que PHP, et s'il y avait des serveurs gratis...

Bah aucun langage n’est sale ou propre, c’est absurde. Il peut plus ou moins te correspondre ou bien s’imposer pour des questions de performance ou par goût.

Curioté : t'es dev ?

Regarde ce qu’est en train de devenir javascript le pauvre lanceur de popup d’il y a 10 ans dont tout le monde se moquait.

Un cancer ?

Pas tout lu, mais j'ai joué pendant deux semaines avec Polymer v0.5 puis 0.8 au boulot parce qu'on comparait des frameworks, y'a des trucs intéressants dedans qui méritent d'y jeter un coup d'oeil, notamment, l'encapsulation, ce qui permet de faire des choses beaucoup, beaucoup plus propres.

Et clairement, y'a 0 back. Une archi classique c'est DB, BackEnd, Front-End (là on a des JSP ou ERB/HAML par exemple) puis sur le client le JS. Aujourd'hui la tendance, et polymer appuie ca à fond, c'est de virer la couche Front-End sur le serveur. Plus que un seul fichier HTML de rendu, puis des appels AJAX sur une API (généralement REST) par le client pour choper les données, et faire le rendu avec du template (type mustach ou handlebar). Donc, clairement, aucun back-end.

@ augier

oui dev spécialisé sur Drupal, ça fait 15 ans que je fais du web, autodidacte et pas du tout snob. Ce qui m'intéresse, c'est que ce que je code répondent à mes besoins, la beauté du langage, je m'en tape total. Si c'est simple, facile d'accès et que ça marche bien, je prends. Du coup j'ai jamais fais de python par exemple ^^

Javascript un cancer ? Pourquoi ? C'était peut-être un cancer quand ça ne servait qu'à lancer des popup mais avec l'arrivée de frameworks élaborés côté front (tu cites toi-même backbone) et de serveurs asynchrones, javascript est intéressant en ce moment.

@fla oui, enfin il y a quand même ton API fait office de backend, l'intéressant, c'est qu'elle est totalement découplée de ce qui se passe devant.

Et vous avez retenu quoi comme framework ?

Aujourd’hui la tendance, et polymer appuie ca à fond, c’est de virer la couche Front-End sur le serveur.

Oh.... doux seigneur... Quelle horreur... Handlebars à fond, vas-y, fais péter les stats de conso CPU de Firefox avec ton gros Javascript plein de poux et de puces...

@Augier pourquoi tant de haine ? ^^

Pour mesurer correctement la complexité algoritmique ! :p

Blague de développeur