1仕様書無しさん2022/05/11(水) 22:18:12.78
次から次と出てくるフレームワーク
世の中の技術オタクが自分の技術を誇示したい
たった1件のデータを取ってくるのに
環境構築する方が10倍の時間がかかる
これはほんとに効率がいいのか
2仕様書無しさん2022/05/11(水) 22:20:49.73
今やプログラミングといっても
フレームワークのAPIを叩くだけ
バージョンアップで動かなくなる
ひたすらフレームワークに振り回されるだけ
自分たちでしっかりと組んでおけば
マイグレーションにかかるコストは
ほとんどなくなる
3仕様書無しさん2022/05/11(水) 23:02:45.31
web系だけだな
4仕様書無しさん2022/05/12(木) 02:18:32.37
使わなければ良い
5仕様書無しさん2022/05/12(木) 22:05:19.49
他の人達が再実装する気もなくなるような鉄板ライブラリを >>1 が作れば解決だろ。
早く作れよ
そもそも才能無い奴にライブラリ作れないけどな
もしくは共産主義者のように進歩のない世界に憧れてるのか 6仕様書無しさん2022/05/13(金) 22:07:19.29
フレームワークに頼りすぎるとマイグレーションで死ぬからな
出来立ての頃はいろんなフレームワークと連携して便利だが
廃れてくると整合性もパッケージ管理もぐちゃぐちゃになってもまともに動かなくなる
逆にプリミティブな作り方をしておけばどんな環境になろうがすぐに持っていける
7仕様書無しさん2022/05/13(金) 22:07:20.99
フレームワークに頼りすぎるとマイグレーションで死ぬからな
逆にプリミティブな作り方をしておけばどんな環境になろうがすぐに持っていける
8仕様書無しさん2022/05/14(土) 01:36:07.28
雇用を生む
9仕様書無しさん2022/05/14(土) 03:20:50.42
雇用が継続するならいいけど
キャッチ&リリースを続けるんだろ?
10仕様書無しさん2022/05/14(土) 13:09:51.35
雇用の継続を求めるのは甘え
11仕様書無しさん2022/05/14(土) 13:34:48.17
3年で正社員になれる制度だけちらつかせるけどさようなら
12仕様書無しさん2022/05/14(土) 13:35:00.09
フレームワークとかライブラリは当たり前だがそっちのが全然楽だから使うわけで
そんなもんさえ使えないならプログラマは無理だ
13仕様書無しさん2022/05/14(土) 13:37:35.44
流行りのフレームワークしか使えない方がプログラマとしてはどうなの?だけど仕事はある
14仕様書無しさん2022/05/14(土) 14:09:38.88
何その禅問答 仕事できなさそうな奴だな
15仕様書無しさん2022/05/14(土) 14:14:20.43
特定のライブラリのみ扱うお仕事しかできません
16仕様書無しさん2022/05/14(土) 14:54:26.64
パッケージバカスカ入れたら依存関係ぶっ壊して動かなくなったよ
設定ファイル消えるとかどんなだよ
みんな好き勝手に作ってるからこうなると
17仕様書無しさん2022/05/14(土) 16:29:25.59
>>13
あれが
>流行りのフレームワークしか使えない
と読めるお前の将来に乾杯というか献杯 18仕様書無しさん2022/05/14(土) 18:22:13.85
環境によってデファクトが合わない場合もあるからしゃーない
19仕様書無しさん2022/05/14(土) 23:31:06.42
このバージョンとこのバージョンとこのバージョンの組み合わせは
うまくいったという一覧表が欲しいよな
20仕様書無しさん2022/05/14(土) 23:58:10.81
バージョンアップしたら
いつも使っていたメソッドが
別のクラスに移動していて
呼び出せなくなっていたでござる…
21仕様書無しさん2022/05/15(日) 00:04:53.35
期間限定の最適解を求めて右往左往
22仕様書無しさん2022/05/15(日) 01:25:39.76
昔: マイクロソフトに振り回される
今: フレームワークに振り回される
23仕様書無しさん2022/05/15(日) 01:39:46.47
未来: かわいい嫁に振り回せる
24仕様書無しさん2022/05/15(日) 02:01:13.60
現在:誰も振り向かない
25仕様書無しさん2022/05/15(日) 02:15:36.09
現在: 睡眠中
26仕様書無しさん2022/05/15(日) 06:52:27.15
彡 ⌒ ミ
(´・ω・`)おはよう
27仕様書無しさん2022/05/15(日) 11:40:05.73
枯れたフレームワーク使うのが正解の落ち?
28仕様書無しさん2022/05/15(日) 11:55:27.91
COBOLとCが正解
それ以外は不正解
29仕様書無しさん2022/05/15(日) 12:01:08.95
>>27
新しいものに踊らされるお調子者の上司や同僚を説得する手間が
定期的に発生するという 30仕様書無しさん2022/05/15(日) 12:09:51.09
生産性とか関係なく
死んだ言語の死んだ機能使う会社は
衰退して潰れるだけだから大丈夫
31仕様書無しさん2022/05/15(日) 12:48:10.89
斜陽企業のプログラマーで人生終わる人には無縁な話だから気にしなくていいですよ。
32仕様書無しさん2022/05/15(日) 13:23:03.99
日本が斜陽
33仕様書無しさん2022/05/15(日) 13:25:04.96
斜陽でございますか
34仕様書無しさん2022/05/15(日) 13:53:05.74
脆弱性も発見されると大騒ぎだからな
アップデートする→動かない、動作に不具合が起きる
オープンだから責任は自己責任でね
35仕様書無しさん2022/05/15(日) 17:29:02.23
strutsとspringは止めた方がいいと思う
reduxも誕生して1〜2年で衰退した
36仕様書無しさん2022/05/15(日) 20:38:44.42
合体してスリムなspringbootができたので用済みだな
37仕様書無しさん2022/05/15(日) 21:20:52.28
基本的には既存のフレームワークを使っていた人達が感じた不満や限界を乗り越える為に
作ってくれてるのが新しいフレームワークだと思えば
本来それがデファクトスタンダードになろうとするのは望ましいことだと思う
歩みを止めるというのはその恩恵を受けられずに衰退して終わることを意味するのだろう
38仕様書無しさん2022/05/15(日) 21:44:19.17
新しいフレームワークって既存のフレームワークの問題を解決してくれるから流行るんであって、個人的に新しいフレームワークがどんどんでるのは大歓迎だけどな
同士おる?
39仕様書無しさん2022/05/15(日) 21:48:39.44
そもそもよくできたフレームワーク以外は流行らないからねぇ
40仕様書無しさん2022/05/16(月) 14:34:15.76
動作が不具合起きたときに、そもそも自分のロジックのバグなのか
フレームワークのバグなのか切り分けのスゲェめんどくさいよな
41仕様書無しさん2022/05/16(月) 18:06:47.24
銀行の案件ではstrutsの見たことないようなレガシーなフレームワークがあった
Java6とかantビルドとか・・・
42仕様書無しさん2022/05/16(月) 18:08:11.14
antビルドあたりになると用語と実際の動作がデタラメな悪い意味のJavaが顕在化する
43仕様書無しさん2022/05/16(月) 18:31:42.54
いまは何ビルドがはやってるの?
44仕様書無しさん2022/05/16(月) 19:18:58.74
証券系だけど、しばらくはantビルドを継続する
というのはビルドツールの変更は工数がかかるからね
45仕様書無しさん2022/05/16(月) 19:22:25.68
ninja
46仕様書無しさん2022/05/16(月) 19:31:08.05
何で証券とかお堅い所はJavaなんか使うんだろうなぁ
もうPHPとかで十分だろと思うわw
47仕様書無しさん2022/05/16(月) 19:34:11.22
銀行がMSに依存するとかない
48仕様書無しさん2022/05/16(月) 20:00:32.78
日本ではそうかも知れないが、世界ではMS依存が結構多いらしいぞ
Azureとか日本ではあんまり採用している話を聞かないが世界シェアはAWSの次だしな
49仕様書無しさん2022/05/16(月) 20:03:46.96
>>30
例えば、核廃棄物の管理システムみたいに
運用期間がものすごく長い期間に及ぶシステムの開発はどうすりゃいいの?
経年劣化したハードウェアを更新するために同じ機能のソフトを
ゼロから開発しないといけないのか 50仕様書無しさん2022/05/16(月) 20:36:26.78
仮想環境でウィンドウズXP使ってるところもあるし
IE6じゃないと動かないらしい
51仕様書無しさん2022/05/16(月) 20:48:34.98
>>1
環境構築なんてdockerイメージをダウンロードするだけで済む。
スレを立てる前に自分の無知さを理解しよう 52仕様書無しさん2022/05/16(月) 21:10:24.37
だから俺らはシェルスクリプトを使う
フレームワークやライブラリに依存すると
アップデートで動かなくなる
53仕様書無しさん2022/05/16(月) 21:32:34.45
ドッカーもシンプルな環境ならいいけど、仕事だとそんな環境は無いわけで
あれやこれやと組み立てようとすると、いろんなものがなかったり
エラー吐いたりしてめんどくさいんだよなぁ
54仕様書無しさん2022/05/16(月) 21:43:01.39
非常に面倒くさかったが
最終的な生産性はそんなに変わらなかった
55仕様書無しさん2022/05/16(月) 22:17:24.13
>>49
実装と並行してドキュメンテーションもしっかりしてるはず 56仕様書無しさん2022/05/16(月) 22:53:10.58
>>53
dockerをちゃんと使ったことがないと言わんばかりの内容のセリフ。ちょっと恥ずかしいよ 57仕様書無しさん2022/05/16(月) 22:54:10.52
dockerなんて使わなくても問題ない世界に生きてまーす^^
58仕様書無しさん2022/05/16(月) 22:55:11.05
環境丸ごとセーブロードできるから
場当たり的なやつほど重宝するぞ
59仕様書無しさん2022/05/17(火) 00:59:44.81
銀行みたいにリスク高そうな開発は手を出さないようにしてるから分からんけど...
Javaのバージョンをあげ
60仕様書無しさん2022/05/17(火) 00:59:56.78
誤爆
61仕様書無しさん2022/05/17(火) 04:04:30.74
Dockerなんていらん。
自分で作ればいいだけ
FreeBSDバンザイ
62仕様書無しさん2022/05/17(火) 05:49:48.63
最近ぜんせんFreeBSDって聞かんな
63仕様書無しさん2022/05/17(火) 09:27:40.49
MSには依存しないけど
IBMやoracleには依存すると
どっちも危ない企業だと思うけどなあ
64仕様書無しさん2022/05/17(火) 19:28:18.84
何にも依存しなければよい
社員が作ったフレームワークやライブラリを使っていれば
社員が死ぬまでは安泰だ
65仕様書無しさん2022/05/17(火) 20:42:30.73
国産データベースってないの
66仕様書無しさん2022/05/17(火) 22:40:42.47
国産にこだわる意味が分からない
67仕様書無しさん2022/05/17(火) 23:10:19.28
サーバーは国内にあってほしい
68仕様書無しさん2022/05/17(火) 23:13:40.87
バックアップも国内にあってほしい
69仕様書無しさん2022/05/17(火) 23:20:29.68
自分の部屋は家の中にあってほしい
70仕様書無しさん2022/05/18(水) 00:04:28.46
ライブラリやフレームワークに依存しすぎると
確かにコードは簡潔だけど何層にも依存しすぎて
何やってるかさっぱりわかんないんだよね
phpだとこんなのがゴロゴロ出てくる
$data = $hoge->hage($foo->fuga($bar, $foobar->piyo));
71仕様書無しさん2022/05/18(水) 00:17:00.44
ライブラリ使うにしても中身知った上で使いたいよね
知らなくても動けばいいんだろうけど
72仕様書無しさん2022/05/18(水) 02:30:33.69
OSから全部作らないとだめだろうな
73仕様書無しさん2022/05/18(水) 07:03:40.84
ちょっとウェハ作るからフッ化水素作るわ
74仕様書無しさん2022/05/18(水) 07:34:25.39
宇宙の創造から
75仕様書無しさん2022/05/18(水) 15:14:43.97
ICって超大企業じゃないともう作れなくなっているよね
ノウハウの塊になっているから
76仕様書無しさん2022/05/18(水) 15:32:35.52
ノウハウ持った超大企業が製造ラインと材料提供したらそれなりの企業でも作れるんじゃね?
77仕様書無しさん2022/05/18(水) 22:35:57.71
自社フレームワーク
78仕様書無しさん2022/05/18(水) 22:45:04.16
もってるところはあるが
大体ばぐってる
79仕様書無しさん2022/05/18(水) 23:19:26.96
人生はフレームワーク
あなたと僕でフレームワーク
80仕様書無しさん2022/05/19(木) 22:14:45.95
>>55
その分分量も爆発的に増えてるんじゃないの?
いちいち全部読んでアーキテクチャから設計し直しだな。 81仕様書無しさん2022/05/19(木) 22:53:52.30
>>49
だから戦闘機の刷新とかプログラムも大変な規模になってるな 82仕様書無しさん2022/05/20(金) 00:07:18.38
戦闘機は浮いてさえいれば大丈夫なんだよ
83仕様書無しさん2022/05/20(金) 00:45:40.16
人生がフレームワーク?
よくできたクソゲーだろ
84仕様書無しさん2022/05/20(金) 01:43:58.36
85仕様書無しさん2022/05/20(金) 09:21:40.85
>>77
自社フレームワークだってPHPやMySQLのバージョンアップで全滅してるから・・・ 86仕様書無しさん2022/05/20(金) 09:27:16.70
自社ライブラリの中に外部のライブラリ使ってるアホライブラリってなんなん?
87仕様書無しさん2022/05/20(金) 10:11:58.67
手アッセンブルでマシン語にしてるとこ以外全部アホってことになるが
大学でアッセンブラとか意味ないやろとか思ってたけど常識の教育って大事かもしれんな
88仕様書無しさん2022/05/20(金) 11:40:10.43
>>86
PHPの場合は言語仕様変わりすぎてどうにもならんよ
古いままだとセキュリティがアウト
それを吸収してくれるのがフレームワーク
結局のところフレームワーク使ってるほうがマシなんだよ 89仕様書無しさん2022/05/20(金) 22:31:40.28
>>86
> 自社ライブラリの中に外部のライブラリ使ってるアホライブラリってなんなん?
その外部のライブラリが知名度があって広く使われているのなら何も問題ないだろ?
自社ライブラリの開発は、外部のライブラリを使おうが
使うまいが大抵はアンチパターンだよ
自社で作ったライブラリは、自社ライブラリではなくて
オープンソースにしないとだめ 90仕様書無しさん2022/05/21(土) 06:44:02.49
オープンソースの次はプットソースしないと
オープンだけじゃ意味ないんだよ
トンカツやキャベツにとっては
かけないとどうにもならない
91仕様書無しさん2022/05/21(土) 07:34:31.66
自社ライブラリだと言語のバージョンが固定になっちゃう
セキュリティ的にアウトだよ
しかも客先ごとにフレームワークのバージョンが分岐するしさ
管理的にもいい事はない
自社でフレームワークを一元的に管理できる部隊を置く事になるけど
それだったら汎用的なフレームワーク使ったほうがいいよねってなるよ
おまけに新入社員が外注使う時にも自社フレームワークだと汎用に比べると工数かかるしな
92仕様書無しさん2022/05/21(土) 12:28:46.77
ギガフレームマスターになると凄いらしいぞ
93仕様書無しさん2022/05/21(土) 15:20:15.70
選択肢があるのはいい事だよ
94仕様書無しさん2022/05/22(日) 01:39:13.40
95仕様書無しさん2022/05/22(日) 17:45:05.71
そもそも>>1の言うフレームワークって何?
具体名出せよ 96仕様書無しさん2022/05/22(日) 22:51:49.63
97仕様書無しさん2022/05/23(月) 22:51:11.66
98仕様書無しさん2022/05/24(火) 19:01:24.35
言語も乱造し過ぎてる件
99仕様書無しさん2022/05/24(火) 19:56:42.48
react vue bootstrap node jquery
100仕様書無しさん2022/05/31(火) 20:38:32.16
select * from user where id = 1
たったこれだけのSQLを実行するのに、フレームワークをインストールしてパッケージをインストールして
モデルを作りメソッドに何があるかを調べて、nullが取れたらエグゼンプションが起こり
その対処方法をまた調べて延々と時間を費やす
そして無駄に何時間もかけて覚えたことを自慢するためにQiitaで自慢する
ひたすら本質から外れたことを延々と世界中の人間が繰り返すために
無責任に作られたフレームワークが存在する
101仕様書無しさん2022/05/31(火) 22:55:03.46
>>100
たったそれだけの事をするのにセキュリティホール作る奴がいるんだから仕方ない
フレームワークのサンプルをコピペしたほうがよっぽどマシ 102仕様書無しさん2022/06/01(水) 00:31:06.03
何もわからないけど動いてるが常態化する悪い例だと思うけど
まぁ上がしっかり管理してるなら構わんよ
103仕様書無しさん2022/06/01(水) 01:08:40.45
>>100
ユニケージならSQLもいらんで
シェルスクリプトとawkと独自コマンドセットを使うだけや 104仕様書無しさん2022/06/01(水) 01:10:47.32
ユニケージならUSP研究所と使用ライセンス契約結んで
独自コマンドセットを購入するだけやからな
そうすればRDBMSなどミドルウェアが不要
クラスタ組みたいなら、アプライアンスを購入するだけや
Oracleよりも安くすむ
105仕様書無しさん2022/06/01(水) 08:12:20.07
例えば>>100みたいなSQLをソースに直書きするでしょ?
そういう奴らが多かったからフレームワークで規制しようっていう流れになった
考慮すべきセキュリティや設計などなど全部学ぶ事に比べたら
フレームワーク使って何も考えずに作ったほうがよっぽど手っ取り早いんだよ 106仕様書無しさん2022/06/01(水) 09:34:04.60
放置されてセキュリティーホールだらけのフレームワークもあるが
107仕様書無しさん2022/06/01(水) 10:39:50.08
ウェブなんて似たような処理を書くわけだし
108仕様書無しさん2022/06/01(水) 11:06:28.47
フレームワークってのは簡単にできるから存在意義があるわけで
フレームワークさえ無理ならもう諦めろ
109仕様書無しさん2022/06/01(水) 12:26:15.38
フレームマークの標準機能を使ってる分には楽なのだが
それだけではできないチェックや表示などのカスタムロジックを入れると途端に破綻する
結局、実際の現場ではカスタムロジックだらけなるわけだが(笑)
110仕様書無しさん2022/06/01(水) 14:05:39.14
フレームワークにも設計の綺麗、汚いあるからな
駄作を使うのはホント時間の無駄が多い
111仕様書無しさん2022/06/01(水) 14:51:47.65
フレームワークに文句を言ってるやつは
だいたいフレームワークを理解してない
大抵のフレームワークは十分な拡張性を持っていて
標準機能にないものは拡張機能を作れば実現できるのだが
それを作れるだけの技術力がない
112仕様書無しさん2022/06/01(水) 15:00:16.99
でも拡張させたら変なことするな!と怒られるだけだよね
113仕様書無しさん2022/06/01(水) 15:03:43.58
拡張機能を作るくらいならオリジナルで全部作る
なんでフレームワークに合わせて拡張機能を作らなければならないんだ?
機能変更されたら地獄だぞ
114仕様書無しさん2022/06/01(水) 15:04:31.81
MFCは糞だったけど.NETはよく出来てると思う
近年のだとLaravelとかReactとかいい設計だと思う
115仕様書無しさん2022/06/01(水) 15:51:48.79
>>112
改善したら余計なことするな!って言ってくるような
アホならどこでもいる。アホのアホさかげんにキリがないのは当たり前で
それはアホが悪い。でだからなに? 116仕様書無しさん2022/06/01(水) 15:52:21.91
>>113
全部作らなくていいからだろ
アホなの? 117仕様書無しさん2022/06/01(水) 15:53:10.31
ほんの些細な問題、それも技術で解決できる問題なのに
それをせずに、人海戦術に切り替えてコストを跳ね上げるって
馬鹿だよね。コスト意識を持ってない。
118仕様書無しさん2022/06/02(木) 15:40:13.53
>>100
内容の是非はともかく Qiita みたいなのを自慢と解釈するメンタリティって
根本的にエンジニアに向いてないと思う。 119仕様書無しさん2022/06/02(木) 19:55:35.50
無能な人間ほどQiitaを馬鹿にする
毎日Qiitaで調べているのにな(笑)
120仕様書無しさん2022/06/03(金) 02:19:11.95
ドキュメント見てわからずにぐぐったときの課題解決の情報先
StackOverflow (7割) > Qiita (2割)> その他個人サイト >Teratail(0件)
121仕様書無しさん2022/06/03(金) 09:10:59.29
かっこいいな!
さすが!
君の承認欲求がさは満たされたから
もう来なくていいよ
122仕様書無しさん2022/06/03(金) 12:09:20.95
「情報先」みたいな言い方、すごいもやっとするんだが俺だけ?
123仕様書無しさん2022/06/03(金) 13:11:38.06
スタックで検索するも、コードが書いてなくてひたすら文章だけのリプライで諦める
124仕様書無しさん2022/06/03(金) 13:26:24.18
Qiitaはちゃんとと解決してるから優秀だと思うよな
teratailとか検索にヒットする癖に未解決なのばっかだからホント検索の邪魔
125仕様書無しさん2022/06/03(金) 13:47:51.29
できてから5年はたってると思うが
自分の場合ほんとうにTeratailで1件も問題が解決してない
尋常じゃないよ
126仕様書無しさん2022/06/03(金) 14:35:05.12
解決してないならヒットしないでくれよGoogleさん。って毎回思う
127仕様書無しさん2022/06/03(金) 17:16:03.31
ララベルをやり始めたけどやっぱ縛りが多いな
「俺様のルールに従っていれば楽だけど、外れたことをする奴は容赦しない」
まぁ、これがモダンなフレームワークのルールだよな
128仕様書無しさん2022/06/04(土) 00:49:58.93
>>127
今までそういうので困った事ないけど枠から外れたらって具体的にどんなの? 129仕様書無しさん2022/06/04(土) 09:14:11.24
laravelの中でdjangoの機能を呼び出したりとか
130仕様書無しさん2022/06/04(土) 09:35:05.60
なにその魔法少女みたいな名前
131仕様書無しさん2022/06/04(土) 10:03:31.41
九平「僕と契約して、このフレームワークを使うWebプログラマーになってよ」
132仕様書無しさん2022/06/04(土) 13:51:48.72
言語の方が統一してほしいわ。。
133仕様書無しさん2022/06/04(土) 14:37:06.18
日本法
国定言語を英語と定める
日常会話および文書にて使用できる言語は英語とする
使用できるプログラム言語はCOBOLとする
134仕様書無しさん2022/06/04(土) 17:10:35.69
Laravelって相当縛り緩いほうだよな
135仕様書無しさん2022/06/04(土) 18:54:47.54
しかもLaravelはFacade使えば自由自在
136仕様書無しさん2022/06/04(土) 22:02:51.82
プログラムじゃなくてウェブ環境を構築するときに
規定のフォルダーから外れるとほんとめんどくさくなるな
137仕様書無しさん2022/06/04(土) 22:26:40.35
だからその規定のフォルダーから外れる場合は
どういうものかって話だろ
机上の空論すぎ
フレームワークで作りにくいものは作りにくいと
言ってるだけじゃん
138仕様書無しさん2022/06/04(土) 22:54:44.41
過去のフレームワークはルーティングが密結合だったので面倒だったが、最近のは疎結合だから作りにくいなんてことはほぼない
139仕様書無しさん2022/06/04(土) 23:16:12.64
規則に縛られるのが大好きなんだね君たちは
140仕様書無しさん2022/06/04(土) 23:38:56.90
便利な道具にすぎないだろ
ソートやTCPIPのコネクションから書くのか?
141仕様書無しさん2022/06/04(土) 23:38:59.76
>>138
ようわからん
StrtusとかSpringとか
SpringBootより設定は面倒だけど
結合は疎じゃなかったか 142仕様書無しさん2022/06/05(日) 00:04:33.75
>>140
はい、ライブラリの使用は全部禁止です
jQueryすら使ってはいけません。
将来動かなくなるかもしれませんからね
ライブラリなんて40行で書ける! 143仕様書無しさん2022/06/05(日) 00:09:23.59
jQueryなんかもはや不要じゃね?
あれ使うなら、バニラで書くよ
144仕様書無しさん2022/06/05(日) 00:10:13.47
>>142
Pythonのライブラリ全部40行でかけるんだ
すごいね 145仕様書無しさん2022/06/05(日) 00:48:53.35
>>141
Javaだと確かJettyが密結合だった記憶が。JavaはStrtus1の頃から疎結合だったね。インタプリタ言語だとイレギュラー的にルーティングの改変が必要だった。 146仕様書無しさん2022/06/05(日) 08:37:21.42
>>144
間違った。Ajax処理ごとき40行足らずでフルスクラッチ可能 147仕様書無しさん2022/06/05(日) 08:38:20.78
148仕様書無しさん2022/06/05(日) 08:41:57.21
Ajax処理ごとき40行足らずで書けるのだから
ライブラリは一切禁止だ
149仕様書無しさん2022/06/05(日) 09:16:09.13
ちょいちょい見かける頭おかしい主張をしてる人のマネしてる系男子か
150仕様書無しさん2022/06/05(日) 10:08:35.23
査読有りの論文だからね。正しいよ。これが
大学が認めてるからね。信用度は抜群。
ソフトウェアの高い互換性と長い持続性を目指すPOSIX中心主義プログラミング
https://www.ipsj.or.jp/dp/contents/publication/32/S0804-R1601.html
4.3.1 各種JavaScriptライブラリ使用の禁止
この指針の下ではjQuery等の各種JavaScriptライブラリを原則使わない.
W3C勧告の範囲の仕様にのみ基づき,プログラムを書く.
後述するXMLHttpRequestに関しても基本的な部分は40行程度で記述できる[12].
一度書けばほかのプログラムにも流用可能であるため,以後はコピーして使えば
開発効率はさほど低下しない.
ライブラリを使わない理由は,そのライブラリが各Webブラウザの独自機能を
利用していないという確証がないからである.そのようなライブラリを利用すると,
将来のWebブラウザでは正常に動作しなくなる可能性が高まる. 151仕様書無しさん2022/06/05(日) 10:37:49.18
>>150
>以後はコピーして使えば
これがライブラリでありフレームワークなのではないか 152仕様書無しさん2022/06/05(日) 10:42:31.41
ライブラリってdllとかになってんのが普通だと思ってたわw
153仕様書無しさん2022/06/05(日) 11:16:04.33
コンパイルの都合で様々な形になってるけどソース提供されるでしょ
154仕様書無しさん2022/06/05(日) 11:28:49.11
煎じ詰めると、
完全に自分の思い通りに動くものを作りたければ、
何やってるかわからない他人の作ったものを使うのをやめて
全部自分で作らなければならない
ってことが言いたいのかな、その論文は
155仕様書無しさん2022/06/05(日) 14:27:26.03
いやほとんど関心無い部分だからどう動いてようがどうでもいいんだが
156仕様書無しさん2022/06/05(日) 14:37:04.14
>>151
重要なのは、それぞれ自分で独自のライブラリを再発明するってところ
他人が作ったものは使ってはいけない 157仕様書無しさん2022/06/06(月) 02:37:55.03
そもそもJS自体ブラウザ依存なのにフレームワークガーとか言っても意味ないだろ
158仕様書無しさん2022/06/06(月) 02:45:39.88
>>147
それをやったのがAjaxなのに本家を差し置いてどこの誰ともわからんやつのAjaxもどきを使う意味がどこにある 159仕様書無しさん2022/06/06(月) 10:14:43.26
>>158
どこの誰ともわからんやつが作ったライブラリなんか使うか
自分でライブラリを作れ
そしてシェルショッカーが作ったライブラリを使え 160仕様書無しさん2022/06/06(月) 12:38:07.41
ニコニコ動画とか見ると全部ajaxでコンテンツ取ってくるのな
ジャバスクリプトを切ると画面真っ白だよ(笑)
アップルのサイトとかジャバスクリプト切ってもちゃんと見れるのにな
161仕様書無しさん2022/06/06(月) 12:42:39.75
今どきjs切るとかどこの官庁だよ?