JavaScriptフレームワーク選定の議論 - Qiita
相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか？ ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか？ 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良
結局VanillaJSである。 - nobkzのブログ
anond.hatelabo.jp nida3001.hatenablog.com 上記のブログに刺激されて私もフロントエンドというかJavaScriptに対する思いを綴ったポエムをば。しかし、なんか書くのダルいので、大分大雑把にかくぞ。 さて、さっそく結論を述べよう。今のフレームワーク論争やらに対する解決策はVanillaJSを使うってことである。 フロントエンドSPAのフレームワークについて まず、今のほとんどのフレームワークが使えないってのはそのとおりである。その話してみよう。その理由は、「フロントエンド」 ってのは一括りにできないからである。「ハッカーと画家」のとある言葉をアレンジして言えば「フロントエンドはユーラシア大陸のようなものである」。フロントエンドが関わる範囲が大きすぎるのである。ヨーロッパもあればアジアもあれば中東もあるという感じである。 範囲が大きすぎて、フレームワー
5000人調査でわかった！世界のフロントエンド開発者が使うツールはこれだ
次々とリリースされるJavaScriptライブラリーにフレームワーク、進化を続けるCSSモジュール……と、変化の激しいフロントエンド開発界隈。いま開発者たちに実際に使われているのはどんなツール？ 開発経験は2年以上ありますか？ 高度なCSSスキルとしてSassやAutoprefixerの使用も含まれていますか？ JavaScriptの知識は十分にあり、Gulp、nmp、jQueryを使いこなせていますか？ そうであれば一般的な開発者だそうです。Ashley Nolan氏によるフロントエンド開発ツールのアンケート調査によれば。 気になる結果を見る前に…… この種のアンケート調査は新たなツールを見つけたり、知識不足の分野の把握に役立ちます。執筆時点で5254件の回答が寄せられていて、アンケート調査としてはかなりのサンプル数です。ただ、結果を疑いようのない真実だと受け取るには慎重になるべきです。
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
React + ReduxではないSPAフロントエンド事情 - Re.Ra.Ku tech blog
丸山です。 弊社も最近はiOSアプリやAndroidアプリだけではなく、いわゆるSPAなWebApplicationを開発しています。 SPAを採用した背景 その背景には サーバーサイドで複雑なビジネスロジックを実装することになるので、サーバーサイドはScalaを利用したい ScalaでHTMLを吐いてもいいのだけれど、そういうのは動的型付け言語のほうがやっぱり楽な気がする だったらScalaでJSONを喋るAPIだけ作ろう そのAPIと喋ってwebのユーザーインターフェイスを実現する部分はRoRにするか？ それともいっそSPAにしてブラウザから直接APIとコミュニケーションすればよくないか？ と、いろいろ考えたところで、まずは社内向けのツールで技術検証も兼ねてSPAでScalaなAPIとコミュニケーションするのを試してみることにしました。 まだまだ開発中なのですが、意外とうまくいっている
なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
コーダーがおさえておきたいコーディングのツール8選 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは。LIGフィリピン支社代表のせいと(@seito_horiguchi)です。 昨今ではWebのフロント周りを取り巻く環境が激変しています。 Webサイト・アプリケーションが進化するに連れて構築も難しくなってきましたし、技術やツールもいろんなものが登場しました。 そこで今回は、フロントエンドエンジニアはもちろん、コーディングに携わる人なら誰でもおさえておきたい、今旬な技術やツールを紹介したいと思います。 コーディングに関わる人ならおさえておきたい必須のフロント技術＆ツール8選 1. タスクランナー フロントコーディングに関わるあらゆるタスクを自動化してくれる頼もしいツールです。Grunt,Gulpといったツールがコレにあたります。 JadeやSass,CoffeeScriptのコンパイル、画像圧縮、バリデーションチェック、webfontのアイコン化、スプライト画像生成、スタイル
フロントエンドできない人が、フロントエンドやりすぎだ。あと、Vanilla.jsが便利だ。 - nobkzのブログ
最近、なんというか、フロントエンド勉強会に出席する度に、「フレームワークじゃねぇんだ! MVC設計がな! 」とか言い続けている気がする。たくさんフレームワークが出てきて、○○フレームワークの問題とか、開発の困難の話を聞く度に、自分の設計を棚に挙げて、「これは、フレームワークがスケールできないせいだ!」「jQueryが糞」とか言ってて、「何言ってんの?コイツ?」みたいな気分になる。 最近になって、なんでこの状況がいつまでたっても変わらないんだろう? って理由が分かってきた。フロントエンドできない人が、フロントエンドやりすぎなのだ。 なんでフレームワーク使うの? そもそも、なんでフレームワークを使うか?ってことに答えられない人が多い気がする。というか、大抵「上司が決めたから」とか「チームで決まっているから」という答えが返ってくる。そもそも、フレームワークを強制して学習させる環境になっている現場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
