Attualmente sto cercando di decidere quale linguaggio lato server imparare e utilizzare per lo sviluppo web, e mentre è relativamente facile ottenere informazioni sul perché x, y o z è una buona cosa, è più difficile capire lati negativi a ciascuno di essi.
In particolare, sono curioso di sapere quali svantaggi ci sono nell'apprendimento e / o nell'utilizzo di Ruby on Rails rispetto a qualsiasi altro linguaggio / framework.
Parlando dall'esperienza: il lato negativo è che ci si affida molto al framework Rails anche un po ' too . Questa è una grande e meravigliosa cosa se scrivi sempre semplici app CRUD greenfield che si inseriscono perfettamente nel "punto debole" di Rails; la tua produttività salirà alle stelle. Tuttavia, nel momento in cui devi fare qualcosa al di fuori di quel punto debole - interagire con un database esistente, parlare con un'altra applicazione che non ha un'API JSON o XML definita, implementare un flusso di lavoro complicato, Rails diventerà il tuo nemico. È è possibile fare queste cose con Rails, ma va "controcorrente", quindi sei fondamentalmente da solo a capire come farlo dato che la comunità di solito risponde solo con "Don" "Fai così, non è il modo Rails" - questo si traduce in perdita di produttività o di codice molto disordinato, dato che devi fondamentalmente hackerare il framework Rails.
Inoltre, c'è un lato negativo inespresso: tutto il resto sembrerà brutto e sfacciato. Una volta assaggiato il dolce e dolce nettare di Rails (okay, evangelizzando solo un po 'qui ...) tutto il resto è buono. Passare da Rails a PHP, o ASP.NET WebForms, o Java è come camminare su un letto di chiodi dopo aver saltato in un giardino rigoglioso; non vedrai le altre lingue / strutture nella stessa luce, e mentre potresti ancora apprezzarle, vorrai segretamente l'abbraccio amorevole di Rails.
Per il tuo primo linguaggio lato server, mi sembra che ci possano essere un paio di problemi con RoR:
Non stai solo imparando una lingua, stai imparando una struttura. Avrei sicuramente bisogno di un po 'di tempo per giocare con il vecchio vecchio rubino prima di buttarmi nei binari.
Dal momento che si tratta di un framework, e di uno "opinato", ritengo che ti darebbe un ambito molto limitato di ciò che sta accadendo nel framework.
Nel complesso Ruby on Rails può essere un buon punto di partenza per far girare la palla, ma c'è molto da imparare sullo sviluppo web che potresti perdere perché sei troppo dipendente da un singolo framework.
Ho provato a imparare RoR più volte e il mio problema più grande è sempre quello di cercare di far funzionare correttamente i pacchetti e la documentazione. Il problema con la documentazione è che sembra sempre non aggiornato (o molto semplice). Ho ottenuto le basi dal sito ma oltre a ciò sembrava tutto così datato (anche il libro che ho comprato e che ho finito per tornare). Un'altra cosa che potrebbe essere un inconveniente è la dipendenza che alcune delle librerie hanno e il modo in cui possono entrare in conflitto con un altro come dichiarato da Ben Coe .
Qualcosa a cui ho pensato più tardi e invece di renderlo un commento, mi limiterò a modificare la mia risposta è questa: RoR ha una possibilità di rovinare Ruby per te. So che quando l'ho provato, mi ha fatto pensare che "Ruby era stupido". Poi qualche mese più tardi decisi di provare Ruby e adoro il linguaggio, era la struttura che mi faceva odiare la lingua. Non mi ci sono dilungato molto, ma quando l'ho fatto, mi sono davvero divertito Sinatra . Penso di aver avuto la gioia che la maggior parte delle persone esce da RoR da Sinatra.
Se questo è il tuo primo linguaggio lato server, è buono come tutti gli altri. La cosa da fare è concentrarsi su uno, e dopo aver sentito di averlo padroneggiato, esplorare gli altri e dedurre le proprie conclusioni.
Lavoro quotidianamente con RoR e ASP.NET, ma stranamente preferisco il mondo ASP.NET, ma questo ha più a che fare con la filosofia personale che con la lingua o l'architettura stessa. (Sono un po 'maniaco del controllo e personalmente gravitano su linguaggi strongmente tipizzati).
Indipendentemente da ciò, dico di provarlo. RoR è un ottimo ambiente in cui lavorare, ma prima di entrare direttamente in Rails, mettiti comodo con Ruby come lingua. Al di là della roba web, Ruby è un linguaggio di scripting piuttosto interessante se si finisce per dover gestire una casella * nix e si può risparmiare un carico di tempo.
Come qualcuno che ha imparato Rails di recente (come hobby - non l'ha mai usato per lo sviluppo commerciale) e aveva già lavorato in JEE e ASP.NET, La risposta di Wayne M è risultata molto vera.
Ad ogni modo, c'è un lato sottile di ciò che nessuno ha ancora menzionato, ma che mi ha infastidito un po 'con Rails - la strong dipendenza da convenzione sulla configurazione .
Essenzialmente, se sei abituato a "trovare nei file" - orientato verso una nuova base di codice, è probabile che CoC ti infastidisca quando cerchi di raccogliere Rails. È fantastico per i greenfield CRUD semplici che sono fatti proprio nel modo Rails (come dice Wayne M), ma per qualcosa di più unico e complicato, sarà difficile capire cosa sta succedendo se cerchi di elaborare il flusso cercando roba nei file per vedere come viene collegato l'impianto idraulico.
Anche se penso, probabilmente questo problema non sarà così grave una volta che avrai più esperienza con Rails. Posso sicuramente vedere che si tratta di un problema per qualcuno che proviene dallo sviluppo web Java / .NET di oldskool che è abituato a un flusso di configurazione molto dettagliato e viene utilizzato per fare affidamento sul vedere tutto ciò che è stato scritto da qualche parte.
Con me, il problema più grande in cui imparo la mia prima X (nel tuo caso, X è un linguaggio / framework web lato server), è che non appena vedo altri problemi, voglio immediatamente iniziare ad applicare X, anche quando potrebbe non essere l'opzione migliore. Sono migliorato in questo, ma è ancora una tendenza strong.
Ruby on Rails è una buona scelta per cominciare: c'è una buona comunità, molta documentazione e buoni tutorial. Ma assicurati di tenere a mente le alternative, specialmente se inizi a fare più sviluppo web. RoR potrebbe essere eccessivo per alcuni problemi, soluzioni inadeguate per gli altri e la scelta migliore per un set diverso. Sapere quali sono i punti di forza, i punti deboli e come utilizzare lo strumento.
Il mio consiglio è di avere un'immagine chiara del progetto che si desidera completare e quindi iniziare a provare a crearlo. Quando ti imbatti in problemi, alla fine prenderai tutti gli strumenti giusti. Questo approccio è buono perché stai prendendo decisioni basate su problemi concreti.
Un'altra cosa da fare è comprare libri. Le esercitazioni su Internet non lo riducono nella mia esperienza; inoltre lasciano molto spazio aperto per distrazione. Quando hai un libro, gli editori devono assicurarsi che forniscano un valore in quanto perdono denaro se ottengono recensioni negative. Spendere un po 'di soldi ti farà risparmiare un sacco di tempo.
Onestamente non riesco a capire chi si accorge poeticamente di cosa sia una passeggiata nel giardino di Ruby-on-Rails. Sono venuto da lui come uno sviluppatore esperto di ASP.NET-MVC, Java, PHP, Python - e ho trovato che fosse il più orribile disastro di tempo mai! Il 90 percento delle risposte google online sono errate o incomplete. Perché? È cambiato così tanto ogni anno? O a nessuno interessa sapere come funziona il codice? Mi ci sono volute enormi quantità di tempo per fare solo cose semplici; molto, molto più di quanto mi porterebbe in C # / ASP.NET-MVC, per esempio. Sicuramente non mi ci è mai voluto tanto tempo per imparare le mie tecnologie originali. Certo, ROR è conciso. Se è importante per te. Ma ho trovato raramente chiaro come creare codice che possa portare a termine un compito. Personalmente, preferirei digitare su una tastiera per 20 secondi per scrivere codice che funzioni sicuramente, è chiaro e puoi seguirlo, piuttosto che digitare il codice Ruby teso per 2 secondi, ma che non funzionerà mai fino a quando non sarò sveglio tutta la notte a cercare modo per farlo funzionare davvero. È un mucchio di dodo orribile e puzzolente. Perché? E 'quel codice open-source (come nel gratuito), non produce incentivi per renderlo uno strumento di qualità? Troppi script-kiddies che pompano revisioni e moduli e cattiva documentazione in esso? Non lo so. Ma quando finalmente sono riuscito a sfuggire al primo progetto Ruby-Rails, ho giurato che non sarei mai più entrato in quel casino!
Ti suggerisco di guardare gli indici che valutano la prevalenza di diverse lingue / script. Ecco un link che potrebbe rivelarsi utile: linguaggi popolari utilizzati in ambito professionale.
Questo dimostra la relativa popolarità dei linguaggi web in base alle ricerche di annunci di lavoro online.
Accetto alcune delle risposte sopra riportate su RoR, ho sviluppato applicazioni con RoR negli ultimi due anni. Funziona davvero bene con le applicazioni semplici, le operazioni CRUD (Crea, Leggi, Aggiorna e Elimina) funzionano molto bene, è un vantaggio per lo sviluppo di applicazioni semplici ma anche i suoi limiti. Anche se ci sono un sacco di gemme offre vari vantaggi e facilità d'uso, fondamentalmente è. Uscire dalla scatola ti porterà tutte le applicazioni contorte.
Se sei un grande team che lavora su un'applicazione che utilizza RoR, la delega del lavoro può essere difficile da superare.
Leggi altre domande sui tag server-side ruby-on-rails