WebAssembly 開発環境構築の本
この文章は Rust を用いた WebAssembly の開発環境を構築する手法を紹介するために作成されました. ハッシュタグ: #WASMの本紹介記事: WebAssembly 開発環境構築の本を公開しました - mizdra's blog# 本書の目的Rust を用いた WebAssembly の開発環境を構築する手法を知ることモジュールバンドラと連携する方法を知ることTypeScript と連携する方法を知ることWebAssembly を利用していて陥りやすい罠を知ることWebAssembly に関する情報を調べる方法を身につけること# 本書でやらないことWebAssembly/Rust/JavaScript の文法や機能の解説が目的ではない Rust からコンパイルして生成された WebAssembly を JavaScript から利用する方法を解説する文法や機能については, W
Node.js製CLIフレームワークoclifを試す - dackdive's blog
はじめに Heroku が oclif という CLI フレームワークをオープンソースとして公開したという記事を読みました。 Heroku CLI や Salesforce DX のベースにもなっているらしい。 どんなもんか触ってみます。 （oclif は (The) Open CLI Framework の略のようです。読み方がわからない。。。） oclif の特徴 手を動かす前に、どういった特徴があるのか公式ドキュメントに目を通してみます。 Features · oclif: The Open CLI Framework Super Speed コマンド実行時のオーバーヘッド（？）がほとんどなく、また依存パッケージもほとんどない 実行されるコマンドだけ require されるので、たくさんのコマンドからなる巨大 CLI でも単一コマンドの CLI と速度が変わらない CLI Gener
がんばらないTypeScriptのはじめ方 - 角待ちは対空
追記 2019/04/16に以下の記事が公開されました。 employment.en-japan.com gfxさんによる記事です。この記事自体2017年の若干古い記事なので、新しく読む方は最新版である上記の記事を読んだほうがいいでしょう。 このエントリは2017/07/12に行われたHatena Engineer Seminar #8 @ Tokyoの発表内容をブログ向けに書き直したものです。 事前の通知では「CoffeeScript脱出にみるTypeScript2.4時代のベストプラクティス」がタイトルだったのですが、主題を変えたためタイトルも「がんばらないTypeScriptの始め方」に変更させていただきました。CoffeeScript脱出の話は一応出てきます。 社内のTypeScript事情 その後のTypeScript 現在の様子 TypeScriptのがんばらないはじめ方
FlowとTypeScriptをESDocで使用する - maru source
ESDoc v1.0をリリースするために、機能をプラグイン化してコアと周辺機能を分離しています。 https://github.com/esdoc/esdoc-plugins この作業は大体終わり、現在はよりadvancedなプラグインのPoCを作成しています。 そこで、今回はFlowとTypeScriptをESDocで扱うための2つのプラグインを紹介します。 ESDoc v1.0自体ついては正式リリース後に紹介する予定です。 FlowをESDocで使用する esdoc-flow-type-plugin Flowで書かれたコードをESDocで使用可能にするプラグインです。 このプラグインはPoCなので、実現可能性を確かめるためだけの最小実装となっています。 ドキュメントコメントに型情報が書かれていない場合、Flowの型アノテーションから型を取得する 型推論による型情報の取得は未実装 このプ
なぜTypeScript推しなのか - Islands in the byte stream
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
Refactoring 30000 lines of JS with types - Reaktor
30000 lines of client-side JavaScript. No tests. Two difficult TV deployment platforms with poor tooling. Strong dependencies on poorly documented
大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deck
All slide content and descriptions are owned by their creators.
ES5 + Facebook JSXで書かれたJavaScriptコードベースをTypeScriptに移行させる - CARTA TECH BLOG
皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 今回は、表題の通り、実際にプロダクトとして動いている既存のコードベースを、ES5ベースからTypeScriptに段階的に移行させた話について書こうと思います。 移行前のコードベース及び直面した課題 今年の1月頃から、アプリケーションのクライアント側の一部を、以下の構成で実際に開発しています。 言語 ECMAScript 5 主要な依存ライブラリ UI開発にReactおよびFacebook JSX syntax 統合イベントシステムとしてのRxJS テストコードのアサーションにpower-assert ビルドチェーン モジュール連結にbrowserify 環境変数に基づくビルドフラグ用途でenvify コードの解析とLintにESLint 未使用変数や未定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - microsoft/vscode: Visual Studio Code