「ウェブは人類の歴史の中で最も複雑なプラットフォームです」-OperaのVadim Makeevへのインタビュー





今回の「Without Slides」では、Opera Softwareの伝道者であるPedimsbeyであるVadim Makeevがゲストとして参加しました。これは、この国で最も有名なフロントエンドの1人であり、業界の多くのイベントの主催者です。



私たちは議論することができました:





インタビューは2月に行われましたが、手が出版されたのは今だけです。



私たちの会話のビデオ版はこちらです:





そして、読みたい人のために、カットの下で私たちの会話の転写があります。







2千分の1ですべてが始まった方法



-どのようにしてウェブダイビングを始めましたか? フロントエンドまたはOperaソフトウェアはあなたの人生で最初に登場しましたか?



-ジャーナリズムをやりたかった。 それから、思いがけず、私はあなたがウェブサイトを作ることができることを知り、フロントエンドに従事し始めた。 そしてもちろん、OperaはWindowsで使用するブラウザとして私の人生に登場しました。 ある時点で、Yandexですでにプロの植字と作業を行っていたときに、Operaのスタッフが私のところに来て、コミュニティを知っている、会議を開催する方法、プレゼンテーションをする方法を知っている経験豊富な人が必要だと言いました。 そして、私は本当に彼らに近づきました。



-あなたは何年からOperaにいますか?



-2009年5月から。



-その前に、あなたはこの業界に何年いましたか?



-私は幸運でした。その後、モスクワで働き、最初の会議「ロシアのインターネット技術」の組織に参加しました。 そこでは、ロシアで初めて、ミンスク、モスクワ、サンクトペテルブルクから多くのフロントエンドの集会者が集まりました。 良いスタートでした。



-今、あなた自身は、大きなチームの一員としてではなく、会議チームの責任者として多くのことをしています。



-はい、最初のRHSを実行し、最初のYandex.Subbotnikを実行できたのは幸運でした。 私たちがオフィスに座って名前を思いついたのを覚えています-これはすべて面白かったです。 Ya。Subbotnikiがスピンを開始するとすぐにYandexを去り、その年の終わりにMinskで最初のWeb Standard Days会議を開催しました。 実際、これは年に数回行う大規模な無料会議の始まりでした。



-今、あなたはOleg Buninと積極的に協力しています:これらのフロントエンドセクションはRIT ++とHighLoad ++にありますか?



-はい、2007年に初めて集まったとき、オレグは次のように述べました。「何らかのフロントエンドを作ります。」 私は自分のレポートを読み、知り合いを招待しました。 そして毎年春に私たちは何度も集まります 。それはかつてRITと呼ばれ、その後RIT ++と呼ばれていました。 現在、 RIT ++のフロントエンドは2日間の大規模な2スレッド会議で際立っていました。昨年は約30件のレポートがありました。 一般に、私たちはさまざまな都市で無料の会議を行うだけでなく、モスクワで大規模な会議を開催しようとしています。



-なるほど。 ジャーナリズムへの興味はどのように始まりましたか?



-どういうわけかそれが起こった。 私は100年前に彼女が出版社「チャンス」にいた都市新聞「Five Corners」に入りました。 似顔絵に興味がありました。



-あなたはアーティストですか?



-私は一度手を出して描いた。 その後、コメント、テキスト、他の何か...すべてがなくなりました...おそらく、それは教育に強く関連していません。 Webの仕組み、JavaScriptの仕組み、Netscape用に1つのバージョンを作成し、Internet Explorer用に別のバージョンを作成する方法を見つけるために、英語またはロシア語で最初の資料を探した方法を覚えています。 一般的に、私はすでに老人です。



ある時点で、ロシア語で良い情報源が少ないことに気づき、ブログを書き始めました-いくつかの翻訳を行い、フォーラムで公開し、人々の質問に答えます。 そしてゆっくりと、社内の最初のレポートに到達しました。 その後、外部からの報告、会議がありました。 そして、一般的に、私は私が伝えることができることに気づきました、そして私は伝えるべきことがあります。



標準について



-そして、なぜWeb標準なのか? これは単なる名前ですか、それとも規格のトピックに特に興味がありますか?



-これは非常に良い質問です。 現在、典型的なフロントエンド開発者またはWeb開発者は、W3Cまたは他の委員会によって発行されたいくつかのドキュメントにサイトを作成する必要があるとき、仕様を読み、すべてを実行しました。 私がメイクし始めたばかりの頃、人々は違ったやり方をしました。 ゴミを試してみましたが、機能する場合は機能しません。 あるブラウザではこのように機能しますが、別のブラウザでは異なる動作をします。3番目のブラウザでは、他のブラウザで行うと一般的に便利です。



それから、ウェブ標準のアイデアは明らかではありませんでした。 そしてそれに応じて、私たちは教育に参加し、互いに助け合うために、フォーラムに座っているさまざまな都市の人々の出現した協会にどのように名前を付けるかを考えました。 Web標準のアイデアが重要でした。



私たちが慣れている方法ではなく、ブラウザにとって便利な方法ではなく、仕様に書かれている方法で、本当にあるべき方法ですべてを行う必要がありました。 Web標準の考え方は、これらすべてを赤い糸で実行するテーマです。 今ではおそらく需要は少ないですが、ポッドキャストと会議で名前の連続性を維持しています。



-それは今では歴史へのオマージュにすぎないことがわかりましたか?



-今日、ウェブ標準が勝利しました。 そして、私たちはコミュニティとして、この旗を喜んで持ち続けています。



-2000分の1で問題が発生しました-各ブラウザーは独自の方法ですべてを実行しました。



-はい、開発者もいくつかのブラウザで同時に作業するために、すべてを独自の方法で行いました。



-過去10〜15年間、標準化プロセスが進行中です。 Webは現在標準化されていますか?



