Akankah HTML5 / JS Akhirnya Mengganti Semua Bahasa Sisi Klien? [Tutup]

12

Saya hanya ingin tahu tentang masa depan dari semua itu. IMHO, ada 4 kekuatan yang menentukan kemana teknologi berjalan: Microsoft, Apple, Google, Adobe.

Sepertinya di Apple iPhone / iPad iADs sekarang dapat diprogram dalam HTML5. Jadi apakah itu berarti HTML5 akhirnya akan menggantikan objektif-c?

Selain itu, Microsoft kini telah mengalihkan fokusnya dari WPF / Silverlight ke HTML5 dan saya berasumsi Visual Studio 2011 akan membahas tentang dukungan perkakas untuk HTML5. Karena itulah yang dilakukan Microsoft. (Alat). Dalam beberapa bulan, IE9 browser utama terakhir akan mendukung HTML5.

Demikian pula Adobe mendapatkan ikut-ikutan HTML5 dan memungkinkan untuk mengekspor konten flash ke HTML5 dalam alat terbaru mereka.

Dan kita semua tahu berapa banyak di tempat tidur Google dengan html5. Heck, Sistem Operasi terbaru mereka (Chrome OS) hanyalah peramban web besar.

Aplikasi untuk Seluler (yaitu, iPhone, Android, WM7) sangat sulit bagi perusahaan untuk memprogram terutama untuk banyak perangkat yang berbeda (masing-masing dengan bahasa mereka sendiri) jadi saya berasumsi ini tidak akan bertahan terlalu lama. Yakni, HTML5 akan menjadi bahasa pemersatu. Yang agak menyedihkan bagi pengembang aplikasi karena sekarang pengguna akan dapat memainkan aplikasi html5 "keren" secara gratis di web dan itu akan sulit untuk menagihnya.

Jadi apakah bahasa yang diketik dengan kuat benar-benar hancur, dan di masa depan, katakanlah 5-10 tahun, akankah pemrograman sisi klien hanya menggunakan HTML5? Akankah kita semua menjadi programmer javascript? :) Karena tanda-tanda pasti menunjuk ke sana ...

programming-languages client-relations html5

1

Para pendukung peningkatan progresif itu harus berguling di kuburan mereka sekarang.

— Gio Borje

2

apakah Anda mengatakan manfaat dari pengetikan yang kuat tidak lagi diperlukan?

— Aaron Anodide

1

Saya pikir itu akan menjadi VS 2012, bukan VS 2011.

— DeadMG

6

Jika itu masalahnya, aku harus bunuh diri.

— Pekerjaan

2

Saya lelah mengkhawatirkan kompatibilitas browser. Ini sangat kekanak-kanakan.

— The Muffin Man

14

Saya pikir itu salah arah untuk menyarankan bahwa HTML5 / JS akan menggantikan SEMUA bahasa sisi klien. Akankah banyak aplikasi seperti itu di tahun-tahun mendatang? Ya mungkin. Akankah mereka semua? Tidak.

Poin utama lainnya yang perlu diperhatikan adalah bahwa bentang alam terus berubah. HTML5 adalah teknologi hebat yang menjanjikan untuk memecahkan banyak masalah yang saat ini dimiliki pengembang ketika mencoba menulis aplikasi yang bekerja lintas platform. Tentu, HTML5 / JS dapat memecahkan banyak masalah tersebut, tetapi lanskap akan berubah dan serangkaian masalah baru akan muncul. HTML5 pada akhirnya akan tampak usang.

Dalam 10 tahun, tanyakan pada diri Anda apakah HTML5 / JS adalah solusi untuk semua masalah dan saya bisa menjamin jawabannya tidak. Dalam 20 tahun pertanyaan itu sendiri mungkin akan tampak konyol.

— Damovisa
sumber

+1 Saya sepenuhnya setuju. Lihat kembali sedikit sejarah, "terbaru dan terhebat" selalu digantikan oleh "terbaru dan terhebat" yang baru. Itu adalah bagian dari apa yang begitu hebat tentang pemrograman, itu akan selalu berkembang.

— Beth Whitezel

banyak hal berevolusi pada kecepatan yang berbeda - seperti interaksi pengguna komputer - kartu punch, kemudian keyboard, kemudian mouse - saya sering bertanya-tanya apa yang berikutnya karena itu mungkin membuktikan pengubah permainan utama dalam aplikasi klien dev - speech, 3D - mereka menambahkan - tetapi akan sesuatu menggantikan keyboard / mouse? Saya pikir begitu - meskipun tidak yakin kapan.

— Aaron Anodide

6

Javascript adalah bahasa pemrograman yang sangat buruk. Terjemahan dari bahasa pemrograman yang diketik secara statis, seperti Java dengan GWT, menjadi semakin umum. Javascript mungkin menjadi jenis bahasa pemersatu yang sama dengan assembler - Anda dapat menulis di dalamnya secara langsung, tetapi jarang itu ide yang bagus.

