アカウント名:
パスワード:
あたらしい環境はBlazorみたいなのしか要らないでしょ
WebAssemblyが普及するとでも思ってるのか
引き合いも着実に増えてるぜ。JavaScriptより数倍速いし、クライアントアプリのWEB化が、JavaScriptとか使うより数倍工数減らせるのが大きい。
とりあえずって程度のノリで、WASMがどういう物なのかを調べながらでも 2、3日もあればC/C++はもとより、.NET系とかでもデスクトップで動いてるクライアントアプリが、どの程度のパフォーマンス出せるのか試せるしな。GUIと不可分な実装してるような奴だと分離が大変かもしれんけど、いまどきの普通の設計してたら気にするほどの手間はかからん。製品レベルの作り込みが大変なのは、今と変わらんけど、ロジック部分のコードをJavaScriptで書き換えるどころか、一切手を加えずに、そのまま動くってのは大きいよ。
メモリ4GBの壁が、けっこう痛いけど。
WebAssemblyって普通のWebサイトで使い所ある？例えばスラドみたいなの。
コメント入力のプレビュー表示とか、閾値による表示内容の絞り込みとか、JavaScriptで出来る/JavaScriptで何か入れたいっていう部分は、全てWebAssemblyが使える箇所だよ。どっちでやるのが楽か、速度が必要か？って話になるけど、コード量が増える/既存のコードがあるって状態だと数倍単位でWebAssemblyが楽。速度が必要ならWebAssembly一択。
まぁ、当面の一番大きい用途は、パッケージやダウンロード販売してるようなソフトをSaaS化したいときにUI以外はWEB用に作り直す必要がなくなるってことだろうね。標準的なUIなら、既存のものがそのまま使えたりするので動かすだけなら1日もかからん。新規開発の案件でもWEB提供用とデスクトップアプリ用で区別する必要がないところも大きい。
既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので、ほとんどは開発しやすさに優先度が振られると思う。WebAssemblyというテクノロジがあるからそれを活用したサービスが設計され、利用されるというのは分かる。
気になるのは、今Web開発でJavaScriptが利用されている領域が、WebAssemblyに置き換わると何かメリットがあるのか、というところかな。それこそコメントをプレビューするだけの話でもWebAssemblyで作る方が開発体験に貢献するのかとか。まあ齧ってみるしかないか。
JavascriptやtypescriptよりもC#のほうが保守性高いと思うから、そういう面でもいいんじゃないかな。Blazorなら既存のjavascriptを使うことも一応できるし。
> 既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
もちろん、それもある。デスクトップアプリをSaaS展開したくて、サーバーサイドとフロントエンドに分離するとかで、サーバーサイドの言語が変わらない場合でも、そもそも分離しないでいいってことになるので WebAssemblyによるSaaSは手軽に手が出せる。
> 速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので
試してみると、なんとなくわかると思う。重いこ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
WebAssembly前提の環境が出てくれば (スコア:0)
あたらしい環境はBlazorみたいなのしか要らないでしょ
Re: (スコア:0)
WebAssemblyが普及するとでも思ってるのか
Re: (スコア:1)
引き合いも着実に増えてるぜ。JavaScriptより数倍速いし、クライアントアプリのWEB化が、JavaScriptとか使うより数倍工数減らせるのが大きい。
とりあえずって程度のノリで、WASMがどういう物なのかを調べながらでも 2、3日もあればC/C++はもとより、.NET系とかでもデスクトップで動いてるクライアントアプリが、どの程度のパフォーマンス出せるのか試せるしな。
GUIと不可分な実装してるような奴だと分離が大変かもしれんけど、いまどきの普通の設計してたら気にするほどの手間はかからん。
製品レベルの作り込みが大変なのは、今と変わらんけど、ロジック部分のコードをJavaScriptで書き換えるどころか、一切手を加えずに、そのまま動くってのは大きいよ。
メモリ4GBの壁が、けっこう痛いけど。
Re: (スコア:0)
WebAssemblyって普通のWebサイトで使い所ある？例えばスラドみたいなの。
Re:WebAssembly前提の環境が出てくれば (スコア:0)
コメント入力のプレビュー表示とか、閾値による表示内容の絞り込みとか、JavaScriptで出来る/JavaScriptで何か入れたいっていう部分は、全てWebAssemblyが使える箇所だよ。
どっちでやるのが楽か、速度が必要か？って話になるけど、コード量が増える/既存のコードがあるって状態だと数倍単位でWebAssemblyが楽。速度が必要ならWebAssembly一択。
まぁ、当面の一番大きい用途は、パッケージやダウンロード販売してるようなソフトをSaaS化したいときにUI以外はWEB用に作り直す必要がなくなるってことだろうね。標準的なUIなら、既存のものがそのまま使えたりするので動かすだけなら1日もかからん。
新規開発の案件でもWEB提供用とデスクトップアプリ用で区別する必要がないところも大きい。
Re: (スコア:0)
既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので、
ほとんどは開発しやすさに優先度が振られると思う。
WebAssemblyというテクノロジがあるからそれを活用したサービスが設計され、利用されるというのは分かる。
気になるのは、今Web開発でJavaScriptが利用されている領域が、WebAssemblyに置き換わると何かメリットがあるのか、というところかな。
それこそコメントをプレビューするだけの話でもWebAssemblyで作る方が開発体験に貢献するのかとか。まあ齧ってみるしかないか。
Re: (スコア:0)
JavascriptやtypescriptよりもC#のほうが保守性高いと思うから、
そういう面でもいいんじゃないかな。
Blazorなら既存のjavascriptを使うことも一応できるし。
Re: (スコア:0)
> 既存のコードがあるってのは、つまりJavaScriptで書かれていないものをJavaScriptに移植するよりは全然ラクという意味かね。
もちろん、それもある。
デスクトップアプリをSaaS展開したくて、サーバーサイドとフロントエンドに分離するとかで、サーバーサイドの言語が変わらない場合でも、そもそも分離しないでいいってことになるので WebAssemblyによるSaaSは手軽に手が出せる。
> 速度が必要ならというのは勿論同意するけど、Web上でクライアントPCにがっつりパワーを要求するケースはそう多くは無いので
試してみると、なんとなくわかると思う。
重いこ