Inside Frontend #2 の発表資料です https://inside-frontend.com
![日経電子版を速くする / nikkei-inside-frontend - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/a1254c629058f5e1822ee901da84c7583d42e7de/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fe8ba758d54f6415d973d0f42e636aef0%2Fslide_0.jpg%3F9399499)
現場のES201x と未来のアーキテクチャ - インサイドフロントエンド2
新規立ち上げのチームを異動して、1年前に作った会社のフロントエンド環境(Vue.js + webpack(+Gulp))をベースに環境を作っていたのですが、 色々古かったので、新しくしました 今回作ったものはGitHubにあげてます https://github.com/kurosame/vuejs-boilerplate この中からやったことをいくつかピックアップして紹介したいと思います パッケージを最新にする npm install -g npm-check-updates npm-check-updates -u // package.jsonのパッケージを全て最新にして上書く npm update // package.jsonに記載してあるバージョンに更新する npm install 今回みたいにバージョンアップするパッケージが多い場合は、これでいいと思う 他のパッケージに依存し
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる!というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
※記事の内容があまりにも雑だったので大幅加筆修正しました。つっこみ下さった方ありがとうございますm( )m どうもせせりです:) この記事は「Railsしかやったことないけど、Android&iPhoneアプリでサイトの専用アプリをサクッと作りたい、push通知したい」という贅沢な人向けの記事です ※この記事で説明するのは「Xamarin.forms」です 前提 KotlinやSwiftで作るのが一番、と言うのは間違いないかと思います でも、Webに慣れきった我々としては使い慣れたHTMLやCSSで解決したいしそんなネイティブガリガリに作り込みたいわけではなく、Webにpush通知を添えた程度のものをサクッと作れればそれでいいのです ページ数だって20枚もない、そのくらいのアプリで良いのです 業務で作っている方からすれば「そんなしょぼいアプリ作る必要あるの?」と思うかもしれませんがpush
Webフロントエンドハイパフォーマンスチューニングを読んだ.最近フロントエンドでがんばるアプリケーションを作ってるので参考になった.ネットワークまわりからブラウザの細かい実装の話まで書かれていて良かった. link rel=prerenderで次のページをプリレンダリングできる 次のエピソードに飛ぶとか,コメントページからメインページに飛ぶとか,次に遷移するページが明確なときは有効そう あとからJSで足してもよい CSSのマッチ方法,div>div>span とか書くと右から左に順にマッチしていく なので入れ子をやめると速くなる.BEMでCSSを書くとネストせず書くので速い デベロッパツールでレンダリングの様子をこまごま見れる ペイントが発生した様子 レイヤの様子 ためしに,このブログのaboutページをプリレンダリングしておいたので,下のリンクから遷移するとすばやく遷移できるはず. <l
ここでは、フロントエンド開発の概要について説明していきます。 *元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
って海の向こうの人が言ってました。 私はjQueryさえあれば概ね生きていけるので全然知らないけど、 あなたは全部知ってるフロントエンドエンジニアなんだね。すごーい! 以下はFront-End Developer Handbook 2017の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール Dash 150以上のライブラリのAPIリファレンスを検索できる。有料、Mac専用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。 有料、Windows専用。 Zeal 200以上略 無料のオフラインドキュメント。 SEOツール Keyword Tool 検索ワードを入れると関連キーワードを教えてくれる。 Google Webmasters Search C
ギークハウス Advent Calendar 2016の12月22日の記事です。 他の方とは、全然違う雰囲気になってしまいましたが、読んでいただけると幸いです。 なぜVue.js?? 普段の仕事では、Ruby/Railsなので、フロントエンド周りは、jQueryにCoffeeScriptで片手間感覚... ↓ しかし最近のフロントエンド界隈は、良くも悪くも盛り上がっていて楽しそうだなあと思う日々。 ↓ いろいろ、ググって調べてみると、ES6、Babel、Reactふむふむ...🤔 ん?? Webpack? JSX?? Flux?? Redux?? 「落ち着け!とりあえず日本語でOK」状態。。正にこの記事で書かれている状態そのものでした。 ↓ Reactとかでイケてるフロントエンド開発をちょっと試したいと思っても、BabelやWebpackの設定など環境構築でつまづき、肝心のアプリケーショ
公開されるどこにも記録を残していないような気がするが、2016年の初めからとある事情により JavaScript のエラーをサーバに送りつけて監視サービスに送りつけてエラーの発生を知り、修正する、ということを地味にくり返していた。 そこに至る顛末と今後の分析の予定のお話。 背景これまで扱ってきたものはそこまで JS ヘビーでないものが多く、また自分で書くものはできるだけユニットテストが動くように書いていた and そもそも監視サービスが入っていなかったので、エラーのログをサーバに送るとか監視するとか、そこまで手をかけていなかった。 しかし今回の案件は初期の設計では考えてもみなかった量のカウボーイスタイル JS がコミットされしまい、要するに非常にイキのいいフレッシュなレガシーコードがてんこ盛りで動いている状態になってしまった。 (あーはい、全部ぼくがコードレビューしてリジェクトすれば防げた
色々あってシンプルなtypescriptの開発環境をつくろうとして消耗した話です 小規模なプロジェクトをシュって書けるシンプルな環境がほしい でもナウくなっててほしい そもそもナウいとは... 最近のフロントエンドの人は何を言ってるのか全然わからないし依存パッケージが多すぎて混乱する でもちょっとはナウくなっててほしい 試行錯誤した結果 npm scripts + browserify + tsify + watchify で構成することにきめた. 本体を1行も書かないまま日付が変わっていた. もうナウくなくていいから本体が書きたい 構成 とりあえずbuildすると色々なものがdistに送られる構成にした ├── dist (static-assets) │ ├── bundle.js │ ├── bundle.css │ └── index.html ├── src │ ├── ts │
プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く