  |
はてなキーワード: spaとは
https://d.potato4d.me/entry/20220405-nodejs/
が話題になっているけど、本来人類に必要なのはクロスプラットフォームな実行環境であってNodeじゃない。
TSが流行ったのはJSがクソだから。BabelしなきゃいけないのもJSにトランスパイルしなきゃいけないからであって、必要なのはJVMやCLRのような言語実行環境。
Reactが流行ったのはshadow domだけど、必要なのはDOMじゃなくてちゃんとした「アプリ」開発用のイベントモデルとレイアウトマネージャ含むGUI環境。
フロント界隈の流行廃りって本質的な改善ってよりもほかの良い技術をいかにブラウザ/Electron等JSエンジンという限られた環境に持ち込んで幸せになるかがメインに見えるので地獄に見える。
「アプリ」書くのになんでドキュメント記述用のHTMLに今ものっかってんだよと。
MavenやらGemsができて依存管理楽になったとか、RailsがでたときのようなCoC良いねとか開発の考え方を変えるフレームワーク、 rspec/Cucumberがでてテスト最高とか、c10kも怖くない非同期I/Oとか、好きな言語が使えるJVM/CLRそもサーバーならrustでもgoでも好きなものが動くとかとか本来の開発を楽にするという意味のブレークスルーってあんまりみられない気がしている。なんでフロント界隈の新技術ってあんまりわくわくしない。
逆にちゃんとしたクロスプラットフォーム実行環境がブラウザしかないということなんだけど、ブラウザなかなか進化しないし RIA は Apple 様が切り捨てるからなぁ。
ということですべてはブラウザが悪い。JavaScript 以外がちゃんと動くクロスプラットフォームのGUI環境が必要。でもプリインでモバイルでも動いてOSから独立して協調して作られていて、Webという既存の大量の資源にアクセスしやすいものは現時点で実質ブラウザ一択。つまりWASM に期待。次にHTMLであるべき文書はともかくSPAなんてもう「アプリ」なんだからHTML手書き文化もうやめてネイティブアプリ並みの GUI 作成環境も復権しよう。
するとクライアントでも好きな言語が使える。そして同じ言語がいいとサーバサイドで Node.js を使う必要もなくなりへっぽこプログラマが Node のイベントモデルを理解せずに使うこともなくなる。
そしてそれらができたときに Node というか JS/HTML の呪いから解放され人類に平和が訪れるのだ。君はその後も Node.js を使っても良いし使わなくてもいい。
https://foo-x.com/blog/is-spa-high-cost/
ぐうの音も出ない論駁だと思っていたら、はてブコメントがクソ煮込みうどんになっていてワロタ。
IQの高い起業家に対しては、自分でコードを書くことを薦めている。
そのときに明らかに学習コストが低く、当面のスケーラビリティに困らない方法は、SPA（というか、NextJS等のSSG）+BaaS（Firebase等）。
Railsなんぞ使ったら、あらゆるレイヤに戦線が広がって、労働集約的になってしまって、IQでゴリ押しできない。
正直、最近のサービスは高IQの人間にとっては極めて快適だと思う。いわゆる文系の人でも、セキュアかつスケーラブルなサービスを容易に開発できると思う。
文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。
文章がMECEでないので「まあそういうことね」という話は措いておいて。
a. 日本語ウェブサイトの記事本数で比較することはフェアではない
新しめの技術を活用している人の情報収集の順番としては、エディタでライブラリの当該部分のソースコードを読む、GitHubにリポジトリがあるのであれば、そこのissuesで検索をかける、Googleで英語（エラー文言等なので必然的に英語になる）で検索する、Stack Overflowで質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。
ミクロで見ると、フロントエンド系の主要な論客がQiitaから離脱していることもある。
SSGの登場によってSPAのネガな部分のほとんどは潰されていると思う。
SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。
他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象を観測できないので、とりあえず以上。
https://president.jp/articles/-/29313?page=2
前ページ
1
2
3
次ページ
「必需品から嗜好品になった瞬間、人はお金を払うようになるんです」
もちろん複数所有を可能にするには価格が関係してくる。上記ブランドは軒並み5000～1万円の間で「3プライス」もしくは「4プライス」を提案。選べるメガネの種類は膨大でも、価格の選択肢をシンプルにしたことで、本来高価格商品には手を出せない若年層までもが、「親に買ってもらう高額商品」としてのメガネではなく「自分で買える商品」として選べるようになったのだ。
3万円のメガネが5000円になる
しかしここで疑問が生じる。従来3万～10万円もした品が、なぜ一気に5000円に下がるのだろうか。
柴山氏は「おそらく品質にさほど大きな違いはないはず」とコメント。
「商品は流通数が少なければ競争も限られ高額な価格帯が保持されますが、多売できるようになれば薄利でも儲けが出るからです」
新興ブランドJINSと、老舗ブランド三城HDの数値を見てみよう。
「『新御三家』中で上場企業はJINSのみ。ここは一時株価の上昇で話題になりましたが、決算書を見る限り経営は堅実です。18年8月期時点で売上高548億円。7年前の11年8月期で145億円でしたから、3.7倍の成長です。しかも原価率約25％、利益率75％をほぼ維持しているのが見事ですね」
一方の三城HDはというと、原価率約33％、利益率は67％だ。実はこの微妙な数値の差が全体的な業績に大きく影響してくる。
「仮に1000円のメガネを販売するとして、JINSは原価250円で利益が750円になる。一方の三城HDは原価が330円で、670円が利益。もちろん実際はほかにも人件費やら広告費やらがかさみますが、この差は全体収益に大きな違いをもたらします」
JINSなど新興ブランドが原価を低く抑えられる理由は、企画デザイン・生産・販売までを一貫して行うSPA方式を採用しているからでもある。ユニクロやZARAなどに見られる手法でもある。
ハズキルーペの“過激”CMの1シーン。老眼鏡のイメージを一新。
流通量が多いから価格を下げられ、価格を下げられたから流通量も増える。「新御三家」はこの波にうまく乗れた成功組といえる。
とはいえこれが業界成功の最終形態ではない。18年の大ヒットはなんといってもハズキルーペである。これも「老眼」や「ルーペ」という本来隠したくなる要素を、「老い」とは無縁そうなエネルギッシュな渡辺謙をはじめ錚々たる俳優陣のCMでイメージを一新、さらには女性のお尻で耐久性を試すなど過激な演出の効果もあり、一気に話題を集めた。
元ネタ: なんでもSPAにするんじゃねぇ！という主張のその先
https://lealog.hateblo.jp/entry/2021/08/12/103111
SPAを採用しているサイトで「これは使いにくい」とすぐにわかるサイトたちだ。これ以外にも、基本的にSPAのサイトは使いにくいものが多い。
世界のコロナ情報がまとまっているとてもありがたいサイト。サイトを開くとワンテンポ遅れて読み込まれる上、ブラウザバックすると再読み込みで表示位置がリセットされて使いずらい
https://www.worldometers.info/coronavirus/
XBoxゲームパス。ロードが遅くて死ぬほど使いにくい。Windowsアプリ版は無限スクロールのチャンク読み込みに10秒以上かかって更に地獄
https://www.xbox.com/ja-JP/xbox-game-pass/games
バンドルサイト。これもワンテンポ遅れる上に戻るボタンの挙動がおかしい
https://www.epicgames.com/store/ja/
Slack。SlackはSPAじゃないと無理だと思うけど、スクロールがあっちこっち飛んだり戻るボタンの挙動がおかしい。車輪の再発名に失敗している
これ以外にもいっぱいあるけど、普段いかないサイトは覚えてないし、イラっと来ても使っているサイトは少ない。基本的に画面ロード後にワンテンポ遅れていろいろなパーツが読み込まれるため、スクロールしても欲しい情報がなかったり、ブラウザバックの動きがおかしかったり、様々な点でSSRのWeb1.0なサイトに劣る。
正直、SPAってHTML書けない(書きたくない)サーバーサイドエンジニアのエゴの産物であり、プロジェクト全体の工数が爆発的に増加する割に利用者が得られるメリットは少ないと思う。
いまもjQueryをWebアプリケーションの大事なライブラリとして使っている会社は少なくないと思う。
jQueryを会社で使っていると何が問題なのかを語っていこう。独断と偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。
採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。
また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人が可哀想なだけで、現役なわけではない。ラガード（遅滞者）の仲間入りをさせているだけだ。新人でもキャリアをデザインできる新人は「jQueryはオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。
そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードをメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。（jQueryでアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQueryに依存しておらず、jQueryに依存していないのであれば簡単にjQueryから脱却できるはずで、簡単にjQueryから脱却できるならもう脱却しているはずだからだ）
メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます！」とにこやかに言うようなものだ。
（ただし、さすがにjQueryだけでフロントをやっているという会社の求人をほとんど見かけることはない。無意識のスクリーニングで落としているのかもしれない）
jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているか、たまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。
「jQueryを使っていました」というエンジニアは、他社からはフロントエンドスキルが0とみなされる。つまり、フロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ（逆はできる）
jQueryを書ける人口自体は増えているだろうが、労働市場からは撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。
私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。
jQueryで入社するのは、昔からjQueryを使っている高齢のエンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。
そのため、需要と供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。
リプレイスはハッキリ言って難しい。モダンなフロントエンドを学習するだけでは足りなくて、それを使いこなせた上でしかもjQueryを使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。
時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。
jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。
何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。
jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合、既存の従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。（もちろん、「jQueryしかなかったサービスをモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある）
ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ？」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体は価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態でリプレイスしようとするのは、生活困窮世帯にリボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。
jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。
jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代で通用しにくいものになっていく。
bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンなインフラエンジニア（もしくはモダンなインフラ知識のあるエンジニア）がいないかもしれない。SREという概念がないかもしれない。
世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。
すべては憶測なので、実際は違うかもしれない。
さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体はメンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。
問題は、jQueryというライブラリを使ってきた時代からアーキテクチャが前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryのバージョンに反比例する。
jQueryを使っているアプリケーションには、jQueryが担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベント、SPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLにベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数、無視される変数のスコープ、サポートが終わったライブラリ、ドキュメントを見つけるのすら困難なよくわからないライブラリ、高齢者しか知らない伝説の機能・伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。
そのため、一定の基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。
そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。
そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。
（そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ）
jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか？」という部分が気になるところだと思う。
そこで、後編では「どうやってjQueryを全廃すればいいのか？」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。
お楽しみに！
そこんとこ詳しく。メタップスとか？
Waf なんて書くな！ WAF とかけ！
うっせーな。クラウドベンダーの独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。
まぁ、それは認める。でもさ、select や create とかのDML/DDL は CRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータにアクセスできなくなるかもよ？
そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ？一方データベースや OS の方は、ここ三十年ぐらい Unix と RDB が鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者はバリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤの根本技術の改善であって、私はそこにプロフェッショナル性を見出しますがね。
わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++ でサーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンスを必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか？いい加減にしろ。
そうだね～。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態の我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの？時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニアを採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。
誰が Next で SSR なんてするか！あれは SEO が必要な場合に限る。そもそも SSR なんて危険だからまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザとクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラにインデックスされるページで SPA をやろうとするやつはセンスないで。
すいませんでした。本当にすいません。
ん？ AWS SQS だとパフォーマンスに問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん？ログ収集は GKE みたいに ログに出したら Fluentd で収集してくれる時代になんでグチグチ言われないといけないの？
ハア？インメモリのデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。
これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。
いや、J1ビザをとってアメリカに留学したことあるよ。あと、「世界でもっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん。馬鹿にしてるのか？
なんで百合豚が嫌いなのかも書き連ねたいわ
なお、ビアンを自称する腐女子とレイヤーとV系バンギャについては闇が深過ぎで精神的にくるのでノータッチにしておきます
▼ 腐女子(BL愛好家・性別女)イメージを悪くしている原因ランキング
第5位：SPA！とかが喜びそうな男が好き過ぎるメンヘラの存在
- 金銭的に破綻し、キャバ堕ち＞風俗堕ち＞パニック障害＞実家へ強制送還、あるいは恋愛感情等が無い男と謎の共同生活を送る。
それでも、バンギャ、ジャニヲタ、2.5次元、ホスト狂い、出会いアプリ厨かつセフレとSEX、なによりBLはやめない。
第3位：ミサンドリストでホモフォビアでミソジニストで女性の権利についてネットで語りたい既婚腐女子と婚活腐女子の存在
- 矛盾王。いわゆるアレな人ですね。ネットで真実に目覚めちゃったりデマに躍るタイプです。自称保守だろうが自称リベラルだろうが困ったちゃん。
ただ、この世のすべての人に等しく発言権はあります。権利が守られている様子が確認できて良かったですね。
- いわく、女は弱く様々な手段で男に縋って生きるほかないとのこと。
