タグ付けされた質問 「front-end」

私はプロプライエタリなWebアプリケーションを作成する小さなチームと協力しており、UXは私たち自身が操作するので優先順位は高くありませんが、仕事を楽にするよう努めています。 開発者として、新しい画面の作成を開始する前にUIモックアップを作成する必要がありますか？派手なことは何もありません。ほとんどの場合、同僚と話し合って参照モデルを作成するための一般的なレイアウトです。盲目的にコードを記述する前に、いくつかのUMLダイアグラムの作成と比較していました。 私の同僚の一人は、これは馬鹿げていると言い、それをするのは私の仕事ではありません。

57 design  modeling  user-experience  front-end 

CSSファイルとJavaScriptファイルを連結してHTTPリクエストの数を減らし、パフォーマンスを向上させます。結果は次のようなHTMLです。 <link rel="stylesheet" href="all-my-css-0fn392nf.min.css"> <!-- later... --> <script src="all-my-js-0fn392nf.min.js"></script> これをすべて行うためのサーバー側/ビルドロジックがある場合は、さらに一歩進めて、連結されたスタイルとスクリプトをHTMLに埋め込みましょう。 <style>.all{width:100%;}.my{display:none;}.css{color:white;}</style> <!-- later... --> <script>var all, my, js;</script> HTTPリクエストは2つ少なくなりましたが、実際にはこの手法を見たことはありません。何故なの？

41 javascript  html  css  front-end 

Python pip、Node npm、Ruby Gemsなどのパッケージマネージャーの利点は、アプリケーションパスにファイルを追加するだけではないため、十分に評価できます。 多分私はポイントを失っている、または私は鈍感であるが、ここに私が見ることができるネガティブがある： プロジェクトをビルドする際の別のステップ 別のパッケージマネージャー（yo dawg）を介してインストールする別個の依存関係 bower.jsonおよび/またはでプロジェクトのルートをより混乱させる.bowerrc レジストリが最新であり、正確であり、利用可能であることへの依存 画像などの一部のインポート/参照が機能しない npmと大きな重複があり、多くの場合、使用するリソースが不明です。 陽性私が見ることができるが、これらのとおりです。 依存関係を手動でダウンロードする必要はありません オプションで、ユーザープロンプトなどに基づいてスキャフォールディングの一部としてパッケージをインストールする 私は気付いていないメリットを知りたいのですが、私は本当に知りたいと思う挑発的なことをしようとしているのではないと言ってください。

32 javascript  front-end 

私がフロントエンドを持っていると仮定します。フロントエンドは、ほとんどが角ばった、うなり声、お辞儀を使って書かれた単一ページのアプリケーションです。そして、私がバックエンドを持っていると仮定します。ほとんどの場合、ORMの上に置かれたREST APIであり、データベースからオブジェクトを保存/取得し、うなり声、エクスプレス、シークライズなどを使用します。 角度のあるアプリケーションは、ユーザーに表示されるすべての視覚的な処理を行いますが、バックエンドによって提供されるサービスを介したGUIとして機能します。 これらを2つの異なるコードベースに分離し、独立した開発、バージョン管理、継続的統合、開発へのプッシュなどを可能にすることが望ましいでしょう。 私の質問は、これをきれいに行うための方法は何ですか？フルスタックJavaScriptの推奨ベストプラクティスはありますか？ オプション＃1はモノリス、つまり「それらを分離しない」ようです。利点は、ビルドチェーンがシンプルであり、すべてが1か所にあることですが、多くの欠点があるようです。個別にバージョン管理するのが難しく、前面が壊れていると、展開できない背面を意味します。 オプション＃2は準モノリスのようです。フロントエンドビルドチェーンにより、多数のファイルがバックエンドに書き込まれます。distフロントエンド上のディレクトリをするとき、フロントエンドminifies、uglifiesなどので、基本的に、バックエンドには、いくつかのディレクトリを参照することになり、それがすべてを実行し、バックエンドに公開してしまいます。 オプション＃3は完全に分離されているようです。フロントエンドとバックエンドはそれぞれ異なるポートで独自のサーバーを実行し、完全に独立したプロジェクトです。欠点は、互いのポートについて知るように設定する必要があるようです。バックエンドは、フロントエンドからのCORSを許可する必要があり、フロントエンドは、それらのすべてのエンドポイントが予想される場所を知る必要があります。 オプション＃4は、docker-composeなどを使用して、すべてをまとめてリグすることです。 私は他のオプションがあると確信しています。推奨されるベストプラクティスは何ですか？

