J'ai lu le post en diagonale, mais j'ai plus l'impression qu'il parle
de l'avenir pour ceux étant capable de maintenir des projets webform:
"""
If only you knew how much people like me make cleaning up WebForms
projects gone wrong!!! With every half-assed DotNetNuke
implementation I save somebody from, it's another *10 billion dollars*
in my pocket.
"""
Pour la question maintenabilité, sans vouloir être expéditif (je pense
que cela soulève un débat intéressant et j'y reviendrais surement),
j'ai beaucoup plus de mal à maintenir une bouillie de tag
asp.net avec
un comportement statefull (mhh viewstate, mmh OnRowDataBound de 1000
lignes) qu'une boucle foreach ou deux dans le code d'une vue (sachant
que le binding avec le protocole http est beaucoup plus sain avec une
approche MVC) et de quelques appels ajax fait explicitement (sans drag
& drop d'un updatepanel au dernier moment).
Pour peu que l'on ai un minimum reflechi au jeu de donnée à
communiquer à la vue, je ne vois pas comment faire plus élégant et
concis.
J'attends d'autres avis, mais j'ai commencé les webforms depuis fin
2002 et disposais (bien heureusement pour moi) d'une expérience web
pré-existante, j'interviens encore sur des projets webforms
rencontrant des problèmes de performance ou autre joyeusetés, mais je
ne commencerais pas de nouveaux projets avec ce framework, et je suis
bien heureux que Microsoft sorte un framework MVC au cas ou un client
serait totalement réticent à utiliser monorail.
Le framework des webform est "puissant", mais il doit y avoir 1% des
développeurs l'utilisant capables de le faire correctement, de manière
optimisée avec à l'issue une architecture "maintenable", je pense que
le ratio des appli maintenable pour les autres langages web est bien
plus avantageux.