Bower, NPM, Gulp in ASP.NET MVC, quale problema sto risolvendo? [chiuso]

Question

Bower, NPM, Gulp in ASP.NET MVC, quale problema sto risolvendo? [chiuso]

#1 da (4 voti)

3

Lavoro in una piccola società di sviluppo web e non usiamo alcuna gestione delle dipendenze di alcun tipo dal lato front-end. Le librerie esterne vengono semplicemente scaricate e incollate nella cartella lib di qualunque sito web abbia bisogno di loro, e le nostre librerie sono copiate felicemente. Tutti i siti Web sono costruiti su ASP.NET MVC.

Recentemente mi è stato chiesto di vedere se i gestori di pacchetti frontend come npm e bower erano utili per noi, principalmente perché questi sono termini che si incontrano spesso al giorno d'oggi quando si cercano online librerie javascript e simili.

Così sono andato a leggere molti articoli su npm, bower, grunt, gulp, yeo e molti altri, e ho iniziato a sperimentare con loro in un'applicazione web di test. Ma dopo aver seguito alcuni tutorial, ho sentito che trascorrevo molto tempo su cose che Visual Studio e ASP.NET MVC già facevano per me, come il raggruppamento di script e minification. C'era molta nuova sintassi che dovevo imparare, anche se non avevo ancora idea di quale fosse il punto. Sembrava che stavo aggiungendo un bel po 'di configurazione in quello che sembrava un modo goffo solo per rendere l'aggiornamento delle librerie frontend leggermente più semplice. Ho faticato di più con Gulp / Grunt; Semplicemente non riuscivo a pensare a nulla che volessi fare con esso, che non potevo fare già.

Quindi la vera domanda è questa: perché dovrei voler usare cose come bower e gulp in un ambiente ASP.NET MVC? Quali problemi risolvono, oltre a rendere gli aggiornamenti della libreria leggermente più veloci? Non sentiamo davvero l'urgenza di aggiornare le nostre librerie quotidianamente; molti dei nostri siti funzionano con vecchie versioni jquery e funzionano bene. Mi manca qualcosa di completamente o semplicemente non siamo il pubblico previsto per questi sistemi?

Mi dispiace se è stato chiesto prima o è noto, ma non sono riuscito a trovarlo da nessuna parte. Ad esempio, se cerchi online "bower + ASP.NET", avrai molti articoli su come per usarli, ma quasi nessuno che tocchi perché .

AGGIORNAMENTO: Permettetemi di chiarire la domanda: quali sono le cose comuni che uno sviluppatore avrebbe usato per il nuovo host di gestori supportati in VS2015 (gulp, pergolato) per, che non può fare a meno di loro?

asp.net-mvc package-managers

posta Dennisch 27.08.2015 - 18:13

fonte

1 risposta

Leggi altre domande sui tag asp.net-mvc package-managers

Design accettabile per utilizzare oggetti membri pubblici nella composizione? Come gestire il recupero dei dati per i riferimenti a oggetti circolari nei modelli di dominio OOP

score 4 · Accepted Answer

Rischio una risposta per questo.

Sei uno sviluppatore .NET, entrando nella terra degli strumenti di frontend in Javascript. Affrontiamo alcuni degli strumenti.

Per prima cosa - nella tua domanda, hai offuscato la distinzione tra gestori di pacchetti (npm, Bower) e task runner (Gulp, Grunt). Ciascuno è uno strumento nel set di strumenti, responsabile di diverse aree.

Visual Studio fornisce i runner delle attività per i flussi di lavoro frontend (come minification e bundling), ma al di fuori di Nuget, non fornisce un gestore di pacchetti per tutti i moduli frontend. Mentre Nuget funziona, in un certo senso, non è stato progettato in particolare per i pacchetti di frontend, in particolare; inoltre, poiché non fa parte dell'ecosistema di frontend, la ricchezza di pacchetti disponibili in npm o anche Bower non è disponibile tramite Nuget. (Quelli che potrebbero essere stati modificati o adattati a un ambiente specifico, che non è sempre quello che vuoi.)

In termini di task runner, l'ecosistema web si è evoluto e sono stati creati plugin open source per Gulp e Grunt che consentono un sacco di comportamenti, ma questi non sono disponibili per Visual Studio. L'ecosistema, la lingua e gli strumenti semplicemente non corrispondono.

Lo sviluppo del frontend non è più un sottoinsieme dello sviluppo del backend, come un tempo. Javascript nel browser è diventato il proprio sistema, non solo un ripensamento; la strumentazione è stata aggiornata per riflettere questo. Ha fatto molta strada nel corso degli anni e si sta muovendo più velocemente, molto più velocemente, degli strumenti equivalenti in Visual Studio. La ragione principale per cui vorrai passare a questi strumenti è la seguente:

L'ecosistema .NET sta migrando verso i toolchain esistenti, invece di provare a lanciare i propri. Le nuove versioni di .NET stanno cambiando i loro task runner per usare Grunt, e stanno anche passando alla configurazione basata su JSON.
.NET punta a diventare più portabile. Usare gli strumenti forniti dall'ecosistema di frontend (che per natura è indipendente dalla piattaforma) ha senso in questo senso.
Questi strumenti sono utilizzabili al di fuori dei confini di .NET (dal momento che JS nel browser, di nuovo, è diventato il proprio sistema).
Avrai semplicemente più opzioni a lungo termine (e, discutibilmente, prima).

Detto questo - se usare gli strumenti forniti in VS è più facile, quindi con tutti i mezzi, usali per portare a termine il tuo lavoro. Familiarizza con i nuovi toolchain, però, perché ne avrai bisogno.