並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1881件

新着順 人気順

webpackの検索結果1 - 40 件 / 1881件

  • 10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。 - 日々、とんは語る。

    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

      10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。 - 日々、とんは語る。
    • TypeScript入門以前ガイド - mizchi's blog

      某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty

        TypeScript入門以前ガイド - mizchi's blog
      • すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita

        はじめに さいきんのWebはSPA技術を中心としたフロントエンドが賑わっていますね💪 従来サーバーサイドを扱っていた人もフロントを触る機会が増えていたり、これからプログラミングを学んでいく人も、フロントエンド領域に興味を持っているのではと思います。 そこで、フロントエンドの経験が浅い方や初学者向けに、おすすめのドキュメントや勉強すべき領域をまとめました。 とりあえず動けば良い段階から一歩進んで、フロントエンドエンジニアとして、良いアプリケーションを作るために必要な知識を浅く広く紹介します。 ※補足 新米と表記しましたが、実際には新卒や未経験でなく、新卒2~3年目の若手フロントエンドエンジニアやフロント分野に苦手意識のあるバックエンドエンジニアの方を対象としています。 数日で目を通せるような内容ではないため、マイルストーンやスキルセットの一つの参考にして頂けると幸いです。 フロントエンド入

          すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
        • 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。

          先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ

            日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。
          • Modern JavaScript概観、そしてElectronへ | さにあらず

            この一か月分の学習成果を整理したリポジトリを作ったので、その成果についてまとめておく。 作ったサンプルプロジェクトだけを手軽に欲しければ、このリポジトリを clone してほしい。 taichi/js-boilerplatemaster ブランチには、ミニマムな JavaScript 開発環境がサンプルコード付きで入っているfrontend ブランチには、React/Redux/webpackなウェブアプリケーション用の開発環境が入っているデフォルトブランチにしてある electron ブランチには、frontend ブランチの内容に加えてElectronでアプリケーションを開発するための環境が入っているはじめに#最近の JavaScript について#僕は仕事として JavaScript を書いている訳ではないけども、この半年くらいの間にちょっとしたツールならいくつか作った。どちらも便利

              Modern JavaScript概観、そしてElectronへ | さにあらず
            • トップデベロッパーになるために作成したいアプリ8選 - Qiita

              こちらの記事は、Indrek Lasn 氏により2017年 12月に公開された『 The Secret to Being a Top Developer Is Building Things! Here’s a List of Fun Apps to Build! 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 著者Twitter https://twitter.com/lasnindrek 少し考えてみてください。あなたがもし健康に関する書籍をたくさん読んだとしても健康になることはありません。実際には、ジムに行き数時間運動をして汗をかかなければ健康は手に入りません。 同じことが開発にも言えます。努力なしに優れたデベロッパーになることはできないのです。 そこで、コーディング力を鍛える8つの素晴らしいプロジェクトを紹介します。 あなたの好きなテクノロジースタックを使っ

                トップデベロッパーになるために作成したいアプリ8選 - Qiita
              • 春からはじめるモダンJavaScript / ES2015 - Qiita

                春ですね!人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ

                  春からはじめるモダンJavaScript / ES2015 - Qiita
                • レトロエンジニアのための近代Webフロントエンド事情 - Qiita

                  フロントエンド開発という言葉があちらこちらから聞こえてくる。 「反対語はバックエンド開発だから、サーバとかCUIじゃない、アプリとかGUIあたりのことを指す広い意味の言葉だよね。」 ・・・とか思ってたらとんでもない。 世の中ではJavaScript界隈を限定している風な使われ方をしている。 私のような C/C++ メインのレトロエンジニアは肩身が狭くなるばかりである。 本文は、近年のWeb技術に追いつこうと調査した結果のメモ書きである。 n番煎じの内容だが、Web業界にいない人間の視点 なので、私と同類のレトロエンジニア等、一部の人には新しい気付きが与えられるかもしれない。 詳しい人の添削・ツッコミは大歓迎。 詳細はリンク先に任せ、私が思う「わかりやすい順序」で、調べたことをざっと紹介していく。 きっかけ 読み飛ばしてもよい。 Reactを使うとなぜjQueryが要らなくなるのか 数年前、

                    レトロエンジニアのための近代Webフロントエンド事情 - Qiita
                  • 2019年前半の「JavaScriptをちゃんとやるための地図」(追記あり)|TechRacho by BPS株式会社

                    こんにちは、hachi8833です。BPS社内勉強会の発表を元に、社内JavaScript勢の皆さまのお力を得て記事を書きました。 目的 JavaScriptをたまにしか使わない私ですが、それもあってなおさら書くときに迷いに迷います。 ネットの情報多すぎ、動き激しすぎ、選り分けるにしても指針が欲しい 古いコードや毒入りコードを拾って食あたりや、泥舟に乗って沈没するのを少しでも避けたい 最初の一歩をどこから踏み出すかの手がかりが欲しい そういったわけで、2019年前半と区切って、一度JavaScript世界について門外漢ならではの「大きな絵」が欲しかったのでした。ここに書いたことの中には来年には古くなっているものあるかもしれません。 ただ、社内のJS勢の話を総合すると、JavaScript世界は数年前に比べるとかなり落ち着きつつあるとのことです。この機会にということで、主に自分のために現在の

                      2019年前半の「JavaScriptをちゃんとやるための地図」(追記あり)|TechRacho by BPS株式会社
                    • 勉強するとこんな人になりますよ - megamouthの葬列

                      axia.co.jp どこかのエントリで呼ばれた気がした。 必要もないのに他人のエントリに乗っかるのは好きではないのだが、たまにはブログっぽいことを書かないと、と思ったので、軽く書く。 ある勉強したプログラマの末路 まず自分の話をしたい。 私は趣味で多数の求人サイトに登録している。 転職エージェントはうるさいので使っていない。 サイトに登録して、経験言語と年数にチェックを入れ、職務経歴書をサニタイズして(なんとこの用語は顧客を特定できないように「無毒化する」という意味で一般的に使われ始めている)掲載しているぐらいである。 ちなみにpaizaでもSランクを持っている。自慢にもならないし、求職活動に役立つわけでもないが、持っている。 こうして、現年収を正直に「200万」と書いておくと、スカウトメールがけっこうやって来るので、それらを暇つぶしに眺めるのである。 Webで年収400万超えるとこって

                        勉強するとこんな人になりますよ - megamouthの葬列
                      • ゼロから始めるJavaScript生活 - Qiita

                        (訳者注: これは、JavaScript Stack from Scratchを翻訳し、まとめて読めるように1ファイルにしたものです。元の翻訳と各種ファイルについては、日本語訳forkリポジトリを参照してください。また、原文が活発に更新されているため、訳文も追従して更新されます。ご了承ください。) モダンJavaScriptスタックチュートリアル、ゼロから始めるJavaScript生活へようこそ。 ⚠️️ このチュートリアルのメジャーアップデート版を3月初旬に公開する予定です。ご期待下さい! より詳しく(英語). これはJavaScriptスタックを使い始めるための最短最速のガイドです。このガイドは一般的なプログラミングの知識とJavaScriptの基礎を前提としています。これら全てのツールを一緒につなぎ合わせることにフォーカスしており、各ツールについて可能な限りシンプルな例を提供します。

                          ゼロから始めるJavaScript生活 - Qiita
                        • 20 年代のフロントエンド.md

                          Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. 明日の下書き これはなに 高円寺.dev #3 用の資料 https://koenji.connpass.com/event/160886/ フロントエンド専門じゃない人向けの、フロントエンドの最先端〜やや未来の話です このレイヤーでは Node.js を使うべき/使うと強いという部分がありますが、他言語を否定しているわけではありません。むしろ他言語でこのアーキテクチャを模倣してほしいという話です。 10 年代のフロントエンドのポストモーテム 10 年代まとめ IE が死ななかったので各種ポリフィル、メタ言語からのトランスパイルが発達。しかしモダンとレガシーの乖離が深刻に。 node と npm エコシステムの成立

                            20 年代のフロントエンド.md
                          • フロントエンドが嫌い

                            ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。 browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。 そしてその全てが死んだ。 Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。 一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。 そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。 最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれた

                              フロントエンドが嫌い
                            • 新人にドヤ顔で説明できるか、今風フロントエンド開発ハンズオン(git/node.js/ES6/webpack4/babel7) - Qiita

                              新人にドヤ顔で説明できるか、今風フロントエンド開発ハンズオン(Git/Node.js/ES6/webpack4/Babel7)JavaScriptNode.jses6webpackbabel 概要 今風の手法でJavaScriptアプリを作ろうとすると色々ツールがあって便利な反面、複雑でわからないことがたくさんあります。 わからないことがあったら、それを放置せず、しっかり理解して大いに寄り道しつつブラウザで動作するJavaScriptアプリをゼロから作っていきます ブラウザ上で動作するフロントエンドアプリを作ったら、ライブラリ化してnpmモジュールとして公開します 対象読者=今風のJavaScript開発の入門者、初心者 11年前からタイムトラベルしてきたひと ブラウザ用アプリを作りたいが今風の手法の初心者(jQueryだけでなんとか生きてきた人とか) Node.jsの環境をつかってフロン

                                新人にドヤ顔で説明できるか、今風フロントエンド開発ハンズオン(git/node.js/ES6/webpack4/babel7) - Qiita
                              • JavaScriptフレームワーク選定の議論 - Qiita

                                相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良

                                  JavaScriptフレームワーク選定の議論 - Qiita
                                • 2016年、サーバーサイドエンジニアがゼロからReact/Reduxを学習したときの方法を振り返る

                                  こんにちは。スタジオ・アルカナのサーバーサイドエンジニアなっちゃん(@natsumican63)です。 この記事はReact Advent Calendar 2016の13日目の記事です。 それは2016年も後半へ差し掛かったある日のことでした… 上司「次の案件、この辺の技術使うから軽く勉強しておいてー」 つ React.js + Redux.js + redux-saga + Cordova + ES6 + Babel + OnsenUI + Gulp + Webpack ( ゚д゚) (つд⊂)ゴシゴシ (;゚ Д゚) !?!? (; ゚д゚)「…わ、わかりました」 ※「何でもやります!やらせてください!」が私の口癖なので、決して無茶振りしてくる弊社ではありませんよ!ほんとだよ!! 斯くして2016年、サーバーサイドエンジニアがはじめてフロントエンドへの門戸を開くこととなった際の学

                                    2016年、サーバーサイドエンジニアがゼロからReact/Reduxを学習したときの方法を振り返る
                                  • あのライブラリは何故誕生したの?のまとめ - Qiita

                                    はじめに 最近、フロントエンドのライブラリ乱立問題について盛り上がってました。 自分はnobkzさんの以下の文に全てがまとまっていると思います。 僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか? 「最近のフロントエンドへの違和感 - nobkzのブログ」より 裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。 つまりは、 "How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう ということです。この記事では どのような既存の問題・要求を どう解決して

                                      あのライブラリは何故誕生したの?のまとめ - Qiita
                                    • npm とか bower とか一体何なんだよ!Javascript 界隈の文脈を理解しよう - Qiita

                                      背景 Javascript で Web アプリを作ろうとすると、よくわからないことだらけで超混乱します。 npm と bower の違いは? npm はサーバーサイド用、bower はクライアントサイド用らしいよ えっ、でもなんで bower のインストールに npm が必要なの? サーバーサイドは Rails で書きたいから npm 要らないと思うんだけど・・・ ていうかサーバーサイドJSとか node.js って何? よく見る browserify って何? こういった疑問が沸き上がるのは、各ツールが生まれた文脈がよくわかっていないからです。いろいろ調べてやっとちょっとわかってきたのでメモします。間違いがあったらご指摘ください。 「CommonJS」誕生 - Javascript は汎用プログラミング言語へ その昔、Javascript 大好きおじさんは言いました。 Javascrip

                                        npm とか bower とか一体何なんだよ!Javascript 界隈の文脈を理解しよう - Qiita
                                      • フロントエンドへの複雑化について、一つの視点 - mizchi's blog

                                        これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記

                                          フロントエンドへの複雑化について、一つの視点 - mizchi's blog
                                        • Webpack の考え方について - mizchi's blog

                                          なぜ初心者は webpackが解らないのか?- Why can’t you understand the webpack? - from 健人 井関 www.slideshare.net この記事バズってたけど、わからない人がよりわからなくなる、という点で問題だと思っていて、webpack の目的の本質的な部分から整理する必要があると思います。 (あと友人が webpack に挑戦していたので入門資料も兼ねてる) Webpack の本質的な部分は次の3つです。それ以外は全部おまけ機能だと思ってよいです。 ES Modules のエミュレート node_modules のリンカ 拡張子ごとの変形 Webpack が本当にやりたいこと こういうコードがあるとします。 // src/a.js export default () => console.log('hello'); // src/in

                                            Webpack の考え方について - mizchi's blog
                                          • Vue.js ではじめるシングルページアプリケーションの開発 - HDE BLOG

                                            Vue.js は JavaScript フレームワークです。 ウェブアプリケーションのユーザーインターフェイス開発を支援する様々な仕組みを提供します。 管理画面はもちろん、HTMLエディタのようにユーザの入力に対して即応性が必要なアプリケーションを簡単に作ることができます。 例えば、テキストエリアに文字を入力すると、 デザインしたページの特定のDIV要素がリアルタイムに更新されるといったデータ反映の仕組みを備えています。 また、JavaScript で大規模なユーザーインターフェイスの開発を行う場合、HTMLファイルのテンプレート化、 JSファイルの依存関係、グローバル変数汚染など様々な課題に直面します。 Vue.js は、コンポーネントという仕組みと Webpack というモジュール管理ツールと組み合わせることで、 これらの課題にうまく対処できるようになっています。 今まで jQuery

                                              Vue.js ではじめるシングルページアプリケーションの開発 - HDE BLOG
                                            • 面倒なJavaScriptコードのとりまとめがこれ1つで可能に、「webpack」入門 | さくらのナレッジ

                                              最近JavaScript関連の開発で採用が進んでいる「webpack」は、JavaScriptファイルの変換や結合といった操作をコマンド1つで実行できるツールだ。本記事では、webpackとは何かという基本的な概念から導入方法、実際の利用例などを紹介する。 モジュール管理機構の不足や未サポート機能の問題をツールで解決する「webpack」 今日のWeb開発においてJavaScriptの利用は避けることができないが、JavaScriptのソースコードをどのように管理・デプロイすべきかという問題に対しては、まだ決定的な解決策が生まれていない状況が続いている。その根本的な原因の1つには、最近までJavaScriptにおいて普遍的に利用できるモジュール管理システムが存在しなかったことがある。 一般的なプログラミング言語では、大規模なプログラムを実装する際に作業性やメンテナンス性を高めるためプログラ

                                                面倒なJavaScriptコードのとりまとめがこれ1つで可能に、「webpack」入門 | さくらのナレッジ
                                              • webpack時代の終わりとparcel時代のはじまり - Qiita

                                                設定不要のビルドツール parcelというビルドツールが空前の勢いでGitHubスターを集めており、リリース数日で5000スターを超えています。今日だけでも1000スター以上増えており、Googleなどの有名企業リポジトリ以外でこのスピードで人気がでるのは異例です。 https://github.com/parcel-bundler/parcel https://parceljs.org/ 実際に試してみたところ、これはwebpack一強時代を終わらせるレベルの使いやすさだと確信しました。 作者はAdobeのエンジニアで、その他著名エンジニアも続々と参加している様子です。 webpack疲れ webpackが出た当初、webエンジニアはgulp/grunt疲れの状態だったことを覚えている方もいるかと思います。 webpackの統合された設定ファイルは、タスクランナーで逐次処理していたものを

                                                  webpack時代の終わりとparcel時代のはじまり - Qiita
                                                • 2022年に起きたフロントエンドの変化

                                                  Burikaigi 2023 https://burikaigi.dev/ Twitter https://twitter.com/__sakito__

                                                    2022年に起きたフロントエンドの変化
                                                  • 現代フロントエンドに欠かせないwebpackとBabelを理解しよう

                                                    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��

                                                      現代フロントエンドに欠かせないwebpackとBabelを理解しよう
                                                    • AWSの料金を「ざっくり」計算できるサイトを作る - Qiita

                                                      AWSの料金、ややこしいですよね。 サービスの選択肢が多く構成が柔軟なおかけで、さまざまな要件をカバーできるのは嬉しいのだけど、そのぶん料金体系がややこしいので、やるせない気持ちになります。 この気持ちはなんだろう、この気持ちはなんだろう、と自問しているうちに春になってしまったので、AWSの料金を「ざっくり」計算できるサイトを作り始めました。 ざっくりAWS 公式ツールの存在 Simple Monthly CalculatorというAWSの料金を計算できる公式のツールがあるのですが、悲しいことに名前ほどシンプルではありません。 正確な料金を算出するために入力項目が多いのは仕方がないとは思うのですが、サイトを開いたときの威圧感がすごいので、もう少しさっぱりできないかという気持ちがありました。 なので、公式ツールの敷居が高いと感じる自分のような人向けに、料金を「ざっくり」計算できるサイトを作り

                                                        AWSの料金を「ざっくり」計算できるサイトを作る - Qiita
                                                      • 2019年版 最先端のフロントエンド開発者になるために学ぶべきこと - Qiita

                                                        こちらの記事は、『Learn to become a modern Frontend Developer in 2019』の和訳になります。 本投稿は転載であり、本記事はこちらになります。 はじめに 新年になって以前書いた記事を少し簡潔にして理解しやすいように書き直してみました。この文章に以前私が書いた文章と違ったことが書いてあったり、少し矛盾する内容が見つかってもあまり気にする必要はありません。 昨年私が書いた記事はGitHubで公開しています。 Web開発は絶えず変化する分野です - 今日私たちがWebサイトを構築する方法は、2~3年前のやり方とは全く違ってきています。利用できるツールが沢山あり、新しいツールも毎日出てくるので、ウェブ開発者はいつもどのツールを使えばよいのか迷ってしまいます。 私は、ウェブ開発に係るフロントエンド、バックエンド、または運用を学びたいと思う人を対象にしたツ

                                                          2019年版 最先端のフロントエンド開発者になるために学ぶべきこと - Qiita
                                                        • グーグルが開発した画像圧縮ツールSquoosh。フロント開発向けにNode.jsで扱う方法まとめ - ICS MEDIA

                                                          グーグルが開発した画像圧縮ツールSquoosh。フロント開発向けにNode.jsで扱う方法まとめ 『Squooshスクーシュ』というGoogleが開発した画像圧縮ウェブアプリがあります。ブラウザで変換結果を見ながら圧縮設定ができるので、画像圧縮の難しい知識を持たない方でも使いやすいことが特徴です。圧縮だけでなく、WebPなどの各種フォーマットへの変換・リサイズといったこともできる便利ツールです。 このSquooshをNode.jsで扱える『libSquoosh』が存在します。libSquooshは大量の画像を一括で圧縮、WebPへの変換、リサイズなどの処理をこれ1つで完結できるのがポイントです。昨今のウェブはページの読み込み時間が重視される傾向があります。画像のファイルサイズは読み込み時間に大きく影響するため、画像圧縮は重要なテクニックです。libSquooshをwebpack・Viteと

                                                            グーグルが開発した画像圧縮ツールSquoosh。フロント開発向けにNode.jsで扱う方法まとめ - ICS MEDIA
                                                          • なんでもSPAにするんじゃねぇ!という主張のその先 - console.lealog();

                                                            Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈(少なくとも自分の観測範囲)では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。

                                                              なんでもSPAにするんじゃねぇ!という主張のその先 - console.lealog();
                                                            • Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか

                                                              Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho

                                                                Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
                                                              • JavaScript おじさんが教える本当の Modern JavaScript 入門 1 - Qiita

                                                                一部修正しました Udemy で React コース公開してます。(絶対 Udemy の 1200 円割引価格にはしないので、このリンクから買ってもらうのが一番お互いに得です。) Udemy React + Redux コース 本発表における Modern JavaScript とは何か Phase 1 として以下の環境での開発ができれば Modern JavaScript に入門できたものとする。 Webpack, Parcel 等の module bundler による "module system" の活用。 ES2015+ や TypeScript といった "Compile to JS *1" の使用。それに伴う Babel によるトランスコンパイルツールの使用。 ESlint, Prettier といった集団開発における、ソース品質安定のためのツール の使用。 ここまでのツール

                                                                  JavaScript おじさんが教える本当の Modern JavaScript 入門 1 - Qiita
                                                                • 「Angular」「React」「Vue」の3大フレームワークに集約 ICSの代表が教える「フロントエンド技術」のトレンド

                                                                  「キャッチアップしておきたいウェブ制作の最前線」というテーマで、Vue.jsなどJavaScriptを駆使したユーザーインターフェイスの開発を主に担当してきた池田泰延氏が、Webのフロント周りの近年の技術的な動向を解説します。前半はフロントエンド技術のトレンドについて。 スピーカー自己紹介、『JavaScript コードレシピ集』を出版 池田泰延 氏(以下、池田):みなさんよろしくお願いします。ICSの話として、私と鹿野の2名で発表します。HTMLとかCSSとかJavaScriptとか、フロントエンドまわりの最新を説明していきたいと思います。では始めていきましょう! ます自己紹介します。ICSの池田と言います。株式会社ICSの代表をやっています。これはオフィスの写真でして、南麻布にあるのですが、こんなところで仕事をやっています。今はこの状況下なので、会社にはほとんど誰も行っていませんが、こ

                                                                    「Angular」「React」「Vue」の3大フレームワークに集約 ICSの代表が教える「フロントエンド技術」のトレンド
                                                                  • 今年お世話になったCLIコマンド集 - mizchi's blog

                                                                    ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境

                                                                      今年お世話になったCLIコマンド集 - mizchi's blog
                                                                    • WebPでモバイルアプリの通信量を劇的に削減する - クックパッド開発者ブログ

                                                                      モバイルファースト室の @slightair です。 クックパッドの iOS/Android アプリは、少し前のバージョンからWebP形式の画像をサーバから取得して表示するようにしています。 この記事では、なぜ画像形式をWebPに切り替えたのか、また切り替える上で注意した点などを説明します。 Cookpad アプリと画像 クックパッドのアプリはユーザさんに投稿していただいたレシピを表示するアプリケーションです。その性質上、レシピ画像や調理手順、検索画面のサムネイルなどたくさんの画像をサーバから取得して表示する必要があります。 画像の数が増えたりサイズが大きくなればなるほど通信量が増えます。最近はスマートフォンの画面サイズがどんどん大きくなっているので、それに合わせて取得する画像を大きくしていくとさらにファイルサイズが増え、通信量も増えていってしまいます。 サーバとやりとりするデータが多くな

                                                                        WebPでモバイルアプリの通信量を劇的に削減する - クックパッド開発者ブログ
                                                                      • モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ

                                                                        投稿推進部の外村(@hokaccha)です。 クックパッドブログの開発でRails上にECMAScript6などのモダンなJavaScript開発環境を導入した経験を元にノウハウを紹介したいと思います。 RailsはSprocketsというgemでJavaScriptやCSSをコンパイルする仕組みが提供されています。Sprocketsによるasset管理の仕組みは非常によくできており、AltJSのトランスパイルやファイルの結合、minifyなど、assetのコンパイルに必要な機能を一通り備えています。 しかし、JavaScriptにおけるモジュールの依存関係の解決や、ライブラリの管理などについてはモダンなJavaScript開発と乖離してきているのが現状です。そこで、Railsでも以下のようなことを実現できることを目標に環境を作りました。 ECMAScript6のシンタックスを使う モジュ

                                                                          モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ
                                                                        • 社内でフロントエンドのパフォーマンスチューニングコンテストを開催した

                                                                          フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。 plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあ

                                                                            社内でフロントエンドのパフォーマンスチューニングコンテストを開催した
                                                                          • 『RequireJS等はもう古い。WebPackとは?』

                                                                            1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 はじめまして。 アメーバ事業本部 クロスイノベーション室のグンタ(@gunta85)と申します。 今回はフロントエンド開発用の、 ありとあらゆる依存関係を簡単に解決してくれる、 WebPackというスグレモノをご紹介します。 導入経緯大きなアプリを開発するにあたり、依存関係を解決してくれるものを探していました。 その中で、RequireJSやBrowserify、Componentなども候補に挙がりましたが、 諸々の理由でWebPackを選びました。 特徴の違いについては「WebPack vs Browserify」等で検索してみると良いかと思います

                                                                              『RequireJS等はもう古い。WebPackとは?』
                                                                            • 俺のJSライブラリの世界観(2014末版) - Qiita

                                                                              http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し

                                                                                俺のJSライブラリの世界観(2014末版) - Qiita
                                                                              • Railsが5.1になることでフロントエンドの開発が本当に楽しくなりました - チラシ裏日記上等!!新館

                                                                                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

                                                                                  Railsが5.1になることでフロントエンドの開発が本当に楽しくなりました - チラシ裏日記上等!!新館
                                                                                • 2020年後半版Vue.jsを使ってる人には必ず知っていてほしいVue.jsの武器とドキュメントに書かれていないコンポーネントやメンテナンスの際に役立つTips - Qiita

                                                                                  2020年後半版Vue.jsを使ってる人には必ず知っていてほしいVue.jsの武器とドキュメントに書かれていないコンポーネントやメンテナンスの際に役立つTipsJavaScriptTypeScriptVue.jsフロントエンドvue-cli はじめに 最近iCAREさんの所でVue.jsを一緒にやらせていただいているのですが、フロントの技術スタックがGraphQL + Vue.js + TypeScriptで開発しており、そこでのVue.jsの開発体験がかなり良く、iCareさんの詳細なノウハウを公開しても良いと言っていただけたので、言語化し、整理して、共有出来たらと思います. ※ いつも通り記事の内容に意見がありましたら直接編集リクエストをください 前置き 今回のサンプルは@vue/cliを利用し、プリセットはTypeScriptだけいれときました. versionは2020年7月16日

                                                                                    2020年後半版Vue.jsを使ってる人には必ず知っていてほしいVue.jsの武器とドキュメントに書かれていないコンポーネントやメンテナンスの際に役立つTips - Qiita