-「ウェブ標準」という用語自体は、ジェフリー・ゼルドマン有名なプログラム本「 Designing with Web Standards 」に由来し、表紙には彼の写真が青い帽子で描かれています。 そして、私の意見では、4月中旬に、皆がBlue Beanie DayのWeb標準の日である「Blue Riding Hood Day」を祝っています。 みんなアバターに青い帽子をかぶっています。



画像



A List Apartというサイトがありました-実際、まだそこにあります-そこからこれらすべてのアイデアが広まり、私たちはそれらを選びました。 WebmasconはA List Apartから多くを翻訳しました。



-Webmascon-このサイトは何ですか?



-アレクサンダー・カチャノフによって作られました。 それは主に翻訳リソースでした:Nielsen、Zeldman、単にAlestapartianの記事-一般的に、最も重要なもの。 その後、マックス・ロスソマキンがこのチームに登場しました。 このサイトは、ロシア語での一種のフロントエンドの集中でした。 そして、この周りに、私たちのコミュニティ全体が形成されました-そこから私たちはすべて行きます。 私の意見では、ZeldmanのWeb標準の考え方は、Webをより良い方向に変えました。



-現代の世界では、誰もがコミュニティ、オープンソースについて語っていますが、原則として大企業が支配しています。 Safari、Internet Explorer、Chromeのブラウザの背後にある企業をよく知っています。 Mozillaの場合と、おそらくOperaの場合を除いて。 巨人が自分たちの間で何かに同意することができたのはどうしてですか?



-標準に対応せず、ブラウザを開発しないと、ウェブが曲がり始めることが判明しました。 Internet Explorer 6は市場の90%を占めていました。これは、非常にクールなブラウザーであり、他のすべてのユーザーが競争するのが非常に困難だったためです。 その後、Netscapeを苦しめました。 そして、地平線には新しいものは何もありませんでした。



わずかなシェアのOperaがあり、Firefoxがありました。 それらはすべて、多くの点で互いにあまり互換性がありませんでした。 Flashが登場し始め、人々は真剣にサイトを作り始めました。 Web上でコンテンツを公開する必要がある開発者にとって、Webは十分ではありませんでした。 代替フォーマットが登場し始めました。



この時点で、他のブラウザーがInternet Explorerのシェアを弱体化させ始め、40%まで低下し、さらに低下しました。 これらはOpera、Firefox、Safari(Appleのデフォルトブラウザであり、Appleとともに成長し始めました)。 その後、Chromeが登場しました。



そして、単一のプラットフォームで対話する方がはるかに便利であることがわかりました。 なぜそう 知りません 典型的なプログラミング言語-C ++、Java、Perl、Python-には明確なドキュメントがあり、それらが行うことの1つまたは2つの古典的な実装があります。 ソフトウェアの分野では、互換性の制御は非常に簡単です。



そして、ウェブは最初からオープン仕様に基づいており、誰でもその実装を行うことができます。 ブラウザは最初からこれを使用していましたが、これは原則としてWebの動作を非常に複雑にしました。



その結果、新しいブラウザエンジンは作成されません。 実際、最新のブラウザエンジンはWebKitでした。 Webは非常に複雑であるため、相互作用の唯一の形式は、どの企業にも属さないオープンスタンダードでした。



ブラウザの開発の歴史とWebKitの進化について



-そして、GoogleがWebKitに来たとき、ストーリーは全体像にどの程度影響を与えましたか?



-Googleは当初からWebKitプロジェクトの開発を支援しましたが、あまりにも夢中になりすぎてcr屈になり、フォークを作成しました-そのBlinkエンジン。 すべての開発者がFirefoxのみを使用し、誰もがFirefoxでテストし、2006年から2008年にかけて世界の主要なブラウザであるという感覚があったため、代替ブラウザを本当にサポートしました。 Firefoxが勝っているように感じました。



-しかし、私の意見では、Chromeは2009年にのみ1年で大規模に始まりましたか?



-はい、彼はかなり遅く始めましたが、非常に強力です。



そして、AppleがWindows用のSafariをリリースしたというニュースを読んでいたのを、私はなんと狂った目で覚えています。 これ以前は、Windows上のWebKitプラットフォームは原則としてではなく、Mac専用でした。 そのため、これはWindowsでの最初のWebKitであり、原則として起動することができました。 そして今、Windows用のブラウザ-WebKitのほとんどすべて:Chrome、Opera、Yandex.Browser。



-最初の移植はApple自身によって行われ、その後Googleは行って終了しましたか?



-はい。 そして、最初のAppleポートはかなり曲がっていました。 ちなみに、最初にWindowsに移植されたChromeもあまり良くありませんでした。 WebKitにはいくつかの結びつきがあり、そのようなポートを通常どおりに作成することが困難だったためです。



Googleはどのように始まり、なぜ勝ったのですか? 広告! 検索! 検索と広告。 便利です。



会社自体がブラウザエンジンを選択し、好きなことをしました。 また、広告をより良く表示するだけでなく、業界に真剣に投資しています。 Googleが行っていることは、新しいエンジンでブラウザを再起動するのに役立ちました。これは、WebKitがGoogleがまだ到着していない状態にあったよりもはるかに簡単で便利です。 それは非常に重要なステップでした。



よりカラフルなブラウザランドスケープが大好きなので、Chromeがはるかに大きな市場シェアを占めるようになるのは少し残念です。 これにより、ウェブがより強力になり、競争がより面白くなります。



-ブラウザ市場は独占されていると思いますか?



-私はそれが明確に独占されているとは言いません。 Firefoxにはまだポジションがあります。 Microsoft Edgeの非常に強力なアプリケーション。







Microsoftパスと新しいブラウザーモデル



「Edgeには新しいエンジンはありませんか?」



-実際、そこの話は、私たちのブラウザで起こったことと非常に似ています。 ある時点で、主なアイデアを残して、完全に再起動しました。 インターフェイスの再起動、エンジンの変更など。 そのため、マイクロソフトのスタッフは非常に似たようなことをしました。



