JavaScriptライブラリ使わずプログラミングする技術 ->画像>1枚

お前らに最高のプログラミング手法を伝授してやろう

使っていいのはw3cで決めれられたAPIのみ
その他のライブラリは使用禁止
ライブラリを使わないと作れないようなものは作るな
これを守れば10年後も修正せずに同じアプリが動く

JavaScriptは書き捨てだから

jsプログラマは使い捨て要員だよな

DOM操作のためにjQuery使ってるのであれば使わずに同じことできるぞ

if (window.$ === undefined)
{
window.$ = (q, p = document) =>
p.querySelector(q);
}

まあここ参考
https://qiita.com/phi/items/e8d8bb6040639b641c50

>>4
jQueryを使ってはダメだ、当然Reactもだめ
その中でブラウザ依存の機能を使ってるかもしれないだろ
使っていいのはw3cで決められたものだけ

D3.jsはどうなったか？今では全然話を聞かない
ライブラリを使うとすぐに使えなくなる
ライブラリを使うな

ライブラリは自分で書けと?
車輪の再発明だな

Node.jsのパッケージマネージャ「npm」まわりで大混乱--多くのビルドが一時的に破壊 - ZDNet Japan
https://japan.zdnet.com/article/35080047/

こういうニュース見ると他のライブラリへの依存を極力減らすよう
努力するのはありのような気がする

>>6
そうやってライブラリに依存すると
ライブリがバージョンアップした時に必要ない更新作業をすることになるだろ

>>7
認めてるのはw3cだけ。ライブラリは一切使うな

github数十数百万スターのライブラリでサクッと作ってサックと請求
あとは鼻くそホジホジ、稼ぎたかったら世の流れに乗っとけ
オナニーコード、オレオレフレームワークなど誰も喜ばない

>>5
D3は火船でも最近取り上げたほどの優ライブラリですが?

>>3
ロートルはいつになったらネスケからアップデートすんの

>>10
これをみよ
https://www.buildinsider.net/web/popularjslib/2014
https://www.buildinsider.net/web/popularjslib/2015
https://www.buildinsider.net/web/popularjslib/2016

2014年のCofeeScript、2016年はどこへ行った？
2014年のthree.js、2016年はどこへ行った？
2014年に「成長力」とされたD3.jsも2015年で消えた
5年、10年動き続けることを目標とするプログラムとしては、危なくてとても手を出せたものではない

重要なことだがjQueryやReactなどのライブラリは使わない。理由はそれらのライブラリが
一部のブラウザでしかサポートしてない独自機能を呼び出している恐れがあるからだ。
自作のプログラムにそういうライブラリの混入を許せば長寿命という特徴が損なう恐れが出てしまう。
互換性や寿命が減る恐れは阻止しなければいけない

ライブラリを使わないということはその部分を自力で1から書くということだ。たいそれたことに思えるかもしれないが
そうとは限らない例えばAjaxによる画面更新は有名なライブラリにたよらずとも数十行で実装できる

一度たかだか十数行のコードを書く苦労を受け入れるか、ライブラリを利用して楽をする代わりに
この先ずっと寿命の短さの恐怖に怯えるか、諸君らはどちらを選ぶ？私なら断然前者を選ぶがな

書くのが大変なら
・凝ったことはやらない
・使わないと出来ないようなことには手を出さない
これだけでよい

JavaScriptのライブラリは今、戦国時代だ
つまり「せっかく覚えた知識が数年で時代遅れになる」ということだ
だからW3Cに準拠したものしか使わない

これが歴戦の開発者すら論破した我らの完璧な理論だ

別スレで暴れてたPOSIX原理主義の人か、そらともそれを見て真似して見ようと思った暇人か

POSIX原理主義の人のマネをして適当なことを言ってるのか、
それともPOSIX原理主義の人が実際に言ってることなのか
どっちなのかな？

もし後者ならPOSIX原理主義はおかしい
POSIXの名前を語るなよ

>>8
バージョンアップしなきゃいいんだよ。
使うライブラリは全部手許にコピーを置いてバージョン固定で使う。