31 architecture  javascript  node.js  front-end  backend 

現在、私はクライアントに学校入学システムの開発を要求しています。今、これはこの種の挑戦をしている私にとって初めてです。私が作成した過去のソフトウェアのほとんどはそれほど複雑ではありません。 私はあなたのほとんどすべてが複雑なソフトウェアを作成したことを知っています。これについてあなたのアドバイスが欲しいです。最初にフロントエンドまたはバックエンドを設計する必要がありますか？ ありがとう！ ここに、私が少し前にインターネットで見つけた記事の結論があります。共有したいだけ http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 フロントエンド開発者とバックエンド開発者（私の意見） 私の個人的なテイク 繰り返しますが、それは訓練の問題であり、いくつかの広範なストロークの一般化です： フロントエンド開発者 通常、CS学位を取得していないか、3級学校のCS学位を取得していません。 基本に似た言語で作業する（PHP is Basicを参照） フォトショップドキュメントをCSS / HTML /などに変換する視覚的なスキルを持っている。 型のない言語のため、反復プログラミングに対して高い許容度を持っている バックエンド開発者 CSの学位または豊富な経験がある 問題解決のアプローチをより体系的にする 漏れているオブジェクトを見つけるのに何日も費やすことを気にしないでください 問題を解決するためのツールを試してビルドする

30 design  database  database-development  database-design  front-end 

私はDjangoとWeb開発の初心者を学んでいます。この質問があまりにも馬鹿だと思うなら、すみません。 そのため、Djangoを使用して、Google App EngineでホストするFacebookアプリケーションを作成しています。このプロジェクトは、任意のWebサイトのRSS / Atomフィードの読み取りに焦点を当てています（これですべてです）。 RSS / Atomファイルを処理するのに十分だと確信していますが、フロントエンド（ユーザーインターフェイス）の部分-「設計部分」について心配しています。HTML / CSS / JavaScriptを知りません（単純なHTMLを扱うことはできますが、それは設計上の問題にはつながりません）。 最初に、dreamweaverまたは同等のソフトウェアのようなツールを使用してUIを設計することを考えましたが、実際にdjangoを学び始めたとき、それは「不可能」なことのようです。 そう、 サイトのUI部分をどのように設計すればよいですか？dreamweaverなどのツールを使用できませんか？ NOの場合、JavaScript / CSSを知らない私のような人にとって最善の方法は何ですか 「はい」の場合、dreamweaverに代わる最良のオープンソースの選択肢は何ですか？ Google App Engineはこれらすべてを処理できますか？ Djangoを扱う人々がこれらのテンプレートページを編集する方法。Djangoは、企業内の異なる部門が個別に処理できるように、論理（ビュー）部分と設計（テンプレート）部分を分離することに言及しています。しかし、DjangoのHTMLページがHTML（設計）に関係のない「タグ」で満たされているという事実を考慮して、UIの人々はそれをどのように処理しますか？

26 web-development  python  web-framework  django  front-end 

私は新しいビジネスWebアプリケーションを作成しています。 それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（単一ページアプリケーション）フレームワークが必要です。 さまざまなタイプのアプリケーション（たとえば、Webアプリケーション、モバイル（Android）、および場合によっては他のタイプ（スマートデバイスなど））から使用するバックエンドエンティティとビジネスサービスを公開します。 したがって、両方の要件を満たすために、バックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API（JSON）を使用してそれらの間の通信を整理する傾向があります。これは健全なアプローチですか？ 多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません（たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します）。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。 私が理解したように、完全に分離されたSPAフロントエンドは通常、サードパーティAPIを使用する必要性から生じます。しかし、バックエンドとフロントエンドの両方が1つの会社によって開発されたとき、そのようなデカップリングサウンドデザインはありますか？ 私が現在選択しているテクノロジーは、Java / Springバックエンドとフロントエンド用のAngular2 / Web Components / Polymerです。この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、それはこの質問とは無関係です。