まず、Microsoftは企業の巨人です。 彼には多くの顧客がいて、企業セグメントから多くのお金が彼に来ています。 したがって、この企業構造全体がまったく機能しないブラウザの新しいバージョン、つまり内部ネットワークをリリースすることは不可能です。 そのため、Internet Explorer 6以降では、互換性のためにすべてのエンジンを使用していました。 IE11には以前はすべてのエンジンがあり、Doctypeに応じて、あらゆる種類のHTTPヘッダーとメタヘッダーを使用して切り替えることができました。



-つまり、どのエンジンが存在するかについての特定の指示をコードに記述できますか?



-はい。 あなたのサイトがIE9に基づいており、完全に機能しているとしましょう。 そして、IE11が登場し、サイトで何かが壊れました。 ブラウザをIE9モードに切り替える特別なヘッダーを追加すると、すべてが完全に機能します。 それはめちゃくちゃ互換性があり、超互換性があります。 しかし、これはブラウザの開発を妨げました。



-私は非常に長い間Javaプラットフォームに取り組んできました。そのため、開発では強力な互換性を維持する必要性が非常に遅いことを知っています。



-まさに。 したがって、Microsoftのメンバーは強力で大胆な動きをしたと思います。 過去数年間で、ブラウザが常緑化していることに慣れてきました。 ハッキングされているため、インストールしていないWindows更新プログラムが到着したときは更新されませんが、ブラウザがそれ自体を更新することを決定したときは更新されます。 そして、これは月に一度起こります。 このクイックアップデートモデルは、Chromeによって最初に示されました。 それからFirefox。 そして、バージョンは猛烈なスピードで増加し始めました。 実際、このような更新システムを備えたブラウザもリリースしました。



私の知る限り、Edgeはより簡単になり、より速く動作し、より頻繁に更新するために、後方互換性を落としました。 また、Windowsの小さな更新ごとに、かなり頻繁に更新されます。



ウェブがさらに速く成長し始めているという事実に向かっています。 競争のためだけでなく、常緑ブラウザの新しいモデルがあるためです。 以前にファームウェアで更新されたSamsung Androidブラウザーでさえ、Androidマーケットのアプリケーションとして更新され始めました。 また、大きな一歩です。



最新のブラウザのアーキテクチャについて



-そして、最新のWebkitベースのブラウザはどのような部分で構成されていますか? Yandex、Opera、Chrome、Safari-それらはすべてアーキテクチャ上同じ部分に分割されていますか? これらのピースが何であるか、どのように相互作用するかを教えてください。



-最初から、KDEを作った人たちは、HTML、CSS、JavaScriptを別々にレンダリングする方法を知っているブラウザエンジンを作りました。 Appleはこのことを分岐し、WebKitの作成を開始しました。



主に2つのコンポーネントがありました。1つはHTMLでCSSを処理し、もう1つはJavaScriptで動作します。 したがって、レイアウトとJavaScriptのこの分離は、Webkitから来たブラウザの世界では依然として主要なものです。 ある種のレイアウトがあり、各企業が所有するJavaScriptエンジンがあります。



AppleとGoogleのメンバーがWebKitに共通のエンジンを作ったとき、彼らはJavaScriptとレイアウトに共通のエンジンを持っていました。そして、Googleは独自のJSエンジンV8を作成しました。



したがって、Safari、Chrome、その他のWebkitおよびBlinkブラウザーはHTMLおよびCSSエンジンを共有します。 しかし、誰もが独自のJavaScriptエンジンを持っています。 SafariにはNitroエンジンがあり、GoogleにはV8があり、Operaには独自のエンジン-Carakanがありました。 Edgeには、独自のChakraスクリプトエンジンがあり、これが過負荷になっています。



だからこそ、Chromeは誰もが喜んで使用を開始し、代替ブラウザーに組み込まれているフレームワークですか? 内部にレンダリングエンジンがあり、ネットワークモジュール、システムとの何らかのやり取り、パスワードの保存、ウィンドウやタブの操作など、本格的なブラウザーを作成できる便利なインターフェイスレイヤーがあるためです。



これはすべて、オープンソースであるため、ブラウザをすばやく作成できます。Chromeに含まれているものの一部を含まないChromiumプロジェクトがあります。これらはGoogleに属し、たとえば何らかの理由で特に特許が取得されているためです。 数ギガバイトのChromiumを自分ですばやくダウンロードし、フォークしてブラウザにできます(Opera、Yandex.Browser、Amigoなど)。 モバイルブラウザでも同じことができます。 Androidやその他のプラットフォームには、Googleのコアエンジンを搭載し、独自のインターフェースを描画するモバイルChromiumが数多くあります。



-Chromiumでは、主な貢献者もGoogleですか?



-はい、Googleは主な貢献者です。 しかし、まだIntel、Samsung、Opera、Yandexがあります。



-Intelが、たとえばJavaScript組み込みエンジンに他のプロセッサ最適化も挿入するという事実に関与していることは明らかです。 そして残りは?



-さまざまな関心があります。 Intel、Dell、およびその他のさまざまな企業は、Webの開発に独自の関心を持っています。 彼らは独自の製品とプラットフォームを持っています。



実際、全体的な互換性を実現するために、Microsoftがブラウザーでサポートしているポインターイベント仕様の実装をChromeに提供すると、驚くべきことが起こります。



すべてが混同されているため、ほとんどすべての人がChromeに参加し、まったく異なるプロジェクトの人々がFirefoxに貢献することがよくあります。 Chromiumが大きな市場シェアを占めているために競争に負けているという感覚がときどき生じたとしても、実際、Chromiumは発展しているため、端に行くように見える同じ企業もChromium自体に従事しています。プラットフォームは、健康的な生活のチャンスを増やします。



OperaがWebkitとBlinkを選択した方法



-OperaがWebKitとBlinkを選択したとき、どのように選択しましたか?



-実際、それ自体は選択肢ではありませんでした。



