Railsフロントエンド技術の今とこれから
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
Rails の フロントエンド周りの未来予測 - ボクココ
ども、@kimihom です。 Rails の Sprockets や Uglifier などが最新の JavaScript に追従していないという理由で、Rails 標準のやり方から外れて最新のフロントエンドツールを追い求める系の報告が多い。一部では完全に Rails の Asset Pipeline から外れて、Gulp などに移行する話もよく聞く。確かに現行の Rails のフロントエンド環境で開発すると、let や クラス構文をまともに使えない(エラーになる)ため、最新の構文に対応した JavaScript フレームワークはほとんど使えないのは大きな問題として残り続けている。 最新版である Rails 5.1 から、ようやく jQuery からの脱却とフロントエンド周りの最新化、つまり Yarn や Webpack の導入が検討され始めている。これに期待されている方も多いのではない
さよなら CoffeeScript - mizchi's blog
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
フロントエンドが嫌い
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。 browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。 そしてその全てが死んだ。 Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。 一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。 そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。 最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれた
JavaScriptにフレームワークが必要な理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? JavaScriptにはむしろもっと抽象化がもたらされるべき - Qiitaという記事で、もう少し踏み込んだ話を書いてみました。 某所でReact.js界隈の人に聞きたいというフレームが発生したのだが、はてなブックマークでコメントしたらIDコールされたので、反論をここに書くことにした。(最近は技術系記事はQiitaにしか書いてないので)。 あくまで僕が考えるなので、JavaScript界の人達が本当はどう思っているかはわからない。そもそもJavaScriptを本格的にさわり始めたのごく最近なので、JavaScript界では異端かもしれな
jQueryプラグイン「pjax」でスムーズにページ遷移するサイトの作り方 | Neganin(ネガニン)
「pjax」とは「Ajax」と「pushState」を組み合わせたもので、非同期通信をしながらURLを変更することができる「jQueryプラグイン」です。 各ページの差分だけ読み込み、描画するので、転送量削減ができ時間短縮を図れますし、ページ遷移時のエフェクトも追加できたり、カスタマイズ性に優れています。検索エンジンからのマイナス点もない非常に優秀なプラグインです。 「Ajax」と「pushState」が何なのかというと・・・ Ajax ページを遷移せずにサーバーからデータだけを非同期でとり、サイトに描画する仕組みのことで、「Google Maps」などに使用されています。 pushState 「HTML5」で導入されたURL操作のAPIで「Ajax」を使用して非同期なサイトを作る時などにアドレスが変更されない問題を解消してくれます。 1. デモ 前置きが長くなりましたが、実際に「pjax
Rails 4のturbolinksについて最低でも知っておきたい事
Rails 4のturbolinksについて最低でも知っておきたい事 （追記）turbolinksに関するセキュリティ上の懸念について turbolinksとは、ページ遷移をAjaxに置き換え、JavaScriptやCSSのパースを省略することで高速化するgemで、Rails 4からはデフォルトで使用されるようになります。 高速化は大歓迎なのですが、JavaScriptのイベントの起き方が変わるため、Rails 3までの書き方をしているとまず間違いなく問題が起きます。しかも、Rails 4ではデフォルトの機能ですので、最新版を使いたいなら必ず知っておかなければいけません。 本エントリではturbolinksを使うために絶対に知らなければいけないことを分かりやすく紹介したいと思います。 動作 turbolinksの動作は、すごく大雑把に言うと以下の通りです。 リンクのclickイベントをフッ
Rails上でのpjaxについて調べたのでメモ [俺の備忘録]
Google+ボタン はてなブックマークボタン 更新日時: 2013年04月03日（水） 作成日時: 2013年02月17日（日） 前の記事 / 次の記事 目次 調べた時のRailsのバージョン: 3.2.11 pjaxとは何か 何がいいのか Railsで動かすには？ やったこと 追記:2013/02/26 追記:2013/04/03 参考ページ 1.pjaxとは何か jQueryプラグインの名前。 pjaxが便利過ぎて鼻血出そうになった（railsのサンプル付き）が分かりやすかった。 何が出来るのかというと、ajaxのようにページ全体のリロードをすることなく、 部分的にビューを差し替えることが出来る。 ajaxに名前がクリソツだけどajax同列の何かではなくて あくまでプラグインの名前っていうのが混乱の元な気がした。 2.何がいいのか じゃあajaxでいいじゃん！！ って話になっちゃうの
pjaxできれいなURL＋非同期画面遷移！ | ヘッドウォータースのブログ TechNote
こんにちは。荒井です。 Facebookもtwitterもgoogleも画面遷移のときには、非同期で次のページを読み込むような作りになってますね！ これは、ajaxで次のページを読み込むのと同時に「History API」というHTML5の機能を使って、URLを更新することで実現してます。 毎回全部読み直さないから通常の画面遷移よりも早いし、URLが変わるから履歴に残るし、良いことばっかり！！SEO的にも「#!」を使ったやつより良いよっていうのを何かで読みました！！！ これからWebサービスを作るなら、導入したいですね！！！ これpjaxを使えば簡単に導入できるんです！！！よし！！！ PJAX!! pjaxとは、GithubのChris Wanstrathって人が作ってるjqueryプラグインです。 上で説明した、History APIとajaxを使った非同期の画面遷移を簡単に導入すること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