21 design  rest  api  front-end  backend 

私のチームはWEBベースの財務アプリケーションを開発していますが、同僚と計算をどこで行うべきかという議論が少しありました。純粋にバックエンドで行うのか、それともフロントエンドで行うのですか？ 簡単な説明：フロントエンドにはJava（ZK、Spring）を使用し、バックエンドにはProgress 4glを使用しています。筋金入りの数学とデータベースからのデータを含む計算はバックエンドに保持されるため、私はそれらについて話していません。ユーザーが値Xを入力し、値Yに追加され（画面に表示）、結果がフィールドZに表示される状況について話しています。純粋で単純なjQueryのような操作、つまり。 ここで、ベストプラクティスは次のとおりです。 1）JavaScriptを使用して値を追加し、バックエンドに行ったり戻ったりするのを防ぎ、バックエンドで「保存時」にそれらを検証しますか？ 2）すべてのビジネスロジックを同じ場所に保持します。したがって、値をバックエンドにもたらし、そこで計算を行いますか？ 3）フロントエンドで計算を行います。次に、データをバックエンドに送信し、そこでデータを検証し、計算を再実行します。結果が有効で等しい場合にのみ、ユーザーに表示しますか？ 4）他に何か？ 注：Javaでいくつかの基本的な検証を行いますが、ほとんどは他のすべてのビジネスロジックと同様にバックエンドにあります。 バックエンドのすべてを再計算することで送信されるデータの増加は問題になりません（XMLサイズが小さい。サーバーと帯域幅はユーザーの操作量の増加に耐えます）。

21 programming-practices  web-applications  front-end 

比較的新しい（独学）Web開発者として、フロントエンド、クライアントサイド、バックエンド、サーバーサイドという用語をよく耳にします。私にとって、フロントエンドとバックエンドは、それぞれクライアント側とサーバー側の同義語でした。 ただし、CodeIgniterのようなMVCフレームワークで作業を開始すると、基本的にエンドユーザーが参照するもの（サーバー側コードを含む）を参照するフロントエンドのインスタンスに遭遇しました。エンドユーザーには表示されません（CMSを含む）。私にとって、クライアント側とサーバー側の意味ははるかに具体的です。それらは非常に明確な線で区切られています。一方、フロントエンドとバックエンドはそうではありません。 他のWeb開発者との会話の中で、彼はCodeIgniter（全体）をフロントエンドと呼んでいましたが、これがループを引き起こしました。私は彼を修正してCodeIgniterが私のバックエンドであると言うのか、それとも2つの用語の定義が完全に間違っているのかを確信できませんでした。 フロントエンドとバックエンドの定義を検索すると、いくつかの点で少し混乱しましたが、いくつかの点が明確になりました。これら4つの用語の間に線が引かれている場所と、Web開発のコンテキスト（具体的にはLAMPスタック）でそれらがどのように結び付いているかを知りたいだけです。

18 terminology  front-end  definition  backend 

私はプロジェクトでフロントエンドの役割を担っています。PHPがJavaScriptに返すJSONの正確な形式をバックエンドチームメイトに指定する必要がありますか？ たとえば、ここで説明する形式と同様の形式を使用する必要があることを伝えます。 フロントエンドで使用するためのJSONを適切に構成する方法 または、自分の役割を可能な限り無菌状態に保ち、単にバックエンドインターフェイスから必要な入力と出力を言葉で説明する必要がありますか？（もちろん、これが発生した場合、異なるデータ構造形式を処理することは私の側でより困難になる可能性があります）