まず、WebKitに切り替えました。 彼らは2012年の終わり頃に決定を下し、2013年の初めにこの移行が発表されました。 したがって、当時の私のレポートは「Why Oper WebKit」と呼ばれています。



しかしその直後、2013年1月から2月にかけて、GoogleはWebKitを分岐します。 最初の6か月間は、WebkitとBlinkのフォークとの間に大きな違いはありませんでした-それらは2つの異なるリポジトリにすぎませんでした。 構造の変更はBlinkで行われ、一部は破棄され、一部は表示されましたが、最初は違いはそれほど大きくありませんでした。 さらに、Googleには独自のJavaScriptエンジンが長い間ありました。



当時、私たちはBlinkやWebKit、つまりChromiumプロジェクトに多額の投資をしていませんでした。OperaはBlinkだけでなくChromiumで作られました。また、レンダリングやその他のことだけでなく、インフラストラクチャソリューションにも貢献します。 ChromiumはBlinkで作成されているため、私たちはそれを追ってWebKitにとどまりませんでした。



「その瞬間から3年以上が経過しました。」 WebKitとBlinkの現在の開発状況を見ると、どういうわけか違いを簡単に特徴付けることができますか?



「WebKitはMac OSコンポーネントが動作する組み込みエンジンであるため、Appleは互換性を維持する必要があるという意味でMicrosoftのように見え始めています。」 このため、互換性を維持する必要があることがわかりました。あらゆる種類のインスタントメッセンジャーや、Mac OSに組み込まれている他のプログラムは、WebKitで動作します。



-そして、どうやら、iTunesは組み込みのWebKitで動作するようです。



-はい、App Store、およびその他のアプリケーション。 本当に互換性を維持する必要があるかどうかはわかりません。 おそらくこの意味で異なるポリシーを持っているかもしれませんが、最初からBlinkでWebKitを強制するというアイデアは、Googleの開発のペースとスタイルが異なり、その意味で近いという事実によるものでした。 したがって、現在、Googleは新しいものを導入する際にはるかに大胆であり、Safariには1年の終了サイクルがあります。 Appleは新しいオペレーティングシステムとともに、Safariの新しいエンジンを示しています。



最近(2016年2月にインタビューが行われた-著者のメモ)、Appleは新しい機能が登場するベータ版をリリースしました。 理論的には、リリースサイクルの前にこのベータ版をリリースする必要があるため、これはイベントでした。 つまり、速度、破棄されたCSSプレフィックス、新しい組み込み機能があります。 Googleは、CSSプレフィックスの破棄、プロパティの削除、および一般的にはるかに高速での展開において、はるかに大胆です。



-これらの手順は標準化に向かっていますか?



-はい。 そして今、ブラウザはブラウザのプレフィックスから遠ざかりつつあります。 安定したChromeで設定に入り、実験モードを有効にすると、ブラウザーに新しい機能が表示されますが、これらはまだ公開されていません。 Safariはこれを行えません。



Safariには、ダウンロードして確認する必要がある特別なビルドがあります。 また、Googleはすべての機能を安定バージョンに直接導入しますが、ユーザーがbreakを壊さないように、デフォルトでそれらをオフにします。 これにより、これらのすべての新機能が開発者により近くなります。 これらには、「実験的な機能を有効にする」という1つのフラグが含まれています。 そして、Googleが現在作業中のすべてがブラウザにすぐに表示されます。



ブラウザは、CSS、JavaScript、およびプロパティのブラウザプレフィックスを放棄し始めました。 しかし、Appleはこれが正しいことだとまだ信じており、実験的なものがブラウザにすぐに表示され、オンとオフを切り替えることはできません。



Appleはいまだにその場でいくつかのことを思いついています:「タブのクールなアイコンを作ってみませんか?」しかし、これにはW3Cの仕様について何もありません。 そこで、彼らはW3Cを経て思いついたもの、作られたもの、文書化されたもの。



または:「WebアプリケーションをiPhoneのデスクトップにインストールする方法を見つけました。」 通常の仕様はなく、サイトに小さなドキュメントがあります。



AppleはIE6以降、Microsoftに少し似ています。 すべてがそれほど悪くない-もちろん、Appleは多くの標準化と開発を行っている。 しかし、いくつかの機能があるので、それを見るのは少し悲しいです。



Webでの標準化の方法と、これが人類の最も複雑なテクノロジーである理由について



-そして、ウェブのいくつかの大きな機能の標準化はどのように行われますか?



-すべてが今起こっている2つの方法があります。



最初の方法は古い方法です。 現在のWebのすべての基本(HTML、CSSなど)が書かれたとき、それらは紙に書かれました。 タイプライターまたはコンピューターで印刷。 それらは最初に発明された後、ブラウザ開発者に「これはこのように動作し、実装する必要がある」と言われました。



そして、ブラウザは答えました:「私たちはそれが好きではありません。 そうでなければ実装します。」 そして、このために、90年代後半と2000年の初めの野生の網が生じました。 そして、この道はどこにも消えていません-今まで、いくつかの標準は最初に紙に書かれましたが、よりよく理解しており、この種の混乱はうまくいきません。



そして、2番目の方法があります。 最初は彼は非常に悪い考えであり、悪いことをもたらしましたが、今では彼はより面白く、より良くなっています。 これは、タスクがブラウザー内または会社内に表示され、ブラウザーメソッドを使用してそれを解決する方法です。 マイクロソフトで生まれた仕様を持つポインターイベントについて考えてみましょう。 彼らは、Windows 8のタイルを作成するためのグリッドレイアウト(Metroインターフェイス)を必要としていました。 そして、ポインターイベントは、タッチデバイス(最初のMicrosoft Surface)を作成し、タッチ市場に参入し始めたために必要でした。



マイクロソフトは自分でこれらの仕様を作成しましたが、非常に優れていることが判明したため、すぐにこれらの仕様を市場にリリースしました-ワーキングドラフトをW3Cや他の場所に送り、業界全体にそれらを自宅で実装するよう説得し始めました



