並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 21 件 / 21件

新着順 人気順

フロントエンドの検索結果1 - 21 件 / 21件

  • 令和のHTML / CSS / JavaScriptの書き方50選

    Web制作の技術は日々進化しており、会社やプロジェクトによっては昨今の環境に適さない書き方をしているケースも時折見受けられます。 そこで今回は「2024年のWeb制作ではこのようにコードを書いてほしい!」という内容をまとめました。 質より量で、まずは「こんな書き方があるんだ」をこの記事で伝えたかったので、コードの詳細はあまり解説していません。なので、具体的な仕様などを確認したい方は参考記事を読んだりご自身で調べていただけると幸いです。 1. HTML 画像周りはサイトパフォーマンスに直結するので、まずはそこだけでも取り入れていただきたいです。また、コアウェブバイタルやアクセシビリティも併せて理解しておきたい内容です。 Lazy loading <img>にloading="lazy"属性を付けると画像が遅延読み込みになり、サイトの読み込み時間が早くなります。

      令和のHTML / CSS / JavaScriptの書き方50選
    • PythonだけでWebアプリが作れるライブラリが増えている(2024.05) - Qiita

      ※本記事で言及しているReflexのdiscord内に日本語チャンネルをつくってもらいました。もし、興味をもった人がいたら参加してみてください。 1.PythonだけでWebアプリをつくるライブラリが増えている 最近(2024.05)、Python界隈ではPythonだけでWebアプリが作れるライブラリが増えています。詳しくは他の記事を参照してもらえればと思います。 以下の記事がとても参考になりました。ありがとうございます。 2.ライブラリの分類 こうしたライブラリも大きくわけて2つの種類があるように思います。 ①データ解析の結果を表示するダッシュボードライブラリ ②汎用的なWebアプリをつくるローコードライブラリ ①ダッシュボード系ライブラリ たとえば、上記の記事にも出てきますし、ネットでもかなり情報の多い、StreamlitやDashは項番1のダッシュボードライブラリに該当すると思いま

        PythonだけでWebアプリが作れるライブラリが増えている(2024.05) - Qiita
      • Magic UI

        UI library for Design Engineers20+ free and open-source animated components built with React, Typescript, Tailwind CSS, and Framer Motion. 100% open-source, and customizable.

          Magic UI
        • ブラウザキャッシュの仕組みについてまとめた

          Web開発において、ページの読み込み速度は非常に重要になります。 そのためにもブラウザのキャッシュは効率的なWebサイト運営に不可欠な機能です。 ブラウザのキャッシュには次のHTTPヘッダを設定することができます。 Expiresヘッダ Cache-Controlヘッダ Last-Modifiedヘッダ ETagヘッダ これらのキャッシュには強いキャッシュと弱いキャッシュで分類が可能です。 「Expires」「Cache-Control」は強いキャッシュであり、「Last-Modified」「ETag」は弱いキャッシュに分類できます。 強いキャッシュと弱いキャッシュ 強いキャッシュは設定された期間内は完全にローカルキャッシュを利用して、サーバーへのリクエストを行いません。 一方で弱いキャッシュはキャッシュされたリソースの検証が必要であり、ETagやLast-Modifiedヘッダを利用して

            ブラウザキャッシュの仕組みについてまとめた
          • React 19を概念から理解する

            2024-05-29うひょさんに聞く! React 19アップデートの勘所 #React19_Findy

              React 19を概念から理解する
            • 巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32

              (WIP まとまったら Qiita とかに上げるかも) TLDR; 「React と Next.js を比較」という記事で、 Next.js と比較できるのは「フレームワークなしで React を使うという選択肢」であって、「React そのもの」ではない。 ✅️ React を使うのに 「フレームワークあり」 vs 「フレームワークなし」 ❌️「React」 vs 「Next.js」 それはそうと、「create-react-app の機能・特徴」のことを、「React の機能・特徴」であるかのように書いてしまっている記事が多い create-react-app 自体が擬似的なフレームワーク(といえそう) そもそも、create-react-app は今は更新されてないので create-vite-app を使うべき フレームワークあり or フレームワークなし 【フレームワークあり】

                巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32
              • Node.js の進化に伴い不要となったかもしれないパッケージたち

                tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら

                  Node.js の進化に伴い不要となったかもしれないパッケージたち
                • 個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論

                  Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは? Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay

                    個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論
                  • React 19の新機能まるわかり

                    2024年4月にリリースされたReact 19 Betaの新機能について、細かい点やポイントを解説します。

                      React 19の新機能まるわかり
                    • レガシーなフロントエンドを リプレースするプラクティス。 エネチェンジが挑む 「React化」

                      ENECHANGEでは、電気とガスの料金シミュレーションサービス「エネチェンジ」を開発しています。リプレース前の「エネチェンジ」のフロントエンドは、jQueryがメインで、ところどころVue2が使われていました。今回は、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。

                        レガシーなフロントエンドを リプレースするプラクティス。 エネチェンジが挑む 「React化」
                      • 生成AI時代のフロントエンド開発術

                        2022年11月にChatGPTがリリースされて、1年と約半年が経過しました。私はChatGPTが話題になった頃から、継続して利用しています。ChatGPTを使い続けていると、Webアプリケーションのフロントエンド開発に役立つことがありました。 そこで、本記事ではフロントエンド開発でChatGPTを活用して効率よく進める3つのパターンにまとめました。これらのパターンを紹介し、読者の皆さんの開発に役立ててもらえればと思います。 以下は、本記事で紹介するFigma、ソースコード、デプロイ先URLです。 Wireframing photo - Figma silverbirder/figma-photo-sample-app-for-ai - GitHub https://figma-photo-sample-app-for-ai.vercel.app ChatGPTを使う前に ChatGPTに

                          生成AI時代のフロントエンド開発術
                        • フロントエンド開発の効率化!Nx と Playwright でビジュアルリグレッションテストを賢く実施しよう - Techtouch Developers Blog

                          はじめに なぜ VRT が必要なのか? VRTとは? Nx と Playwright で賢く VRT を実施する どう賢く実施したか 結果 まとめ 参考資料 はじめに 「食べログ ラーメン TOKYO 百名店」の全店舗訪問を目指してラーメン巡りを続けているフロントエンドエンジニアの kenshin です。 フロントエンド開発者の皆さん、新機能を追加したり、ライブラリをアップデートした後に UI が予期せず変更されてしまった経験はありませんか?このような問題を素早く検知し、未然に防ぐ方法として、ビジュアルリグレッションテスト(以下、VRT)があります。 この記事では、Nx と Playwright を用いて VRT を効率的に行う方法をご紹介します! なぜ VRT が必要なのか? フロントエンド開発では、新機能の追加やライブラリのアップデートにより、予期せぬ UI 変更が発生することがありま

                            フロントエンド開発の効率化!Nx と Playwright でビジュアルリグレッションテストを賢く実施しよう - Techtouch Developers Blog
                          • フロントエンドから Amazon S3 にマルチパートアップロードしたい - カミナシ エンジニアブログ

                            はじめに Presigned URL(*) などで、Amazon S3 へのアップロード処理を実装していると、大きなサイズのファイルをアップロードしようとしたときに、以下のような課題に直面することがあります。 一回のPUT リクエストでアップロードできるサイズの上限が 5GB まで 単一の HTTP リクエストでアップロードするため、大きなサイズをアップロードしようとしたときに問題が起きる。例えば、アップロードの処理の途中で失敗したとき、最初からやり直しになる。 このようなときに活用したいのが、マルチパートアップロードです。マルチパートアップロードとは、その名の通り、アップロード対象のオブジェクトを小分けにしてアップロードする方法です。 AWS の SDK には、マルチパートアップロードが簡単に行えるような API が用意されているものの、多くは、S3 にアップロードを行うことができる I

                              フロントエンドから Amazon S3 にマルチパートアップロードしたい - カミナシ エンジニアブログ
                            • Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog

                              こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、転職サービス Findy の開発チームにおける開発生産性の向上に対する取り組みをご紹介します。 以前の状況 モノリスの解体 開発基盤の刷新 コンポーネント設計の刷新 テストの拡充 CI の高速化 改善の効果 まとめ 以前の状況 2020年頃の Findy は Ruby on Rails と React のモノリス構成で作られていました。 機能の増加に従いコードが複雑化し、しだいに開発スピードが伸び悩むようになりました。 ここで Findy Team+ で算出した当時のリードタイムを見てみましょう。 2020年のFindyのリードタイム 上記のグラフから次のことがわかります。 改修が本番に適用されるまで 約1週間 かかる プルリクエストがレビューされるまで 約5日 放置される

                                Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog
                              • SPAは万能じゃない。「革新的」と言われているPWAはどこがすごいのか? | レバテックラボ(レバテックLAB)

                                執筆 山内 直 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)に所属するテクニカルライター。出版社を経てフリーランスとして独立。ライター、エディター、デベロッパー、講師業に従事。屋号は「たまデジ。」。著書に『Bootstrap 5 フロントエンド開発の教科書』、『作って学べるHTML+JavaScriptの基本』など。 監修 山田 祥寛 静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「独習」シリーズ、「これからはじめるReact実践入門」、「改訂3版 JavaScript本格入門」他、

                                  SPAは万能じゃない。「革新的」と言われているPWAはどこがすごいのか? | レバテックラボ(レバテックLAB)
                                • 【ハンズオン】RemixでTODOアプリを作ってReactの違いを体感しよう【TypeScript/Supabase/TailwindCSS】 - Qiita

                                  【ハンズオン】RemixでTODOアプリを作ってReactの違いを体感しよう【TypeScript/Supabase/TailwindCSS】TypeScriptハンズオンRemixtailwindcssSupabase はじめに Reactを使っていてステートがクライアントとサーバーで辻褄が合わなくなった そんな経験がReactをある程度使ったことがある人はおそらく経験したことがあるはずです。 Reactにおいて状態管理は誰でも使いやすく直感的である半面、クライアントとサーバーの状態を意識する必要が有ります。 どのタイミングでステートの変更をサーバーでも行うのか難しく思う場面もしばしばあります。 今回は最近巷でReactと並んで見かけるようになったRemixについてハンズオン形式で学べるような記事を書いていきます。 ハンズオンを通してRemixの特徴であったり、SupabaseやTail

                                    【ハンズオン】RemixでTODOアプリを作ってReactの違いを体感しよう【TypeScript/Supabase/TailwindCSS】 - Qiita
                                  • Svelte v5 で導入された Runes によるリアクティビティシステム

                                    <script> let count = 0; function handleClick() { count += 1; } $: doubled = count * 2; </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? "time" : "times"} </button> <p>{count} doubled is {doubled}</p> 上記のコード例では通常の JavaScript と同じ方法で変数が宣言されていますが、これは Svelte のコンパイラによりリアクティブな変数に変換されます。count 変数の値が更新されるたびに、UI が自動的に更新されます。$: で始まる式は Svelte のリアクティビティシステムにより自動的に監視され、変更があると再評価されます(構文として

                                      Svelte v5 で導入された Runes によるリアクティビティシステム
                                    • コーポレートサイトでの htmx 実装をデモサイトで試してみよう | htmx | ブログ | a-blog cms developer

                                      2024年2月、JavaScriptライブラリ htmx の発見から始まり、短期間でその可能性に引き込まれ、以下の3つの記事を書きました。 JavaScript ライブラリ htmx と a-blog cms は相性が良さそうだ | kazumich.log kazumich.log htmx という JavaScript のライブラリが、2023 JavaScript Rising Stars : Front-end Frameworks で 2位 になっているが、日本ではあまり聞かない。私自身も最近知ったばかりだが面白そうな... Ajax 通信を簡単にする htmx の基本と実践 | フロントエンド | スタッフブログ | 名古屋のCMS構築・Web制作会社 アップルップル appleple htmx は、JavaScript のコードを書かずにサーバーとの非同期通信を実現し、ページ

                                        コーポレートサイトでの htmx 実装をデモサイトで試してみよう | htmx | ブログ | a-blog cms developer
                                      • ウェブの最新情報  |  Blog  |  web.dev

                                        Google I/O で、昨年の I/O での発表以降、ベースラインがどのように進化しているかについてニュースを共有しました。ウェブ プラットフォーム ダッシュボード、RUM Archive との統合、RUMvision との今後の統合についても発表しました。この投稿では、講演で取り上げたすべてのリソースを 1 か所にまとめます。 ウェブ プラットフォーム ダッシュボードは、ウェブ プラットフォーム全体と個々の機能の相互運用性の過程を確認するための新しい方法です。これにより、ベースラインに含まれるようになります。詳細については、ウェブ プラットフォーム ダッシュボードの発表をご覧ください。 Baseline を日常的に使用するツールと統合することは、このプロジェクトのビジョンの一つでした。Google は、ユーザーがブラウザの互換性への対応について、あまり時間をかけて考える必要がないように

                                          ウェブの最新情報  |  Blog  |  web.dev
                                        • The Static Site Guide

                                          This is a book about creating and publishing static websites using HTML, CSS, and the Hugo static site generator. It’s still a work in progress, but you can read the draft chapters here. Table of ContentsIntroductionMaking Your First Web PagePublishing Your Web PageSprucing Things UpCreating a Static Website Using HugoCustomizing Our Hugo WebsiteUsing a Custom Domain NameImplementing Version Contr

                                            The Static Site Guide
                                          • Q by LivesenseをWordPress on EC2からHugo on Cloudflare Pagesに移行しました - LIVESENSE ENGINEER BLOG

                                            はじめに 技術構成(before)と課題 技術構成(after)と選定の理由 改善したこと パフォーマンスの向上 デリバリー速度の向上 セキュリティ面でのリスク低下 大変だったこと 記事のマークダウン変換 段落分けと改行の区別 字下げ 書式の追加 Lintが必要になった 記事ごとのOGP画像周りの実装 URL変更に伴うリダイレクト設定 標準の検索機能がない おわりに はじめに 技術部の @mom0tomo , @etsxxx です。 技術部では、事業部横断的な仕事としてコーポレートサイトの運用も行っています。このたびWordPress on EC2で運用されてきた弊社のWebメディア(Q by Livesense)を、Hugo on Clouflare Pagesに移行しました。 q.livesense.co.jp 弊社のWordPress運用はやや特殊で、エンジニアがサーバーにSSHして

                                              Q by LivesenseをWordPress on EC2からHugo on Cloudflare Pagesに移行しました - LIVESENSE ENGINEER BLOG
                                            1