La mia osservazione è che WebForms è in declino. C'è una buona ragione per quello. Avendo ampiamente utilizzato WebForm in passato, è difficile fare qualcosa fuori dagli schemi. Oltre ai controlli di apprendimento dell'aspx e al loro corretto utilizzo, ci sono molte minuzie tecniche per apprendere il ciclo di vita della pagina quando si va oltre le basi. E alla fine, stai scrivendo in un linguaggio proprietario basato su XML che si traduce (spesso male) in HTML + JS che devi effettivamente supportare nei browser di destinazione. Spesso l'implementazione del rendering del controllo passa attraverso il tuo problema e devi farlo funzionare con gli hack JS / CSS sull'output renderizzato. Le dichiarazioni sono piuttosto prolisse e a volte non si traducono in ciò che immaginate di fare in HTML. Quando hai bisogno di applicare classi per lo styling, significa che devi anche conoscere intimamente come il controllo rende l'HTML. I controlli delle scorte utilizzano molti standard HTML antiquati come il rendering basato su tabelle. Quindi perché esistono diversi fornitori di controlli di terze parti per WebForms.
(Modifica: non sono nemmeno entrato in View / Control State qui. Devo averlo bloccato. Ecco un articolo di esempio che spiega le interazioni tra il ciclo di vita delle pagine e lo stato di visualizzazione (25 pagine stampate).)
MVC e le strutture client-side successive come Angular amano esporvi direttamente all'HTML / JS perché è ciò che effettivamente avete bisogno di sapere e avere comunque il controllo. Nota esistono fornitori di controllo MVC di terze parti che rendono alcuni HTML / JS per te.
I miei ex datori di lavoro hanno utilizzato progetti WebForms (alcuni ampiamente). Ne ho creati diversi Io mantengo diversi in produzione oggi della mia o di altre creazioni. Penso che chiunque conosca lavorando su progetti WebForms ora li considera "legacy" e li tocca solo quando richiesto. La nuova funzionalità viene migrata a qualcos'altro. Abbiamo pagine angolari all'interno della maggior parte dei nostri progetti WebForm in cui erano necessarie nuove funzionalità.
Specificamente del tuo collega di lavoro. Se WebForms è qualcosa che il tuo team supporta, allora va contro la maggior parte delle pratiche agili per essere specializzato solo su MVC. "Chiunque nella squadra dovrebbe essere in grado di svolgere qualsiasi compito". Questo è l'ideale Sono stato in team dove era gradito che tutte le parti (ad eccezione del Product Owner) fossero specializzate. Tuttavia, questo può diventare un ostacolo per ottenere le storie con la priorità più alta se la disponibilità della persona specializzata è bassa a causa di vacanza o malattia. Se è un obiettivo della squadra avere tutti allenati in modo trasversale, allora tutti dovrebbero continuare ad allenarsi come se le opportunità si presentassero.
Sono sicuro che qualcuno potrebbe fare una carriera facendo solo MVC in .NET. È abbastanza facile indicare la tua preferenza ai datori di lavoro su un curriculum e nelle interviste. Tuttavia, non mi limiterei a questo. MVC su .NET è una tecnologia (e una meno utilizzata nel grande schema) e i tecnici vanno e vengono. Non uso WebForms o MVC per i nuovi front-end Web e non ho perso nessuno dei due. MVC a volte si intrufola nel lato API delle cose perché si è mescolato con le API Web su alcuni modelli di progetto.