Vue vs React vs Angular vs Svelte Part.8 YouTube動画>5本 ->画像>1枚

>>88
いやいや今はSSGの次、ISRだよ
なんて言うのは簡単なんだけど、どうも胡散臭さが抜けないね
なんかひと昔のフレームワーク乱立時代の感覚と似てる
シンプルなものをシンプルに作りたいだけなのにって

技術的には延長線上にあるから、そこまでの乱立感はないかな

むしろSSRしかしない昔からの遅く不便なサイトや
CSRしかしない最初の表示が遅くて重いダメなサイトが
どちらも時代遅れでかつ利用者の体感悪すぎなことに気付かず大量に残っている現状を

SPAで構築するようなサイトはアプリのような動きを期待しているのに
SEOガーとかそもそも話が合っていないんだよね
企業サイトみたいなのを無理やりSPAにするのがそもそもの間違い

俺の仕事だとガチのアプリ開発だから、
SSRとかSSGとか全く興味がない。
そもそもinstall以外でサーバー使わん。

サーバー使わないガチのアプリとは

そらもうCやRustで書いた超高速ネイティブアプリやろなあ

>>95
サーバーはサービスAPIだけだよ
UI要素はゼロだ

サーバは使わないけどAPIは使います。

日本語へのコンパイルエラーが出てるんだけど。

SaaSとかのサードパーティ製のAPI使うって意味じゃねえの？
サーバーレスというワードと同じで、自分で管理するサーバーは持たないってだけなんだろ、多分

>>93
それは違う
SPA/PWAにするのはユーザーの体感向上と通信減少とサーバー負荷減少など総合的な目的がある
企業サイトでも何でもその目的で有利となる
企業に限らず検索によるトップページやそれ以外の途中ページ流入も欲しいのは当たり前
そしてSSRはSEOのためだけでなくユーザーの体感向上が第一だ

YouTube で有名な、雑食系エンジニア・KENTA のサロンの初心者用コースが、

Ruby on Rails, Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース

今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, React, Vue.js, TypeScript が加わった

EC2 ではなく、サーバーを管理しない・サーバーレスのFargate。
他にも、AWS サーバーレスのLambda, Aurora, Elastic Beanstalk など

だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！

KENTAってまこ様に噛みついていた人だっけ？

>>101
宣伝お疲れ
未経験が見てると思えないけどこれを浅く覚えても意味ないからな
フロントもバックも浅い知識しか持たない奴なんてお荷物でしかないから所詮インフラ要員止まりだろうしでしさっさとAWS一択に絞ったほうがいいよ

クラウドは正直Firebaseしか理解してない。青天井怖いもん。
VPSはわかるけど、フロント向開発者向けのナウでヤングなクラウドでは無いだろうし……

仕事なら別に金払うの俺じゃないし客からの指定が無い限りは99%AWSだよ
個人でAWSは確かに高くつくかもしれないが今はAWSでもLightSailやら
安いサービスはあるし、小規模なら十分安く抑えられそう

Fastly、Compute@Edge の JavaScript 対応を発表
https://www.fastly.com/jp/press/press-releases/fastly-launches-new-era-of-highly-secure-serverless-javascript-with-zero
>Fastly は、セキュリティを考慮し、WebAssembly でコンパイルされた JavaScript から個々のリクエストに対してサンドボックスを生成または破棄する、独自の高セキュリティな分離技術を開発しました。
米国 RedMonk 社のアナリスト兼共同設立者である James Governor 氏は次のように述べています。"JavaScript は、最も人気のあるプログラミング言語で、普及が進んでいます。サーバーレス・プラットフォームは、新しい JavaScript のワークロードにとって自然な環境です。一方、パフォーマンスとセキュリティは依然として重要な懸念であり、速度は何よりも重要な要素となっています。攻撃対象が減り、コールドスタートがなくなることは、最先端の Web 開発者にとって非常に魅力的です。"
Fastly は Compute@Edge の開発者の体験向上に注力しており、最近ローカルテスト環境の提供開始を発表しました。これにより、開発者は本番レベルと同様の環境でテストコードを実行し、サーバーレス コンピューティング環境でスケールとパフォーマンスを追求しながら、問題の発見と修正を迅速に行うことができます。

企業が求めているのは、バックエンド技術者。
Rails, Linux, Docker, AWS、データベース

だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
AWS Solution Architect 資格とか、この本を読むとか

Amazon Web Services パターン別構築・運用ガイド 改訂第2版、2018

サーバー構築運用は難しいから、Amazon はサーバーを管理しない・サーバーレスを勧めている。
EC2 ではなく、Fargate, Lambda, Elastic Beanstalk など

Amazon Linux, Aurora も管理不要。
Amazonがセキュリティー更新してくれる

>>102
KENTA は基本、マナブ・マコなりなどの高額学校などに噛みつく

>>101
の内容は、80万円も払わなくても勉強できると言うこと。
今は、200万円の学校をぼったくりと言ったから、業務妨害で訴えられている

KENTAのサロンは、日本6位の2千人も入っているから、
売名目的で、高額学校がKENTAを訴えてくる

古い技術者だから技術ってのは本と公式ドキュメント、時々現場で学ぶものだと思ってる。オンライン勉強会に参加することもあるけど、あれは知見を広げるってだけで身に付く勉強じゃねーわな

本から学ぶのはやめなさい

本は古い遅い検索できない
どの言語もどのフレームワークも公式サイトがベスト
金を払うのはバカ

え、TypeScriptの本とか買わない？ マジ？

マジ

なるほど、おまいらと差をつけるには本を読めば良いんだな！

本は有用だよ
だけど悲しいことに、日本語で最近のweb界隈のナウい本をあまり見ない
ハロワから毛のはえたくらいのしかコード載ってないしね
昔からある言語やアーキとかSQLあたりとかなら本もいいと

まあ結局コードをgithubあたりからDLするってなるしね。。

おまえら、本だしたとして買ってくれるのか？

確かに素人ぐらいしか釣れなさそうな公式マニュアルをかなり簡略化したような本は多いかも。出版社と題名見ればだいたいわかるけど。
言語とかHTTPとかRESTみたく歴史があって基盤になってるようなものは本に頼るなぁ。
スレタイにあるようなものは公式マニュアル頼り

やっと明日vuexとかいうゴミから解放される
しばらくフロントはいいやｗ


ところで、意識高い系の人は何に困ってあんなゴミ作ったの？ｗ

reactは今の状態でもう完成形なの？
さらに改善されそうな部分ってあるの？

RecoilはHooksに最適化されてるから遥かに使いやすいよな

ReactはHooksもあるしコマンド一発で環境作れるようになったし、
Vueは応援してたけどなんか迷走してるみたいだし

毛嫌いしてたけどなんかもうReact覚えればいいっぽいね

React.js Examplesってところで部品漁りするのが結構楽しい

オライリーのReactハンズオンラーニングって買う価値ある？
すでに大規模ECサイト作れるくらいの実力はあるが

お、なんか良さげな本じゃん。いい事聞いたわ、サンキュ！

と思って目次読んだけど……これは……2年前に読みたかった内容だな

目次みた感じあんま価値なさそうだな

Vueのおすすめできる本がないんだよな

タイトルの4つでそこそこ踏み込んでてナウい本ある？

Reactオライリー読んだ人感想よろ

>>128
初心者が買ったら後悔する

オライリーの本ってどれも初心者向けではないイメージ
全部読んだわけじゃないから個人的なイメージでしかないけど
めっちゃぶ厚かったりするからねえ

オライリーの本はかなり信用できる。半端な本を5冊買うより価値がある。リファレンスとして手元においておきたい。
もちろん変化の速い分野だと陳腐化はあるけど、それは本という媒体の問題であってオライリーの問題ではないしね。

