SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
今年、JavaScriptでの仕事の幅を広げた技術６選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。久しぶりのQiita投稿です。 今回は「ex-KAYAC Advent Calendar」の13日目の記事として寄稿させていただきます。 さて、改めて私の今やっていることを紹介させていただきますと、独立してから株式会社Lucky Brothers & co.という会社を設立し、主にWebの受託制作を行っています。 かれこれ３期目に突入致しました。 アドベントカレンダーということで改めて2018年という年を振り返ってみたのですが、一言で言うと「今年はフロントエンドエンジニアにとって大きな当たり年であった」と言えるのではないかと
Vueを昔触った後Reactをどっぷり触ってもう一回Vueを触ってReactに戻って得た感想
最近ReactとVueをどっちも触る機会があったり、「ReactとVueどう選定するの？」という問いを投げられ、スッと答えられなかったな、と後悔があったりしていたので、Vueを触って得られた感想をまとめてみる。 結論としてなにか新しいことを発見したというものではなく、世間で言われている事を自分なりに再構築しただけの結論になったと思う。 TL; DRVueからは全体的に優しさ（Gentleさ）を感じる事が多く、良い点だと感じた大規模になるときReactの堅牢さは魅力的。Vueが大きくなった時に支えられ設計が出来るかは個人的には懐疑的。「こうだったらVue、こうだったらReact」みたいな分岐点があるというわけではないので、最終的には好みになってくると思う。ぞうさんが好きかきりんさんが好きか。これまでのフレームワーク遍歴今回の話をするにあたって、僕と各フレームワークの付き合いをまとめておくと、
フロントエンドに秩序は戻ったか？
Kyoto.js 12発表スライドです。 https://speakerdeck.com/fand/hurontoendonizhi-xu-woqu-rili-sufang-fa の続編です。
CoffeeScriptからES2015(ES6)へ移行しました - Pepabo Tech Portal
ネットショップ運営サービス カラーミーショップで「新カゴプロジェクト」と呼んでいる最高のショッピングカートの開発をしている@tsuchikazuです。 2014年に開発を開始した新カゴプロジェクトではフロントエンドをCoffeeScript + Angularで開発してきました。ES5までの時代にAltJS文化を作り、Class構文やArrow Functionを先取りしていたCoffeeScript。それらはES2015(ES6)の仕様に採用され、一方でCoffeeScript自体の開発は止まり、CoffeeScriptは役割を終えたのではないでしょうか。先月、今後も変化し続けるフロントエンドに追従するためにも、新カゴプロジェクトで200ファイル以上のCoffeeScriptをES2015へ移行しましたので、今回その方法を紹介します。 トランスパイラ 移行方法としてCoffeeScrip
フロントエンドで使ってるものがあまり変わってない - No Regrets in Bathing
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。 毎回使う フレームワーク：Vue.js 消耗、などの意見が散見されたが、べつに今でも便利に使えている。 browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き データフローは特に考えない。状態がそこにあるので書き換えれば良い。 あまり頭を使わなくていいのが助かる Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。 ビルドシステム： browserify / watchify substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全
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
Webフロントエンドの人達(?)が次々と微妙なツールを導入して「流れが早過ぎる」とつぶやいているのを横目で見て感じている事 - latest log
自分の会社に「新ツール導入の際はCTOの許可が必要」というルールを生やして居心地を悪化させたり、後輩のやる気を削りたくなかったら、ツールの将来性を考えて行動したほうが… SI等のアレな現場にその手のルールが存在するのは何故なのか?という事と、自分達もその歴史の一節にならないように— コラーゲンたっぷりさん (@uupaa) November 20, 2015 必要な物は生まれる(創れば良い)ので、どんな問題がありどのような解決方法があり、状況の変化にどう対応するかなど、大人はツール導入前に織り込んでおくし、”勉強会の人が流行ってるって言ってたし”ですぐ廃れるツールを導入するなんて事を繰り返してると、あっという間にデストピアな職場に。な— コラーゲンたっぷりさん (@uupaa) November 20, 2015 “ツール導入で劇的に効率や抱えている問題が改善される”なら導入すればいいし、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How it feels to learn JavaScript in 2016 | HackerNoon