Ruby on Rails sont / Grails les cadres les plus rapides pour obtenir rapidement des sites?

Question

J'envisage d'utiliser Grails pour un nouveau site Web, mais je suis ouvert à d'autres / nouveaux langages de programmation et des cadres. Je l'ai fait à l'aide au développement J2EE / JSF2, ASP.NET et PHP. Grails est ou Ruby on Rails à peu près la meilleure façon d'obtenir des fonctionnalités rapidement opérationnel?

Quelques réflexions initiales:

• django ressemble à RoR / Grails et je considérerais cela
• GWT est un concept intéressant mais il ne semble pas que le délai d'exécution est tout aussi rapide

Merci, -Jon

Answer 1

Comme toutes les questions de ce genre, la réponse est « ça dépend ». Les facteurs à considérer comprennent comment vous sentez-vous avec la langue / cadre et quelles sont les caractéristiques nécessaires au projet. Cela dit, je l'ai construit des sites en utilisant un certain nombre de cadres, chacun avec ses propres forces et faiblesses:

Grails

Si je dois obtenir un site rapidement pour quoi que ce soit professionnel , Grails serait probablement mon premier choix. GORM est de loin la plus simple ORM et la plus intuitive que je l'ai essayé, le paradigme MVC est très bien exécuté, il y a 0 configuration pour commencer à coder (se soucier pas sur les URL, les correctifs DB, quoi que ce soit), itération très rapide (juste rafraîchir la page), l'intégration Java transparente (une bonne chose dans le monde des affaires), et quelques plugins merveilleux (par exemple Searchable est une chose de la beauté). Le plus gros inconvénient est que l'hébergement peut être difficile à trouver (et coûteux).

Ruby on Rails

Mon expérience avec RoR est très similaire à celle de Grails: MVC bien exécuté. Du côté positif, il a une plus grande communauté, donc les ressources en ligne (documentation, FAQ, exemples de code, etc.) sont très nombreux, il y a des TONNES de plug-ins, Ruby est un peu plus souple / expressif / « funky », et il est beaucoup plus facile de trouver l'hébergement (en particulier pour des projets personnels.); du côté négatif, la gestion de la dépendance / configuration suce (je l'ai utilisé RubyGems sous Windows, Ubuntu, Fedora et Mac OS X et a rencontré des problèmes non négligeables sur chacun), il est légèrement configuration plus / les frais généraux que Grails (en particulier, traitant des routes.rb et des tonnes de fichiers de migration db), et apparemment, RoR a des problèmes d'évolutivité graves.

PHP (y compris le cadre CakePHP)

Si je dois quelque chose rapidement pirater ou de construire un site pour personnels utilisations, alors je serais probablement aller avec PHP. PHP est loin le plus facile d'apprendre la langue et deploy: télécharger un des paquets LAMP pratique là-bas, cliquez sur une ou deux fois, et commencer à bidouiller. La communauté est plus grande que celle de RoR, si la documentation est abondante et il y a d'innombrables plug-ins (facilement « installés » simplement en laissant tomber dans le fichier php et de rafraîchir la page). La langue est simple à apprendre, mais certaines choses en PHP sont juste carrément étrange et il faut beaucoup de discipline pour éviter le code laid. Le cadre CakePHP applique un beau paradigme MVC pour les choses de l'aide keep ordonnée, et pour la plupart est à égalité avec RoR, même si personnellement je trouvais un peu plus unintuitive.

Java (servlets, des JSP, JSTL, entretoises, Velocity)

Je l'ai construit de nombreux sites en utilisant les technologies de servlet Java, et je peux honnêtement dire qu'il n'y a pas de bonnes raisons de venir les chercher pour tout nouveau site de nos jours. Ils ont une courbe d'apprentissage abrupte, des tonnes de configuration pour combattre avec (XML enfer), itération lente en raison de la nécessité de redéployer des choses tout le temps (sauf si vous utilisez JRebel), bavard code et pas « freebies » en termes de fonctionnalité. Je l'ai joué avec le Play! Cadre et Roo printemps un peu et les deux sont en train de faire des trucs très cool avec plus ou moins « pure » du code Java et sont dignes d'intérêt plus loin.

Answer 2

Lorsque vous utilisez CakePHP, je peux tourner une application web plus rapide que ... un ... vraiment gars rapide. Quoi qu'il en soit, il est rapide. Laissez tomber les fichiers dans votre dossier racine web, configurer deux fichiers (environ trois lignes de changement de chaque). Et commencer à coder.

Parce qu'il favorise la convention sur la configuration, il faudra une certaine expérience pour veiller à ce qu'il est configuré de manière optimale, mais je vous garantis que, avec des niveaux égaux d'expérience, sports CakePHP les plus de déploiement rapide de tout cadre, probablement période .

Cela dit, le projet de CakePHP original était un clone de PHP de rails (il est plus), donc je suis sûr que des rails est rapide à déployer ainsi.

Answer 3

Je travaille avec ASP.NET MVC cadre pour un certain temps maintenant, et je l'ai trouvé qu'il était un joli cadre de bon darn. Extrêmement facile à utiliser, surtout si vous êtes familier avec .NET. Le cadre a connu une croissance rapide depuis sa sortie en 2009, MVC 3 aperçu a été rendu public récemment. Je pense que MS est en train de faire toutes les bonnes choses avec le framework ASP.NET MVC.

Answer 4

Je n'ai pas utilisé tout, mais Rails est sacrément rapide. Je pense Grails est trop car il incarne la philosophie DRY assez bien. Je ne sais pas assez sur d'autres cadres de langage dynamique à dire.

Même avec de bonnes stratégies de génération de code ASP.NET (mes) webforms ne semblent pas aussi efficace.

Answer 5

J'ai tâté de Django et Rails et trouvé Rails à plus de mon goût. Cela étant dit, je préfère ASP.Net MVC 2 beaucoup mieux que Rails. Je suis beaucoup plus rapide dans MVC (ou même seulement des formulaires Web) que Rails simplement parce que mon esprit « fonctionne mieux » avec C #.

Pour moi, il se résume à ce que vous savez et ce que vous aimez. Je l'ai entendu beaucoup de gens que Ruby est amusant, pas pour moi, ce n'est pas. C # est amusant! Haskell est amusant! Si vous n'aimez pas la langue / cadre, alors vous ne serez pas aussi rapide qu'un cadre « plus lent » que vous aimez.