— Don Reba
sumber

1

Tidak tahu hanya tentang bahasa yang diketik secara statis, tetapi jika Anda melempar jQuery atau MooTools atau sejenisnya di sana, saya akan setuju dengan Anda :)

— Damovisa

8

Saya tidak setuju dengan Anda bahwa JavaScript adalah bahasa yang buruk, ini sama sekali tidak benar! :) Karena tampaknya ada banyak programmer malas yang tahu Java atau bahasa sisi server lain selama bertahun-tahun dan mereka tidak ingin memperbaiki diri dengan mempelajari bahasa baru dan mereka mengatakan JavaScript itu buruk: D Itu sebabnya ada begitu banyak alat dan kerangka kerja untuk menghasilkan JavaScript dengan bahasa sisi server! JavaScript bukan mainan web, itu bahasa nyata!

— Zango

Saya juga tidak setuju. Saya percaya ini adalah komentar yang salah tempat tentang JavaScript. Banyak profesional dan produk yang sukses tidak setuju. Waktu adalah ujian terbaik, dan sejauh ini JS melakukan pekerjaan yang baik untuk mengatasi jam teknologi.

Saya tidak dapat membayangkan mengapa saya lebih suka menulis 50 baris Java, berharap bahwa perubahan saya dapat ditukar, ketika saya bisa menulis sepuluh baris Javascript, dan hanya memuat ulang halaman. Atau apakah web server restart telah dihilangkan ketika saya tidak melihat?

— kevin cline

5

Saya telah menulis perangkat lunak komersial dalam sekitar selusin bahasa selama karier saya dan saya menulis JavaScript setiap hari. JavaScript adalah bahasa yang masuk akal mengingat itu dirancang dan diterapkan selama beberapa minggu pada tahun 1995. Meski begitu, saya tidak dapat memahami para pembela JavaScript. Ini memiliki kelemahan serius yang mengharuskan pembuat kode yang bertanggung jawab untuk sepenuhnya menghindari fitur bahasa tertentu, dan menggunakan yang lain dengan cara yang awalnya tidak dimaksudkan untuk menyediakan fungsionalitas yang hilang. Mungkin mereka tidak menggunakannya untuk proyek besar? Saya telah menemukan bahwa menggunakannya untuk sistem besar dengan banyak coder relatif sulit.

— PeterAllenWebb

1

Iya.

Inilah sebabnya. Aplikasi terdiri dari kode antarmuka pengguna dan data back-end. Kode antarmuka pengguna dijalankan dalam HTML5 / CSS3 / Javascript. Kode back-end dapat menjadi milik dan dijalankan dalam bahasa apa pun. Selain itu, jQTouch dan perpustakaan serupa dapat digunakan untuk meniru UI mirip iPhone tetapi open-source dan ditulis dalam Javascript / HTML5 / CSS. jQTouch telah menunjukkan bahwa jika browser memberi JS programmer akses ke acara UI perangkat, programmer JS akan meniru gaya UI mana pun yang sedang mode untuk platform yang sama.

Pemrogram Javascript akan lebih laris dari sebelumnya. Dalam arsitektur model-view-controller, model dan pengontrol berada di bagian belakang, tetapi kode tampilan paling baik ditulis di browser. yaitu HTML5, Javascript, CSS. Dan Anda perlu menulis kode JS untuk mengakses data back-end, terutama dengan kode AJAX yang berat.

Keuntungan produktivitas semua akan pergi ke bahasa yang ditafsirkan dinamis. Seiring dengan semakin cepat dan cepatnya prosesor, produktivitas pengkodean programmer, produktivitas sysadmin, dan produktivitas aplikasi-admin adalah pengaruh yang lebih kuat pada produktivitas keseluruhan. Anda tidak perlu khawatir tentang seberapa cepat kinerja VM atau kompiler bahasa pemrograman Anda. Anda perlu lebih khawatir sekarang tentang berapa biaya untuk penyediaan dan dukungan aplikasi Anda.

Sebagian besar aplikasi yang berdiri sendiri tidak terlalu bagus menurut saya. Sama seperti ada beberapa aplikasi PC mandiri yang hebat, dan yang terbaik sedang diubah menjadi aplikasi web. Sebenarnya lebih baik untuk memberikan aplikasi klien HTML / JS / CSS secara gratis dan membebankan biaya bulanan untuk akses ke data back-end dan logika bisnis. Pemrogram akan melakukan langganan penjualan yang lebih baik daripada aplikasi satu-shot.

BTW melihat video ini tentang menulis bagian dari aplikasi web mandiri di browser Webkit. Ini menarik...

— Jay Godse
sumber

1