これは良い方法です-彼らは、Firefoxを含む他のブラウザの実装を示し、実装し、支援しました。 彼らはChromeを壊しました-しかし、開発者はすぐに同意しませんでした。



Firefox、Safari、Chromeにはグリッドレイアウトの代替実装がありますが、最初はすべてIE10に登場しました。



-そして、それはどのように正式に見えますか? このすべてがどのように階層化されていますか? ブラウザ開発者は、私たちのブラウザがいくつかの独立した仕様のセットをサポートするようになったと言うだけですか?



-要するに、以前はHTMLとCSSの仕様が主要なものでしたが、開発者はそれらの1つにすべてを押し込もうとしました。 HTML仕様には、構造、HTMLに関連するある種のAPIなどがあります。 CSSでも、CSS1は機能のコレクションであり、CSS2は他の機能のコレクションです。



その後、CSS3が出現し始め、人々はこれがすべてナンセンスであることに気付き、現在CSS3やHTML5のようなものは正式には存在していません。 単にHTMLとCSSの仕様があり、それぞれにモジュールがあり、モジュールにはバージョンがあります。



同じグリッドレイアウトは、「グリッドレイアウトレベル1」と呼ばれるようになりました。 以前はCSSカラーレベル3でした。そして、人々は「まあ、これらはCSS3カラーです」と言いました。 しかし実際には、「CSS、問題を解決するための3番目のアプローチ」です。



これで、グリッドレイアウトレベル1ができました。 それは、CSSとグリッドレイアウトバージョン1です。新しい機能が必要な場合、ほとんどの場合、既にレベル2、レベル3などになっています。 つまり、各モジュールには独自のバージョン管理があります。



-モジュールはたくさんありますか?



-多くのモジュールがあります-それらは数十あります。 さまざまなトピック:フレックスボックス、グリッド、色、ブロック、フロートの動作。 興味深いのは、以前に別々のモジュールを作成し、ブラウザ開発者がこれらのモジュールが互いにどのように相互作用するかを本当に理解する必要があった場合、統合モジュールの作成を開始したことです。 つまり、異なる仕様を取り込んでバインドし、3つ目の仕様を作成して友だちにします。 そして、最終的に、実装ははるかに興味深いように見えます。 たとえば、以前のフロートを使用して画像を左に移動して、テキストが画像を囲むようにできる場合、

フロートトップ、フロートボトムなどがあります。 このために、彼らは別の仕様を書き、他の要素との相互作用を記述します。 CSS仕様とHTML仕様の間には、多くの統合作業が行われています。



「組み合わせ爆発はありませんか?」 それぞれの相互作用を説明する必要がある場合、雨上がりのキノコのように、スペックが増え始めます。



-言うのは難しいですが、グリッドやフレックスボックスなどの新しいレイアウトシステムを考え出す必要がある場合は、配置、フロート、その他あらゆる種類の動作を考慮する必要があるため、新しい仕様の作成は間違いなく複雑になります。 ブラウザー開発者がこれらの組み合わせを正しく実装し、Web開発者がそれらを正しく使用できるように、各要素または要素のグループについて世界中のすべてを埋めて、相互に明確に相互作用する必要があります。



私にとって、ウェブは人類の歴史の中で何でも作成するための、インターフェースを作成するための複雑なプラットフォームであるようです。 したがって、新しいブラウザエンジンはなく、仕様の記述は困難であるため、1つのブラウザでは対応できません。競争が必要で、移動が必要です。



Web開発者の仕事の難しさについて



-現在、業界のほとんどの人々は何らかの形でWebに接続しています。 そして実際、ウェブの下で、彼らはプログラムします。 これは大変な仕事ですか?



「Webは、まだ簡単に始められるプラットフォームです。」 iPhone用にプログラムを作成し、App Storeでアプリケーションをリリースするには、Macを購入する必要があります。iPhoneを購入する必要があり、Appleサブスクリプションに対して年間100ドルを支払う必要があります。 また、プログラミングのパラダイム、パターンを一般的に理解し、言語を習得するなどの教育も必要です...



また、最初のHTMLページを作成し、モバイルデバイスまたはデスクトップを使用して地球上の数十億人に表示するには、メモ帳を開いてHTMLタグを書き込むだけです。 テキスト。 そして、誰にも何も支払わないでください。 ある種の無料ホスティングにサイトを置きます。 入場の閾値はまだ非常に低く、いくつかの便に飛び乗る必要はありません。



-低参入しきい値は、ウェブが業界全体を動かすことを可能にする要因ですか?



-これがウェブが勝ち、一般的に勝った主な理由の一つだと思います。 2つの理由があります。 まず、エントリのしきい値を低くすることが重要です。 学校または大学の教養教育を受けた人は、いつでも組版を開始できます。



-HTMLは現在、10年生の多くの学校で...



-はい。 そして、リベラルな教育を受けた人々はウェブ開発に従事し始めます。 これは、エントリのしきい値が低いことを示しています。 ここで私は原則として人文科学の出身であり、それからひっくり返った。



2番目の重要な理由-これは誰にも属していません。 たとえば、誰もが「ウェブの未来」だと言ったFlashは、長い間Macromedia、Adobeに属していました。 したがって、彼らは特許を所有しています。 大企業は他の会社に属するものに投資しないので、特許の問題や何らかの年金の狭い枠内に収まることはありません。



今、これが私たちの共通の遺産であるウェブとウェブ技術です。 もちろん、人々は次のように言います。「私たちはウェブが好きではありません。 Webは複雑で、多くのエンジンがあります。Swiftでクールなソフトウェアプラットフォームを作成しましょう。」 新しいフロントエンドソフトウェアプラットフォーム、新しい言語、クールでオープンソースですらあります。 そして、それはそれをはるかに興味深いものにします。



Mac OSとiOS向けに誰もが書いていたObjective-CはAppleに属します。 そして多くのベンダーは、完全に他の会社の手にある技術を台無しにしたくありませんでした。



