Installation ¶ Pug is available via npm: $ npm install pug Overview ¶ The general rendering process of Pug is simple. pug.compile() will compile the Pug source code into a JavaScript function that takes a data object (called “locals”) as an argument. Call that resultant function with your data, and voilà!, it will return a string of HTML rendered with your data. The compiled function can be re-use
最近の日本のフロントエンド界隈では「Native ESM時代」という言葉が聞こえてきます。Native ESM時代におけるビルドツールがどうなるかといったことが主な話題です。 個人的には面白い概念なので流行ってほしいと思い、Native ESM時代とは何かを解説する基礎的な資料を用意しました。 そもそもNative ESMとは Native ESMとは、ES Modulesのことです。つまり、ECMAScript仕様の一部として定義されたモジュールシステムを指します。現在、モダンな部類のフロントエンド開発において広く用いられている、import宣言でインポートしexport宣言でエクスポートするのがES Modulesです。 特に、ES Modulesはブラウザによって直接理解されるモジュールシステムです。Nativeという単語はこのことを強調しています。 Native ESM時代とは N
この記事は、ウェブ技術の開発者（Java, PHP, Ruby, Go... 全て含む）のうち、少しでもJavaScriptを触ったことがあるけど、現代ウェブフロントエンドというか、特にウェブアプリケーション —— React, Vue, Angular など—— が分からない人に向けて、たったひとつの理解方法を提示するものです。 追記: ちなみに果てしなくどうでもいいですが、今回の記事が記念すべき100記事目らしいです。（Noteさん！その手のヤツはいっそ自動で記事にバッヂを表示するとかしてくれるとうれしいです！） 対象読者は、Java, PH(以下略）などのコードと一緒に、ほんの少しでもJSのコードを触った、見たことがあるというレベル感の人なので、既にReact, Vue, Angular などでガリガリコードを書いている人は対象ではありません。 あとホームページ屋さんとかウェブコーダ
キャッシュは、CPUのバスやネットワークなど様々な情報伝達経路において、ある領域から他の領域へ情報を転送する際、その転送遅延を極力隠蔽し転送効率を向上するために考案された記憶階層の実現手段である。(引用: フリー百科事典『ウィキペディア（Wikipedia）』) こんにちは、@kaa_a_zu です。私たちエンジニアは、「キャッシュ」というワードをよく口にしています。それはインフラの設計をしている時かもしれないし、表示されるコンテンツが変わらない時かもしれないし、パフォーマンスの改善をしている時かもしれません。普段何気なく使っている「キャッシュ」とは一体何なのでしょうか。この記事は、そんな「(Webフロントエンドを触るエンジニアが知るべき)キャッシュ」について、どんなものがあるのかがちょっと分かったという状態になることを目的に書いています。
お知らせ（2021/05/26 追記） 以前はeslint --fixなどで ESLint を実行時に Prettier でコードを整形し、整形したコードに対して構文チェックが実行されるようにすることが推奨されていました。 ESLint で Prettier を実行するためには、ESLint の Plugin が必要でしたが、これを利用することが公式で推奨されなくなりました（詳細はこちら）。 そのため、記事を更新して Prettier と ESLint をそれぞれ実行させるような内容に変更しました（ついでに husky のバージョンも上げており、それに関する内容も更新しています）。 更新前のコードや記事は以下にありますので、必要に応じてご確認ください。 はじめに Prettier（v.2.3.0） に関しての備忘録です。 「Prettier の何が便利なのかよくわからない」 「ESLint
- はじめに - 9月くらいから趣味でフロントエンド周りをやっていたので、その勉強過程のまとめ。 何が良かった悪かったとか、こうすればよかったとか、所感とか。 - はじめに - - 前提 - - どんな感じで進めたか - 最初の開発 TypeScriptとNext.jsを使った開発 アプリ手伝いから自分のアプリ開発まで - できてないこと - - 所感 - - おわりに - - 追記 - - 前提 - 前提として9月頭くらいの私のフロントエンドに対する理解と技術的な知識はこんな感じ。 5年程前まではjQueryで謎のWebサービスや動きモリモリのプロフィールページを作ったりDjangoで研究室のWebサイトを作ったりしてた Railsチュートリアルはやったことある 仕事では普段機械学習モデル作ってるが、機械学習のデータやモデルの変更が及ぶ場合に既存のPHP、Railsアプリの改修をしたり、
フロントエンド技術は、ある時期を境に爆発的進化を遂げて、面白く・DX（開発者体験）の良い世界に発展しています。 DXはDeveloper eXperienceの略で、2017年くらいから話題になっているようです。（正しい起源はわかりませんが、雑に検索した限りは、2017年のMediumやdev.toでの英語記事がヒットします） DXに関して日本語での記事は「DX: Developer Experience （開発体験）は重要だ」を読むとわかりやすいと思います。 ウェブ技術をやっている人の中で、バックエンド側しかまだ触ってない、JavaやRuby、PHPのような言語でしかウェブに触れてない人は多く、そういった人に、今のフロントエンド情勢ってこんな感じだよ！って知ってもらいたいという思いがあり、都内の某所にある「ラボ」でモダンフロントエンドエンジニア勉強会というのをお試しで開催してみました。
HTML5 Conference 11/25
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに サーバーサイドプログラミングを勉強していると、自分でWebサービスを作りたいという気持ちがわいてくるものです（私はそうでした）。しかし、ここで大きな問題が立ちはだかります。どんなにすごい機能をつけても、いい感じのデザインのWebサービスでないとそもそも使ってもらえないのです。 試しに、QiitaのトップページのCSSを無効にしてみました。使える機能は変わらないはずなのに、全く使う気が起きなくなりますね。 しかしそうは言っても、フロントエンドの経験がほとんどないとどうすれば見た目をいい感じにできるかがわかりません。今回は、ちょっ
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
はじめまして、ほそだと申します。昨年秋まで個人事業主の立場でドワンゴでお仕事させていただいておりましたが、いろいろ経緯がありまして中の人になりました。ドワンゴ歴はそこそこ長い新入りです。よろしくお願いいたします。 さて、今回はデザイナー（HTML/CSS/JSは扱えるいわゆる「Webデザイナー」）として1年間ほどReactを使ってみたので、そのメリットを書いてみようかと思います。 Reactとの出会い ReactとはFacebook製のJSライブラリです。 https://facebook.github.io/react/ WebアプリケーションのView部分を実装します。2014年の暮れにエンジニアの方々が魂を震わせているのを見て存在を知りました。2015年はReact元年な感じでしたよね。 僕自身、以前から比較的JSを書くタイプのデザイナーではありましたが、正直なところ自分が関わってき
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
こんにちは Rails5.1に向けて、DHHのjqueryを依存から外す発言を発端にフロントエンド周りが急激に発展しているので、簡単にですがまとめてみました。 各issue, PRの詳細には踏み込みませんが、知見に溢れているので読んでみるの推奨です。 間違い、足りないものがあったら編集リクエストお願いします。 jQuery依存を無くす話が出る rails(issue): Drop jQuery as a dependency jquery-ujsはjqueryに依存しないようにする jquery-ujs: Drop jQuery as a dependency "jquery"-ujsじゃなくなったので名前変更 rails-ujs誕生 実際にRailsからjquery依存がなくなる rails: Drop jQuery as a dependency jsライブラリを入れる方法がnpmパッ
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
