CakePHP, CodeIgniter o Rails per clone di Tumblr multiutente?

Question

Sto per iniziare a costruire un clone tumblr che gestisce più utenti (così come cloni premade Gelato non è tagliato) e io non sono sicuro di quale quadro mi piacerebbe costruire questo è.

In questo momento, ho intenzione di costruire un prototipo. Qualcosa su cui posso mettere una dozzina di amici per testare il concetto e crescere fino a un paio di centinaia di utenti per dimostrare il mercato, quindi non sono preoccupato per la scala a lungo termine. La mia più grande preoccupazione al momento è l'implementazione rapida. Mi piacerebbe passare da zero alle iscrizioni nel più breve tempo possibile, con il minimo di personalizzazione possibile nel quadro della scelta.

Ho esperienza con PHP, ma non Ruby. Tuttavia, non penso che la curva di apprendimento sarebbe troppo ripida, quindi non escludo i binari. Voglio solo il framework che è più appropriato per un sistema come un clone di tumblr multiutente in modo che io possa costruirlo con il minor fastidio possibile e il più rapidamente possibile.

Se qualcuno ha esperienza con un progetto simile, o con queste strutture e può offrire una prospettiva perspicace, sarei molto riconoscente.

Grazie per aver dedicato del tempo per leggere.

Cheers, ~ Jordan Feldstein

Answer 1

Sono in sviluppo in PHP dal 2000 e ho ancora un sacco di sistemi PHP in produzione (utilizzando sia CodeIgniter che CakePHP).

ho trovato Rails ad essere incredibilmente più efficiente per sviluppare in ... facilmente il 50% in più di produttività, a seconda del caso d'uso. Più veloce, più alta qualità. Scelta facile per me.

Answer 2

CodeIgniter è molto leggero, che è probabilmente a scapito di questo progetto, se si vuole codificare il meno possibile.

Answer 3

CakePHP è praticamente un tentativo di trasferire Rails in PHP, quindi la scelta tra questi due framework dipenderà da altri fattori.

Un fattore potrebbe essere se si vuole imparare Ruby o no. Mi sono dilettato e ho sentito che è superiore a PHP, ma preoccupazioni più pratiche mi impediscono di sperimentarlo di più (devo usare PHP al lavoro).

Un'altra preoccupazione sarebbe ospiterà. Io uso Dreamhost, e la tariffa è la stessa per PHP e Rails. Tuttavia, un mio amico ha appena ottenuto un account di hosting GoDaddy e in realtà deve pagare una tariffa mensile più alta per avere un host abilitato a Passenger.

Answer 4

Definitivamente Rails. Sarebbe molto più veloce sviluppare un progetto come questo in Rails.

Per quanto ho visto, PHP è di gran lunga il numero di Rails in ORM. E il routing Rails è molto meglio di qualsiasi altro framework PHP.

Answer 5

+1 per Rails.

Non posso parlare di Codeigniter. La mia comprensione generale riecheggia le affermazioni di cui sopra. Leggero e non completamente orientato agli oggetti.

ho sviluppato in CakePHP Da gen 2006, dopo aver tentato di ottenere Rails schierate sul mio server e in mancanza di male. Rails non era facile da schierare in quel momento ... almeno non per me. Al momento Cake era l'alternativa migliore, e lo è ancora in molti modi.

La torta è una struttura molto competente. Tuttavia, sono d'accordo con le affermazioni che è in molti modi "dietro" Rails. Alcune funzionalità non sono ben progettate, meno integrate o semplificate in confronto.

Alcuni mesi fa ho trascorso un paio di giorni trascinando una delle mie app per Cake su Rails2. Proprio come un esercizio. La curva di apprendimento è stata molto superficiale per qualcuno come me (con una conoscenza decente dei concetti su cui Cake e Rails sono costruiti). Recentemente abbiamo iniziato a trasferire una delle nostre app al lavoro su Rails (anche da Cake) perché abbiamo scoperto che il supporto per molte cose che sono importanti per noi sono disponibili in Rails o Ruby ma non sono disponibili o sono complete in Cake e PHP.

Se non si è sicuri di passare a Ruby, è consigliabile consultare Lithium (precedentemente CakePHP v3). È solo PHP 5.3 e comunque è un buon modo dalla 1.0 ma la community è attiva e in genere sembra che sia stata Cake se fosse stata avviata oggi e non nel 2005.