Mengapa praktik yang buruk mengembalikan HTML yang dihasilkan alih-alih JSON? Atau itu?


301

Sangat mudah untuk memuat konten HTML dari URL / layanan Web khusus Anda menggunakan JQuery atau kerangka kerja serupa lainnya. Saya telah menggunakan pendekatan ini berkali-kali dan sampai sekarang dan menemukan kinerja yang memuaskan.

Tapi semua buku, semua ahli berusaha membuat saya menggunakan JSON alih-alih HTML yang dihasilkan. Bagaimana ini jauh lebih unggul daripada HTML?

Apakah ini jauh lebih cepat?
Apakah ada beban yang jauh lebih kecil di server?

Di sisi lain saya punya beberapa alasan untuk menggunakan HTML yang dihasilkan.

  1. Ini markup sederhana, dan seringkali sama kompak atau sebenarnya lebih kompak dari JSON.
  2. Itu kurang rawan kesalahan karena semua yang Anda dapatkan adalah markup, dan tidak ada kode.
  3. Ini akan lebih cepat diprogram dalam banyak kasus karena Anda tidak perlu menulis kode secara terpisah untuk klien.

Di sisi mana Anda berada dan mengapa?


Perlu dicatat bahwa X dalam AJAX adalah XML, dan HTML pada satu titik seharusnya XML. Idenya adalah bahwa HTML adalah data yang dapat dibaca manusia dan mesin (seperti JSON), dan CSS akan melakukan presentasi. Di bawah kondisi itu, itu tidak akan melanggar "pemisahan keprihatinan" untuk mengirim HTML dalam permintaan AJAX
code_monk

Jawaban:


255

Saya agak di kedua sisi, sebenarnya:

  • Ketika yang saya butuhkan di sisi javascript adalah data , saya menggunakan JSON
  • Ketika apa yang saya butuhkan di sisi javascript adalah presentasi di mana saya tidak akan melakukan perhitungan, saya biasanya menggunakan HTML

Keuntungan utama menggunakan HTML adalah ketika Anda ingin mengganti sebagian penuh halaman Anda dengan apa yang kembali dari permintaan Ajax:

  • Membangun kembali sebagian halaman di JS (cukup) sulit
  • Anda mungkin sudah memiliki beberapa mesin templating di sisi server, yang digunakan untuk menghasilkan halaman di tempat pertama ... Mengapa tidak menggunakannya kembali?

Saya biasanya tidak benar-benar mempertimbangkan sisi "kinerja", paling tidak di server:

  • Di server, menghasilkan sebagian dari HTML atau JSON mungkin tidak akan membuat banyak perbedaan
  • Tentang ukuran barang yang melewati jaringan: well, Anda mungkin tidak menggunakan ratusan KB data / html ... Menggunakan gzip pada apa pun yang Anda transfer adalah apa yang akan membuat perbedaan terbesar (tidak memilih antara HTML dan JSON)
  • Namun, satu hal yang dapat dipertimbangkan adalah sumber daya apa yang Anda perlukan pada klien untuk membuat ulang HTML (atau struktur DOM) dari data JSON ... bandingkan dengan mendorong sebagian HTML ke halaman; -)

Akhirnya, satu hal yang jelas penting:

  • Berapa lama waktu yang Anda butuhkan untuk mengembangkan sistem baru yang akan mengirim data sebagai kode JSON + yang diperlukan JS untuk menyuntikkannya sebagai HTML ke halaman?
  • Berapa lama untuk mengembalikan HTML? Dan berapa lama jika Anda dapat menggunakan kembali beberapa kode sisi server yang sudah ada?


Dan untuk menjawab jawaban lain: jika Anda perlu memperbarui lebih dari satu bagian halaman, masih ada solusi / retasan untuk mengirim semua bagian di dalam satu string besar yang mengelompokkan beberapa bagian HTML, dan mengekstrak bagian yang relevan di JS.

