僕らを縛る Node.js という呪いについて
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
Next.js12.xのLayouts機能
この記事はNext.js 12.xのLayouts機能です。 Next.js 13.xのLayoutsについては公式を参照してください https://beta.nextjs.org/docs/routing/pages-and-layouts Next.jsのLayoutについてTypeScriptの記事を探してもあまり見つからなかったので Layoutsとは🤔 ページ間で共通のコンポーネントを定義する機能 HeaderやFooterなどはほぼ全ページ同じレイアウトを使うけど、ページコンポーネントに直接書くとコンポーネントの状態（入力値など）が保持できないのでページコンポーネントの外に書くことでレイアウトの状態も保持できる🤝 検証に使ったリポジトリ Next.jsのLayoutsを使うと何が嬉しいのか 一部共通ではないページが有る場合もページ単位でLayoutを変えられるので対応可能
Next.js + NestJS で新サービスを作った話 | EUPHORIA DEV BLOG
はじめに はじめまして、ユーフォリア開発部エンジニアの山本未知彦です！ このたび、ユーフォリアではJRFU(日本ラグビーフットボール協会)協力のもと、ラグビー選手の育成・強化のためのフィジカルデータベースシステムSCOTのリリースを行いました。（詳しくはこちらのプレスリリースをご覧下さい） 本記事では、SCOTのWebアプリケーション部分のアーキテクチャ紹介について、その技術選定理由と実際に開発してみて感じた良い点・気になった点をご紹介したいと思います。 SCOTのアーキテクチャ選定 まず技術選定の話をするに際して前提となるユーフォリア開発部の体制を説明します。当時、開発部にはエンジニアが２名しか在籍しておらず、SCOT開発に際しては業務委託の方々に協力いただいての開発となりました。そのため、技術選定においてはコードのレビューのしやすさと、仮にプロジェクト途中で人員の入れ替えが発生した場合
大規模チームの中でフロントエンドを立ち上げて2ヶ月経ったのでまとめる
とある大規模開発プロジェクトの中で WebView 用のフロントエンドシステム開発を立ち上げて2ヶ月経ちました。Android, iOS専任のエンジニアがいないため、外部協力者の指導のもと、モバイルアプリの画面を WebView で作るためです。 ある程度その営みについて見えてきたものがあるので記事にまとめることにしました。 プロジェクト参加人数は30名以上 プロジェクト自体は4ヶ月前から動いてる このプロジェクトへのフロントエンドチームの参加は1月から 現在 WebView とモバイル・バックエンドなどの結合試験をはじめている 背景 去年12月いまの会社にテックリードとして入社し、前述とは別のプロジェクトでフロントエンドチーム立ち上げを行っていました。同タイミングで、いまの会社に誘ってくれた飲み仲間もテックリード・チームリーダーとして入社しています。フロントエンドチームはこの2名がプロパ
フロントエンドの消失 - または戦争が激しくなる話
React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド（とは？）の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域を食い合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHP や Rails の領分を侵そうとし
新規事業開発での技術選定の意思と意図 (フロントエンド編) - Sansan Tech Blog
こんにちは、関西支店で新規事業開発室に所属するソフトウェアエンジニアの加藤です。Bill Oneという新規サービスの開発に携わっています。 バックエンド編の続きとして、フロントエンドで私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきます。 Bill Oneは今年の1月ごろにピボットし、それまで開発してきたフロントエンドを全て捨て、1から作り直しました。ピボットの際に改めて技術選定を行い、それまで使っていたライブラリ等を見直したので、本稿ではピボット前後で変化した箇所を中心にフロントエンドの技術選定を紹介します。 前提 改めて前提です。私たちのチームで開発しているBill Oneは今年の5月にローンチしたばかりのサービスで、チームのエンジニアは5名です。開発しているアプリケーションはSingle Page Application (SPA) で、エンジ
なぜNext.jsを選んだのか？ DMMのサービスを支えるフロントエンド技術の今
2018年11月13日、DMM.comが主催するイベント「DMM meetup」が開催されました。今回のテーマは「【LIG・エアークローゼット・DMM】3社のフロントエンド開発最新事情」。規模や業務内容が異なるWebサービスを提供する3社が一堂に会して、プレゼンテーションとパネルディスカッションを通して、お互いの知見を共有しました。プレゼンテーション「DMMのサービスを支える最近のフロントエンド技術 ~ next.js の実践利用」に登場したのは。合同会社DMM.com、Webエンジニアの千葉弘太郎氏。DMMの現在の技術スタックから、新たに採用した技術の選定理由を解説します。 DMMのサービスを支える最近のフロントエンド技術 千葉弘太郎氏（以下、千葉）：こんばんは。長丁場になりますが、最後までお付き合いください。DMMからは「DMMのサービスを支える最近のフロントエンド技術」という
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今、我々は、 GUI の設計について 何を考えるべきか