17 development-process  teamwork  interfaces  json  front-end 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた2年前。 XSLTは成熟した、広く受け入れられている標準です。 ブラウザー（古いIEでも）およびサーバー側で使用できます（nginxにはXSLTモジュールがあり、もちろんプログラミング言語から使用できます）。その実装はコンパイルされているため、PythonやJSよりもはるかに高速である必要があります。JS実装Saxon JSは、少なくともフォールバックとして使用できます。Jinja、Angular、RubyのSlim、ASP、およびPHPのテンプレートは近いものではありません。 XSLテンプレートは、IDEで簡単に検証できます。JinjaまたはAngularに役立つIDEはいくつありますか？ XSLTでUIとデータを分解するのは完璧なアイデアのようです。 確かに、実装はいくつかのコーナーケースで異なる結果を与える可能性がありますが、それはクライアント側でのテンプレート化だけの問題です。また、HTML、CSS、およびクライアント側で行われる他のすべてについても同じです。 それでは、なぜXSLTではありませんか？

12 web-development  web-applications  web  front-end  xslt 

マイクロフロントエンドの私の理解は、彼らが解決する重要な問題は、企業が複数の可能な異なるチームを持ち、大規模なWebアプリケーションを構成するために使用される個々のコンポーネント/スモールアプリで作業するのを支援することです。 ここで解決されている重要な問題は、複数のチームが独立して作業し、大規模なコンポジットを構築できる能力です。問題は、エンドユーザー向けに無駄のないリリースバンドルを用意することではありません。その理解は正しいですか？ 大きなWebアプリケーションを作成するために複数のスモールアプリを使用している場合、同じJavascriptライブラリ（Lodashなど）をエンドユーザーのブラウザーに配送する複数のスモールアプリを潜在的に含めることができるというのは本当ですか？個々のベンダーバンドルは、ある程度の重複/冗長コードがユーザーに送信される原因になりますか？ これは、フロントエンドアプリケーションの設計中に心配する必要がある問題ではありませんか？

12 optimization  builds  front-end  angular2 

ユーザーを識別するために、ユーザー名よりもメールを使用した登録ログインの方が良いでしょうか？

12 security  user-interface  front-end 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はウェブ開発の経験から、PHP、Java、Pythonなどの言語がバックエンド開発のもの（サーバーで実行されるソフトウェア）に使用され、フロントエンド言語にはJS / HTML / CSSが使用されることを知っています。 しかし、多くの企業が、たとえばフロントエンド開発にPHPを、バックエンドにpythonを使用していると言っているのを目にします。 それは、PHPがREST、RPCなどを介して他の言語で書かれた他のサービスを呼び出すためのフロントエンドであることを意味しますか？

10 web-development  architecture  server  design  front-end 

私は私たちのウェブサイトプロジェクトをバージョン管理するためのより良い方法を考えています。私はフロントエンドの開発者にすぎないので、VCSに関する深い知識はありません。 ワークフローは変化しており、過去のバージョン管理の習慣は時代遅れになっています。主な問題は、各Webサイトにフロントエンドファイルの2つの配列があることです。 開発環境（少ないファイル、非圧縮のjs、イメージなど）。「不正な」ビルド環境（すべて圧縮され、人間が読み取れないもの）。 ただし、ソースファイルを含むWebサイトを販売することはできません。まあ、それは完全に正しくないと感じています。 2つのリポジトリを持つソリューションがあります。1つはビルド、1つは開発で、gulpがビルドファイルをビルドディレクトリに送信します。しかし、それを維持するのは面倒であり、小さな会社では、それはそれほど素晴らしいとは思いません。それは多くのレポを作成し、人々はいくつかのレポで、時には1つのsvnレポでさえも管理しなければならず、問題が発生します。 したがって、同じsvn内のソースファイルとprodファイルの1つのリポジトリを持つソリューションもあります。ただし、Webサイトがローカルの開発サーバーから本番サーバーに移動するときに、ソースファイルを削除する必要があります（そのため、単一のリポジトリには、その場所、開発または本番に基づいて異なるファイルがあります）。私が聞いたことから、それは良くありません バージョン管理システムに関して、不適切なフロントエンドワークフローを管理する正しい方法は何ですか？

9 web-development  version-control  development-process  svn  front-end