Misalnya, Anda dapat mengembalikan beberapa string yang terlihat seperti ini:

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Itu tidak terlihat benar-benar bagus, tapi itu pasti berguna (saya sudah menggunakannya beberapa kali, kebanyakan ketika data HTML terlalu besar untuk dienkapsulasi ke dalam JSON) : Anda mengirim HTML untuk bagian halaman yang butuh presentasi, dan Anda mengirim JSON untuk situasi yang Anda butuhkan data ...

... Dan untuk mengekstraknya, metode substring JS akan melakukan trik, saya kira ;-)


6
Semua data pada akhirnya disajikan.
Cyril Gupta

47
@Cyril: Hah? Saya pikir Anda mencoba mengatakan bahwa data, agar berguna, harus digunakan dan dengan demikian disajikan di suatu tempat dalam bentuk tertentu, dan saya setuju. Tetapi untuk mengatakan bahwa data adalah presentasi tampaknya sesat, paling tidak.
Vinko Vrsalovic

10
Hai Vinko, perhatikan 'akhirnya'? Maksud saya persis apa yang Anda maksud. Hanya mencoba masuk ke dalam buku kutipan yang dapat dikutip di sini. Ha ha!
Cyril Gupta

37
Pertanyaan mendasarnya adalah apakah Anda benar-benar, secara positif, pada akhirnya yakin Anda tidak akan menggunakan data ini untuk apa pun selain HTML. Karena begitu dikemas ke dalam HTML, data akan hampir tidak dapat dipulihkan. Dengan JSON, backend Anda dapat bekerja dengan XML, SVG, mesin basis data, lintas situs API dan ribuan frontend dan sistem lain yang dapat menerima JSON. Dengan HTML, Anda hanya dapat menggunakannya di dalam HTML.
SF.

3
@ SF: Ketika mengembalikan HTML dari server, saya pastikan untuk membagi kode penghasil HTML dari kode yang mengakses database. Dengan begitu saya bisa dengan mudah menambahkan formulir JSON juga.
Casebash

114

Saya terutama setuju dengan pendapat yang disebutkan di sini. Saya hanya ingin meringkasnya sebagai:

  • Merupakan praktik yang buruk untuk mengirim HTML jika Anda akhirnya mem-parsing sisi klien untuk melakukan beberapa perhitungan di atasnya.

  • Merupakan praktik yang buruk untuk mengirim JSON jika pada akhirnya Anda hanya akan memasukkannya ke dalam pohon DOM halaman.


3
bagaimana jika Anda perlu melakukan beberapa perhitungan dan juga memasukkannya ke DOM halaman?
Enrique

Saya ingin tahu berapa lama pernyataan di atas memiliki kebenaran yang melekat padanya, Jika Anda menambahkan " Paruh Pengetahuan " ke dalam persamaan?
Val

apakah mungkin untuk mengembalikan HTML yang memiliki tag <script> dan kemudian menjalankannya di sisi klien ketika halaman dimuat?
nish1013

Ini. Juga jika Anda mengembalikan data yang harus lancar dalam presentasinya dengan cara tertentu, misalnya jika Anda memiliki tabel HTML dengan kolom yang ingin Anda urutkan. Apakah Anda SUDAH membuat mereka disortir sekarang atau tidak, Anda mungkin ingin nanti, jadi dalam kasus seperti itu, pemeriksaan di masa depan sepadan dengan usaha ekstra untuk menempuh rute JSON.
trpt4him

Saya juga akan menambahkan, jika Anda meminta url gambar melalui JSON hanya untuk mencoba merendernya di halaman, itu jauh lebih baik untuk memasukkannya dalam HTML dari awal, sehingga gambar dapat mulai memuat lebih awal (sebelum ajax Anda kembali) .
FailedUnitTest

30

Baik,

Saya salah satu dari orang-orang langka yang suka memisahkan hal-hal seperti ini: - Server bertanggung jawab untuk mengirimkan data (model); - Klien bertanggung jawab untuk menunjukkan (melihat) dan memanipulasi data (model);

