改めて見直すGoの特徴
以前にまとめた内容に続き、 極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるよう
Go 1.16のembedとchiとSingle Page Application | フューチャー技術ブログ
シングルページアプリケーションは、1つのHTMLファイルであらゆるページを表現します。history APIを使ってそのようなページが実際にあるかのように振る舞います。 一方で、画面がリロードされたとき、メールでSNSでシェアされたときにその該当ページをきちんと再現するためには、サーバー側でハンドリングを行う必要があります。具体的には、存在しないページがリクエストされたら、アプリケーションのルートとなるHTMLファイルの内容をそのURLから配信するというものです。 https://angular.jp/guide/deployment#server-configuration それにより、どのURLでもJavaScriptが動作し、そのURLで表示すべきコンテンツが表示されます。もし想定していないパスの場合は、ウェブサーバーではなく、JavaScriptがエラーを出します。 Goでウェブサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