-率直に言って、舌はまあまあです。 60年代から洗練された、古い、Cのような...



-ここ。 そして、ウェブ...ウェブは、基本的なリテラシーを持っている単純な人にとって、常に夢のようで、宣言的で、理解しやすいものでした。 そして、本当にオープンでアクセシビリティがウェブを今のようにしています。



JavaScript、その長所、短所、および「続編」について



-しかし、まだ宣言的ではないJavaScriptがまだあることを理解しています。 そして今のところ、ウェブが批判されている主なものはJavaScriptでもあります。 エンジンが異なり、エンジンには多くの問題があるためです。 そして、言語自体に大きな問題があります。 このかなり奇妙で古代の構文言語が勝ったのはどうしてですか?



-彼は誰にも属しておらず、すべてのコーヒーメーカーで働いています。 ブラウザはほぼどこにでもあります。 Cで記述されたコードを実行するには、いくつかのプラットフォーム用にコンパイルする必要があり、ブラウザーでJavaScriptがすぐに動作します。



, JavaScript, : « , , ». — , -, .



— , ?



— . , , . , — JavaScript TypeScript ..



— , : «, JavaScript, , ». , JavaScript - , ? ?



— ECMAScript. ECMA-, JavaScript. , , : , - , , ECMAScript 5 — JavaScript, . CoffeeScript. , , , , …



— — .



— . CoffeeScript ECMAScript, JavaScript . ECMAScript, ECMAScript 5 , ECMAScript 6 90. 10%, , . , ECMAScript 6, ECMAScript-2015, , , ECMAScript 5.



, , - , . CSS — Sass, Less, Stylus, PostCSS, .



JavaScript, . JavaScript .







jQuery,



— 10 AJAX. jQuery . , jQuery — .



— , - , jQuery. jQuery JavaScript , JS- . , . AJAX-, jQuery.ajax(), — , , , 30 .



. , , - . , , — Bootstrap, jQuery-, , — ! — , , , . jQuery . , , , .



, , jQuery . , jQuery polyfill- , . jQuery 2 , jQuery 3 , -, , : , .



. , jQuery , . , , , — . , .



Microsoft - XMLHttpRequest, AJAX. XHR2. , fetch , , polyfill . , jQuery , fetch, , . fetch .





— , , . ? ?



— SPA (Single Page Application). , , , , — : , , — .



, , json-, , . , , . JavaScript, . - ..



— , .



— . — , , JavaScript- HTML , HTML . .



, . , - .



— . , , ..



— . , - . , JavaScript — ! , . , - . - JavaScript, .



— , .



— . — HTML, HTML JavaScript- , . - .



Ember.js AngularJS : HTML, , JavaScript. « ».







HTTP, HTTPS HTTP/2



— . HTTP HTTP/2. ?



— - . JavaScript, , , . , , , — , .



— HTML URL-, 6, 10, 20. .



— , , , .



, , , — . SPDY , . -, Opera Presto ( Opera 12 — . .) .



— ?



— Google, . SPDY- Nginx, Apache, . SPDY HTTP/2. , , . , ; , .



— , .



-はい、はい。 , , , , HTTPS. HTTP/2 , , , . , , , — , , , , .



, , - , . , polyfill .



CoffeeScript. -, : « », : «, », , , .



— , ?



— , HTTP/2.



— HTTP/2?



— , . HTTPS, , , , , . , 90 .



HTTPS , API . HTTP, Chrome HTTPS.



, — . API, , HTTPS. , , HTTP.



: , , . , Let's Encrypt , . - HTTPS, , API . , HTTPS HTTP/2.



— ?



— , . — HTTP/2. . , , .



— , ? , , , HTTP/2 — . ? , , ?



— . .



— , ?



— , , , , . , .



— , , HTTP/2...



— … - . , , HTTP/2.



«-» - HTTP/2. . HTTP/2 , HTTPS, …



— ? ?



— - . — , , . , . . Smashing Magazine , HTTPS, HTTP 2, . , . – , , , . , . .



— , HTTP , . , — , — Highload: HTTP-, HTTPS. () HTTP , HTTPS.



— , . . : , HTTPS, - . , . - .



— , , , , — HTTPS. , — .





-あなたにとっての伝道は、イベント、記事、コミュニティ、会議で話しますか?



-前の時代に聖書を片手に持ち、もう片方に十字架を持っている伝道者だったら、馬車から降りて村に行って話をしたことはないでしょう。

当然、インターネットを使用すると、はるかに多くのオンラインを実行できます。 例えば、多くの人があなたとのインタビューを見るでしょう-私は彼らのそれぞれに家に行く必要はありません。



私たちはウェブ上で行き詰まっており、ある種のコミュニケーションがあまり認識されていないことが起こりました。 そして、会議のアイデア、会議のアイデア、あなたが人の目を見て、彼に何かを説得し、彼に何かを告げることができるとき、それはまだ有効です。 したがって、私はより頻繁に会議に出席しようとします。



一方、Opera Softwareには私のチームの特徴があります。それはすべて配布されています-チームには5人がいます。 私たちは皆、年に数回、中央オフィスまたは他の場所に集まります。 すぐに再び集まり、同期し、通信し、何をするかを計画します。



-あなたが言っていることの主な方向は? 今、たとえば、標準について多くのことを話し、Operaについて、Opera Softwareについて少し話します。 これはなぜですか? あなたの興味はOperaビジネスにどのように適合しますか?



-2009年にオスロでのインタビューのために電話がかかってきたとき、彼らは私に質問をしました。「一般的に、あなたはどうしますか? 何に興味がありますか?」 当然、私は自分自身について話しました、彼らは会社について私に話しました。 そして、私は最終的に何をしなければならないか尋ねました。 Operaの販売額とWeb標準について話す割合 大まかに言って、Web標準-70%、Operaの販売-30%と言われました。