Jadi, server harus fokus pada pengiriman model (dalam hal ini JSON lebih baik). Dengan cara ini, Anda mendapatkan pendekatan yang fleksibel. Jika Anda ingin mengubah tampilan model Anda, Anda menjaga server mengirimkan data yang sama dan hanya mengubah klien, komponen javascript, yang mengubah data itu menjadi tampilan. Bayangkan, Anda memiliki server yang mengirimkan data ke perangkat seluler serta aplikasi desktop.

Juga, pendekatan ini meningkatkan produktivitas, karena kode server dan klien dapat dibangun pada saat yang sama, tidak pernah kehilangan fokus yang terjadi ketika Anda terus beralih dari js ke PHP / JAVA / dll.

Secara umum, saya pikir kebanyakan orang lebih suka melakukan sebanyak mungkin di sisi server karena mereka tidak menguasai js, jadi mereka mencoba untuk menghindarinya sebanyak mungkin.

Pada dasarnya, saya memiliki pendapat yang sama dengan mereka yang bekerja pada Angular. Menurut saya itu adalah masa depan aplikasi web.


Ya saya sangat setuju dengan Anda. Namun melakukan sebanyak sisi server ketika informasi sensitif yang saya anggap terbaik. Jika Anda memerlukan klien untuk bereaksi berbeda tergantung pada hasil saya akan menggunakan json kalau tidak saya akan menggunakan html.
Fi Horan

9

Saya punya sesuatu yang menarik yang saya pikir bisa saya tambahkan. Saya mengembangkan aplikasi yang hanya memuat tampilan penuh satu kali. Sejak saat itu ia dikomunikasikan kembali ke server dengan ajax saja. Hanya perlu memuat satu halaman (alasan saya untuk ini tidak penting di sini). Bagian yang menarik adalah bahwa saya memiliki kebutuhan khusus untuk mengembalikan beberapa data yang akan dioperasikan di javascript DAN tampilan parsial untuk ditampilkan. Saya bisa membagi ini menjadi dua panggilan ke dua metode tindakan terpisah tetapi saya memutuskan untuk pergi dengan sesuatu yang sedikit lebih menyenangkan.

Saksikan berikut ini:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

Apa itu RenderPartialViewToString () yang mungkin Anda tanyakan? Ini sedikit nugget kesejukan di sini:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

Saya belum melakukan pengujian kinerja pada ini jadi saya tidak yakin apakah itu menimbulkan lebih atau kurang overhead daripada memanggil satu metode tindakan untuk JsonResult dan satu untuk ParticalViewResult, tapi saya masih berpikir itu cukup keren. Ini hanya cerita bersambung tampilan parsial menjadi string dan mengirimkannya bersama dengan Json sebagai salah satu parameter itu. Saya kemudian menggunakan JQuery untuk mengambil parameter itu dan menamparnya ke simpul DOM yang sesuai :)

Beri tahu saya pendapat Anda tentang hibrida saya!


1
Mengirim tampilan yang diberikan dan data dalam satu permintaan tampaknya sedikit berlebihan. Hanya bercanda, jika Anda memiliki kemampuan untuk melakukan rendering tampilan sisi klien akan lebih baik untuk mengirim template tampilan dan data sebagai permintaan terpisah. Itu membutuhkan permintaan tambahan tetapi hanya sekali karena permintaan templat akan di-cache untuk permintaan selanjutnya. Idealnya akan lebih baik menggunakan kombinasi rendering tampilan sisi klien dan server sehingga Anda dapat membangun halaman di server dan sebagian di browser tetapi jika Anda hanya menerapkan rendering tampilan sisi server, ini bukan pendekatan yang buruk.
Evan Plaice

8

Jika respons tidak memerlukan pemrosesan sisi klien lebih lanjut, menurut saya HTML adalah OK. Mengirim JSON hanya akan memaksa Anda untuk melakukan pemrosesan di sisi klien.