double arrow使ってて当然主張としてbabelも使わないんだからES6なんだろうが
俺はpreset-env S5出力してるからこいつのコードよりブラウザ互換性高いわ

S5 -> ES5 E抜けた

>>12
ブラウザ互換性なんかよっぽどの知恵遅れのガイジかドマイナーブラウザ使ってる奴なんか切り捨てるのが当たり前
今はアクセシビリティを重視することが重要

そもそも契約前の要望確認時に対象ブラウザ指定しないのがおかしいし、
そこに主要でないブラウザが要求されるなら金額上乗せしとけってだけの話

>>19
そういう話はしてない

ライブラリを使わないでW3Cに準拠して自分で書けば
5年10年後でも修正せずに動くということ

ライブラリには一部のブラウザでしかサポートしてない独自機能を呼び出している
恐れがあるから、そんなものを使うと長寿命という特徴が損なわれる恐れがある

W3Cに準拠すれば、すべてで20年動くプログラムになる
一度書けばどこでも、ずっと使えるプログラムになる

ツッコミどころ満載だな

5年、10年たったらハード、ソフトともにものすごく変化するから
今作っているものが使える可能性がそもそもものすごく低い

ライブラリが数行で済むならいいんだが、往々にして数百行になったりするし
誤差はどうするんだとかテストはどうするんだとか
自作のプログラムは何かと問題が多い
ドキュメントをかっちり残しておかなければ行けないという点もある
ライブラリだとこの辺の問題が解決されている

>>20
W3C発行のHTMLがすべて廃止された日
https://www.mitsue.co.jp/knowledge/blog/frontend/202102/08_0910.html

W3C自体が終わってるけどね

>>21
W3Cには全てのブラウザが準拠しているから
ハードやソフトが変化したとしても同じように動く

数百行になるような場合はすでに書いたとおり
凝ったことはやらない。ライブラリを使わないと出来ないことには手を出さない。
それだけ

デバッグ作業からは何も生まれない。そもそもやる必要をなくせばいい。
そんなことができるのか？と思うかもしれんが、
答えは「1行書き足しては実行、書き足しては実行・・・を繰り返す」だ

何十何百行もあるプログラムを書き終えたあとでおかしな動きをすることがわかったら
どの行に問題が潜んでいるかの特定には時間がかかるし
全部作ったあとで出来上がったコードを見ながらテスト項目を立案するのも骨の折れる作業だ

一方、毎行1行ずつカキコ足しては実行というテストをしていて、ある1行書き足した時点で
おかしなことになったと気づけば、今書いた1行に原因がある可能性が高く、場所の特定に割く時間を抑えられる

この1行書いては実行というのは別にシェルスクリプトに限ったテクニックではない。
コンパイル不要な言語ならどれでも気軽にできる

>>22
やはり20年、いや25年後もWin/Mac/UNIXすすべてで動く普遍的なプログラムを書けるのは
POSIXに準拠することだけであることが証明されたようだな

W3Cはもう終わったのでブラウザが準拠する保証はないよ
プログラマとしては5年ごとに最新技術で作り直す方が楽しいんじゃないかな
式年遷宮ですよ

世界の覇者であるLinuxがPOSIXに準拠し続けるかどうかはわからん
UNIXで残ってるのはMacだけだしなあ

手を出さないって客にどう説明するんだよ

>>26
覇者？w
覇者はwindowsなのだが

素人のネタスレに客てｗ

>>29
これがネタだったらどれだけいいかって思うよ・・・

某大学でこの内容がそのままを講義になってるの

そもそもhtmlやjsは全体的に行きあたりばったりな仕様が多いから、今考えるとどう考えても欠陥としか思えない仕様が多い
box-sizingの初期値なんて結局みんなborder-boxにしてる
jsの文法全般とかそのまま使うのはアホらしい
みんなもう少しマシなものにリセットしたがってるし、例えば仕方なくlintとtypescriptでお茶お濁したりしてる

商業の話ではなくて理想の話で言っても、htmlやjs後方互換性が劣悪な環境の原因になってるのは明らか

何が言いたいかといえば、理想論の話をすると>>20のような存在そのものが邪魔