実際、彼らは私に嘘をつきませんでした。なぜなら、あなたがウェブ標準について話すとき、あなたはウェブについて、技術について話し、そして一般的にこの分野の専門家であるので、あなたは顕著になるからです。 彼らはあなたを知っている、彼らはあなたを聞く。 それに応じて、もし人々がOperaに対して何らかの質問や問題を抱えているなら、彼らは思い出します:「ええ、Makeevはカンファレンスで話をしました。 まあ、彼はそこで働いています。 彼に頼りましょう。」



Firefoxに何か問題がある場合はどうしますか? Safariに何か問題がある場合 あなたはおそらくトラッカーにそれらを書くでしょう。 そして、ここであなたは私と会い、話をすることができます、私は手紙を書くか、他の方法で連絡することができます。



-Twitterで。 あなたと私が昨日見つけたように、2つのTwitterでさえ。



-2つのtwitter- 英語ロシア語を話す 。 中国語にする必要もあります。 冗談。



-まあ、それは難しい話です。 そこで伝道者を雇う方が簡単です。



-そのように。 ちなみに、私たちは中国から紫Binを持っていました。 その後、13人のチームがあり、人々はラテンアメリカとアジアにいました。 新しいエンジンに切り替えると、互換性が向上し、その結果、問題を解決するために必要な人が少なくなりました。 その結果、私の仕事量が増え、今ではもっと旅をしています。



-主にロシア、ヨーロッパですか?



-だけではありません。 カリフォルニア州で非常に興味深いイベントであるChrome Dev Summitを2年間運営しています。 Googleのオフィスを通過します。 Chromeはさまざまな方向にリードしているため、非常に興味深いレポートがあります。 そして、彼らはそれをすべて放送し、すぐにレコーディングを投稿します。 したがって、 Chrome Dev Summit録画を視聴していない場合は、最新の出来事が発生しているのでお勧めします。



モバイルWebとOpera Miniについて



-約2年前、彼らはモバイルトラフィック、モバイルデバイスからのトラフィックが勝ったと言いました。これはモバイルブラウザーとアプリケーションの両方です。 あなたの意見では、ウェブは一般的にどのように変化しますか? この点に関して、Web開発者はどのように方向転換すべきですか?



-大きな問題があります。 開発者は自分が開発しているものに近づいています。 現代の開発者は、ポケットに入っている携帯電話で開発することはありません。そこで行うのは単に不便です。 彼はデスクトップで開発しています。 そのため、開発者が開発するサイトは、デバッグツールやその他すべてのものがあるため、デスクトップで最適に動作します。 便利なデバッグツールがモバイルブラウザに表示されるようになったため、USBを介して一部のAndroidに接続し、便利なデバッグを開始し、すぐにデスクトップを見て電話でデバッグできますが、これにはデバイスが必要です。 ターゲットプラットフォーム用のポケットに電話がある場合は便利ですが、ボタン付きのNokiaがある場合は複雑です。 デバイスなどのある工場にアクセスする必要があります。



「かつては多数の仮想マシンを配置していた...」



-それでも、IEまたはEdgeでテストするには、仮想マシンが必要です。 簡単になりましたが、無料の仮想デスクトップをいくつか入れてください。 また、Internet Explorerは、適切なバージョンを備えた便利な無料の仮想マシンのレイアウトを開始しました。 それらをすぐにダウンロードします。



「マイクロソフトはあなたのことを考えています。」



-はい、テストの観点から、彼らは大いに役立ちました。



開発者はデスクトップのことを心配する傾向がありますが、もはや価値はありません。 そして、ブラウザ開発者はこれを支援しようとしています。 昨年11月のChrome Dev Summitで、彼らはChromiumベースのブラウザ向けのChrome用の新しいデバッガを発表しました。 以前にChromeでデバッグパネルを開き、通常のページと下部のパネルが表示されていた場合、適応バージョンが自動的に開きます。 サイズを変更できるウィンドウを開きます。このウィンドウでは、携帯電話のモデルを選択できます-彼はズーム、拡大縮小などを行います。 ブラウザ開発者は問題を解決しようとしています。 しかし、とにかく、テーブルの上の現代のAndroid、iOS開発者が、おそらく、彼はすでに遅れています。



-私は、モバイル開発に携わっている人たちがこれらのデバイスをすべて所有していることを知っています。 テストラボの役割は、スマートフォンを備えたボックスによって果たされます。このボックスでは、必要なものを受け取ります。



-自宅に4台の電話、3台のタブレット、その他のものがあります。 私の仕事の特異性は、私たちの会社の製品が動作するすべてのデバイスを持っているということです。 しかし、典型的な開発者が自分の携帯電話と間違ったプラットフォームしかない場合、彼は運が悪かった。



-ボタン電話にはOpera Miniがあります。



-私は時々店に行き、ボタン付きのあらゆる種類の携帯電話を探します。 彼らはまだ単純な携帯電話を生産し続けています。 私たちのブラウザが存在する前に、去年、私たちは彼らとすべてJavaで実行されているSシリーズの携帯電話を転送し、その結果私たちのソリューションに転送する契約を結びました-今ではすべての新しい携帯電話にOpera Miniを搭載しています。



-Opera Miniでは、多くの興味深い技術が生まれ、それが「大きな」Operaになりました。 たとえば、Prestoエンジン上の古いOperaには、興味深いストーリーがありました。サーバーを介して画像のレンダリングを開始すると、オプションのサーバーレンダリングが画像を圧縮し、ユーザートラフィックを節約し、ページの読み込みを高速化します。



-Opera Miniとは直接関係ありませんでした。他の出来事が発生しているためです。 それぞれトラフィックを通過させ、写真は圧縮されていました-最初はより強いjpgでしたが、その後WebPなどを使用し始めました。



