Java低速GUI Swing 10
男は黙ってJEditorPane
サシャナゴンの方が好きだ >>451
本業の合間にやってたから今頃なったけど、Windowsでピンチ操作拾えないバグの回避実装に成功した~
JNAでWin32のローカルメッセージハンドラフックしてピンチイベント検出できた
VC++の構造体の内部資料が無くて
色々なソースから類推するのが大変だったけど勉強になった >>452
亀レスすまん
流行りのWebのvue.jsとかreactとかより
設計がシンプルだからデバッグしやすいなど実装が楽ってだけ
業務用はuiのカッコ良さより安早楽が大事でしょ?
あとビジネスロジックにおいてJavaは高機能ライブラリが豊富なのも有難い
MSの.NETほどにフレームワーク設計しくじってぐちゃぐちゃになってないし
逆に今どきのおしゃれインターフェースにしたいならjs系がいい そういやスレタイでswingを低速言うてるけど
JavaFXのほうが初期化しめちゃめちゃ時間かかってもっさりしてるんだけど…
そしてmacでは未だにスレッド競合解決してない
swnigよりオワコンな気がする スタンドアロンアプリ自体が絶滅しようとしているんだ…
クラウドが大規模障害起こして復旧目処立たなくなったとき
人々はjavaアプリの偉大さを噛みしめることであろう
swingは死なず、ただ去りゆくのみ JavaでGUIするぐらいならウインドウにHTMLでええやん… まあハードウェアアクセラレートあってもHTML/jsのUIがもっさりしてるのみんな慣れてきたしね GUI表現としてHTML/CSSは十分なんだけどロジックをJavaScriptで書くのはつらい ビジネスロジックは鯖側のnode.jsで書けるしスタンドアロン系も同じnode.jsで動くフレームワークあるよ
ただマルチスレッドじゃないから似非非同期による安定実装めんどくさい サーバー側のnode.jsだってJavaScriptじゃん
それに昔と違ってビジネスロジックはサーバーサイドが担当するって考え方も今は通用しない
SPAが流行しててクライント側で動かさなければならないロジック(JavaScript)が昔より増えてるのだ ビジネスロジックとUIロジック整理しないで実装してるから開発管理破綻してるのでは?
フロント/バックエンド部隊の連携、運用保守まで考慮した設計できないならSPAは採用すべきでないと思うけどなぁ
俺のvue.jsとlambdaの開発リーダー経験からの話だけど
next.jsあたりはもっと進歩してスッキリしてんのかと思ったが違うの? ビジネスロジックをサーバー側に閉じ込めようとすると
SPAではクライント/サーバー間の通信回数が増えてレスポンスが低下したりするのよ
だからクライントでビジネスロジックを動かすようになってきてる そうなのか、そんなファットになると
遅延読み込み使ってもロード&jsコンパイルのせいでキャッシュ前は凄く重そうだ
そんならアプレットやActiveX時代のほうがよほど合理的だよねw
4年くらい前は鯖と無駄な通信しないように同期対象データを複数のグループにまとめてパフォーマンスと操作性のバランス保ってたけど
いまだにフレームワークで鯖と自動差分同期も出ないんだ…
というわけで、アプレットはダメでもswingアプリ復活の方向でめでたしめでたしw Ruby on Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack
JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する
https://techblog.gmo-ap.jp/2022/07/05/rails-7-hotwire/
https://zenn.dev/shita1112/books/cat-hotwire-turbo/viewer/abstract SSRていうやつけ?
Rails嫌いではないがすっかりオワコンイメージだなあ
いやほんとにファットなアプリケーションをHTML/JSで実装しようというアプローチ自体が間違ってたんだなぁとしか思えない
そんならアプレットやバイナリ配信してキャッシュさせるアプローチに戻したほうがいい Rails 7 のHotwire, Elixir のPhoenix もLiveView で、
websocket によるリアルタイム通信に変わった。
これはHTTP2 で通信速度が速くなったから
ここ数年、SPA でReact に奪われたシェアを回復すべき戦略。
JSON を送って、ブラウザ側で組み立てなくても良い Webフロントエンドは成熟しないねー
次々と新しい技術が登場してきて大変
いま最新技術を選択しても数年後には「まだそんなの使ってるの?」と言われちゃう 日本の客も開発者も要件整理苦手だから泥縄で作るじゃない?
そういうやり方の場合SPAは実装ぐちゃぐちゃで使い勝手も悪くメンテも困難になる
レガシーなページ遷移あったほうが自然とトランザクション整理されるからお似合いと思うけど そういう意味ではswingとかスマホでスタンドアロンアプリ作るのも日本人向きじゃないと思う >>478
>レガシーなページ遷移
Ruby on Rails では、turbolinks を使って、pjax になる
ajaxとhistoryAPI(popState, pushState)を利用して画面遷移する。
js, cssの読み込みを初回時に行い、次回以降の読み込み処理を省略することで高速化する いまではPCのスペックが上がって、遅くもなんともない。 JAVA SWING のボタンはお洒落だからカワイイから
JAVA SWING はボタンはカワイイくてお洒落だ
swingアプリメンテしてて困るのは
最近は横4000ドット近くあるノートPCで
アイコンやフォントが小さすぎる問題
古いフレームワークだからそういうの想定したスケーリング機能がない
結局自分でcontainer内のフォントサイズを再帰的に設定するメソッドとか作ったが
何十個もあるダイアログ全部まで手が回ってない…
逆に>>481 の言うように、スピードは全く問題なくなったね >>482
かわいいっていうか
ちっさすぎて見えなくなったよ SwingってHiDPI対応してないの?
Swing で作られてるらしいIntelliJ IDEAはHiDPI対応してるっぽいけど? >>485
標準のL&Fは対応してないよ
対応しているように見える実装は独自L&F実装してる
OS側の強制拡大スケーリングはうまくいかないこと多いし
やはり時代遅れ そうなのか
ちなみにJavaFXはHiDPIに対応してた >>483
そんな高解像度のまま使っているのがおかしい jfxはmacOSで致命的ハングするから
代替にならないんだよなぁ ところでJavaFXにあるような
カレンダーによるdatechooserいいの無い?
名前忘れたけど有名どころのやつは
HiDPI対応してないうえにフォント拡大も
パネルサイズ変更も対応してないので
つかえないんですよ