Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Vue.jsとは Vue.js(ビュージェイエス)は、インタラクティブなUIを構築するためのJavaScriptライブラリです。Webサイト内のウィジェットや管理画面のダッシュボードといったビュー(view)層に特化しています。設計の特徴としてMVVMパターンに影響を受けています。 Vue.jsは2013年にEvan You氏の個人プロジェクトとして開始、2014年2月にバージョン0.8が正式に公開されます。その後いくつかのリリースを経て、2015年4月にLaravelへの標準搭載決定を機に一気に知名度があがりました。2015年10月に1.0が、2016年10月1日(日本時間)に2.0がリリースされ現在に至ります。 Vue.jsの主な特徴には以下のものがあります。これらによって短期間で実用的なアプリケーションを作成できるため人気を集めています。 シンプルなAPIやHTMLベースの平易なテン
Vue.js + Vuex = Magic コンポーネント指向とFlux architectureで始めるモダンフロントエンド こんにちは、フロントエンドエンジニアの蔀です。 ここ数年のフロントエンド開発の潮流の変化は急激で、雨後の筍のように色々なフレームワークが出てきていますね。 8月末には、Mediumでこんな記事が人気になりました。 The State Of JavaScript: Front-End Frameworks と銘打たれたこの記事は、React/Angular/Angular2/Ember/Vue/Backbone といった、近年流行しているJavaScriptフレームワークに関する興味、満足度、知名度などを調査して比較してくれています。 注目していただきたいのが、「Satisfaction(使ってみて満足したかどうか)」の項目です。 近年流行しているReact.jsと
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
はじめに 導入 textlintrcを設置 最初のつまずき prh を使ってみる | 2度目のつまずき 追記: 絶対パスにも対応して頂きました prh を使ってみる(2) | 辞書を選ぶ 結果をテキストファイルに書き出す 追記: [39m[32m などを消す方法 コードを書く tx.sh textlint_pretty_error_tidy.pl Vimから使えるようにする 展望とまとめ はじめに textlintについては少し前から時々名前を聞くなと思っていましたが、自分に関わりがありそうなものとして意識したきっかけは、@t_wada さんによる以下のツイートだったと思います。 とある技術文章のレビューをする際に、細かな言い回しの修正を逐一指摘する代わりに textlint を入れてもらったら、文章がみるみる良くなってきているのをリアルタイムに見ている。 textlint は偉大だ。—
この記事はWebpack — The Confusing Partsを、筆者の許諾を得て意訳しています。 何か誤りがありましたら、ご指摘いただけると幸いです。 (以下、訳) ReactとReduxで作られたアプリケーションにとって、Webpackは最先端を行くモジュールバンドラです。Angluar2やその他のフレームワークを使っている人々は、たいへんWebpackのお世話になっていることでしょう。 私が初めてWebpackの設定ファイルを見た時、それはさながら宇宙人のようで非常にわかりづらく見えました。しばらく試しているうちに、今では次のように考えるようになりました。Webpackは単に独特のシンタックスと新しい哲学を持っており、それがとっつきにくさの原因になっているのだと。偶発的とはいえ、これらの哲学は、Webpackの人気を押し上げた原因の1つでもあります。 Webpackのとっつきに
この記事は2016年に書かれた古い記事です。当時はまだTypeScript2.0も出ていないころで今とは状況がかなり異なっています。参考にする場合注意してください。 はじめに TypeScriptの型システム Declaration space Open-ended ここまでの確認 型定義ファイルを読み書きできるようになるために declare キーワード 既存のオブジェクトの型定義を拡張する グローバルなオブジェクトに対する宣言 module Export Assignments Relative or Non-relative module imports ES2015形式 実際の定義ファイル 既存の定義ファイルを拡張する declare global { } について Typings について おわりに インターン募集中 はじめに こんにちはアプリケーションエンジニアの id:t_k
JavaScript Plugin ArchitectureというJavaScriptのプラグイン設計についての電子書籍を書きました。 この書籍はJavaScriptのライブラリやツールにおけるプラグインアーキテクチャについて見ていく事を目的としたものです。 以下の形式で読むことができます。 Web版 PDF形式 ePub形式 Mobi形式 GitHub上にソースコードも公開されているでので直接Markdownファイルを読むこともできます。 MarkdownよりはWeb版の方が見やすいのでそちらをオススメします。 Twitterのハッシュタグは#js_plugin_book 更新情報はRSSやリリースノートから見ることができます。 v1.0.0 最初に書くと決めたプラグインアーキテクチャが揃ったので1.0.0としてリリースしました。 JavaScript Promiseの本の時と同じく、継
The document discusses Vue.js 2.0, including its features and improvements such as enhanced rendering speed, separated compiler and runtime, and server-side rendering. It also covers the integration of Vue Router for single-page applications and Vuex for state management, highlighting their functionalities, benefits, and examples. Additionally, it emphasizes community involvement and resources for
textlintはMarkdownなどテキスト向けのLintツールで、テキスト版ESLintみたいな感じのツールです。 JavaScriptでルールを書けるテキスト/Markdownの校正ツール textlint を作った | Web Scratch 最近azu/JavaScript-Plugin-Architectureという小さな書籍を書いていて、色々簡単に使えるような仕組みを追加しています。 この記事では簡単なtextlintの導入方法について紹介します。 公式サイトには一部ルールを含むオンラインデモが公開されています。 textlint · The pluggable linting tool for text and markdown ドットインストールにてNode.jsのインストール、textlintの利用方法、エディタとの連携などのチュートリアルが公開されています。Node.
F# |> BABELThe compiler that emits JavaScript you can be proud of! Fable is an F# to JavaScript compiler powered by Babel, designed to produce readable and standard code. Try it right now in your browser! Fable brings all the power of F# to the JavaScript ecosystem. Enjoy advanced language features like static typing with type inference, exhaustive pattern matching, immutability by default, struct
Published 14 Apr, 2016 under Announcements Welcoming JSCS To ESLint We are happy to announce that, effectively immediately, the JSCS team is now part of the ESLint team. We would like to invite everyone to welcome Marat Dulin, Oleg Gaidarenko, Mike Sherov, Alexej Yaroshevich, and Henry Zhu, and we're looking forward to working with them all. ESLint and JSCS started out at roughly the same time, ju
https://www.npmjs.com/package/what-do-i-depend-on github.com 先日のleft-pad騒動で、自分のプロジェクトのnode_modulesを慌ててチェックした。 普段依存の依存とかまったく意識してないけど、いざ見なおしてみるとその数の多さにビックリする。 全ての依存を把握するのは正直無理だけど、ざっと見てみるだけでも発見がある。 意外とscoped packageが使われてたり。めちゃくちゃミニマルなパッケージが人気だったり。 babel関係のパッケージが多すぎて目眩がしたり。 というわけで、自分のプロジェクトの依存パッケージを再帰的に調べて、依存度合いをチェックするツールを作った。 node_modules/ 内の package.json を再帰的に調べて、パッケージが登場した回数を表示する。 使い方 インストール npm i
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。 毎回使う フレームワーク:Vue.js 消耗、などの意見が散見されたが、べつに今でも便利に使えている。 browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き データフローは特に考えない。状態がそこにあるので書き換えれば良い。 あまり頭を使わなくていいのが助かる Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。 ビルドシステム: browserify / watchify substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx
例のleftpad, GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装なので、こんな小さい関数のために、信頼できない人のコードを、実装を見るでも無く、依存性追加してたってことで、— INADA Naoki (@methane) March 24, 2016 ここから始まる一連の、モジュールの依存性に関する議論はなかなか興味深いが、自分的に気になったのは以下の一節 GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装 ソースを見てみようか。 left-pad/index.js at 0e04eb4da3a99003c01392a55fa2fdb99db17641 · azer/left-pad · GitHub なるほど一見するとクソコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く