Quali sono gli svantaggi del RoR? [chiuso]

Attualmente sto cercando di decidere quale lingua lato server imparare e utilizzare per lo sviluppo Web, e mentre è relativamente facile ottenere informazioni sul perché x, y o z sia una buona cosa, è più difficile capire i lati negativi di ogni di loro.

In particolare, sono curioso di sapere quali sono gli svantaggi dell'apprendimento e / o dell'uso di Ruby on Rails rispetto a qualsiasi altra lingua / struttura.

Parlando per esperienza: il rovescio della medaglia è che ti affidi un po ' troppo al framework Rails . Questa è una cosa fantastica e meravigliosa se stai scrivendo app CRUD semplici e greenfield che rientrano esattamente 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: interagisci con un database esistente, parla con un'altra applicazione che non ha un'API JSON o XML definita, implementa un flusso di lavoro complicato, Rails diventerà il tuo nemico. Lo èpossibile fare queste cose con Rails, ma va "controcorrente", quindi sei praticamente solo per capire come farlo poiché la comunità di solito risponde semplicemente con "Non farlo, non è Rails modo "- questo comporta perdita di produttività o codice molto disordinato poiché in pratica devi hackerare il framework Rails.

Inoltre, c'è il rovescio della medaglia non detto: tutto il resto sembrerà brutto e maleducato. Una volta assaggiato il dolce, dolce nettare di Rails (ok, evangelizzando un po 'qui ...) tutto il resto è bello. Tornare da Rails a PHP, ASP.NET WebForms o Java è come camminare su un letto di chiodi dopo aver giocherellato in un giardino lussureggiante; non vedrai le altre lingue / strutture nella stessa luce, e mentre puoi ancora apprezzarle, segretamente desidererai l'affettuoso abbraccio di Rails.

Per la tua prima lingua lato server, sento che ci possono essere un paio di problemi con RoR:

1. Non stai solo imparando una lingua, stai imparando un quadro. Sicuramente mi prenderei un po 'di tempo per giocare con il vecchio rubino prima di saltare nelle rotaie.

2. Dal momento che si tratta di un framework e di uno "presuntuoso", penso che ti darebbe una portata molto limitata di tutto ciò che sta accadendo nel framework.

Nel complesso Ruby on Rails può essere un buon punto di partenza per far rotolare la palla, ma c'è molto da imparare sullo sviluppo web che potresti perdere facendo affidamento su un singolo framework.

Ho provato a imparare il RoR diverse volte e il mio problema più grande è sempre cercare di far funzionare correttamente i pacchetti e la documentazione. Il problema con la documentazione è che sembra sempre non aggiornato (o molto semplice). Ho preso le basi dal sito, ma oltre a tutto sembrava così datato (anche il libro che ho comprato e ho finito per tornare). Un'altra cosa che potrebbe essere uno svantaggio sono le dipendenze che hanno alcune biblioteche e il modo in cui possono entrare in conflitto con un'altra, come affermato da Ben Coe .

Qualcosa a cui ho pensato più tardi e invece di fare un commento, modificherò solo la mia risposta è questa: RoR ha la possibilità di rovinare Ruby per te. So che quando l'ho provato, mi ha fatto pensare che "Ruby era stupido". Poi qualche mese dopo ho deciso di provare Ruby e ho adorato la lingua, è stata la struttura che mi ha fatto odiare la lingua. Non mi sono dilettato molto, ma quando l'ho fatto, mi è davvero piaciuto Sinatra . Penso di avere la gioia che la maggior parte delle persone esce dal RoR da Sinatra.

Se questa è la tua prima lingua lato server, è buona come una qualsiasi. La cosa da fare è concentrarsi su uno e, dopo aver sentito di averlo imparato, esplorare gli altri e dedurre le proprie conclusioni.

Lavoro quotidianamente con RoR e ASP.NET, ma stranamente preferisco il mondo ASP.NET, ma ciò ha più a che fare con la filosofia personale che con il linguaggio o l'architettura stessa. (Sono un po 'un maniaco del controllo e personalmente gravito su linguaggi fortemente tipizzati).

Indipendentemente da ciò, dico di provarlo. RoR è un ottimo ambiente in cui lavorare, ma prima di saltare direttamente su Rails, mettiti comodo con Ruby come lingua. Al di là del Web, Ruby è un linguaggio di scripting piuttosto interessante se si arriva a dover gestire una * nix box e può farti risparmiare un sacco di tempo.