Nah satu hal yang menyenangkan tentang aplikasi "satu-shot" adalah bahwa setidaknya Anda tidak harus melakukan seluruh nama pengguna / kata sandi yang menyebalkan seperti Anda hampir di mana-mana di web. Status disimpan secara lokal. Juga, banyak aplikasi sisi klien tidak benar-benar membutuhkan back-end. Pikirkan game flash. Dan siapa di dunia yang membeli langganan untuk game flash mom football? Tidak ada Dan siapa di dunia yang membeli aplikasi seluler? semua orang. Sayangnya, saya khawatir html5 akan mematikan aplikasi. Sangat menyenangkan memiliki pengembang independen menghasilkan uang sekali saja.

@ Schnitzel - Pengembang independen akan menghasilkan uang jika mereka juga membangun back end.

— Jay Godse

2

-1 untuk "Keuntungan produktivitas semua akan pergi ke bahasa yang ditafsirkan dinamis" - itu sangat salah menurut saya. Saya jauh lebih produktif dalam bahasa statis yang diketik dan dikompilasi seperti Scala. Saya menemukan kesalahan jauh lebih cepat, langsung di IDE saya, daripada yang saya miliki dengan bahasa dinamis seperti PHP, Python dan Ruby.

— Jonas

Saya benar-benar tidak melihat manfaat untuk menggunakan PHP / Ruby / Python, bukan Scala.

— Jonas

@Jonas - Pertanyaan Anda sendiri di programmers.stackexchange.com/questions/7516/… menunjukkan bahwa bahasa dinamis memimpin paket produktivitas.

— Jay Godse

1

Ada keinginan untuk mengganti bahasa pengkodean aplikasi seperti C ++, Java ... dengan HTML / Javascript. Ada banyak alasan di balik itu, beberapa di antaranya:

Pengembangan lebih cepat
Tenaga kerja lebih murah
Konektivitas terpasang
Lebih mudah menghasilkan sesuatu yang terlihat bagus
Teks dapat diakses oleh mesin pengindeksan

Namun mungkin bahasa lain akan muncul, untuk digunakan sebagai pengganti drop-in untuk JavaScript. Bagaimanapun, sulit untuk memiliki bahasa yang dapat melakukan segalanya dengan benar, sambil tetap menggunakan bahasa tingkat tinggi! Dan JavaScript telah ada untuk sementara waktu dan mengakumulasi beberapa kekurangan.

JavaScript mungkin berakhir sebagai bahasa utama untuk sisi klien, namun saya pikir itu bukan satu - satunya bahasa, karena JS menjadi bahasa yang digerakkan oleh standar, dirancang oleh komite, ini hanya akan mematikan inovasi pada tingkat itu (bahasa pemrograman).

— Rolf
sumber

0

Ini juga tergantung pada keterampilan mayoritas pengembang dan alat yang mereka gunakan. Raksasa teknologi yang Anda sebutkan dapat menggerakkan teknologi berdasarkan alat yang mereka sediakan. Sebagai contoh, orang mengatakan HTML5 adalah Flash killer tapi saya merasa terlalu jauh ada banyak pengembang Flash dan itu adalah tugas yang menakutkan untuk mengalihkan keterampilan mereka ke JavaScript. Apa yang akhirnya terjadi, skill tetap sama tetapi output menjadi berbeda. Dalam hal ini, Adobe mengeluarkan alat konversi HTML5.

Anda juga harus memikirkan kinerja aplikasi klien. Jika diperlukan, alat khusus platform akan digunakan. Mengambil game dan aplikasi iOS misalnya. Saya tahu WebGL keluar bagus tapi saya merasa orang masih menggunakan C untuk membuat game. Atau mereka akan membuat bahasa gim yang menciptakan gim berkinerja tinggi. Apple awalnya hanya menginginkan webapps tetapi ketika pengembang melihat keajaiban Cocoa mereka langsung menggunakannya untuk membuat aplikasi berkelas.

Singkatnya, akan selalu ada alat / bahasa / teknologi baru yang akan selalu lebih keren daripada yang saat ini.

— Manish
sumber

0

Tidak semua tapi mungkin sebagian besar. Mungkin javascript bisa menjadi cukup cepat untuk menggantikan HashCalc tetapi tidak ada alternatif web untuk VLC (browser tidak akan mendukung semua codec itu). Saya ragu webbrowsers akan membiarkan saya mengakses file apa pun yang saya inginkan atau menyimpan daftar file terbaru (tanpa 'apakah ini oke untuk diakses' setiap kali saya mengklik file baru-baru ini) dan saya tidak suka gagasan mendistribusikan aplikasi yang 99% browser web (beberapa mb) dengan 100kb kode saya ketika datang ke kasus di mana kode istirahat browser bc tidak kompatibel dengan html atau saya perlu varian / sedikit modifikasi dari webkit.

-edit- juga saya suka bahasa statis daripada dinamis tetapi saya berasumsi saya bisa menggunakan bahasa yang baik dengan LLVM yang harus didukung oleh browser.

-1

Saya pikir kita akan terus ke arah itu sampai browser menjadi sistem operasi dan kemudian semuanya akan mulai siklus ulang dalam urutan yang sama tetapi dengan pelajaran dan perbaikan.

— Aaron Anodide
sumber