You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
れこです。この記事はNode.js Advent Calendar 2020の 12 日目の記事です。今回は年の瀬ということで酒の肴になりそうな記事を書きたいと思います。 本記事では 2020 年に GitHub のトレンドに上がったリポジトリをいくつかの切り口で集計して、独断と偏見で感想を付け加えます。 この記事を酒の肴に 2020 年の JS/TS について懐かしんでもらえたら幸いです。 集計方法 GitHub のトレンドは過去の履歴が残っていないので非公式に集計されたデータを利用しています。 集計期間は 2020/01/01 から 2020/12/05 までの 341 日間 対象言語はJavaScriptとTypeScriptのみ トレンドの過去データのソースはxiaobaiha/github-trending-historyを参照 日ごとにまとめた markdown になっており、
Storybook is the industry standard UI component workshop. It organizes components and their states to structure UI development, testing, and documentation. It's used by teams at Twitter, Slack, Airbnb, Shopify, Stripe, and Microsoft. As Storybook grows in popularity, companies are building more components in it than ever before. Atomic components, full blown pages, and everything in between. Perfo
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS(Angular系の1.x系)の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
先日のPyCon JP 2018の野球の話にてVue.js(Nuxt.js)の話をした結果、技術評論社様のご厚意により、一冊頂戴いたしました. Vue.js入門 基礎から実践アプリケーション開発まで 作者: 川口和也,喜多啓介,野田陽平,手島拓也,片山真也出版社/メーカー: 技術評論社発売日: 2018/09/22メディア: 単行本(ソフトカバー)この商品を含むブログを見る 正に欲しかった類の本で大変助かりました、ホントありがとうございます! 結論から言うと、 Vue.js(またはNuxt.js)で開発するなら一冊持っておけ!(ただし他のFWにもいい本がある) っていうくらい素晴らしい書籍でした、自信を持ってオススメができるレベルです. このエントリーでは、 「 Vue.js入門 基礎から実践アプリケーション開発まで」の簡単な感想 私がフロントエンド開発するまでにやってきたJavaScri
ng-kyoto Angular Meetup #9 での発表資料です。 https://ng-kyoto.connpass.com/event/113358/
はじめに はじめまして。 null です。最近の悩みは 2 歳半の息子が言うことを聞いてくださらないことです。 2 歳児もそうなのですが、 ソフトウェアフレームワークに振り回されてるって感じること、稀によくありませんか?? ある程度の学習コストがかかるのは当然としても、冗長な書き方を要求されるわ、かゆいところに手が届かないわ、実データ投入したらパフォーマンス問題だらけだわ、バージョンアップしたら動かなくなるわで、あぁ私いま振り回されてるなぁ、みたいな。 「じゃあ使わなければいい」「じゃあ自分で作ればいい」という話ではなく、「必要以上には依存しない方が無難だよね」「フレームワークの外へ切り出せるところは切り出してみよう」という話をします。 続きを 3 行で 状態更新ロジックってフレームワーク非依存にできそうだよね でもフレームワークによって状態をイミュータブル(状態更新=状態オブジェクト生成
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: When (and when not) to use Redux – LogRocket 原文公開日: 2018/01/20 著者: Christian Nwamba サイト: LogRocket 2018/03/13: 初版公開 2021/06/03: 更新 Reduxが登場するまで、複雑なタスクを組むときのステート管理は相当つらい作業でした。Reduxは、Fluxというアプリケーションデザインパターンにヒントを得て、JavaScriptアプリでステートを管理するために設計されました。ReduxはReactと併用されることが多いのですが、ReduxはjQueryやAngular、Vueといった別のフレームワークとも併用できます。 Reduxのサイズは非常に小さい(依存関係も含めてわずか2KB)にもかかわらず、アプリの各コンポーネ
はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか? たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在の
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何? まず基礎ということで、Flux i
問題点はIsomorphic実装難易度です。では、アメブロのIsomorphicの実装方法と実装する際にあった問題及びその解決策をお伝えします。 ちなみに、Michael Jackson氏はIsomorphic JavaScript ではなく、 Universal JavaScript と呼ぶべきだと主張しています。私たちはIsomorphic JavaScriptという名前で使うのに慣れたので、ここでは*Isomorphic JavaScriptと記述します。 AmebloのIsomorphic 技術選定 先に結論をあげます:React + Redux 技術選定の基準は下記となります。 安定さ。基本的にプロダクト環境で使える正式版があること。 アクティブな開発。 よいコミュニティ。技術の周りに大きいコミュニティが育っていること。 実績がある。 まずView層のライブラリの選定です。このプ
乱立するフレームワーク/ライブラリーをどう選ぶか? あるスタートアップ企業がフロントエンド開発フレームワークを選択するプロセスをケーススタディとして紹介。 シンガポールを拠点とした福利厚生サービスを提供するスタートアップ「CXAグループ」(日本版編注:CNETの記事を参照)のコアWebプラットホームを評価するにあたって、時代遅れとなった既存のアーキテクチャをお払い箱にすることにし、イチからフロントエンドを再構築することにしました。課題は、CXAグループが進出しているアジアにある12の対象国のどこでも機能するWebアプリケーションの開発です。 プロジェクトの納期がタイトであることを考慮しつつ、さまざまなフロントエンドJavaScriptフレームワークを評価しました。企業の大型プロジェクトでこれほどの改変をする機会はめったにないため、評価プロセスは可能な限り詳細に詰めました。 フレームワークを
Qwintryチームは最近、既存のすべてのプロジェクトのフロントエンドをVue.jsに移行しはじめました。新しいプロジェクトでもVue.jsを使います。 レガシーなDrupalのシステム(qwintry.com) ゼロから新しく書きなおすqwintry.comのブランチ Yii2で動くb2bシステム(logistics.qwintry.com) その他、比較的小さめのプロジェクト(ほとんどは、PHPとNode.jsでバックエンドを構築しているもの) プロジェクトの規模についていうと、 Qwintry は世界中で約50万人の顧客が使っています。アメリカとドイツに倉庫を持っていて、アメリカ国内 最大の郵送先 のひとつで、東欧や中東への出荷に注力しています。Qwintryは、アメリカのオンラインストアでグッズを購入する人たちのためのツールです。私たちの倉庫に届いた荷物をコントロールパネルで管理で
そもそものところで色々ツッコミたい気持ちはみなさんあるでしょうが、せっかく当選したので観戦に行ってきました。 React陣営は @koba04 & @yosuke_furukawa Angular陣営は @laco0416 & @armorik83 モデレータは @Shumpei メモは雑なので、漏れとか齟齬とかあるかもですよ。 トークバトル React / Angular 2の概要 スター数とかバージョンとか コードがだいたいこんな感じとか 開発言語 こば: だいたいBabel、TypeScriptでもやれる 会長: だいたいBabel使ってると幸せになれる らこ: JavaScript or TypeScript or Dart らこ: まあTypeScriptですよね らこ: Dartはリポジトリが分かれました はち: ReactやるからAngularやるからで開発言語を選ぶのはナン
はじめまして、ほそだと申します。昨年秋まで個人事業主の立場でドワンゴでお仕事させていただいておりましたが、いろいろ経緯がありまして中の人になりました。ドワンゴ歴はそこそこ長い新入りです。よろしくお願いいたします。 さて、今回はデザイナー(HTML/CSS/JSは扱えるいわゆる「Webデザイナー」)として1年間ほどReactを使ってみたので、そのメリットを書いてみようかと思います。 Reactとの出会い ReactとはFacebook製のJSライブラリです。 https://facebook.github.io/react/ WebアプリケーションのView部分を実装します。2014年の暮れにエンジニアの方々が魂を震わせているのを見て存在を知りました。2015年はReact元年な感じでしたよね。 僕自身、以前から比較的JSを書くタイプのデザイナーではありましたが、正直なところ自分が関わってき
react-router@1.0.0-rc3を使っていると、onEnterでStoreを更新して、終わってからRouteへ移動したい。Angularで言うui-routerのresolveが欲しいと思っていました。 EventEmitterを継承して.emitをオーバーライドすれば対応可能です。軽くテストを通したライブラリも公開しています。1 具体的には下記のように実装します。 // Dependencies import {EventEmitter} from 'events' // Public class AsyncEmitter extends EventEmitter{ emit(event,...args){ let promises= [] this.listeners(event).forEach(listener=>{ promises.push(listener(...
コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること(切っても良さそうなんだけど...) 既製品・スクラッチは問わないが極端なリスクは踏めない(納期がシビア) あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く