Di sisi lain, saya menggunakan JSON ketika saya tidak ingin menggunakan semua data respons sekaligus. Sebagai contoh, saya memiliki serangkaian tiga pilihan rantai, di mana nilai yang dipilih dari satu menentukan nilai mana yang akan digunakan untuk mengisi yang kedua, dan seterusnya.


7

IMV, ini semua tentang memisahkan data dari penyajian data, tapi saya dengan Pascal, itu tidak selalu mengikuti pemisahan yang hanya bisa melintasi batas klien / server. Jika Anda sudah memiliki pemisahan itu (di server) dan hanya ingin menunjukkan sesuatu kepada klien, apakah Anda mengirim kembali JSON dan mempostingnya kembali pada klien, atau hanya mengirim kembali HTML, sepenuhnya tergantung pada kebutuhan Anda. Mengatakan Anda "salah" mengirim kembali HTML dalam kasus umum terlalu berlebihan untuk pernyataan IMV.


6

JSON adalah format yang sangat fleksibel dan ringan. Saya telah menemukan keindahannya ketika saya mulai menggunakannya sebagai data parser templat sisi klien. Izinkan saya menjelaskan, sementara sebelum saya menggunakan smarty dan tampilan di sisi server (menghasilkan beban server tinggi), sekarang saya menggunakan beberapa fungsi jquery khusus dan semua data ditampilkan di sisi klien, menggunakan browser klien sebagai parser templat. menghemat sumber daya server dan di sisi lain browser meningkatkan mesin JS mereka setiap hari. Jadi kecepatan parsing klien bukanlah masalah penting saat ini, bahkan lebih, objek JSON sangat kecil sehingga mereka tidak mengkonsumsi banyak sumber daya sisi klien. Saya lebih suka memiliki situs web yang lambat untuk beberapa pengguna dengan browser yang lambat daripada situs yang lambat untuk semua orang karena servernya sangat dimuat.

Di sisi lain, mengirim data murni dari server Anda abstrak dari presentasi jadi, jika besok Anda ingin mengubahnya atau mengintegrasikan data Anda ke layanan lain, Anda dapat melakukannya dengan lebih mudah.

Hanya 2 sen saya.


Dan bagaimana Anda memastikan Anda mendapatkan halaman yang dapat dibaca ketika javascript dinonaktifkan?
Vinko Vrsalovic

8
jika JS dinonaktifkan Anda tidak akan dapat memuat html juga. JS dinonaktifkan pada 2,3% pengguna menurut statistik Google Analytics saya. Cara terbaik untuk turun adalah mencoba menyenangkan semua orang.
Mike

4
Saya setuju 100% dengan Mike. Mencoba menyenangkan semua orang adalah hal yang mustahil dan hanya akan menyakitimu. Jika pengguna mematikan JS maka mereka harus digunakan untuk banyak situs yang tidak berfungsi untuk mereka sekarang.
Chev

1
Bagaimana Anda mendapatkan statistik JavaScript di Analytics karena Analytics menggunakan Javascript untuk melacak data?
Nick

@Nick Pertanyaan bagus, tetapi saya menemukan ini: stackoverflow.com/questions/15265883/…
Renan Cavalieri

6

Jika Anda ingin klien dipisahkan bersih, yang menurut saya adalah praktik terbaik, maka masuk akal untuk memiliki 100% DOM yang dibuat oleh javascript. Jika Anda membangun klien berbasis MVC yang memiliki semua tahu cara membangun UI maka pengguna Anda mengunduh satu file javascript satu kali dan itu di-cache pada klien. Semua permintaan setelah pemuatan awal berdasarkan Ajax dan hanya mengembalikan data. Pendekatan ini adalah yang terbersih yang saya temukan dan menyediakan enkapsulasi presentasi yang bersih dan independen.

Sisi server kemudian hanya berfokus pada pengiriman data.