Come qualcuno che ha imparato Rails di recente (come hobby - non l'ha mai usato per lo sviluppo di livello commerciale) e aveva già lavorato in JEE e ASP.NET, Wayne M la risposta di suonato 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 forte dipendenza dalla convenzione sulla configurazione .

In sostanza, se sei abituato all'orientamento guidato da "Trova nei file" con una nuova base di codice, è probabile che il CoC ti dia fastidio quando cerchi di raccogliere Rails. È ottimo per i semplici greenfield CRUD che sono fatti esattamente nel modo Rails (come dice Wayne M), ma per qualcosa di più unico e complicato, sarà difficile capire cosa sta succedendo se provi a calcolare il flusso cercando roba nei file per vedere come è collegato l'impianto idraulico.

Anche se penso che questo problema probabilmente non sarà così grave una volta che avrai molta più esperienza con Rails. Posso sicuramente vedere che si tratta di un problema per qualcuno proveniente dallo sviluppo web Java / .NET oldskool che è abituato a un flusso di configurazione molto dettagliato e fa affidamento sul vedere tutto spiegato da qualche parte.

Con me, il problema più grande con 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 forte.

Ruby on Rails è una buona scelta per iniziare: c'è una buona comunità, molta documentazione e buoni tutorial. Ma assicurati di tenere a mente le alternative, soprattutto se inizi a fare più sviluppo web. Il RoR potrebbe essere eccessivo per alcuni problemi, soluzioni inadeguate per altri e la scelta migliore per un set diverso. Conosci i suoi punti di forza, debolezza e come usare lo strumento.

Il mio consiglio sarebbe di avere una chiara immagine del progetto che si desidera completare e quindi iniziare a provare a costruirlo. Man mano che si verificano problemi, alla fine afferrerai tutti gli strumenti giusti. Questo approccio è valido perché stai prendendo decisioni basate su problemi concisi.

Un'altra cosa da fare è comprare libri. I tutorial su Internet non lo tagliano nella mia esperienza; lasciano anche un sacco di spazio aperto per la distrazione. Quando hai un libro, gli editori devono assicurarsi che fornisca valore in quanto perderanno denaro se ottiene recensioni negative. Spendere un po 'di denaro ti farà risparmiare un sacco di tempo.

Onestamente non riesco a capire coloro che cerano poeticamente su cosa sia una passeggiata nel giardino di Ruby-on-Rails. Ci sono arrivato come esperto ASP.NET-MVC, Java, PHP, sviluppatore Python - e l'ho trovato il più orribile perditempo di sempre! Il 90 percento delle risposte online di Google sono errate o incomplete. Perché? È cambiato così tanto ogni anno? O è che nessuno si preoccupa di far funzionare davvero il codice? Mi ci è voluto molto tempo per fare cose semplici; molto, molto più di quanto mi porterebbe in C # / ASP.NET-MVC, per esempio. Certamente non mi ci è mai voluto così tanto tempo per imparare le mie tecnologie originali. Concesso, ROR è conciso. Se questo è importante per te. Ma ho trovato raramente chiaro come creare codice che avrebbe portato a termine un compito. Personalmente, preferirei digitare su una tastiera per 20 secondi per scrivere un codice che sicuramente funzioni, è chiaro e puoi seguirlo, piuttosto che digitare il codice Ruby per 2 secondi, ma che non funziona mai fino a quando non sono sveglio tutta la notte alla ricerca di un modo per farlo effettivamente funzionare. È un mucchio orribile e puzzolente di dodo. Perché? È quel codice open-source (come nel free), non produce incentivi per renderlo uno strumento di qualità? Troppi script-kiddie pompano revisioni e moduli e cattiva documentazione? Non lo so. Ma quando sono stato finalmente in grado di sfuggire a quel primo progetto di Ruby-Rails, ho giurato che non avrei mai più fatto un casino! non produce incentivi per renderlo uno strumento di qualità? Troppi script-kiddie pompano revisioni e moduli e cattiva documentazione? Non lo so. Ma quando sono stato finalmente in grado di sfuggire a quel primo progetto di Ruby-Rails, ho giurato che non avrei mai più fatto un casino! non produce incentivi per renderlo uno strumento di qualità? Troppi script-kiddie pompano revisioni e moduli e cattiva documentazione? Non lo so. Ma quando sono stato finalmente in grado di sfuggire a quel primo progetto di Ruby-Rails, ho giurato che non avrei mai più fatto un casino!

Ti suggerisco di esaminare gli indici che valutano la prevalenza di diverse lingue / script. Ecco un link che potrebbe rivelarsi utile: popolari lingue professionali utilizzate dal web.

Ciò mostra la popolarità relativa delle lingue relative al Web in base alle ricerche di annunci di lavoro online.

Sono d'accordo con alcune delle risposte di cui sopra sul RoR, ho sviluppato applicazioni con RoR negli ultimi due anni. È davvero buono con le applicazioni semplici, le operazioni CRUD (Crea, Leggi, Aggiorna ed Elimina) funzionano molto bene, è un vantaggio per lo sviluppo di applicazioni semplici ma ha anche i suoi limiti. Anche se ci sono molte gemme offre vari vantaggi e facilità d'uso, è fondamentalmente. Uscire dalla scatola ti farà contorcere tutte le applicazioni.

Se sei un grande team che lavora su un'applicazione che utilizza RoR, la delega del lavoro può essere difficile da evitare.