>>26
LinuxはPOSIX準拠してない定期

>>5
>>4はES6以降の標準しか使ってないぞ

>>34
4.3　W3C勧告準拠指針の詳細
2016年現在，一般ユーザに対する操作画面はWebページとして作成するケースが主流になっており，
アプリケーション開発においてWeb（HTML/CSS/JavaScript）は必要不可欠な存在になっている．
Webの規格はPOSIXとはまったく異なる発展を遂げてきたが，POSIXに似た事情を抱えている．

UNIX業界では各OSが機能を独自拡張し，互換性が低下した状況を改善すべくPOSIX規格が策定され
一方，Web業界では各Webブラウザが機能を独自拡張し，互換性が低下した状況を改善すべく
W3Cという組織が設立され，勧告（W3C勧告）がアナウンスされるようになった．

そこで，クライアント端末向けにWebプログラムを作成するにあたってはW3C勧告に準拠するという指針を設ける．
W3C勧告もまたWeb上で閲覧でき[11]，プログラマは常にその内容を確認しながらプログラミングできる．

4.3.1　各種JavaScriptライブラリ使用の禁止
この指針の下ではjQuery等の各種JavaScriptライブラリを原則使わない．
W3C勧告の範囲の仕様にのみ基づき，プログラムを書く．
後述するXMLHttpRequestに関しても基本的な部分は40行程度で記述できる[12]．
一度書けばほかのプログラムにも流用可能であるため，以後はコピーして使えば開発効率はさほど低下しない．

ライブラリを使わない理由は，そのライブラリが各Webブラウザの独自機能を
利用していないという確証がないからである．そのようなライブラリを利用すると，
将来のWebブラウザでは正常に動作しなくなる可能性が高まる．

それ結局独自ライブラリじゃん

>>7
＞2016-03-24 11:52

情報が古い

>>37
W3Cに準拠してるから5年くらい余裕ですわ

>>38
>>7はnpmパッケージの所有権絡みの問題？でW3C準拠とか全然関係ない話で5年も経つんだから当然解決済だろ。
情報が古い

>>39
どう解決したのかな？ おん？

> 解決済だろ

「だろ」は推量で自分は知らないってこと、だろ？

npmのパッケージ依存地獄問題を解決したらノーベルIT賞もらえるわ

エコシステムは依存関係の増大を促し脆弱さをもたらす
僕たちの絆社会も同じ問題を抱えているのかも知れませんね

解決っつか、それで困るようなところは自衛手段とるようにしてるだろ。

>>44
> してるだろ。

「だろ」は推量で自分は知らないってこと、だろ？

お前らさては知ったかぶりだろ

だからそれ結局自分の独自ライブラリじゃん

パッケージ管理の手本はdebian。
後続のnpmはdebianの運用ノウハウでなんとでもなる。
npmパッケージのライセンスに注意して使えば問題ない

jsなんて所詮DOM装飾
ライブラリが壊滅しても誰も実損しない
カード決済や金融取引などのように
厳格で高セキュリティを求められないしな
なので開発が楽なライブラリをどんどん使って
効率的に稼ぎましょう

jsの仕様にはDOMは含まれていません
基本からやり直し

だろよりじゃろの方が可愛いじゃろ

JSはマークアップを装飾するために生まれた言語
JSが破綻しても深刻な被害なんてないんだから
どこも間違ってない
50はJS以外何を扱ってるんだ？
多言語扱う人間からしたら
JSは単なるマークアップ言語
ブラウザ・ユーザー・インターフェイス言語なんだけど？
サーバーセキュリティがしっかりしてれば
ブラウザが崩壊しても深刻な被害はないんだよ
つまりブラウザ側のフレームワークやライブラリの信頼性なんて重要じゃないから
効率よく作って稼げばいいって話

それは偏見

フレームワークやライブラリを使うなっていうほうが偏見な

何言ってんだ？

オープンソースにして放流したり
チームで作業したりせんかぎりは
我流で作ったほうがいい。

w3cには現実で使われているAPIの半分しかない

金曜日入れないの？