どれ使うかは好みだけど、Vueが迷走したのでデファクトがReactから揺らぐことはないのでは

フロントWASM化するまでReactのままのような気がしてる。

基礎から学ぶ Vue.js、mio、2018/5

React の古い本では、Stoyan Stefanov の、2015, 2017 の本がある

オライリーに求める様な事は公式リファレンス見ればいいからオライリーってあんまアドバンテージない気がする

アーキテクチャとかそういうレイヤーの本なら読む価値はあるけど、言語詳細とかは
今はもう本じゃ追いつかんだろ。

Angularで
const user = {　...this.user,　status　}
のような宣言がありますが、このthis.userの前にある3つのコンマってどういう意味でしょう？

失礼、自己解決
AngularでもTypescriptでもなくJavascriptの構文でした

>>139
restはあるあるやな
他言語から来た当初は俺も分からんかったわ

>>140
似ていますがrestではありません
spreadと言います
たまたま同じ...を用いますが明白に区別されています

...みたいな記号は、ググラビリティーが悪いから調べにくいんだよ。
そのような書き方は結局ネットだけでは分からずじまいになってしまうことも多い。
本だとまとまって書いてあるから読んでいるうちに出てくることがあるが。

>>142
どのプログラミング言語でも同じですが公式ページが最も良いです
正しい最新の情報がまとまって載っています
本では情報の不足があったり古かったりありえます

今回ならばJavaScriptの演算子なので
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators
ここを見ると演算子の一覧が載っています
...objは展開記法(スプレッド記法)として詳細ページへのリンクがありますね

>>143
いや、だから...がJavaScriptの文法だっていうことすら分からないのよ。
特に今までバックエンド専門で急遽フロントエンドやれとか言われた場合、
Javascriptとか触ったこと無い状態でAngularとかVueとか始めるわけよ。

もうググりまくるしか無いわけだが、上で言われている通り記号演算子は検索しにくい

>Javascriptとか触ったこと無い状態でAngularとかVueとか
無茶しやがって…

>>144
AngularもVueもReactもプログラミング言語部分は全てJavaScript(またはその拡張のTypeScript)です
まずはJavaScriptを一通り勉強しましょう
プログラムコードでわからないことがあったら先程のようにJavaScriptの公式に情報が一番まとまって載っています

＞const user = {　...this.user,　status　}
何気に二つ目のも新しい省略記法なんだよね。

>>147
それも公式ページのオブジェクト初期化のプロパティ定義のところに{ a: a }は短く{ a }と書けることが載っていますね
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Object_initializer#property_definitions

新しいつってももう６年も前だけどな

GoogleChromeのUserAgentが段階的に廃止になる件について、Angularへの影響を確認したいです。
AngularライブラリでもUserAgentを使用していると思われるのですが、影響内容は公開されているかわかりますでしょうか。

今どきUserAgentなんか気にしてるのは
お前ぐらいなもんだろ

バックエンドでも、Ruby on Rails では、

jQuery, Node.js, Webpack, Babel, React, Vue.js, Bootstrap も、知っているのが常識だけど

>>152
Rubyは不要
JavaScriptだけで完結できる

サーバーサイドだとORMで何度も型を書くのが面倒くさいのだけど、Prisma2とやらを使えば幸せになれる？

なんでRubyガイジだと一秒でわかってしまう文章なんだろうか

読点の使い方が糖質特有のものだからだと思う

electronで使いたいんだけど何が正解？

色々やってみたがAngular一択だなぁ

jsxをきもいと思うのはエンジニアの本能だよね
jQueryの用に近い将来、技術的負債化しそう

あんなんただのマクロやん。キモイも何もない。

jQueryはいうてもJavascriptやHTMLとしてvalidだったんよ。
Vueもそういう使い方もできる。
(俺はそういう風に良いjQueryとして使うこともある位)

Reactは無理だからな。
jsxはコンパイラが絶対に必要という所が異常。

Reactもjsx無しで書けますが……

そもそも今の時代は生のJavascriptよりTypescriptを使うのが主流だからコンパイラ云々は気にしなくなった

標準のWeb Componentsだけで困る事が分からない、技術的に分断が起きてる気がする
もちろんVueなどは親和性があるが・・・

標準のWebComponents使いにくいんだよね。あとリアクティブだと状態管理が単純化して設計難度とバグが減るのが大きい

JSXはやったことない人からみたらガバガバに見えるかもしれないけど実際に使ったらめちゃくちゃ厳格で
逆にガバイ書き方してるhtmlが許せなくなるよね

>>162
書けるのとそれが普通なのは別では？
特に関数コンポーネントとhooksが主流になってからは、もはやほぼ不可能だと思ってる。

JSXといううんこをひねり出さなければいけなかった理由が知りたい
それを知ればReactが気に入るかもしれない

>>168
実際に書いてみたら分かると思うよ
JavaScriptの中にタグが書けるからと言って何でもかんでも許されるわけじゃないから
結構ロジカルな作りになってる

あくまでもマクロなんだから普通に書けるし、長くなるのが嫌ならエイリアス関数作って書けばいいだけなわけで……

むしろJSXは自由に書けない（分岐とか）のが使いづらさだという印象。

でもこの話題がいつも不思議で、JSXに嫌なところがあったとて、結論Reactでしょ

なんで敢えてVue? React以降をしてるプロジェクトをよく聞くし、Vueがいいというのは単にサンクコストじゃないの

日本はVueのがひろまってたから、つまりざっくり言って国内業界全体として技術選定ミスったんでしょ

ちょっとreactはじめてみようとおもってドキュメントの最初の
hello world表示するだけのコードを開いてみたのですがレスポンスが悪くて勉強するか悩んでます
https://raw.githubusercontent.com/reactjs/reactjs.org/master/static/html/single-file-example.html
reactで作ったものはどうしてもレスポンスが悪くなってしまうのでしょうか？
JSXを使わなければ少しはまともになるのでしょうか？

そのソースにコメントで書いてある通り、その使い方では遅いんだよ。
とりあえずnpmでcreate-react-appしてからレスポンスを語れ

reactってフォームが糞だったが
今はましになったかな

フォーム用のReactライブラリ使うとすげー楽だぞ

>>173
ありがとうございます。コメント見てませんでした。
コンパイル的な作業が必要になるんですね。
10年ぶりぐらいにWebやっていて、npmは使ったことがなく、
まだnpmのくだりはでてきてないので読みすすめて行こうと思います。

>>172
最初の読込みに時間が掛かるのは仕方ないと割りきらなきゃいかんが
ちゃんと作れば初回ロード以外のページ遷移は軽くできる
あとプロダクションビルドすれば初回ロードも多少速くなる

レンダリング前の画面が一瞬チラッとするのがムカつく事はあるけど、初回含め遅いと思ったこと無いなぁ。

