Ramblings pada Fitur Browser Baru, Interoperabilitas, Kerajinan, dan Masa Depan Web



Harga
Deskripsi Produk Ramblings pada Fitur Browser Baru, Interoperabilitas, Kerajinan, dan Masa Depan Web

Minggu lalu Peter-Paul Koch (PPK) memposting sebuah risalah yang panjang tentang mengapa browser harus berhenti "mendorong web maju". Aku benar-benar menikmati membaca dan setuju dengan dia pada sejumlah poin. Saya juga setuju dengan tanggapan yang diartikulasikan dengan baik dari Jake Archibald (dari Google) dan Bruce Lawson (dari Opera). Kurasa aku bilang aku melihat kedua sisi. Seperti Chris Coyier, saya tinggal di dunia yang dipenuhi berbagai nuansa abu-abu dan bukan hitam & putih.
Fitur Baru vs. InteroperabilitasKlik untuk mendapatkan tautan ke tempat yang tepat ini.
Salah satu argumen yang dibuat PPK adalah melawan browser yang bersaing dengan fitur. Itu benar-benar berbunyi jujur ??padaku:
Saya meminta moratorium fitur browser baru sekitar setahun. Mari kita tunda semua fitur baru yang saat ini belum berfungsi di browser manapun. Browser didorong untuk menambahkan fitur yang sudah didukung oleh browser lain, dan untuk menulis perbaikan bug. Sebenarnya, mencari waktu untuk pekerjaan yang tidak penting tapi perlu ini akan menjadi keuntungan penting dari moratorium tersebut. Sebagai bonus tambahan akan menurunkan jumlah tool yang dibutuhkan pengembang web.
Kembali pada bulan Januari, saya menulis tentang bagaimana saya sangat senang dengan pengumuman Microsoft "Project Spartan" (sekarang "Microsoft Edge") dan fokus pada interoperabilitas. Interoperabilitas adalah kata yang panjang, jadi saya akan pergi dengan "interop" dari sini keluar.
Standar web membantu kami mendapatkan semua orang di halaman yang sama dan menengahi apa yang kami harapkan akan menjadi kedamaian abadi.
Saat itu saya tidak berada dalam daftar gaji Microsoft saat itu, tapi saya masih terpaku melihat fokus mereka pada interop di mesin rendering yang baru. Mereka bahkan telah pergi, menurut pendapat saya yang rendah hati, di atas dan di luar dalam hal ini - mengaitkan algoritme CSS eksperimental dan legacy Webkit ke penerapan modern berbasis standar mereka. Ini memastikan bahwa situs dengan kode buruk bekerja dengan baik di browser mereka dan tidak menghukum pengguna karena kesalahan perancang. Bicara tentang menjadi warga web yang baik!
Tentu saja, Microsoft Edge bukanlah browser pertama yang melakukan hal ini. IE 7 Mobile diimplementasikan -webkit-text-size-adjust kembali di tahun 2010. Opera dan Mozilla juga merasakan tekanan dan akhirnya menerapkan - awalan awalan pada versi browser mereka. Ini adalah dunia yang aneh ketika satu vendor browser dipaksa untuk menerapkan sintaks milik orang lain hanya untuk membuat karya web, tapi ini adalah keadaan menyedihkan dari keseluruhan perkembangan dunia StackOverflow kita.
Dengan beralih dari awalan vendor di CSS ke "bendera fitur", Anda akan menganggap hal seperti ini ada di belakang kami, tapi sebenarnya tidak. Karl Dubost, dari Mozilla, baru-baru ini mengeluhkan implikasi dari kecanggihan awalan vendor terbaru Apple di blognya. Di pos itu, dia melakukan pengamatan yang tajam:
Kami telah mencapai titik di mana vendor browser harus mulai menerapkan atau meng-aliasing prefiks WebKit ini hanya agar pengguna mereka dapat mengakses Web, lihat Mozilla di Gecko dan Microsoft di Edge. Hal yang sama terjadi lagi. Di masa lalu, vendor browser harus menerapkan kebiasaan IE agar kompatibel dengan Web. Sebanyak yang saya benci, kita harus menentukan awalan -webkit saat ini untuk menerapkannya secara seragam.
Saya benar-benar mengerti keinginan PPK agar browser sedikit mengerem dan fokus pada interop. Dengan fitur baru ditambahkan ke "web" -tetapi kenyataannya hanya browser X, Y, atau Z-on yang biasa, tanpa interop yang terjamin, rasanya kita sedang mengaduk perang browser lagi. Semua kilau baru itu menggairahkan, tapi saya menjalani perang browser pertama kali dan mereka mengisap semua orang yang terlibat. Standar web membantu kami mendapatkan semua orang di halaman yang sama dan menengahi apa yang kami harapkan akan menjadi kedamaian abadi.
Sekarang saya tidak yakin saya setuju dengan mengerem rem untuk jangka waktu tertentu, tapi saya melihat nilai yang bagus dalam memprioritaskan interop mengenai fitur baru. Dan ketika browser menerapkan fitur baru, mereka pasti harus meletakkannya di belakang bendera fitur (atau beberapa pilihan serupa) untuk memastikan kita - komunitas pengembangan web - jangan mulai mengandalkan beberapa fitur baru yang keren sebelum telah diperiksa. Flag unggulan sangat hebat karena memungkinkan saya, perancang, untuk bereksperimen dengan teknologi baru di browser saya sendiri tanpa mempengaruhi hal-hal untuk orang lain di web terbuka.
Kami dulu berpikir prefiks vendor cukup jera untuk menggunakan properti CSS eksperimental tertentu atau metode JavaScript. Sayangnya itu ternyata tidak terjadi. Saya berani bertaruh uang yang baik pada kenyataan yang menyedihkan bahwa 80% perancang web yang bekerja di luar sana tidak mengerti bahwa - * - berarti "eksperimental" atau bahkan "eksklusif". Kami - para penulis, pembicara, pendidik, dan influencer perancang web - melakukan pekerjaan yang menyebalkan bahwa pesan dengan industri secara keseluruhan. Tetapi bahkan jika kita memburu orang-orang tentang hal itu, mungkin itu tidak akan menjadi masalah: properti yang dipasok oleh Vendor-prefixed bekerja. Dan sekarang mereka bekerja bahkan di browser yang tidak pernah mereka inginkan.
Jadi, inilah yang saya ingin lihat vendor browser lakukan:
Prioritaskan interop atas fitur baru. Jangan hentikan pengembangan fitur baru, taruh saja di belakang kompor sehingga pasang naik bisa, seperti yang mereka katakan, angkat semua kapal. Pengembang web dan pengguna akhir semuanya mendapatkan keuntungan saat ada fitur paritas dan stabilitas di antara browser.
Letakkan larangan pada prefiks vendor. Mereka umumnya tidak dipahami sebagai eksperimen. Jika Anda merasa harus menggunakan awalan vendor, pastikan itu hanya diaktifkan oleh flag fitur yang sesuai.
Gunakan bendera fitur (atau beberapa pilihan serupa) untuk memungkinkan pengembang menguji fitur eksperimental di browser mereka sendiri, namun juga untuk memastikannya tidak tersedia di "web terbuka" sebelum mereka siap.
Web vs. NativeClick mendapatkan tautan ke tempat yang tepat ini.
PPK telah menyinggung hal ini beberapa kali. Saat ini ada ketegangan antara "pribumi" dan "web". Ini mendorong sebagian besar fitur baru di "platform" web 1 dan ini memberi banyak dari kita orang tua sentuhan angina.
Jika Anda tidak meluangkan waktu untuk memahami bagaimana web bekerja, Anda menghabiskan separuh waktu untuk mengutuknya dan separuh lainnya mencoba mengatasi hal-hal yang membuat Anda frustrasi (yang mungkin Anda tulis sebagai "dirancang dengan buruk" atau tidak "Kurang dipahami").
Alasannya sederhana: Web diciptakan sebagai gudang dokumen yang saling berhubungan. Kekayaan pengetahuan bergantung pada hyperlink dan URL. Web itu (dan memang masih) tanpa kewarganegaraan secara default, yang berarti tidak tahu siapa Anda atau apa yang telah Anda lakukan dari permintaan untuk meminta. Ini sangat egaliter: setiap orang memiliki akses dan siapapun dapat berkontribusi.
Seiring semakin banyak bisnis bergerak online, web menjadi transaksional. Tiba-tiba situs web perlu mengetahui informasi tentang "negara bagian Anda" sehingga mereka dapat menjual barang dan melacak pergerakan Anda di sekitar situs mereka dan keseluruhan web. Dengan munculnya cookies dan Common Gateway Interface (CGI), server web dapat menyesuaikan konten yang dikirimnya sebagai tanggapan atas permintaan, berdasarkan pada apa yang diketahui tentang Anda dan apa yang Anda lakukan.
Dengan mengambil kapasitas sederhana ini selangkah lebih maju, menjadi mungkin untuk menulis perangkat lunak sebenarnya di web. Sistem pengelolaan konten mungkin merupakan perangkat lunak pertama yang bergerak secara online, namun segera diikuti. JavaScript datang dan memungkinkan kami menambahkan sedikit logika ke sisi klien, mengurangi ketergantungan kami pada perjalanan pulang-pergi ke server. Lalu kami mendapat Ajax dan seluruh dunia JavaScript meledak. Kami sekarang memiliki editor foto berbasis web, lingkungan pengembangan terpadu (IDE), permainan, dan banyak lagi, semua bergantung pada kemampuan JavaScript untuk berinteraksi dengan browser dan memanipulasi apa yang pengguna lihat secara real-time.
Ada beberapa intrik sebelumnya, tapi sepuluh tahun terakhir ini telah melihat dorongan terbesar untuk menghadirkan interaksi perangkat lunak yang lebih tradisional ke web. Puluhan organisasi, besar dan kecil, berusaha membuat tanda mereka menciptakan kerangka kerja untuk membangun pengalaman aplikasi berbasis web "generasi mendatang" ini. Jujur saja, saya tidak punya masalah dengan itu. Saya tidak benar-benar memiliki kepentingan dalam kerangka sisi klien, tapi saya juga tidak memiliki masalah dengan mereka ... memberikan pengembang yang ingin membawa talenta pemrograman mereka ke web memerlukan sedikit waktu untuk belajar tentang media.
Jika Anda tidak meluangkan waktu untuk memahami bagaimana web bekerja, Anda menghabiskan separuh waktu untuk mengutuknya dan separuh lainnya mencoba mengatasi hal-hal yang membuat Anda frustrasi (yang mungkin Anda tulis sebagai "dirancang dengan buruk" atau tidak "Kurang dipahami"). Jika Anda tidak mengerti bagaimana web bekerja, Anda akan membangun pengalaman rapuh yang runtuh seperti rumah kartu bila ada salah satu dari banyak dependensi Anda-jaringan, JavaScript, beberapa elemen tertentu atau API browser-tidak tersedia. Jika Anda tidak mengerti bagaimana web bekerja, apa yang Anda bangun hanya akan berada di web, bukan dari itu.
Saya tidak terlalu peduli tentang membawa pengalaman "asli seperti" "60fps" ke web. Bukannya saya tidak menulis perangkat lunak (saya lakukan), saya hanya tidak terlalu peduli jika sesuatu yang saya buat untuk web terasa seperti perangkat lunak terinstal. Saya akan melakukan segalanya dengan kekuatan saya untuk memastikan pengguna saya memiliki pengalaman yang hebat, namun saya tahu bahwa pengalaman setiap orang akan sedikit berbeda dan saya tidak lagi merasakan kebutuhan untuk memaksakan kehendak saya atas pengalaman mereka. Saya lebih suka menciptakan banyak cara bagi seseorang untuk berinteraksi dengan hal-hal yang saya bangun dan berharap satu atau lebih dari mereka bekerja dengan baik untuk siapa pun yang kebetulan dan perangkat apa pun yang mereka gunakan.
Perangkat lunak asli dan web selalu ada. Kami telah menginstal perangkat lunak pada komputer jauh sebelum web itu ada dan kami akan terus menginstal perangkat lunak selama ada komputer. Beberapa perangkat lunak akan berpindah ke web jika masuk akal jika melakukannya. Perangkat lunak lain akan tetap asli. Salah satu pilihan bisa benar atau salah tergantung pada apa yang ingin Anda lakukan. Misalnya, saya tidak akan pernah secara pribadi menulis editor foto di browser karena pengolahan gambar memerlukan banyak siklus memori dan CPU. Menempatkannya di browser memindahkannya satu tingkat lagi dari perangkat keras. Abstraksi memudahkan pengembangan, tapi selalu meningkatkan overhead dan mengurangi kinerja.
Perangkat lunak tradisional dan web bisa dan harus hidup berdampingan. Mereka juga bisa dan harus terus saling menginformasikan. Pada akhirnya, itu akan membantu kita melayani kebutuhan pengguna kita dengan lebih baik, namun mereka menggunakan ciptaan kita.
Ubah vs StagnasiKlik untuk mendapatkan tautan ke tempat yang tepat ini.
Mendasari keseluruhan "pribumi vs web" ini, menurut saya, perasaan banyak dari kita adalah orang tua yang memiliki web kita-web yang kita bangun di gedung-terlepas dari kita. Kami berpegang pada gagasan web sebagai platform terbuka2 bagi orang untuk berbagi pemikiran, hasrat, dan foto kucing mereka. Kami menyukai web seperti aslinya. Kami menyukai web saat kami membuatnya.
Web berubah. Dalam beberapa hal itu berubah menjadi lebih baik, dalam beberapa hal menjadi lebih buruk. Ini adalah binatang yang jauh berbeda hari ini daripada saat Tim Berners-Lee mengetikkan yang pertama <HEADER> dan Anda pasti bisa melakukan lebih banyak hal di browser sekarang daripada saat saya pertama kali mengambil HTML. Tapi saya tidak berpikir menghentikan kemajuan di web sangat dibutuhkan.
Seperti yang ditunjukkan Jake dalam tanggapannya, stagnasi bukanlah kebijakan yang baik. Stagnasi iPad hampir terbunuh. Hal ini juga menyebabkan banyak frustrasi pengembang dalam kedok IE 6.
Perubahan tidak secara inheren buruk. Ini kecepatan bisa sangat frustasi di kali, meskipun. PPK nampaknya akan merasa seperti itu tentang kecepatannya sekarang seperti Alex Russell yang menyesalkan kemajuannya yang lamban di tahun 2007. Tapi ketika Anda melangkah mundur, terutama dengan perspektif sejarah, Anda melihat perubahannya bersifat siklis dalam banyak hal. Masalah bandwidth yang kita hadapi selama era dial-up ada bersama kita lagi dalam bentuk jaringan bergerak. Pelajaran yang kita pelajari membangun web untuk layar 640x480 sama-sama berlaku di dunia yang dapat dikenakan. Dan interaksi berbasis teks yang kami buat di hari-hari awal akan menjadi template saat kami bergerak maju dengan berani ke ranah pengalaman pengguna berbasis suara.
Cutting Edge vs CraftClick untuk mendapatkan tautan ke tempat yang tepat ini.
Di posnya, PPK juga mengeluhkan bahwa kita hanya mendapatkan terlalu banyak fitur baru di web, yang membuat sulit untuk mengikuti. Lebih dari itu, bagaimanapun, membuat sulit untuk benar-benar memahami lebih jauh bagaimana karya-karya yang berbeda ini bekerja. Untuk benar-benar mengasah keahlian kita. Dengan kata lain, menjadi lebih sulit untuk menjadi ahli generalis.
Secara individu, kita tidak akan pernah bisa mempelajarinya semua, tapi secara kolektif kita bisa.
Jake dan Bruce benar-benar mendapatkan ini, seperti juga. Gardener Lyza Danger bahkan telah memberikan sebuah pembicaraan yang luar biasa mengenai topik ini. Volume draft, spesifikasi, dan konsep baru (belum lagi pilihan perkakas) sangat banyak. Saya yakin saya tidak tahu setengah dari fitur yang ada di spec HTML5, apalagi modul CSS3 sekian. Saya mungkin tidak akan pernah Dan aku baik-baik saja dengan itu. Saya akan memilih dan memilih potongan-potongan yang saya minati untuk bermain-main dan menemukan cara untuk mengintegrasikannya ke dalam praktik saya sedikit demi sedikit. Begitulah cara kita belajar. Begitulah cara kita selalu belajar.
Untuk meredakan kekhawatiran PPK, bagaimanapun, saya berpendapat bahwa ada lebih banyak lagi kita bekerja di web sekarang daripada di hari-hari yang serba santai sehingga ia mengingatnya dengan sangat baik. Dan kita berbagi apa yang kita pelajari. Entah didorong oleh keinginan altruistik untuk menyebarkan pengetahuan atau ketertarikan pada ketenaran seperti rockstar di industri (atau bahkan smidge keduanya), tidak masalah bagaimana kejadiannya - faktanya adalah begitu. Kita belajar dan kita berbagi. Dan alat yang kita miliki sekarang membuatnya lebih mudah untuk melakukannya. Kami tidak hanya memiliki majalah dan outlet blogging biasa, tapi kami juga memiliki CodePen dan JS Bin dan Github dan banyak lagi.
Kita masing-masing memiliki kemampuan untuk meneliti keluar dari satu bidang desain web yang spesifik dan menjadi saluran pengetahuan itu ke dalam sarang histori desain web. Lihatlah Sara Soueidan dengan SVG atau Rachel Nabors dengan CSS Animation atau Zoe Mickley Gillenwater dengan flexbox. Secara individu, kita tidak akan pernah bisa mempelajarinya semua, tapi secara kolektif kita bisa. Bersama-sama, kita bisa mengatasi masalah dengan mengakses apa yang perlu kita ketahui saat kita perlu mengetahuinya.
Kemudahan Pengembang vs. Kebutuhan PenggunaKlik untuk mendapatkan tautan ke tempat yang tepat ini.
Sudut lain dalam potongan yang sangat padat dari PPK ada di sekitar perkakas dan polyfill:
Kami mendapatkan lebih banyak fitur yang menjadi semakin kompleks dan membutuhkan lebih banyak peralatan polihf dan alat lainnya untuk berfungsi-alat yang merupakan bagian dari masalah, dan bukan solusinya.
Seluruh "mengisi dan memindahkan gerakan" membuatnya sedikit kesal. Saya berbagi sentimennya. Saya tidak berpikir solusi berbasis JavaScript harus dianggap "cukup baik" untuk interop. JavaScript tidak dijamin Apalagi, implementasi JavaScript juga tidak akan pernah secepat implementasi browser. Jika browser ingin mengambil polypill dan menerapkannya di belakang layar, tidak apa-apa karena akan berjalan lebih cepat, namun memuat situs web kami dengan potensi megabyte senilai polyfill agar bisa menggunakan "standar" baru tampaknya menggelikan.
Kita menghabiskan lebih banyak waktu untuk memecahkan masalah pembangunan kita sendiri (secara sah dalam beberapa kasus, dibuat di pihak lain) dengan melemparkan lebih banyak kode ke masalah ini.
Sebagai industri, kami melakukan banyak tatapan pusar. Kita menghabiskan lebih banyak waktu untuk memecahkan masalah pembangunan kita sendiri (secara sah dalam beberapa kasus, dibuat di pihak lain) dengan melemparkan lebih banyak kode ke masalah ini. Sebagai konsekuensinya, pengguna kami membayar harga di situs yang lebih lambat, halaman web yang lebih berat, kinerja buruk, dan pengalaman buruk (atau tidak ada pengalaman). Dan, lebih dari itu, kita memecahkan masalah kita bukan masalah mereka.
Semua tidak hilangKlik untuk mendapatkan link ke tempat yang tepat ini.
Kami adalah desainer. Desain adalah tentang memecahkan masalah bagi pengguna kami, bukan menciptakan yang baru untuk mereka. Apakah kita sedang menulis kode, membuat sketsa antarmuka, menyalin authoring, mengurasi konten, atau membangun server, kita harus membuat setiap keputusan berdasarkan pada apa yang akan menguntungkan pengguna kita. Jika itu berarti kita tidak bisa menggunakan teknologi baru yang mengilap, biarlah. Kita masih bisa bermain dengan barang baru di browser kita sendiri, di situs pribadi kita, dan di CodePen. Kita bisa belajar tentang mereka dalam eksperimen kita sendiri dan berbagi pengetahuan itu dengan industri lainnya. Kita bisa memperbaiki keahlian kita. Web bisa menjadi lebih baik.Baca juga: map raport
5 24
Copyright © 2015. OKEbutik Template Allright reserved.