Bien sur que c'est de l'opinion perso. J'ai jamais pretendu exprimer
l'opinion de quelqu'un d'autre.
On peut en debattre.
J'ai cependant precise "en ce qui concerne les applis web", en opposition a
"site web", donc le SEO n'est pas sense etre un probleme. React sait tres
bien gerer les problematiques de SEO, donc les technos frontend ne sont pas
non plus un obstacle a ce niveau la. Au pire, une instance node et tu fais
du server side rendering de tes composants, ca marche tres tres bien, on
l'utilise tous les jours (je bosse pour un website builder et nos rendering
de page sont faites en react).
Quand au surcout de temps, il faut prendre en compte le cout de faire mais
aussi celui de ne pas faire, ie: la maintenance, les tests et les
evolutions futures.
Si t'as un projet one shot, petit budget, scope reduit, avec une interface
"debile", ca vaut ptet pas le cout d'investir dans une stack frontend. Par
contre, des que t'as de l'application avec differents composants et des
etats, ca devient tres interessant. Si le projet doit etre maintenu et
evolue, ca prend encore plus de sens. Tester des rjs, ou du "observe_field"
c'est juste infernal, meme avec selenium & friends. Tester automatiquement
du react (ou meme du ember) c'est 1 milliard de fois plus simple et
maintenable. Du coup, le cout d'assurance "anti-regressions" diminue
largement.
Si tu as plus d'un client (appli IOS / android / windows phone etc),
considerer ton FE comme un client parmi tant d'autres fait aussi beaucoup
de sens, plutot que de dev tous tes controllers en double: 1 pour l'api, 1
pour le html. Les couts de bande passante du html peuvent entacher les
perfs de l'api et il c'est plus complique de balancer la charge entre les 2
... bref, t'as tellement de benefices a avoir un serveur agnostique des que
ton projet le justifie. Et y'a pas beaucoup de projets qui le justifient
pas SELON MOI.
Enfin, le but etait simplement de signaler qu'il existait depuis rails 2
d'autres outils de developpement pour les clients web, plus modernes et
plus adaptes a certaines (beaucoup... SELON MOI) de situations. Ca concerne
aussi la pipeline qui, en son temps etait bien utile, mais maintenant fait
de la peine a cote des outils tels que webpack ou brocolijs et assimiles.
Bisous
2016-02-12 16:30 GMT+08:00 Cyril Mougel <cyril.mou...@gmail.com>:
> 2016-02-12 5:18 GMT+01:00 Florian Dutey <fdu...@gmail.com>:
> > Salut,
> >
> > A partir de rails 3, les choses ont pas mal change. Si tu dois faire une
> > update, tu vas devoir fixer beaucoup de bugs tant lapi a change (et
> observe
> > field nest plus, le standard etant devenu jquery).
> > Va falloir que tu geres la logique client toi meme. C pas tres complique
> (
> > on("change", ... en jquery).
> >
> > Ceci dit, et au risque de paraitre meprisant (ce qui n'est pas le but),
> le
> > developpement web a beaucoup evolue depuis rails 2.
> > Les ignominies telles que le rjs ont disparu, et, bien que les helpers de
> > vues rails supportent toujours des "options ajax", c'est vivement
> recommande
> > de ne pas les utiliser (je recommande meme vivement de ne pas utiliser
> rails
> > pour faire du rendering, a part json). Exit asset pipeline aussi.
> > De meme, l'idee d'un serveur qui sert un document html qu'on "enrichi"
> par
> > la suite avec du js et du css est bien morte. Du moins, pour ce qui
> concerne
> > les applications web.
> >
> > Ca depend evidemment du type de projet que tu developpes mais pour eviter
> > les problemes sur le long terme, c'est mieux d'avoir un backend qui ne
> > retourne que du data et nessaie pas de manipuler l'etat du client.
> >
> > Les technos frontend sont maintenant tres matures et essayer de les
> piloter
> > en ruby (via la pipeline, ou des taches rake) est une tres mauvaise idee
> > aussi.
> > Donc bye pipeline, bonjour webpack + react / ember.
>
> C'est clairement de l'opinion personnel. Rails est largement utilisé
> pour faire du HTML et le HTML ne mourrera pas. Ne serait-ce que pour
> le SEO.
>
> Je voudrais pas que ce propos soit considéré comme une réalité.
> Développer séparément son frontend de son backend entraine aussi un
> surcout de temps.
>
>
>
> --
> Cyril Mougel
> http://blog.shingara.fr
>
> --
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> railsfrance@googlegroups.com
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> railsfrance-unsubscr...@googlegroups.com
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> railsfrance+unsubscr...@googlegroups.com.
> Pour plus d'options, visitez le site https://groups.google.com/d/optout .
>
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
