私は自分がよく訓練されたWordPressテンプレート開発者であり、最近、Webアプリのフレームワークに関する本やドキュメント、特にDjangoとRuby onRails。2つの言語はまったく知りませんでしたが、別の言語を1つまたは2つ習得しても問題はありません。フレームワークを使用することの本当のメリットは得られません。例えば、PinterestはDjangoを使用して作られていますが、WordPressで同じ結果を達成できると思います= JavascriptとCSS3を使用したテンプレート。その特定のケースでフレームワークを使用することの違い/利点を教えてもらえますか?
Wordpressで同じフロントエンドを実現できますが、実現できないのは、よりアプリケーション指向のアーキテクチャに基づいたアプリケーションの速度と規模、そして最も重要なのは保守性です。
Wordpressは非常に柔軟性がありますが、低速であり、あらゆる種類の重要な規模で動作できるようにするには、非常に多くのTLCが必要です。その設計により、動作の非常に柔軟なランタイム変更が可能になりますが、これはコードが特定のページの至る所で実行される可能性があり、メンテナンスが悪夢になるため、Pandora's Boxでもあります。
WordpressはCMSとして非常に優れていますが、これらの境界の外側にプッシュを開始すると、問題が発生し、Wordpressアプリケーションのニーズを満たすことができます。
そうは言っても、Wordpressのコンテキストでビルドできるアプリケーションがあれば、ぜひ行ってみてください。 Wordpressは、概念実証またはMVPを構築するための素晴らしいツールです。それが起動して実行できる場合は、完全なアプリケーションを作成するよりも適切な選択となる可能性があります。アプリケーションがかなり狭い設計要件のセットに収まらない限り、製品デザインが成熟し、視聴者が増えるにつれて、レンガ壁にぶつかることになるので、長期的には、カスタムに移行する必要があることに注意してください応用。
資格情報:過去数年間、毎月2,500万以上のユニークなサービスを提供するWordpressインストールを維持してきましたが、それを実行し続けるには非常に巧妙にならなければなりませんでした。 Rails 10x-30x程度の速度でページを提供し、アプリケーションとして非常に拡張性の高いアプリケーションです。これにより、実際には得られないアプリケーションの可能性の探索を開始できます。ワードプレス。
私はかつていくつかのスタートアップで、高度なeコマース、コミュニティ主導型の市場向けにWordPressを選択することを決めました。
それ。だった。最悪。可能。決定。
これは私が感じていた方法です:
初めは見栄えが良かった-あなたは素晴らしいコミュニティ、すべてのためのプラグインなどを持っているが、真実に直面しましょう-それはルートです-WordPress is blogging platform!
post
です。get_post_meta
_のような多くのfunctions
を使用して、そのコア機能を管理する必要があります。 $post->author()->comments()
のようなものは単なる夢です。WordPressコミュニティは素晴らしい仕事をしていますが、優れたフレームワークと比較すると、1つの大きな違いがあります-Frameworksは単なるフレームワーク-set of toolsとそれらyourプロジェクトの実行を支援するツールがあります。 WordPressは既に変更する可能性のあるものになろうとしています。
車が必要な場合は、いくつかのツールを購入して構築するか、トラックを購入して車のように見えるようになるまで変更を試みることができます。
よく整理されたカスタム機能を必要とするものには、WordPressを使用しません。
ブログや小さなeコマースに適しています(一部の人はトラックを改造して車になり、製品の機能、つまり投稿、プロモーションとの結び付け、ポストメタ、プロモーションの追加などを行う車になりました。いくつかの魔法の方法でそれを一緒にラップするマネージャー)。
トップの答えを支持したにもかかわらず、私は反対意見を述べたい。
Railsは本当に特別ですか?
Railsは、無料のWordpressプラグイン WP Project Manager で複製されるソフトウェアであるBasecampから抽出したDavid Hanssonによって作成されました。 Rails開発者がPHPとWordpressを過小評価していることを示す良い指標だと思います。
MVCおよびWP
確かに、MVCパターンに従っていません。しかし、 hooks を使用すると、ロジック(プラグイン内)をビュー(テンプレート内)から分離すれば、コードを適切に分離できます。 (ヒント:カスタム投稿タイプはモデルのようなものです。)
フレームワークとアプリケーション
ご覧のとおり、Wordpressはアプリケーションまたはフレームワークのように扱うことができます。これはアプリケーションであり、フレームワークで見つけることが期待されるすべてのコンポーネントを備えています。すぐに使えるセキュリティ、認証、拡張性があります。そして、それは拡張されることを意図しています。
スケーリング
WPは、TechCrunch、Smashing Magazine、およびCNN(の一部)を含むインターネットのWebサイトの18%をサポートしています。 WPスケールを作成する方法があるようです。 免責事項:私はこれらのようなメガサイトで作業した経験がないので、単なる推測を提供しています。
WP Future
WPコミュニティの現在の目的は、WPをCMSからフレームワークにシフトすることです。すべてのピースが揃っていることを考えると、それは自然な流れだと思います。そして、Wordpressコミュニティは強くなっています。
本当の答えではなく、ヒント:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
それを完全に置き換えることができるかのように...私はそれが主にロジックフローの問題だと思います。それは、どの程度の命令型(Ruby on Rails)対記述的(WordPress)プログラミングを行うかによって異なります。
wordpressがRailsを置き換えることができるとは思いません。なぜならwordpressは、RoRと比較すると、APIとサポートのセットが限られているためです。 wordpressはブログアプリケーション用の強力なツールですが、Railsでも、Radiant CMS、Refinery CMS、Locomotiveなどの宝石を使用して同じ効果を実現できます。 ttdのような、Railsで簡単に変更できるパワーを追加することは、ワードプレスでは非常に困難です。
Deviseやcancanなどの認証および承認メカニズムと同じです。ワードプレスで同じことをする簡単なオプションはありません。
Railsはプログラマーの生活を楽にします。 Webアプリ全体では、Railsを使用することを常に好みます。
WordpressはXフレームワークを置き換えることはできませんが、2つは確かに相互に補完できます。
たとえば、魅力的なテーマでCMSコンテンツを提供するWPフロントエンドは、打ち負かすのがかなり困難です。カスタムコンテンツと出来上がりのためのバックエンドサーバーへのプロキシ、両方の長所。そうしないと、WPは必然的にすべての要件を満たすことができず、四角い丸穴のウサギの穴に行くことになります。そこでXフレームワークが登場し、WPギャップを埋めます。
WPがスケーリングしないという概念にはある程度の真実があるかもしれませんが、一般的な場合は95%で、特にWP Cacheまたはミックスにスローされる他のキャッシュプラグイン。
WPをDjangoまたはRoRで構築できると言う人もいるかもしれません!へー、へー、最初にあなた;-)
FWIW、私は動的言語フレームワークを避けて、静的/強く型付けされた対応物を支持します。ブリングにはWPを使用し、速度/スケーラビリティ/安全性には静的Xフレームワークを使用します。もちろん、それは好みの問題です。明らかに、コンパイル時の安全性よりも実行時の柔軟性を好む人もいます。私は最近、後者のキャンプに完全にいます...