Vueが使い込むと辛いことになるとか言われ始めてるけど
そんなん言い出したらWeb技術全般がつr(ry

使い込んでもつらくないのってどれ？

Reactは慣れてきたらコンポーネント定義が楽しくなってくる

>>180
3年前からAngular使ってるが、破壊的な変更や
根本的な概念の更新がほぼ無いので安心してる
一番辛いのが流行り廃りに翻弄される事だしな

もちろんマイナーだし今後は分からんけど
一つの意見として聞いてくれれば

Reactのが長いことやるのにいいと思うよ
Vue使ってる会社は、騙されたと思って書き換えた方がいい
したら意味わかる
メンバーも喜ぶ

破壊的な変更で人がゴッソリ減ったのがAngularなんだが

version5以降くらいからの話じゃない？知らんけど

ずっとAurelia使ってるけど情報が少ないことと2が出るまでバグが放置されてること以外は辛くないな

そりゃ辛そうだな…
金と女に縁がないこと以外は幸せ、みたいなｗ

空席を除いてほぼ満員、みたいな奴か

人の気持ちが分からなくてすぐ手が出ちゃうだけで根はいい子

Material-UIがいつの間にかv5になってた
スタイルが書きやすくなってるね

Reactのオススメの学習方法ある？

Webpackがわからんレベルならそこからまとまってて最近充実してきた書籍を買う。そうでなければ、公式のドキュメントを読む。そして何か（ベタにToDoアプリとか）作ってみる。
クラスコンポーネントで解析してるようなものは慣れるまで避けろ

Webpackって分かりにくいけど
今後も生き残るものなのだろうか？

>>191
create react app

仮にWebpackが死んでも似たような物に変わるだけじゃね？
ECMAのimportだけじゃminifyできないし

Webpackは出来るだけいじらないようにして
Webpackの時代が終わるのを待ってるかんじ

必要なら当日するけど
其処まで踏ん切りつかん状況

...必要なら投資...

似たような後続はあるにはあるが大幅に良くなることは無いしなぁ
nodejs自体から変わらないと革新的なものはでなさそう

Webpackは設定ファイル書き書きするだけでそんなに難しくない。ただバージョンアップで苦しむこともあるし、0からReactと並行して始めると辛いので本の導線があると楽かなって思う。

押しつけの難解な設定より
普通のコードで設定書くほうが良いんだけどな
そんなのなかったっけ？

押しつけじゃない簡単な設定ならもっと良いんじゃない？

AngularならWebpack意識せず学習可能

>>202
Reactもかわらんよ

今の主流ってzero-configだしな

あとコンフィグなんて基本は使い回しよ
webpackがrollupがesbuildがーって頭悩ましてる記事とか見掛けるけど
そのあたりのファイルを現場で直に触ることなんてほとんどない

そうか？
ターゲットとか指定したいし、ライブラリ入れたら弄らないと駄目なこともあるくね？

>>205
そういう場合も特定の人だけが触るからな
ざっくりと何をしているのかが分かっていれば十分よ
ターゲットやバージョンもほぼ固定だし
弄らないとダメなライブラリはよっぽどの理由がない限りは選定されない

個人やフリーランス、めちゃくちゃ裁量権のある立場は知らん

LaravelMix使うとwebpackの設定は割と簡単に書けるからオヌヌメ

>>206
ざっくり理解すれば十分ってのは同意。よほど踏み込まない限りWebpackも難しいものでない

Laravel使う現場って実在するのかよ
プログラミング教室でしか使わんだろと思ってたわ

ParcelでWebpack要らなくなるとか言われてたけど結局こんなもんだな。

laravelは割と主流派だぞ。
laravelmixは信者しか使っていないと思うが。

ホームページ屋さんが頑張って使ってるミドルウェアな印象

Reactできる人はみんなCSS作れるの？

おまえらPage Insightの結果はどのぐらい当てにしてる？
SPAは評価悪くなるよな
評価上げるためにリファクタリングするのに疲れちゃったよ

>>214
SSRとハイドレーションやろう
サイトによるがそもそも気にしないという選択肢は十分あり

CSRだけだとページ表示ユーザ体感が悪すぎるしSEOも不利なので一般向け情報ページならば
SSR/SSG＋プログレッシブリハイドレーションが良いでしょう

CSRって言うほど遅いか？

規模によるとしか
旧来のサーバーサイドのルーティングで十数ページに渡るような内容をSPAにしてCSRにした場合等はえらいことに
まあ継ぎ足しロードとかにするんだろうけど

そこまでするならそもそもSPAという選択が間違ってるような
よくあるコーポレートサイトやブログってSEO命なのにそれを犠牲にするってのは本末転倒

それはそう
コーポレートサイトやブログのようにほとんど変化ない情報が掲示されるようなサイトはSPAの恩恵はほとんど受けられず悪い影響は被っていいとこない
向き不向きあるとは前から言われてたのに人は金づち持てば全部釘に見えるようで…

逆にログインして操作する業務システムでSSRはあんまり意味無いと思うんだがやりたがる人結構居る、

単純にSEOとページインサイトを考慮するならspaじゃなくて静的ページジェネレーターがベストだろうね
動的サイトとの間をとってgatsbyとかで自動化するのが今風な感じする

>>221
逆にSPAを知らないんだろうね
何ができるか
なぜSPAなのかを

>>221
なんでなんだろうね

Nuxtはじめた＾＾
なんか注意事項とかあったらレスくださいね＾＾

>>222
Gatsbyやってみたけどなんか…
電球一個取り替えるのに椅子に乗ってその椅子を４人で回すみたいな大ごとになってなんだかなぁと思ったわ
それほんとにGraphQL介す必要あるの？とか

草
俺はなんかしっくり来ないなと思ってNextに行った。まぁ最終的には同じような事するわけだが

react周りserver componentsだっけ？
なんかそういう頑張って良いとこどりしようとしてるけど、
開発者が追いきれてない感じがして混迷しつつあるように見える
やりたいこととやり方はわかるけど、結局自分らがどう選択していくの？がまとめずらい
選択肢が無尽蔵に増えそうで二の足を踏み続けそう

○ 俺が追いきれてないので気に入らない
○ やりたいこともやり方も分からない
○ 俺が二の足を踏み続けている

>>229
マジか、みんな迷わず選択できてんのか。。

素直にVueやっとけばいいのにな
対して難しい事しなくてもやりたい事は大抵出来るし
新参にも教えやすい

そういう用途だとSvelteの方がよくね？
と思ったけど、情報とか使える人が少ないかな？

結局全部試すくらいの覚悟がないならフロントフレームワークなんて使うべきじゃないと思うよ

今はある程度選択肢は固まってるし
まあReactで、と言えるだけ随分楽になったよ

ただ、根底にある思想みたいなのは
スレタイにあるvue,react,angulaのどれも共通部分が多いよ
実装が違うだけで結局やることはそう変わらん

とりあえずreactでよくね

でも状態管理めんどうじゃん

そりゃ何使ったって面倒なのは変わらない

結局Recoil使うのが一番シンプルだけどな

個人的にはApollo clientでの状態管理が一推し

SPAでもそんな複雑な管理をクライアントでやったりするのかなぁ

SPAではせざるを得ないってとこだよね
本来は誰もやりたくない

SPAはSPAで楽な部分もある

ただ小規模なサイトであっても何かしらのフレームワーク使う事が大前提になった。以前のもメンテはするが

JWTやマイクロサービスを踏まえるとクライアントで状態を持つのが前提になってきてるもんね
クライアントでの状態管理は必須

Reduxは最近出ているReactの技術書では全く取り上げられなくなったな

改版を期に削除されたりしてるよね

狂信者はいるけどみんな大嫌いだったもんな
Context APIで全部解決出来れば楽なんだけどね
選択できる自由があって贅沢な悩みではあるけど

useCentextよりもRecoidの方が明解でいいと思うけどな

recoilじゃなく？

ごめんタイポ

このへんはredux一強から戦国時代に入った感じかな。大勢が決まるまでは情報収集しつつ様子見。

このままrecoil一強になってreduxの息の根止めた方が世界の為
Reduxのあれをするにはあれやこれやが追加で必要でもっと勉強して下さいとかニートじゃないと対応出来ないって

Reactの入門ググったら未だにRedux Toolkitとか勧めてる輩いるもんな

記事が古いんじゃねえの

ReactってTypescriptじゃないと人権ないの？

そんな話聞いたこと無いが

Typescriptなんて逆に消えそう

typescriptはjavascriptに吸収されるんじゃね

GraphQL使ってる？

使ってない、RESTで事足りてしまう。
いつかGraphQLがバシッとマッチする用途でシステム組んでみたい

直接は使ってないけど、実は間接的に使ってる

RESTの倍ぐらいSQLクエリ走るの見ると使う理由あるのかな？って思っちゃう
リクエストは減るんだろうけど
プロジェクトによるんかね

聞いてるとRDBと相性悪そうだね
ドキュメント型DBならどう？

GraphQLの好き勝手なクエリに対応するのはドキュメント型じゃかえって厳しいだろ。

カラム指向DBでは？

カラム指向DBって最適化の方向が違うだけでデータモデル的にはRDBと変わらんじゃん。

じゃ、じゃあグラフ指向DB！？

>>257
TypeScriptの型は少量で滅茶苦茶雄弁なコメントみたいなもの。おかげで新しいライブラリもサクサク使えるし、バグに震えることなく安眠できる。

>>263
どれも一長一短
テーブル結合ではなく複数のサービスからのレスポンスをjoinする目的の物だからどんなデータベース使おうが総クエリ数は増える
ただマイクロサービスには最適だしフロントエンド開発も楽
GraphQLに合わせるんじゃなくて各サービスに合わせたデータベースの選択が最適解じゃないかと

>>268
どこで妥協するかだけの話
普通の強い静的型付け言語をしてきた人たちから見ればTypeScriptはヌルくて甘いとなるし
型なし言語をしてきた人たちから見ればTypeScriptは面倒くさい
公平に見ればTypeScriptは中途半端な妥協の産物

>>269
あとは更新よりも読み出しが多いケースならば
読み出し毎に各DB各サービスに問い合わせるよりも
読み出しに合わせた複合DBを保持してそこも常に更新維持するなど
無駄なクエリを減らして高速化の方向もありますね

もうrecoil使ってええか？

TypescriptはAltJSとして生まれたもの
実際JSより格段に安全に組みやすくなったしそれで十分
TSが選べる環境ならJSを使う理由は一切ない
生のCSS組んでる奴なんてとっくに全滅してるやろ

>>273
Wasm上でのフレームワークも進化していてJavaScriptを使わずにフロントエンドが組める時代になりつつあるので
中途半端な立ち位置のTypeScriptをいずれ使わなくなるかもね

WasmはWasmだけで完結できないので……

というか他の言語使おうが結局DOMを触る必要があって、余程上手にラップしないとJS的なフワフワ世界に突っ込む上にオーバーヘッドが出る。それなら最初からTS|JSでええやんってなる（なってきた）。
今後のことはわかんないけどね

wasm自体が未完成だから未来の覇権は誰にも読めない
それこそTS→wasmが可能になってるかも知れんし

TS使っても現状anyだらけで、意味あるんかいなって思う

>>278
そうはならんやろ……。たまにas使ったりはするけど

>>275
既にWasmだけで完結できるようになっている
JavaScript部分はWasm呼び出す固定コード

>>276
もちろんDOM操作のみだとVanilla (生JavaScript)がWasmより速い
ところがDOM操作以外の処理が多いと逆転してしまいWasmが速い

さらにVanillaではなく仮想DOM系フレームワーク(ReactやVueなど)と比べると実DOM操作以外の処理が多いためWasmが圧勝になっている

>>280
お、マジ？
ソース出してソース

>>281
各フレームワーク比較ベンチマーク
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html

ベンチ
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
を見ると素のJSが一番速い
ついでなんだかよく分からんフレームワークを2つ挟んで、
solidっていう非vDOM系のJSフレームワーク、
ついでやっとwasm-bindgen
wasm-bindgenってのはRustでwasmやる基礎ライブラリだからフレームワークまで行かない（素で使うのはキツイ）
Rustスレでドヤ顔で貼られてたdominatorってフレームワークはそれよりずーっと右（遅い）

DOMのAPIがwasm側に提供されてない現状でUIフレームワークにwasmベースのものを選ぶのはバカのすること

DOMの関わらない演算ヘビーな処理に特出しでwasmモジュールを使う、といったやり方が当面は賢いだろう

>>282
ありがとう。
しかしえらいプリミティブな内容だな。
並んでるフレームワークも機能がバラバラ過ぎてWasmが速いとは一概に言えないよ……。
てか普通にVanillaが最速じゃないか

結局tsなんていらんかったんや

>>282
Reactがあまりにも遅すぎなんだな
しかしそれでもReactがこれだけ使われてるということはDOM操作の速さは気にしなくて良いってことか
つまりWasmでも全く問題ないという結論になってしまうな

>>286
いや、ベンチマークテストの内容見ればわかるけど、Reactでそんな処理しないだろみたいな内容あるよ。苦手な処理がいくつか刺さった感じ。コードの小ささに降ったPreactより結果が悪い事からもそれが読み取れる。
遅いWasmで問題無いという結論の持って行き方もちょっと筋道立ってないように感じる。

どういうDOM操作を行うかあらかじめわかっているならよけいなオーバーヘッドがないvanillaが速いのが道理だけど
このベンチマーク自体はどういう意味があるんかね。

>>287
なるほど
Wasmで問題ないと思ったのはそのReactの件だけでなくて
素のJSであるVanillaとWasmの差がわずか6%しかない点も含めてそう思った
DOM操作のオーバーヘッドがあるからWasmは使えないという意見が嘘だと分かったことが大きい

そうなんだよ
DOMの操作でのWasmの不利は誤差範囲
もちろん歴史の深さの差があるから今すぐではないけれどTypeScriptの天下は長く続かない可能性大

wasm使ったWebアプリが未だに実用的に見たことがないんだが

バニラJSはえぇえ
やっぱ最強のフレームワークやな

バーニラJSって体感でそれくらい変わった？

>>289
あぁそうか、Wasmに速度を求めるわけでなくてオーバーヘッド食ってでもJS|TS以外の言語で使いたいって視点なら、それはそうか。
まぁでも、まだまだこれからだね。
現状では他の言語使うモチベーションがフルスタックフレームワークぐらいしか無さそう。

>>294
SSR/SSGをCSRと同一コードでDOM生成(HTML生成)させる言語も
JavaScript/TypeScriptよりRust等の方が圧倒的に速くてサーバーコストも下がりそうね
もちろん強力な静的型付け言語を使えて今よりさらに開発効率と質も上がるメリットもあるけれど

流石にRustでWeb系を書きたくないなぁ（パフォーマンスが求められる局所なら良いけど）。平衡して考えなきゃいけないレイヤーが増えすぎる。
静的型付け言語のメリットはTSで十分補えてるから俺は要らないかな。

c#でいいじゃん
VS使えばアホみたいに簡単に作れる

C#おじさんであったか

じゃあRust使ってろ

流石にC#で作るとオーバーヘッドが半端ない事になるなぁ

新しいflash作ってるって話？

.NET, Web, Flash...!!

Silverlightは死んだんだ
いくら呼んでも帰っては来ないんだ
もうあの時間は終わって、
君も人生と向き合う時なんだ

Silverlightは死んでもいいけど光るちゃんは残して

海ちゃんと風ちゃんは？

ブラウザ自体が根本的に変化しないとこれ以上は無理やろ
結局はDOM JS CSSが最小単位でフレームワークが力技で現代風な開発環境を整えてくれてるだけだし

ブラウザは頑張ってるよ。あんな複雑なアプリケーションなかなか無い。現代的な開発環境ってのは常に変化するからいちいち対応してたらブラウザのさらなる肥大化を招きそうに思う。
鳴り物入りで導入されたWebComponentsに関しては妙に使いにくくなっちゃったね感はあるけど……。

へーーWebComponentsってどの辺りがダメ？

継承やShadowDOMとかでコードが長く複雑になって気軽にコンポーネントを作りにくい。
気軽に作るのに役立ちそうなtemplateタグがHTML importが無くなっちゃった関係で疎結合化し難く使いにくい。
他にも使っててなんかあったけど忘れた。

まぁその代わり強力なカプセル化出来るし、ネイティブだから速いしどこでも使えるとかって利点も強いけどね。

>>308
普通React使ってるだけだから良くわからんけど、
WebComponentsってネイティブとか関係あるの？wasmじゃなくて？

Web Components
https://developer.mozilla.org/ja/docs/Web/Web_Components

いずれreactがラッパーになりそう
ある意味なってるのか既に

>>309
DOM APIのラッパー＝jQuery
WebComponentsのラッパー＝React

SPAで開発するとバックエンドはやることないよな

ユーザの権限管理とか、セキュリティとか、スケールするシステム構築とか、キャッシュ管理とか、データ破損に備えたりとか、いっぱいあるんじゃね？

>>314
あるねーー
クライアントにlogic持ち込みたくないわー！

バックエンドこそSPAの根幹でしょ
いわゆるホームページならSPAだけで成り立つけど

>>313
こいつの作ったSPAはセキュリティー保ててんのか？

dev toolsでゴニョゴニョしたら
見えちゃいけないものも見えたりすんじゃね？

まぁFirebaseとか使えばセキュリティとバックアップの類以外はフロント側に持ってこれるけど

Nuxt3はいつですか

SaaS使ったところでバックエンドのロジックをフロントエンドに持ってくる訳ねーだろ
どんな設定だよ

むかしのくらさばみたいなこーどかいてんだろ

>>320
究極的にはフロントエンドで直接DB読み書きリクエストしてロジック全てをフロントで持つケースもある
現実のサービスのほとんどが様々な理由でその体系を取っていないというだけに過ぎない
・企業サービスロジック問題
・セキュリティ問題
・効率問題など

いやそれただのデスクトップアプリでしょ

>>320
お前が知らないだけ
フロントでロジック組むシステムはいくらでもある

作れるのはもちろんそう
ただバッドノウハウで
作ってるやつがバカというだけ

FirebaseのFirestore使うとクライアント側でDB（非SQL）のコード書くのよ。セキュリティルールと特殊なケース（Cloud Functions）だけサーバ側に書く。
ここに来る連中ならFirebase知ってるかと思ったけど意外と知名度低いのね。

>>326
フロントのコードは改変実行される前提に立たないといけないからセキュリティ関係だけはサーバーで持たざるを得ないね
あとは公開したくないDBや公開したくないロジックがある時
それと複数DBアクセス多くて効率悪い時で例えばGraphQLなど挟んで解決

デスクトップアプリだって解析されれば同じ話
webだろうがなんだろうがサーバー側とクライアント側で独立したアプリケーションが動くだけ

>>327
Firesroreはセキュリティルールをかなり複雑に書けるからユーザIDをごまかす手段がなければセキュリティ関係もフロントに書ける
DB自体に権限情報を持っておいてそれに従った読み書きができる
正直ルールがややこしいし普通にサーバサイドに置いたほうがいいと思うことも多いが

Firebaseエンジニアになりたいん？
おれ(´・д・｀)ﾔﾀﾞなーー

外部サービスに依存しといてバックエンドは必要無いとか笑うわ
そもそもfirebaseっていうバックエンドを使ってることに気づいてないんかな

>>329
それはサーバー側で頑張ってくれている、と同じ

出来るよって話しただけだよ。別にならなくても良いよ

>>331
そういうと思ったわ

ログインありならログイン等認証サーバは必須としても
そのサーバ自体にはここで言うロジックは直接関係ないので他は全てブラウザ側というのは可能だし実際にあるよね

>>313
POSTを受け取ってJSONを返すんだよ

>>318
まぁ無くなるって事はないだろうけどGoogleだけしか提供してないインフラに頼るってのは一抹の不安があるなぁ

データベースでベンダーロックインとかマジ勘弁

できるかできないかの話だったからできるよって話しただけなので、皆好きなもの使えば良いと思うな

フロントにDB置けないかなと真面目に検索した事はあるけどな
一時的なキャッシュ程度でもいいから
結局データ自体壊れる事がある(特にsafari)のが分かって全面的に諦めた

ブラウザのキャッシュストレージを1サイトで100MBとか使ってもいいものなのか？
みんなが使いだしたらやばいよね

そんなん保守として扱いきらんやろ、エンドユーザが少数で決まってるならともかく

キミたちは最先端でかつこの世に数少ない貴重なSPAフロントエンジニアなわけだが当然年収は1000万超えてるよね？
安売りしてる奴がいたら今すぐ転職して1000万未満は断ってくれ

よしわかった、会社紹介してくれ

>>340
SPAてかWEB自体が最先端でも何でもないよw
アプリもWEBも単にフロントでしか無いし
最適な選択できる人はどんな時代でも給料も高いと思うけどね

現実社会では多重下請けの末端の派遣がプログラミングしてることが多いから
貴重でもなんでもないんだなｗ

web界隈は土方が集まってるイメージ

これは完全に偏見なんだけど、ITドカタと言われると多重下請け業者が集まる出向先で、社内向けシステムをJavaとか.NETとか使ってドリンクガブ飲みしつつ作ってるイメージ。
いや、流石に古いか

ただ常に人手不足なのは確かなんだよなあ
こんな時代でも仕事には困らんから幸せなんだと思う
ITは確かに体力勝負の土方ぽい部分もあるけど、学ぶ環境も稼ぎ方も選択肢が多くて恵まれてる方だよ

SPA/PWAに時代が変化したことで
ちゃんとしたプログラミングが出来ない旧フロントエンドの人たちがついていけなくなったり
フロントエンドを食わず嫌いしてたサーバーサイドの人たちが一部関わらざるを得なくなったり
Web界だけに限っても大きな変化が起きつつあるから

アプリは顧客に使ってもらうから画面が命
バックエンドエンジニアやこれまでの古いタイプのプログラマーたちは、画面にあるべきボタンやフォーム類が正しく配置して正しく動作させることができない

こんなゴミどもにフロントを作らせることは不可能だ

美しく60fpsを超えるインタラクションやアニメーションとかどうあがいても作れないよな

昔よりアニメーションは簡素化と（ライブラリの助けもあって）デザインの統一が進んでる。16ms毎に処理呼び出してた頃に比べれば雲泥の差。ある意味ではとても楽に、ある意味では大変になった。

>>351
もうゴテゴテにアニメーション効かせればいいって時代でもないんだがなぁ

>>353
その程度の思考しかできないから安月給なんだろうな
ゴテゴテなんて誰も言っていない
Material Youすら理解できないだろう
インタラクションの何かも理解できないならフロントやめたらどうかね

う～んこの煽りたいだけな人

触れないほうが吉

まあクソアニメーション動かすだけのサイトだったら阿部寛のホームページのが１００倍価値あるわな。

フロントエンドしか作ったことないひとってこういう極端な考え方するよね
知り合いのデザイナにもいるわ

>>358
そんなゴミみたいな奴ってここにいるのか？
バックエンドもDBも普通にできるわ
むしろできないほうがおかしい

>>359
へぇ
どんなバックエンドつくったの？

Appleがフラットデザイン推して10年経ったが、すっかり浸透して今更フロントのデザイン揉める事もほぼ無いけどな
常識的に分かるでしょって最低ラインはどのライブラリもカバーしてるしむしろ下手なもん作る方が難しい

バックエンドコンプおじさんに草生える

フラットデザインに関しては、ボロクソ言われながらもしつこく普及を頑張ったMSが先駆者だと言わざるを得ない。
個人的にWindows8のデザインは衝撃だった。

SignalrRとかWebSocketのUI側テストってどのようにやってる？
双方向通信のコネクションはった後プッシュ的にサーバから送られてくるデータのテストで悩んでる。
テキトーなボタンつくってぽちぽちするとデータ流し込むのを作ってるけど何か違う気がする

>>364
なんのテストかによると思うが
あと自動化はするべき

SPAの方が好きだが
SPAで頑張るとjsの逆汗等でリバエンクラックされやすくなるリスクは増えるんじゃね

>>366
どういう設計してんのよ

一体どこを逆アセンブルするのさ

>>366
秘密ロジックだけフロントに持ち込まなければ大丈夫
あとはフロントでもWasm使えばネイティブアプリのバイナリ配布レベルと同等になるかな

なんだこの低レベルスレ
クライアントのjsなんてクラッキングし放題だろ
Firebaseアプリがクラッキングされまくってんの知らんの？
wasmにしたって一緒
バカじゃねーの？

う～んこの安い喧嘩売り

一応Firebaseの名誉のために言うと、Firebaseがクラックされるのはあんだけ警告されるのにセキュリティ設定をガバガバにした奴が悪いのだ

firebaseに問題があったとしてそれJS関係なくね

置いたユーザに落ち度がなくてクラックされたことってあるの？

firebaseの責任ではないけど
穴のある設定にしがちなユーザと適切に警告なり検出していないfirebase双方の未熟さが合わさって起きた事件があった
特にFirestore周り
だったと記憶してるがゴメン正確にはググって

いや、普通にフロントとバックくらい両方やるだろそんなところで役割分担とか無駄でしかない

分業と言えばデザイナとの付き合いは変わったね
今でもdreamweaver使ってる現場ってあるのかな
10年前から追いかけてないが今でもCCに入ってるの見ると需要はあるんだろな

4000年後からの電波受け取った人か

秘密ロジックってなんすか？秘密データじゃなくて？ wasmにしたって一緒なのはその通りｗ
低レベルスレww

みゅーと

僕の考えた最強の秘密ロジック！

ｗｗｗ

Google謹製ソフトウェア使っとけばセキュリティ問題が自然と解決すると思ってたり
mBaaS使っときながらバックエンド必要ないとか言ってみたり
バイナリがデコンパイルされること知らなかったり
そのくせフロントエンド開発者はバックエンド開発者より上だとか言ってみたり

なんか色々と察してしまうわ

はいはい僻み乙

なぜかフロントだけがセキュリティリスクあるみたいな流れ

これより一子相伝、門外不出の秘密ロジックを伝授する！用意は良いかケンシロウよ！

セキュリティ全無視のレスしてるからだろ

型はいらない派も笑うよな
小規模プロジェクトしかやったこと無いのが丸わかりで
一人でシコシコ最強秘密ロジック書いとけって話

仕事でvue使ってるけど自由すぎてしんどい
angularのがライフサイクル固まってて間違いないように見えるが不人気なんだよな

vueうちの会社でも使ってたけど、
一覧生成とかをvueにして基本Jqueryと併用したほうが早い　からの、結局Jqueryでいいになって
今じゃ使われなくなったわ

そりゃ上手くいく訳ない

>>389
俺もangularの方が好きだよ
色んな意味で最初抵抗あるのはよく分かるから仕事じゃ無理に勧めないけどね

久々にjQueryって言葉聞いた

let $ = document.queryselector;とかこの業界まだやってんの？

>>388
いらんでしょw
javascriptで書けませーんwとか言いそうw

Intへの変換とDecimalへの変換とStringへの変換のメソッドつくっときゃ一緒やで

まだこんなレベルなんだな、安心したわ

このスレのレベルが低いだけだよ

一体いつjQueryの利用が減少に転じるんだろうね
まだjQueryの利用者は増え続けてるからね
現在78.3%、このペースだと2年後に80%超えても不思議じゃないな
https://w3techs.com/technologies/history_overview/javascript_library/all/y

レベルが低い奴がいたっていい。山が高くなるには裾野が広くなくちゃいけないからな。
それにレベルが低くたってC#おじさんとjQueryおじさん、あるいはフロント見下しおじさんがスレ違いの事ばかり言ってるのに比べれば100倍生産的なんだなw

>>383
KENYAの匂いがするよな

>>388
一般的に秘密ロジックとはセキュリティロジックやビジネスロジックのうち公開したくないもののことだね
それをフロントエンドに持って来ると難読化でもバイナリ化でも解読されうるからサーバーサイドに持つという話かと
だから全てをフロントエンドに持ってくることはなくサーバーサイドに少なくとも秘密ロジック部分が残るという話の流れと理解

今さら理解したのか

サーバーにあるべきロジックが
いくらSPAになったとしても
クライアントにもってこれるわけねーーだろ！
ってはなし

それ教えてあげてもフロントエンド開発を見下してるとか言い出すしな
訳がわからない

オープンソース隆盛の時代に、秘密ロジックおじさんの長文ってなんで言い訳に聞こえるんだろ（笑

いやそれはそれで意味が違うゾ

フロントエンドは「データ取ってきて表示する」ぐらいにしとかないと破綻するよ
何でも出来るから何でもして良いってわけじゃない

リスクとパフォーマンスを天秤にかけて個別に判断するだけ
SPAがどうとかぶっちゃけ関係ない

またそんな適当なことを

いまエンジニア転職市場ではまともな開発ができるSPAフロントエンドエンジニアが求められている
なぜならどの業界もエンジニアが欲しくてたまらないから
しかしフロントエンドエンジニアは圧倒的に少ない

安売りするなよ

お前が安いだけだろ

日本のゴミのようなシステムのフロントに変革をもたらすんだ

reactはhooksのおかげで価値が数倍になったな
よくjavascriptにこんな機能乗せたもんだ

>>411
あんたエンジニアじゃないじゃん

>>415
じゃあ俺はなんなんだよ

簡単なもの作るなら、jQueryが楽だと思います

無い無い。ちょっとでも複雑なもの作るならReactの方が断然楽だし、ドシンプルなもの作るならバニラJSの方が良い。
jQueryは環境に付属してる場合以外、積極的に採用する理由はない。

jQueryの話は荒れそうだしやめようよ

>>419
バニラJSを使うことってあるんですか？

そのバニラJS vs jQueryで比較しましょう

Reactがダメな所はバニラJSと組み合わせられないところなんだよな

ReactはJSの上に構成されているので組み合わせれるも何もないよ。それとややレアケースではあるけど（仮想ではない）生DOMとも組み合わせられるよ。特殊なイベントを扱いたい時にcurrentTarget経由で使ったりとかね。

バニラJSが何なのか分かってないっぽいな

バーニラ、バニラバーニラ

>>415-415
youtuber ですねわかります

バニラJSを使うような人は、jQueryを使ったほうがいいだろうな
開発しやすさが段違い

（10年前なら）そうだよ

このスレあかんw

>>420
別のスレでやってくれ

>>394
let $ = document.querySelectorAll;だろ、、常考

秘密鍵もフロントエンドに乗せてそう

バニラJDとかなんかときめくよな

日本はreactとvueの分断が酷いね
またガラパゴス化してしまうのか

日本だとvueが人気って嘘だと思うんだよな
日本のツイッターの言及数でもreactの方が2、3倍多い

https://trends.google.co.jp/trends/explore?q=%2Fg%2F11c0vmgx5d,%2Fm%2F012l1vxv,%2Fm%2F0j45p7w

>>435
それは二年以上まえの話
既に逆転してるから

世界で比較するとvueが結構reactに迫ってるんだな
あくまでgoogle trendでの比較だけど
USでも倍か。もっと差があると思ってたわ
Angularはまあ、安定してるw

Vue良いぞ。Reactも良いけど、フォームアプリとなるとつい俺はVue選ぶ。
あと、jQueryで良いような小さいツールでもDOMいじりしたくなくて、コンパイルせずにVue使ったもできるのかVueの強み。

>>436
日本でReactとVueが絶賛競い中だな。2020年末ぐらいからは若干Reactの方が多いし増加傾向に見える。
中国といえばVueというイメージあったけど55%か、意外と少ない。

>>438
USだと4～5倍差に見えるんだけど、俺は見方を間違えてる？

未だにvue押してる老害がいるから日本はガラパゴスって言われるんだよな

react一強ですな

日本のエンジニア求人も一年前からreactに傾いてます

日本のWebフロントエンドはまだガラパゴスにすらなって無い

vue.js 日本ユーザーグループが、3千人だろ

YouTube で有名な、雑食系エンジニア・KENTA の、
転職用Ruby on Rails サロンは、月千円と有料だけど、3千人

単に、1人の有料サロンと同数w

鷲とカモが同数いたから何だって？

そもそも日本のバックエンド人口とフロントエンド人口が圧倒的な差がある
ガチフロントはバックエンド100に対して1すらない

でも、最近のKENTA のサロンの、
Ruby on Rails 初心者用コースには、フロントエンドも入っている

Rails, Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース

今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, Vue.js, React, TypeScript も入っている

だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
今では、1年の未経験者が、10年以上のプロよりも技術力が上になってる！

はいはいカモ乙

>>447
フロントしかいじれない人とか需要ないよ
よくいるワードプレス屋さんみたいな人だろ？

Preact使ってる人はどれくらいいるのかな？
Reactの大半の機能が使えて十数KBくらいのフットプリントで済むから気に入ってるけど

以前遊びで使ってみてこれでいいじゃん！ってなったけど外部ライブラリの対応で死んだ

>>450
お前がバカだから知らんのだろう
このスレでwordpress屋とかほざいて脳みそ大丈夫か？

>>452
preact/compatでは駄目だった？

>>454
普通のjsライブラリはそれで良いんだけどReact系のライブラリだと型が合わなくなるでしょ
その対応がめんどくさくてreactで良いやーって
今は楽に行けるのかもしれんけど

>>424
高収入

asp.netのわい、高みの見物

>>455
preact/compatはReact依存ライブラリ用だぜ

ややスレ違いなんだけど、みんなクラウドでREST生やすときは何使ってる？
LambdaとDinamoDBとか？

>>458
いやapiは互換だけど型はそれぞれ違うじゃない？

>>460
う～ん、TypeScriptで使ってるけど特に問題なかったけどな。昔はそういうのがあった、とか、ライブラリによっては影響が出るのかな

>>461
2、3年前の話だしね
軽くて最高だーとノリノリでいつくかのライブラリの定義して力尽きた
今は型定義整ってきてるとは思うけどね
追ってないから分からないけど

>>459
ぼくはCloud Functions！
でもクラウドよりVPS派！

Vueの方が直感的だしこれを理解出来ないなら今すぐ引退したほうが良い
reactはjsxがキモい

Javascriptのくせにコンパイルとか勘違いしてるよな正直

>>463
正直俺もVPS(Linux)の方が慣れてて楽なんだよね。
クラウドだと可用性でメリットあるかなとか思って使い始めたけど、止まる時は何使ったって止まるわけで、スケールさせる事とか考えなきゃVPSで十分かな……

そのスケールさせるのがVPSだと一番大変なわけで・・・
VPSでスケールできたらいいのに

>>465
2000年代に基本情報とか勉強して世代ならジェネレートじゃんって思うよね

オーケストレーション前提でまずはスケールアップできるVPSで良いんじゃない？

VPS複数台でK8s環境組めばええんでね？

あまり詳しくないけども。
K8s使うまでもなくnginxをロードバランサに使えばロジックはスケールしない？
スケール面での問題はDBだと追うんだけど

あとスケール前提で組もうとするとスモールスタートにならないという問題もあるな
その点googleとかならヒットしなかったら無料でいける

GCPとかAWSって見積り予測しにくいから嫌い

>>472
前半すげえわかる

おまいらインフラまで担当してるの？
その辺はインフラエンジニア任せだ

GCPやAWSは基本的にインフラをGoogleやAmazonが提供していて
アプリケーションエンジニアはそのインフラを使うものだよ
GCPやAWSを知らずしてクラウドアプリは開発できない

>>475
趣味とか勉強でバックエンド欲しいときあってインフラもやるやん？
そゆことやってると多少詳しくなる

>>477
開発環境くらいは構築出来るけど
本番やそれに関するjenkins等の設定は完全にノータッチだな

本番でJenkinsなんて今でも使われてるの？
Jenkinsの開発者は今はTerraform作って業界標準くらいヒットしてるけどビジネス展開してるだけあってTerraformは24hサポートとかも付けられる
対してJenkinsはもう放置状態でもともとサポート付けたビジネスも展開してないでしょ？
トラブル時不安じゃないの？

>>479
素人さんかな？あちこちの現場いけばわかるよ

なるほど派遣で回ってる現場ね
そりゃ環境古臭そう
秀丸でコーディングしてそう笑

てらふぉーむと比較ｗｗｗ

>>481
独立して法人成りしたコンサルだよ
現場に席もらっても常駐はしない
日中は外出多いし
そもそも請負だから

ぶっちゃけ自分で環境構築できないような奴にはフロントフレームワークとか使いこなせんやろ

>>296
なんて言ってたけど、最近Rustでバックエンド書いてみてわかった。ちょっと面倒くさいしとっつきにくいとこあるけど、意外と生産性高い。
記法や思想でモダンJavaScriptに近い部分もあって、書いてて妙にしっくりくる。C#よりはるかに書いてて気持ちいい言語だわw

>>485
同感
全く似ていない言語なのに
Node.jsでの心地良さがRustでさらに心地良く感じてRustを気に入ってしまった

どっちも関数型言語の考え方を取り入れているから似ていると感じるのは自然な気が

Javascript知らないしコールバック見ると吐き気がするんですが異動で来年度からフロントやらされることになりました…
まだ何使うか決まってないから取り敢えずなんかフレームワーク勉強しとけって言われたんですが、、vueとReactってどっちが勉強のコスト低いですか？
PythonとC++ならやったことあります

0からやるならangularがいいと思う

javascript知らないならまず生を勉強しないとreactとかおまじないだらけに見えるぞ

angulerなんか使われていないからやめとけ

>>488
たぶん挫折する
javascriptもバックエンドからみたらなんじゃこれ？みたいになる
コールバック地獄はもうないけど

Reactも初めてみたらワケわからんだろうしコンポーネント思考でデータストリームで何度もレンダリングされるとか、コンポーネント増えたらバケツリレーどうすんのとか
何よりバックエンドエンジニアが最も苦手なhtmlとcssがjsxとstyle Componentとかでjavascriptの中に入ってくる
cssできなかったらデザイナーと共同作業になる

>>488
まずここで現代のJavaScriptを学べ。
https://jsprimer.net/
とりあえずの生産性を求めるなら古いJSを知る必要はない、混乱の元になるだけ。
モダンな言語使ってれば高階関数は使ってるだろうし、現代のJSならコールバック地獄になることは（余程設計が不味くない限り）無いから安心するといいよ。

あ、C++使えるのか、それならJSは簡単に感じると思うよ。

>>488
コールバックってクロージャだぞ
クロージャを見ると吐き気がするプログラマーなのか
クロージャの理解ができない？

>>494
そういう事言ってるんじゃ無いと思われ

Nuxtをずーっと今まで「ぬくすと」って読んでましたごめんなちゃい

>>495
じゃあ何？
大昔からC言語ですら関数のポインタ渡しは普通に行われてきたし
吐き気がする意味がわからない

コンポーネントと再レンダリングとjsxとcssとかもろもろキモいだろ
こんな言語とフレームワークは他にはない

そのへんは単に思想の違いだから。
安い挑発には乗らないよ

コールバックで吐き気って、関数を関数に渡すのが意味わからんとかってことじゃね？
そのレベルだとフロントかなりきつい気がするけど

高階関数や関数型プログラミングが嫌いな人たまにいるけど
狭い世界でしかやっていけないプログラマーだね

一昔前のコールバック地獄知ってるんでしょ
あんなスパゲティコードみたら誰でも吐き気するって
他人の書いたそんなコードとか読みたくも無いわ
あ、お前ら一人で書いてるんだったね
ならお好きに

はいはい安い挑発乙

はいはい安い挑発乙

>>502
コールバックとコールバック地獄は全く別の話
一方でJavaScriptは継続渡しプログラミングとしてもコールバックを多用してきたがそこには非同期プログラミングも許容する柔軟性こそJavaScriptの強みの一つ
もちろん同期プログラミングしかできない人はasync/awaitのみによる限定的な使い方に徹するしかない
例えばその元となる非同期にresolveやrejectをするPromiseを返す関数などを自分で作れないだろうから

JSに慣れてくると非同期前提の設計って結構便利だなと感じ始めるよね

そりゃどの言語でも一緒

UIつくる以上非同期からは逃げられない

>>505
電車とか好きそう

>>505
そういうのは例えば『XMLHttpRequestとPromiseとJSONのマニュアル見ていいからそれらを使ってURLを与えるとJSONオブジェクトを返すasync関数を作りなさい』
とか課題を与えるとまともなJavaScriptプログラマーか駄目プログラマーかすぐに判別できる

>>510
XMLHttpRequestはもう随分使ってなくて細かいとこ忘れちゃったな。
とりあえず200以外はエラーで良いですか？ って試験出した人に聞いちゃう

AJAX派なんですけど・・・

>>511
そこはマニュアルを見ていいから大丈夫
あと題材としてはXMLHttpRequestでなくてもよくて
コールバックする関数からPromiseを返す関数を複雑な場合でも作れるプログラマーか
それともそれを使ってawaitするだけのプログラマーか
その違いがわかればOK

>>513
なるほど。
setTimeoutを使って早期終了もできるasync sleep関数を作れ、とかいう課題でも面白いかもね

皆さん色々とありがとうございます
取り敢えず>>492さんのサイトで学習から始めてみようと思います


Javascriptがあまり受け付けないのは引数の中に関数をそのままぶち込むっていう
今までやってきた常識とは異なるコードを割とよく見るので…
理屈が分かれば簡単なんだろうとは思いますが前提知識無しでちょっとデバッグしようかなレベルの時にこういうの見るとちょっと辛いですね

https://pastebin.com/pgmkMw1Q

>>515
JavaScript以外でもモダンな言語なら（無名）関数を引数にするのは日常茶飯事だよ。慣れた方が良いかも。
頑張ってね。

何故にnode？

pythonなんて変数がすべてオブジェクト型だぞ

間違った
数値や文字列などすべてがオブジェクト型

>>511
それよりもJSON.parseでエラー出た時にPromiseをrejectするのを忘れずにｗ

>>515
今どき関数型プログラミングをしたことないとは化石のような方で驚く
関数に関数を渡すのを覚えるとプログラミングが捗りますよ
あとイテレーターを使ったり作ったり慣れるとよいでしょう

Rustいじってるけど良いねこれ
継承が無いってのが凄く良い

>>521
あんまり言うとスレ違いになっちゃうけど。
implがオブジェクトの実装に寄り添ってたり、return無しで値が返せたり、ifとmatchが式だったり、デフォルトでimmutableだったり、エラー処理やOption周りのワンライナーっぷりだったり、所有権周りの合理性だったり、コンパイル時の親切さだったり、ほんとにモダンだし、洗練された言語設計哲学を感じるし、書いてるとな～んて美しい言語なんだろうって惚れ惚れする。
まぁJavaScript|TypeScriptも大好きなんだけどねw

JSフレームワークもぐぐること多いんだけど
技術系記事の日付はこれでもかっていうくらいに目立たせてほしくなるな
いつの記事かによって見る見ないがガラリと変わる

んな事するならドキュメント読んだ方がはやいって

間違ってる記事多いもんな
せめてドキュメント読んでから書けよって突っ込みたくなる

JSは母数が多いからねえ

最近はもう誤用のほうも辞書に載り始めてるとは言え、
そもそも統計学を翻訳するときに成立した造語だからな母数って
統計用語としてのparametersの訳だよ
それさぁ…「分母」じゃダメなの？
もし統計用語としての「母数」を意図してます、と言うなら「JSは母数が多い」は文意が通らないよ
まぁ分母なんだろうけど
どうして小学校で習う分母ではなく母数を使いたがるのだろう？
少しでも頭良く見せたいとか？
逆効果だと思うが

>>527
それは本末転倒で
parameterの訳語を母数したところからおかしい
parameterは特性とかでいいだろ
一方で母数は誰もが母集団の数や分母の数と認識するのは当たり前

>>528
悪訳語であるとは俺も思うがそれとこれとは話がdifferent

>>529
明らかに『母集団や分母の数として母数』が使われている状況で
わざわざ『馬鹿げた訳語である母数』を持ち出す人がバカだと言ってるだけです

>>530
馬鹿げた訳語をわざわざ使ったのはなぜ？
分母ではダメだった？
なぜ小学校で習う分母ではなく、「馬鹿げた訳語」である母数を、その訳語の創出の意図と違った誤用である分母の意味でわざわざ使ったの？
頭良く見られたかったの？
バカなのにｗ

>>531
は？
俺は使ってないぞ

悪法も法なりではないが、統計学を日本に導入する際に創出され、それ以降差し替えられず、現在でも統計用語としてのParametersの唯一の訳語なわけよ
それを小学校で習う分母の代わりごときに流用する必要なんてないわけ
そもそも小学校で習う単語である分母で誤解の余地なく正確に言い表せるものをなんで本来その意味を持っていない母数で言い表したがるわけ？
特にプログラミングなんてどんなに気に入らなかろうが利用する言語・APIの仕様に沿ってコーディングしなきゃ動かんのに、
オレオレ解釈で書いておいて、本末転倒だ！仕様がおかしい！馬鹿げている！俺の思った通りにコンピュータは理解するべきだ！
と言っているようなもの

>>533
それ誤用だよで済ませとけばいいのに。
それを人を馬鹿にしたみたいに「頭良く見せたいの？」とかつけるからいらぬ論争になるんでしょ。
多分使った本人は誤用である認識すらないでしょ。そうやって誤用が広まって行くんだし。

まぁ煽り合いが文化なら違う場所でやってよ

>>534
それが母数警察だ
どうだ怖いか？ｗ

>>535
超怖い。俺も母数を誤用してた口だからまじかってなったわ。明日から会社でマウント取りいくわ

誤用ではありません
複数の意味があるだけです
そして片方がパラメーターを母数と失敗誤訳してしまったというだけにすぎない
全ての常識人に母数は全体の数の意味で通じます

良く考えてみなよｗ
少なくとも統計の文脈では母数は全体の数には使えないじゃんｗ
そして母数は一義的には統計のためにひねくり出された言葉でしょ
分母の意味が後づけなんだよ。
偉い人が勘違いしてムキーっ！俺の意味も正しいの！って言って辞書に分母の意味足したんだろうなｗ

な、何のスレだっけ？

>>538
言葉には正しい形も定義もなくその形も意味も用法も時間とともに常に変化してきたナマモノ
そして多義性こそ最も盛んに行われてきたものだから何かに一つにこだわっちゃダメ
一番重要なことはその時代に通じてきたかどうか
現代のほとんどの日本人は母数を全体の意味で用いて通じるからOK
少なくとも誤用ではないですね

まあ、ら抜き言葉の酷い版みたいなものだからねｗ