Burikaigi 2023 https://burikaigi.dev/ Twitter https://twitter.com/__sakito__
![2022年に起きたフロントエンドの変化](https://cdn-ak-scissors.b.st-hatena.com/image/square/b30b65524b563bfd5476768a937844af5d42902f/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9bfda5f907f648fb9fb3b24d12cf1322%2Fslide_0.jpg%3F24166032)
Rails 7.0ではフロントエンドサポートが刷新されます。新たなライブラリが多数導入され、選択肢が増えるため、「Rails公式のものを選べばOK」という戦略が通用しなくなります。 本稿では、Railsでフロントエンドを書くための選択肢について、その歴史と実装を踏まえて比較検討します。 結論から言うと(まだアルファ版なので今後も状況が変わる可能性はありますが、) 新規アプリケーションではSprocketsの役割は無くなりそうです。新しいライブラリとして Propshaft, importmap-rails, jsbundling-rails, cssbundling-rails が登場し、主要な選択肢として以下が提供されます。 (各ライブラリの詳細については後述します) Propshaft + importmap-railsデフォルトの選択肢。Node.jsが不要。トランスパイルを含め、複
Transcript ݱϑϩϯτΤϯυʹ͔ܽͤͳ͍ XFCQBDLͱ#BCFMΛཧղ͠Α͏ʂ� CVJMEFSTDPO�UPLZP����� /BNF� ����4BLJUP�.VLBJ� 5XJUUFS ����!@@TBLJUP@@� $PNQBOZ� ����$ZCP[V�JOD� ����'SPOUFOE�&YQFSU�5FBN "CPVU�NF w#BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ� w#BCFMʹ͍ͭͯ� wXFCQBDLʹ͍ͭͯ� wXFCQBDL #BCFMͰ෦࣮Λ͍ͬͯ͘ "HFOEB #BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ &$."4DSJQUͱ5$�� w+BWB4DSJQUʹ&$."4DSJQUͱ͍͏ݴޠ༷͕͋Δ� w͜ͷݴޠ༷ΛܾΊ͍ͯΔҕһձ͕5$�� 5FDIOJDBM�$PNNJUUFF��� � w&4��
# Babel 7.4.0で非推奨になった@babel/polyfillを使わず、core-js@3で環境構築する @babel/polyfill (opens new window)のページにBabel 7.4.0から非推奨になったと書かれている。 As of Babel 7.4.0, this package has been deprecated この記事ではwebpack4でBabel7.4を使った環境構築の方法を記載する。 # 環境構築 # インストール @babel/polyfillではなくcore-jsとregenerator-runtimeをインストールしているのがポイント。 Polyfillはcore-jsにまとめられており、async-awaitを動かすにはregenerator-runtimeが別で必要になる。 そのほか、BabelやWebpackでビルドするために必
webpacker脱出を表現した絵画初めに脱webpackerアドバイザーの小宮山です。最近の趣味は相変わらずランニングですが、下の階のヌーラボさんにインスパイアされてボルダリングにも夢中になりつつあります。 フロントエンド原理主義とはサーバーサイドからフロントエンドへの干渉(特にレンダリング)を嫌う一派に私が勝手に名前を付けただけです。ただしSSRはこの限りでは無いので最近は結構曖昧になりつつあります。 動機webpack関連のアップデートがwebpacker対応待ち最大のデメリットはやはり、webpack関連のアップデートがwebpacker対応待ちになってしまうことでした。どんなにwebpack4が3から進化しているとしても、導入するにはレールとなるwebpackerが対応してくれるのを待つしかありません。 そしてwebpackerが対応してくれたら即導入なんてうまくいくはずがなく、
こんにちは、hachi8833です。 Rails 5のWebpackerでつらみを踏まないために、公式のWebpackerドキュメントの要点をまとめてみました。追加情報がありましたら今後も更新したいと思います。 rails/webpackerより 公式のドキュメントが分散しているのと、mdファイル名から内容が推測しにくくて見通しがよくないので、ファイルの並びを再編成して概要を一覧できるようにしました(せめてファイル名の頭に番号でも振ってくれれば...)。具体的な設定方法についてはリンク先をご覧ください。 ⚓概要 ドキュメントリポジトリ: rails/webpacker/tree/master/docs -- mdが16ファイルあります。本記事ではこちらのみを扱います。 上のドキュメントリポジトリの最終更新日: 2018/04/23 更新や誤りにお気づきの方は@hachi8833までお知らせ
javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし
先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、Vue、Ember、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに
Since the beginning of August — when we forked webpack/webpack#master for the next branch — we’ve seen an incredible influx of contributions! Git contribution stats for the webpack next branch at a glance using gitinspector! Try it on your project to see insights. PS: This doesn’t include the incredible work done in our webpack-cli team and webpack-contrib organization supporting our loaders and p
Lessons learned adopting the Webpacker gem in an existing Rails app In case you missed the news, Rails is loving JavaScript and Rails 5.1 ships with the option to compile JavaScript with webpack via the Webpacker gem. This is a big change after years of the Rails asset pipeline running on Sprockets. My team at LearnZillion recently decided to embrace this change and make the switch to webpack with
こんにちは。メドピアでエンジニアをしている村上(pipopotamasu · GitHub)です。 普段はRailsを触っていますが、時々フロントエンド周りの開発もしています。 今回はメドピアの環境におけるWebpacker導入とフロントエンド周りの改善をテーマに記事を書きます。 目次 なぜWebpacker(Webpack)を導入するのか? フロントエンド改善計画 Webpackerの導入で気をつけたこと github.com なぜWebpacker(Webpack)を導入するのか? Webpackerを導入する背景として、主に2つの課題がありました。 JavaScriptのビルド時間が長い パッケージのバージョン管理ができない JavaScriptのビルド時間が長い 元々メドピアのフロントエンド開発においてBrowserifyというbundlerを使用していました。 しかし、これにはビ
エンジニアの望月(@c5meru)です。 この前の日曜は、HTML5カンファレンスにボランティアスタッフとして参加してきました。 いくつか聴衆としても聴くことができてとても楽しかったのですが、ずっと立ちっぱなしだったので今すごく腰が痛いです…運動不足…(´・ω・`) さて、弊社では表題の通り、JOBLISTのCoffeeScriptのコードをES2015(ES6)に移行しました。 移行の経緯 移行前はRailsで、こんな感じのフロントエンドでした。 JSのライブラリはvender下に直接置くか、gemで管理 CoffeeScript jQueryベースの開発 そこで、より効率的で高品質なフロントエンド開発を目指すにあたって、社内で以下のような点を検討しました。 npmや、yarnを用いたパッケージ管理 CoffeeScriptからES2015(ES6)に移行 React.js、Vue.js
After we released webpack v2, we made some promises to the community. We promised that we would deliver the features you voted for. Moreover, we promised to deliver them in a faster, more stable release cycle. No more year-long betas, no breaking changes between release candidates. We promised to do you right by you, the community that makes webpack thrive. The webpack team is proud to announce th
こんにちは。マーケティングプロダクト開発部の長田です。 この記事では、私が現在進めているプロジェクトで、Webpackerを使ったJavaScriptのモジュール管理を導入したので、それについて紹介したいと思います。 Webpackerとは Webpackerとは、Webpackを用いてRails上でJavaScript開発をするために必要な一連の流れを提供してくれる、Rails organizationで開発されているgemです。 これまで、Rails上でJavaScriptのパッケージをどのように管理するか、また、モジュール依存をどのように解決するかについて、多くの選択肢があり、それらをどう組み合わせて使うのかについて悩まされてきました。 このブログでも過去に何度か記事が投稿されており、その中でも複数の選択肢が上げられています。 webpackを使った Rails上でのReact開発
Ruby on Rails の 5.1.0.beta1がリリースされましたね! weblog.rubyonrails.org 仕事でRailsを使うものとしてちゃんと触っておかねばと思い、まずは自分の好きなJavaScript周りがどれぐらい良くなったのか見てみたところかなりびっくりしました。JavaScriptすごく開発しやすいです。 webpack があって yarn がありますし、ReactやVue、angular まで rake タスクでセットアップできます。ちょっと前までRailsでJavaScriptやるのが辛いなんて言っていたのが嘘みたいです・・・。 今回はRails 5.1.0 で Vue.js を使って新しくプロジェクトを作るところまでやってみました。 rails new rails webpacker:install:vue Webpackでのビルド Hot Modul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く