Web版のストックフォトサービスを作るにあたって最適なプログラミング言語と勉強方法を知りたいです

１. 何度も書く非効率か？
　複数のコードをリファクタリングし、
　自分の１つのレシピに書き直すことが早道
２. どの言語が最適か？
　どれでもok
　レシピ作成は最初は３言語から初めて
　２０レシピあたりから絞ることを推奨
３．どんな流れで勉強するのがベストか。
　目的（ストックフォトサービス）を
　実現できるレシピ調べ、１つのコードに
　リファクタリングする
　２０レシピあたりから、１冊入門書を
　読んで、自分のリファクタリングが
　稚拙、幼稚であるか？思い知って、
　自分が選んだ言語に真面目に向き合う
　ことがベストです。
　（失敗から始める異世界言語！）

ストックフォトサービスは画像劣化させるサムネル等の画像変換がキーになると思います。

data:image/png;base64,....

例えば、サーバのローカルファイルの画像は
＜img src="パス"＞で表示できますが、
DB保存の場合、どうしましょう？

BytesIO　などでローカルファイルに画像を書き出さず、変数にbase64で保存し、直接、クライアントへbase64で送信する必要がでてくるでしょう。svg変換した画像、Live動画・・・どうしましょう？webSocketによるチャットはどうしましょう？

その時、開発フレームでは対応できないかも知れません。

個人的な感想ですが、ruby,python,go,php等でマルチスレッドhttpサーバ＋マイクロアプリ構成(Ajax)で作成する方が早道とおもいます。
　例外処理を度外視すると、通勤時間で３００行位で作成できました。go<python<ruby<php感はありますが、pythonはコードの美しさ、rubyはプロトコルの品質、goはコード短さで、phpは頑張れよ！で１へーです。

p.s. sslはnginxで実現するとテストが簡単です。

僭越ながら作りたいサービスを作ってからその時利用した技術のデメリットやメリットがわかると感じるので、一旦作りたいものを作ってみれば悩みは解決するのかなと感じます

１．「漢字ドリル方式で何度も書く！」を心がけていますが、非効率でしょうか？(「さっさとフレームワークを覚えろ」みたいな)
開発ではあまり必要ないのかなと
資格の勉強とかなら自分もそうです！

２．皆さんならストックフォトみたいなWebサービスを作ろうとした場合、どの言語が最適だと思われますでしょうか？
購入した書籍のphpでもできると思いますよ！
ストックフォトじゃないですがweb漫画アプリでもurlで.phpのアプリ見たことあるので

３．どの言語をどんな流れで勉強するのがベストでしょうか。
作る過程でわからないところを都度調べるが一番効率いいと思います
なので自分が調べて信じた言語を信じて一旦作り上げるのが個人的にベストな気がします！

ひとまずあれこれ考えずに作りたいものを作るために調べて作っちゃえば、多分今感じている悩みは無くなると思いますよ
あと、プログラミング言語の優劣って確かに考えることあると思いますが、現時点で現役の言語はニーズがあるから現時点でも現役で利用されているので、この言語はダメ、この言語こそ至高という考えは個人的にはナンセンスな気がします
とりあえずなんでもいいから作ってしまえ！
大事なのは言語じゃなくてやりたいことの実現です！
いいお年を！

　作りたいモノがはっきりしていることは良いことだと思います。作りたいモノのイメージを詳細に思い描いて欲しいと思います。

　ただ、プログラム言語もフレームワークもＷｅｂサービスも実装のための道具であって、道具から作りたいモノのカタチは定まりません。Ｗｅｂサービスで使われている言語には、それほど狭い用途性はありません（無いからこそ広く使われています）。すでに他の方がおっしゃられている「言語はなんでも良いです」というのはそういう意味であろうと思います。

　個人的には、まず作りたいストックフォトサービスの姿を明確にすることをお勧めします。
　そのサービスはどういうウェブページを持っていて、どういう機能ブロックを持っているのでしょうか。そして中核となる機能は何になるでしょうか（あるいは、最低限必要な機能は何でしょうか）。

　以上を踏まえた上で答えると以下のような答えになると思います。

１）効率性
　効率的ではありません。
　作りたいもの（機能ブロック）の動きを自分なりに描き（フロー図でも日本語（いや、何語でもいいんですが）の箇条書きリストでもなんでも良いです）、その動きをプログラミング言語で置き換えていくことがプログラミングです。この「作りたいモノ」を「プログラミング言語で置き換える」操作は漢字ドリル方式では身に付きません。なぜならあなたの造りたいモノは「独自のアイディア」に基づくものであって、誰もその手本を提供することはできないからです。もし漢字ドリル方式で身に着けた技術で実装できたのだとしたら、そのストックフォトサービスはすでに誰かが作ったものをなぞっているだけです。

２）最適な言語は何か
　自分ならＰＨＰを選びます（たぶん、プロトタイプ作製の段階ではフレームワークも使わないと思います）。それはＰＨＰにアドバンテージがあるわけではなくて、自分が良く使っていて公式ドキュメントをいちいち読み返さなくても済むからです（それでも時々読みます）。

３）どの言語をどのような流れで
　当たり前すぎることですが、プログラミング言語はコンピュータに行わせたいことを記述するもので、コンピュータが行えることというのは、（意外かもしれませんが）それほど多岐にわたるものではありません。ごく単純な動作を積み重ねさせて少し複雑なことをさせています。その「少し複雑なこと」の中にはだいたいの人が同じようなことをさせるものが数多くあり、そういうものはライブラリとして誰かがまとめてくれていて「フレームワーク」と呼ばれていたりします。（すでに誰かが作ったライブラリを自前で作ることを「車輪の再作成」と呼んだりしますが、最近はあまり見ない言葉ですね）
　ここから先は私見で、おそらく異論が多いことと思いますが、次のような流れが良いと思います。

1. スタートアップは（何かの）言語のみで、シンプルな機能ブロックを作る
   　作る物は最小限の機能で、下位レイヤがシンプルなものが良いと思います。
   フォトストックサービスなら、ダミーのフォトファイルを用意しておいて、その画像イメージを一覧表示するだけのもの、とか（これはファイラーと呼ばれるものに近いと思いますが）。

2. 下位レイヤが少し複雑なものに手を出す
   　入出力（Javascriptも使わないシンプルなフォームから投稿し、ファイルを配置する）やＤＢアクセスなどを持つ機能ブロックでしょうか。ファイルアップロードを伴うサービスはイタズラされないようなセキュリティ機能も必要です。複雑なものを作ることで使う言語の機能も広がって行くでしょう。

3. 実際に作ったものを整理してドキュメント化する
   　自分がどういう風にモノづくりしたか、整理しておきます。どういう機能をプログラムで実際に用意したでしょうか。最初に作った（プロトタイプということですが）機能には似たようなＷｅｂサービスで使う機能がおおよそ含まれているはずです。それが見通せるようになった後でフレームワークのドキュメントを眺めてみてください。
   　そのフレームワークがなぜ便利に使われているのか良く解る（言い方を替えると「効率よく学習できるようになる」）のではないかと思います。
   　また、フレームワークを使う中で出て来るトラブルの対応もしやすくなっていると思います。言語そのものに関わるエラーなのか、フレームワークを使うから発生したトラブルなのか、見極められるようになっていることでしょう。（これも「効率性」に関わってきます）。