タグ

フレームワークに関するhachir0のブックマーク (7)

  • ReactとAngular、使うならどっち? JavaScriptギークが6つの視点で徹底比較 - エンジニアHub|Webエンジニアのキャリアを考える!

    ReactAngular、どちらを選ぶべきか? 使用するJavaScriptフレームワークを選ぶ際、この2つはよく比較対象に挙がります。しかし、両者の特徴をよく理解していなければ、選定は困難でしょう。 今回は、両フレームワークが具体的にどんな強みを持っているのかを、Reactの専門家 小林徹さんとAngularの専門家 稲富駿さんに解説してもらいました。両フレームワークの設計思想から使用において考慮すべき点、今後実装される予定の機能まで、利用者が気になるポイントを網羅しています。 JavaScriptギークである2人のノウハウ、ぜひ選定の参考にしてください!

    ReactとAngular、使うならどっち? JavaScriptギークが6つの視点で徹底比較 - エンジニアHub|Webエンジニアのキャリアを考える!
  • Vueを昔触った後Reactをどっぷり触ってもう一回Vueを触ってReactに戻って得た感想

    最近ReactVueをどっちも触る機会があったり、「ReactVueどう選定するの?」という問いを投げられ、スッと答えられなかったな、と後悔があったりしていたので、Vueを触って得られた感想をまとめてみる。 結論としてなにか新しいことを発見したというものではなく、世間で言われている事を自分なりに再構築しただけの結論になったと思う。 TL; DRVueからは全体的に優しさ(Gentleさ)を感じる事が多く、良い点だと感じた大規模になるときReactの堅牢さは魅力的。Vueが大きくなった時に支えられ設計が出来るかは個人的には懐疑的。「こうだったらVue、こうだったらReact」みたいな分岐点があるというわけではないので、最終的には好みになってくると思う。ぞうさんが好きかきりんさんが好きか。これまでのフレームワーク遍歴今回の話をするにあたって、僕と各フレームワークの付き合いをまとめておくと、

  • JSフレームワーク選定の勘所

    大づかみなお話です 結論: 課題を知ったらなんでもいいから手を出してみよう! (細かいところは犠牲にしてます。React でもステートフルコンポーネントつくれるよねとか)

    JSフレームワーク選定の勘所
  • 技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

    ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ? 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから? o 信用できないテストデータ も負債 o 現

    技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
  • 私がMVCフレームワークをもはや使わない理由

    数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

    私がMVCフレームワークをもはや使わない理由
  • PlayFrameworkをただの静的型付けMVCだと思って本番稼動させると死ぬ - サナギわさわさ.json

    (3/15 : タイトル修正しました。wは小文字ですね、すみません・・・) PlayFrameworkが流行り始めてから割と経ちますので、そろそろ正式採用しようと考える方も多いのではないかと思います。 強力な静的型付けで守られたPlayは、ミッションクリティカルなシステムや数万行を超える大規模システムの構築に特に向いているような気がします。 また、Servletを使っていないのに加えてMVC構造がベースなので、今までRailsなどで開発をしていた人でもシームレスに移行できると思います。 しかし、忘れてはならないのがPlayのアーキテクチャが全ての処理が非同期で行われることを前提としているという事です。 ここを忘れてPlayをただの強力な静的型付けで守られたMVCフレームワークとだけ考えて開発を進めてしまうと、番環境で稼動させた時にパフォーマンスが上がらずに困ることになるかもしれません。今

    PlayFrameworkをただの静的型付けMVCだと思って本番稼動させると死ぬ - サナギわさわさ.json
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。

    dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
  • 1