Jadi besok ketika produk meminta Anda untuk mengubah desain halaman sepenuhnya, semua yang Anda ubah adalah sumber JS yang menciptakan DOM, tetapi kemungkinan bisa menggunakan kembali event handler yang sudah ada dan server tidak menyadari karena 100% dipisahkan dari presentasi


1
Saya setuju, Anda juga dapat menggunakan kembali json untuk aplikasi seluler Anda.
Alex Shilman

Ini seharusnya jawaban yang diterima - 6 - 7 kata pertama menjawab pertanyaan dengan singkat.
nicholaswmin

Setuju. Keuntungan dari data pengembalian (JSON) daripada presentasi (html) adalah bahwa Anda sekarang memiliki API web "gratis" yang dapat digunakan kembali untuk klien lain baik itu seluler atau aplikasi yang sama sekali berbeda yang tertarik pada beberapa data dari aplikasi ini. dll. Dalam pengalaman saya menggunakan kerangka kerja web sederhana di sisi server yang hanya berurusan dengan data dan tidak presentasi sering mengarah pada hasil yang baik dan sederhana. Browser dan CPU modern sangat cepat sehingga hanya dalam kasus-kasus khusus rendering akan menjadi hambatan. Hambatan terbesar sebagian besar adalah jaringan itu sendiri dan panggilan basis data.
beginner_

4

Bergantung pada UI Anda, Anda mungkin perlu memperbarui dua (atau lebih) elemen berbeda di DOM Anda. Jika respons Anda menggunakan HTML, apakah Anda akan menguraikannya untuk mengetahui apa yang terjadi? Atau Anda bisa menggunakan hash JSON.

Anda bahkan dapat menggabungkannya, mengembalikan data w / html JSON :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

Merupakan praktik yang buruk untuk mengirim JSON jika akhirnya Anda hanya akan memasukkannya ke dalam pohon DOM halaman ... dan dengan menggabungkan JSON dengan HTML Anda menggunakan praktik buruk ini
thermz

2

HTML memiliki banyak data yang berlebihan dan tidak ditampilkan yaitu tag, style sheet dll. Jadi ukuran HTML dibandingkan dengan data JSON akan lebih besar yang mengarah ke lebih banyak waktu pengunduhan dan render juga itu akan menyebabkan peramban menjadi sibuk merender data baru.


1

Mengirim json umumnya dilakukan ketika Anda memiliki widget javascript yang meminta informasi dari server, seperti daftar atau tampilan hierarki atau pelengkapan otomatis. Ini adalah ketika saya akan mengirim JSON karena ini adalah data yang akan diuraikan dan digunakan mentah. Namun jika Anda hanya akan menunjukkan HTML maka itu jauh lebih sedikit bekerja untuk menghasilkan sisi server dan hanya menampilkannya di browser. Browser dioptimalkan untuk memasukkan HTML secara langsung ke dalam dom dengan innerHTML = "" sehingga Anda tidak salah.


FWIW, innerHTMLsecara historis jauh lebih lambat daripada sebuah fragmen dokumen: coderwall.com/p/o9ws2g/… .
Nate Whittaker

0

Saya pikir itu tergantung pada struktur desain, itu hanya lebih seksi untuk menggunakan JSON daripada HTML tetapi pertanyaannya adalah bagaimana orang akan menanganinya sehingga dapat dengan mudah mempertahankannya.

Sebagai contoh, katakanlah saya memiliki halaman daftar yang menggunakan html / style yang sama dari seluruh situs, saya akan menulis fungsi global untuk memformat bagian-bagian dari HTML dan yang harus saya lakukan adalah meneruskan objek JSON ke dalam fungsi.


0

Respons html cukup di sebagian besar kasus kecuali Anda harus melakukan perhitungan di sisi klien.


0

Tergantung pada situasinya.

Terkadang penting untuk menghindari JSON. Ketika programmer kami mengalami kesulitan pemrograman dalam js, misalnya.

Pengalaman saya memberi tahu saya bahwa: lebih baik menggunakan layanan ajax daripada inline JSON.

Cepat atau lambat js menjadi masalah

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.