Open SourceTypeScript AI AgentFrameworkEscape no-code limits and scratch-built overhead. Build, customize, and orchestrate AI agents with full control, speed, and a great DevEx.

「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」という本を書きました。 「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」 どんな本? 簡単な型チェッカを自作してみることで、型システムの仕組みを概観する本です。 型チェックする対象の言語はTypeScript(のサブセット言語)、型チェッカを実装するための言語もTypeScriptです。 たとえば、次のようなプログラムが型チェックできるようになります。 const add = (x: number, y: number) => { return x + y; } const a = add(1, 2); const b = a + true; 型チェッカは、それぞれの変数がどういう型を持つか管理しつつ、プログラムの各パートがどういう型になるかを判定していきます。
Ubieでは、Ionic(Capacitor)でガワアプリ的に実装されていたモバイルアプリ(Android/iOS)を、2024年初頭にReact Native (with Expo)にリプレイスしました。 「なぜ今更React Nativeを?」という方もいらっしゃると思います。本記事では、UbieにとってReact Nativeがフィットした理由や検討した点を紹介します。Ubieの技術資産、人材、事業展望などのコンテキストを前提とするものであり、一般的な技術の良し悪しを論じる記事ではないことに注意してください。 Full-Stack TypeScript Ubieのプロダクト開発チームでは、フロントエンドエンジニア/バックエンドエンジニアといった技術領域での担当分けは原則せず、プロダクト開発エンジニアとして企画から開発、分析などに一貫して携わっています。 このように仕事を広く持つ前提で
TypeScriptではtype alias syntax(型エイリアス構文)とinterface declaration(インターフェース宣言)を使って型を定義できます。 おおよそ両者同じことができるので、どちらを使うか迷います。 両者の使い分けに関する記事は沢山あります。 これらの記事を読んで基本的にはtypeを使えば良いと思っていました。 ですが最近以下のことがあり、typeとinterfaceの使い分けがわからなくなってしまいました。 typeよりもinterfaceの方がコンパイルのパフォーマンスが良いという話を耳にした。 interfaceしか使えない特定の機能を知った。 そこでtypeとinterfaceの違いを学んで、どう使い分ければよいかを整理しました。 type, interfaceそれぞれのメリット typeのメリット interfaceで表現できないことが表現できる
WebアプリでURLシェアを実装する際に、URLにすべての情報を持たせてしまいたい場合があります。そのとき、情報をそのままクエリ文字列に渡してしまうとURLの文字数制限に引っかかってしまうかもしれません(厳密にはURLに上限はないようですが、現実はいつもブラウザ実装依存)。 そんなときURLセーフな文字列形式で圧縮してくれるライブラリがあります。lz-sringです。 変換の例 ライブラリで compressToEncodedURIComponent というAPIが提供されているのでこれを使用します。標準のencodeURIComponentでURLセーフな文字列に変換した場合とサイズ比較をしてみましょう。 import lzstring from "lz-string"; const rawData = "Lorem ipsum dolor sit amet, consectetur a
WebUIはデスクトップアプリを作るためのライブラリ。HTML, CSS, JavaScriptでフロントエンドを作り、バックエンドをC, C++, Python, Go, TypeScriptなどの言語で開発できる。システムにインストールされているWebブラウザで動作する https://webui.me/webui.me 2023年にhassandragaさんが公開し、V言語コミッタのttytmさんらも参加した 本体はCで開発されていて、Python, Go, TypeScriptにバイディングが提供されている 似た技術としてはElectronやTauri、Gluonなどが存在する laiso.hatenablog.com zenn.dev アーキテクチャについて ElectronやTauriと比較すると、WebUIのアーキテクチャはWebアプリをブラウザで開くだけなのでより単純かつ制
僕が開発しているWebフレームワークHonoは、同じJavaScriptのフレームワーク、Expressと比べられることが多いです。どちらもやれることはほぼ同じですが、HonoのアドバンテージはファーストクラスでTypeScriptをサポートしていることです。特に「RPC」機能は他のフレームワークにはなかった「TypeScriptの型でサーバーとクライアントの仕様を共有する」ことを可能にしています。今回はそのHonoのRPCについて紹介します。 どんなものか まず、どんなものかを箇条書きで共有します。 Web APIの仕様、特にインプット・アウトプットをサーバーとクライアント間で共有するためのもの OpenAPIやgRPCを使ってやりたかったことを叶えるかもしれない サーバーとクライアントをどちらもTypeScriptで書くことが大前提である 同種のものにtRPCがあるが、Honoの場合、
Denoが新フレームワーク「Fresh 1.0」リリース。Just-in-timeレンダリングやランタイムオーバヘッドゼロなどの特徴がもたらす優位性とは? JavaScriptやTypeScriptのサーバサイドランタイム「Deno」を開発するDeno Land Inc.は、Deno用のフルスタックフレームワーク「Fresh 1.0」のリリースを発表しました。 バージョン番号の1.0が示すように、安定版としてのリリースです。 Fresh is a new full stack web framework for Deno. It sends zero JavaScript to the client by default and has no build step. Today we are releasing the first stable version of Fresh.https
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
今年も GitHub のトレンドで 2021 年の JavaScript/TypeScript を振り返ります。去年の記事はこちらです。 — GitHub のトレンドで振り返る 2020 年の JavaScript | WEB EGG 集計方法 GitHub トレンドは過去の履歴を公式に提供していないため、非公式に集計されたデータを利用しています。 データソースはlarsbijl/trending_archiveを使用 去年はxiaobaiha/github-trending-historyを利用したが今年のデータは無かったので変更 日ごとにまとめた markdown になっており、remark で AST→ データ化しました 集計期間は 2021/01/01 から 2021/12/15 まで 対象言語はJavaScriptとTypeScriptのみ 集計後のデータはこちらのスプレッドシー
lightGallery A lightweight, modular, JavaScript image and video lightbox gallery plugin. Available for React.js, Vue.js, Angular, and TypeScript. View on GitHub
TypeScript でフロントエンドな皆さん、今日も型パズルしていますか? 型が好きなら Rust ですよね。ということで、いまいち使い所が思いつかない WebAssembly と Rust でなにか面白いことできないかな、と爆速(JS比2倍)の Markdown Editor を作ってみました(面倒な人は直接 GitHub みてください) この記事は iCARE Advent Calendar 2020 の 8日目の記事になります。昨日は アオキタカユキ さんの 【adobe XD】線型、円型のグラデーションを引く方法 という記事でした Webアプリケーションを作る まず、利用する側の Web アプリケーションを作成します どんな構成でもいいんですが、タイミング的にもちょうど良い Vue3 + TypeScript で環境を作りました $ npm install -g @vue/cli
Semgrepはr2cという会社/サービスが開発しているツールです。 Semgrepの特徴としてTree-sitterでコードをパースしたConcrete Syntax Tree(CST)の構文木をベースにして検索や置換ができます。 コードをCSTにパースした構文木に対して検索/置換することで、ただの文字列検索/置換に比べてミスマッチしない検索/置換ができます。 例えば、次のa.js、b.js、c.jsはそれぞれevalを使っていますが、スタイルは違いますが意味はほとんど同じです。 // a.js eval("const a = 1, b = 2; eval(a + b);"); // b.js eval('const a = 1, b = 2;\ eval(a + b);'); // c.js eval(`const a = 1, b = 2; eval(a + b);`); $ sem
lerna/yarn/npm workspacesとTypeScript Project Referencesの設定を同期するツール TypeScript Project Referencesは、tsconfig.json同士の依存関係を定義することで、効率的なビルドが可能になる仕組みです。 Project Referencesの仕組みを使うことで、monorepoなど一つのリポジトリ内で複数のTypeScriptで書かれたパッケージがある場合に効率的なインクリメンタルビルドなどができます。 また、VSCodeなどのコード補完に使われるTS-Serverなどのスキャンも効率的になります。 Migrating Large TypeScript Codebases To Project References — Developer Tooling Optimizing multi-packag
TypeScript + Preact + Material UI + material-table で作っている管理画面のビルドツールを Rollup から esbuild に変えたお話です。 2021/01/07 追記 esbuild に新しく CSS ローダーやプラグイン機構が実装されたので紹介記事を書きました! esbuild の機能が足りないならプラグインを自作すればいいじゃない https://www.kabuku.co.jp/developers/create-your-own-esbuild-plugin はじめに これまでの JavaScript ビルドツールと私 以前は私も定石通り「アプリには webpack、ライブラリには Rollup」をビルドに利用していましたが、近年はアプリのビルドにも Rollup を利用することが多くなり、 webpack を利用することはな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く