しかし、Opera Miniはまだ人気が出てきましたが、一部のサイトはまだ機能していません。 JavaScriptはすぐに実行できないため、Opera Miniでのクライアントレンダリングは機能しません。 あなたはサーバーに行く必要があり、それでも何も道を破壊せず、戻ってくる。 ドロップダウンメニューなどの次のフレームを描画するには、サーバーに移動する必要があります。 長すぎます。 そのため、Opera Miniと同じくらい強く圧縮するが、動作が異なるテクノロジーの開発を続けています。



-Opera Miniは開発中ですか? それは古い携帯電話用のインターネットですか、それとも、たとえば、何らかの組み込みデバイス、またはテレビですか?



-一度Opera Miniがシンプルなボタン携帯電話で動作するようになった後、Android用Opera Miniをリリースしました。これは、ブックマーク、インターフェース、ボタン、タッチなどがある本格的なブラウザです。 ただし、ページはとにかくサーバー上でレンダリングされます。



iOS向けのOpera Miniの立ち上げは興味深い転換点でした。 3つの圧縮モードがありました。通常のSafariエンジンがあります。iOSには圧縮画像を備えたSafariとOpera Miniしかありません。 また、トラフィックを節約し、互換性を保つために必要な量に応じて、圧縮モードを切り替えることができます。 Opera MiniのプロダクトマネージャーであるChristine Uribeが私に言ったように、Mini圧縮はデバイスによって少し異なります。 iPhoneでは、人々は高品質の写真に慣れているため、圧縮された写真は少なくなります。 また、小型の携帯電話では、より強力な圧縮が機能します。



今日、私たちは普通の携帯電話から大型デバイスに移行しました。 多くの市場では、Android用の2つの本格的なブラウザ、OperaとOpera Miniがあります。 Operaには独自のエンジンがあり、レンダリングは電話で直接行われます。 すべてはChromiumエンジンを使用して描画されます。 Opera Miniでは、レンダリングはサーバー上で動作し、すべてが圧縮されます。JavaScriptなどの一部の機能はまったく動作しません。 おもしろいことは次のとおりです。人々は強力なスマートフォンでOpera Miniをますます選択しています!



-エンジニアリングの観点から、OperaとOpera Miniの違いは何ですか?



-視覚的には同じように見えますが、それらのページは異なってレンダリングされます。 その結果、トラフィックが高く、貧弱で、ネットワークが混雑している国々、一部のアジアやアフリカの国々の人々は、しばしばOpera Miniを選択します。 彼らの3Gは、通常のインターネットよりも早く有線で始まりました。 したがって、ネットワークは過負荷になり、全員が携帯電話からのみインターネットにアクセスしています。 そして、まったく異なる問題を解決する必要があります。



ブラウザによるRFIDタグとビーコンのサポートについて



-ジオロケーションAPIに関連してWebはどのように変わりますか? 私はこの例を知っています。あなたは地下鉄を離れ、最寄りの醸造所と契約していて、ギスメテオと気温に関するデータを持っているプロバイダーがSMSを送信します。 そんなビールハウスで冷たいビールを飲みたいですか?」 Webは本当に見たこともない方法になります。ジオデータが表示され、ビッグデータが表示されます...これについてどう思いますか? おそらくOperaはこの分野で何かをしているのでしょうか?



-8月のどこかで、bicons(フィジカルウェブ、Android向けのOperaの単なる実験ビルド)のサポートをリリースしました。 そして、それがこの領域を探求する私たちの試みでした。 これらは、ブラウザにブロードキャストされる実際のRFIDタグです。 お使いの携帯電話でブラウザを開いている場合、Androidで何らかのラベルがあることを知らせる通知が送信されます。 たとえば、バス停に来て、スマートフォンでバスの時刻表を見ることができます。



-Opera自体が通知を送信しますか?



-はい。 ブラウザはこれらのマークを使用できます。 Android自体ではなく、ブラウザです。



ほとんどのタグはリンクです。 エンコードする方法はいくつかあります。 私の家には、2〜3年無料で使える小さな小さな白い箱があります-単に封印されています。 彼女は側面にステッカーを持っています。 貼り付け、貼り付け、エンコードして、いくつかのアドレスまたは現在の温度をブロードキャストしました。 そして、これらはすべてブラウザに送信できます。



-あなたが地下鉄の出口にそのようなビーコンを置いた場合、私もする必要はありません

連絡先プロバイダー...



-はい、Opera自体が場所に関連する情報を提供します。 ところで、これは、Chromeで最近開始されたため、Chromiumに先んじたケースの1つでした。 そして、2015年8月になんとかできました。 同じエンジンを持っていますが。 私たちは実験にもう少し投資し、それを急いでいくつかのことを試みました。 そして今、私が話したのと同じChrome Dev Summitで、各参加者に小さなビーコンが与えられました。 その結果、400人がプログラム可能なこれらの小さなものを残しました。



-長い間、あらゆる種類のモバイルアプリケーションを作成して、人が会議に来てホールに行き、会議アプリケーションが彼にすべてではなく、このホールに関連する何かを表示するように提供されてきました。 たとえば、現在この部屋にある特定のレポートに関する情報。



-会議で全員がバイコンを与えられたのはとても面白かったです。 400人用のホールがあり、誰もがポケットにビーコンを持っています。 そして、あなたは電話を開き、どれがあなたのものかを理解しようとします-そして、それらの多くがあります。 これらはすべて、工場出荷時にデフォルトで含まれています。

そして、私は自分自身を見つける方法を思いつきました! そこに温度センサーがあるので、ビーコンを少しこすりました-温度が上がったので、自分で登録しました。



-それらを使用すると、多くの問題を解決できます。 データを取得できます:人々がどのように歩き、どの部屋で。 フィードバックプロファイルを詳細に送信できます。 バッジを掛けることができます。



-原則として、これは興味深いタスクです。 問題はこのテクノロジーをどのように適用するかです。私たち全員がそれをサポートしましたが、広告プロデューサー、エンターテインメントプロデューサー、または他のビジネスがそれを使い始める必要があります。










All Articles