JSON के बजाय उत्पन्न HTML को वापस करने के लिए एक बुरा अभ्यास क्यों है? या यह है?

301

JQuery या किसी अन्य समान ढांचे का उपयोग करके अपने कस्टम URL / वेब सेवाओं से HTML सामग्री लोड करना काफी आसान है। मैंने कई बार और अब तक इस दृष्टिकोण का उपयोग किया है और प्रदर्शन को संतोषजनक पाया है।

लेकिन सभी किताबें, सभी विशेषज्ञ मुझे उत्पन्न HTML के बजाय JSON का उपयोग करने के लिए प्राप्त करने की कोशिश कर रहे हैं। HTML की तुलना में यह अधिक श्रेष्ठ कैसे है?

क्या यह बहुत तेज है?
क्या यह सर्वर पर बहुत कम लोड है?

दूसरी तरफ उत्पन्न HTML का उपयोग करने के लिए मेरे पास कुछ कारण हैं।

  1. यह सरल मार्कअप है, और अक्सर जेएनएसएन की तुलना में कॉम्पैक्ट या वास्तव में अधिक कॉम्पैक्ट होता है।
  2. यह कम त्रुटि वाला कारण है जो आपको मिल रहा है वह मार्कअप है, और कोई कोड नहीं।
  3. यह ज्यादातर मामलों में प्रोग्राम करने के लिए तेज़ होगा क्योंकि आपको क्लाइंट एंड के लिए अलग से कोड नहीं लिखना पड़ेगा।

आप किस पक्ष में हैं और क्यों?

javascript  jquery  html  ajax  json 
— सिरिल गुप्ता
स्रोत
यह ध्यान देने योग्य है कि AJAX में X, XML है और HTML एक बिंदु पर XML होने वाला था। यह विचार था कि HTML मानव और मशीन पठनीय डेटा (जैसे JSON) था, और CSS प्रस्तुति करेगा। उन शर्तों के तहत, यह एक AJAX अनुरोध में HTML भेजने के लिए "चिंताओं को अलग करने" का उल्लंघन नहीं करेगा
— 13 से 13

जवाबों:

255

मैं वास्तव में दोनों तरफ एक सा हूँ:

  • जब मुझे जावास्क्रिप्ट साइड पर डेटा की आवश्यकता होती है , तो मैं JSON का उपयोग करता हूं
  • जब मुझे जावास्क्रिप्ट पक्ष पर जो चाहिए वह है प्रस्तुति जिस पर मैं कोई गणना नहीं करूंगा, मैं आमतौर पर HTML का उपयोग करता हूं

HTML का उपयोग करने का मुख्य लाभ यह है कि जब आप अपने पृष्ठ के एक पूर्ण भाग को अजाक्स अनुरोध से वापस लाना चाहते हैं:

  • JS में पृष्ठ का एक भाग फिर से बनाना (काफी) कठिन है
  • आपके पास संभवतः पहले से ही सर्वर पर कुछ अस्थायी इंजन हैं, जिसका उपयोग पहले स्थान पर पृष्ठ उत्पन्न करने के लिए किया गया था ... इसका पुन: उपयोग क्यों नहीं किया जाता है?

मैं आमतौर पर चीजों के "प्रदर्शन" पक्ष पर विचार नहीं करता, कम से कम सर्वर पर:

  • सर्वर पर, HTML या कुछ JSON के एक हिस्से को बनाने से शायद इतना अंतर नहीं होगा
  • नेटवर्क के माध्यम से जाने वाले सामान के आकार के बारे में: ठीक है, आप शायद सैकड़ों KB डेटा / HTML का उपयोग नहीं करते हैं ... जो भी आप स्थानांतरित कर रहे हैं उस पर gzip का उपयोग करना सबसे बड़ा अंतर बनाने के लिए जा रहा है (HTML के बीच चयन नहीं करना और JSON)
  • एक बात जो ध्यान में रखी जा सकती है, हालाँकि, JSON डेटा से HTML (या DOM संरचना) को फिर से बनाने के लिए आपको क्लाइंट पर किन संसाधनों की आवश्यकता होगी ... तुलना करें कि पृष्ठ में HTML के एक हिस्से को आगे बढ़ाया जाए; -)

अंत में, एक बात जो निश्चित रूप से मायने रखती है:

  • आपको एक नई प्रणाली को विकसित करने में कितना समय लगेगा जो JSON + कोड के रूप में डेटा भेजेगा जेएस को पेज में HTML के रूप में इंजेक्ट करने के लिए आवश्यक है?
  • HTML को वापस करने में कितना समय लगेगा? और यदि आप अपने पहले से मौजूद सर्वर-साइड कोड का फिर से उपयोग कर सकते हैं तो कब तक?


और एक अन्य उत्तर का उत्तर देने के लिए: यदि आपको पृष्ठ के एक से अधिक हिस्से को अपडेट करने की आवश्यकता है, तो अभी भी उन सभी हिस्सों को एक बड़े स्ट्रिंग के अंदर भेजने का समाधान / हैक है जो कई HTML भागों को समूह करता है, और जेएस में संबंधित भागों को निकालता है।

उदाहरण के लिए, आप इस तरह दिखने वाली कुछ स्ट्रिंग लौटा सकते हैं:

<!-- 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 -->

यह वास्तव में अच्छा नहीं लगता है, लेकिन यह निश्चित रूप से उपयोगी है (मैंने इसे कई बार उपयोग किया है, ज्यादातर जब HTML डेटा JSON में एनकैप्सुलेट होने के लिए बहुत बड़ा था) : आप पृष्ठ के कुछ हिस्सों के लिए HTML भेज रहे हैं जो प्रस्तुति की आवश्यकता है, और आप उस स्थिति के लिए JSON भेज रहे हैं जिसे आपको डेटा की आवश्यकता है ...

... और उन लोगों को निकालने के लिए, जेएस सबस्ट्रिंग विधि चाल चलेगी, मुझे लगता है ;-)

— पास्कल मार्टिन
स्रोत
6
सभी डेटा अंततः प्रस्तुति है।
— सिरिल गुप्ता
47
@ सिरिल: हुह? मुझे लगता है कि आप यह कहना चाह रहे हैं कि डेटा, उपयोगी होने के लिए, उपयोग किया जाना है और इस प्रकार कहीं न कहीं किसी रूप में प्रस्तुत किया गया है, और मैं सहमत हूं। लेकिन कहना है कि डेटा है , प्रस्तुति गुमराह लगता है कम से कम।
— विन्को वेर्सालोविक
10
हाय विंको, 'अंततः' नोटिस? मेरा वही मतलब है जो आपका मतलब है। बस यहाँ उद्धरण योग्य उद्धरणों की पुस्तक में आने की कोशिश कर रहा हूँ। हा हा!
— सिरिल गुप्ता
37
मूल प्रश्न यह है कि क्या आप पूरी तरह से सकारात्मक हैं, अंततः सुनिश्चित करें कि आप इस डेटा का उपयोग किसी और चीज के लिए नहीं करेंगे, लेकिन एचटीएमएल में। क्योंकि एक बार HTML में पैक हो जाने के बाद, डेटा लगभग अप्राप्य हो जाएगा। JSON के साथ आपका बैकएंड XML, SVG, डेटाबेस इंजन, क्रॉस-साइट API और एक हज़ार अन्य फ़्रंट और सिस्टम के साथ काम कर सकता है जो JSON को स्वीकार कर सकते हैं। HTML के साथ, आप केवल HTML में ही इसका उपयोग कर पाएंगे।
— एसएफ।
3
@SF: सर्वर से HTML वापस करते समय, मैं डेटाबेस को एक्सेस करने वाले कोड से HTML जनरेटिंग कोड को विभाजित करना सुनिश्चित करता हूं। इस तरह मैं आसानी से एक JSON फॉर्म भी जोड़ सकता हूँ।
— केसबश
114

मैं मुख्य रूप से यहां बताई गई राय से सहमत हूं। मैं बस उन्हें संक्षेप में प्रस्तुत करना चाहता था:

  • एचटीएमएल भेजने के लिए यह बुरा अभ्यास है अगर आप इसे खत्म करने के लिए क्लाइंट-साइड की गणना करते हैं।

  • JSON भेजने के लिए यह बुरा अभ्यास है अगर आप सभी को कर रहे हैं तो इसे पेज के DOM ट्री में शामिल करना है।

— विन्को वर्सलोविक
स्रोत
3
क्या होगा यदि आपको कुछ गणना करने की आवश्यकता है और इसे पृष्ठ के DOM में भी शामिल किया जाए?
— एनरिक
मुझे आश्चर्य है कि उपरोक्त कथन में कितनी देर तक एक सत्यता जुड़ी होगी, यदि आप " आधा जीवन ज्ञान " को समीकरण में जोड़ते हैं?
— वैल
क्या ऐसा HTML लौटना संभव है जिसमें <script> टैग हो और जब पृष्ठ लोड किया जाता है तो क्लाइंट साइड पर उन्हें निष्पादित करता है?
— nish1013
इस। इसके अलावा यदि आप ऐसे डेटा को लौटा रहे हैं जो किसी तरह से इसकी प्रस्तुति में तरल होना चाहिए, जैसे कि यदि आपके पास स्तंभों के साथ एक HTML तालिका है जिसे आप सॉर्ट करने में सक्षम होना चाहते हैं। चाहे आपने उन्हें अभी क्रमबद्ध किया है या नहीं, आप बाद में चाहते हो सकते हैं, इसलिए ऐसे मामले में, भविष्य का प्रमाण-पत्र JSON मार्ग पर जाने के अतिरिक्त प्रयास के लायक है।
— trpt4him
मैं यह भी जोड़ूंगा, यदि आप JSON के माध्यम से छवि के यूआरएल का अनुरोध कर रहे हैं, तो उन्हें केवल पृष्ठ पर रेंडर करने की कोशिश करें, यह शुरू से ही HTML में उन्हें शामिल करने के लिए कहीं अधिक प्रदर्शनकारी है, ताकि छवियां पहले लोड करना शुरू कर सकें (इससे पहले कि आपका AJAX वापस आ जाए) ।
— FUUnitTest
30

कुंआ,

मैं उन दुर्लभ व्यक्तियों में से एक हूं जो इस तरह से चीजों को अलग करना पसंद करते हैं: - सर्वर डेटा (मॉडल) देने के लिए जिम्मेदार है; - ग्राहक डेटा (मॉडल) दिखाने (और) में हेरफेर करने के लिए जिम्मेदार है;

इसलिए, सर्वर को मॉडल वितरित करने पर ध्यान केंद्रित करना चाहिए (इस मामले में JSON बेहतर है)। इस तरह, आप एक लचीला दृष्टिकोण प्राप्त करते हैं। यदि आप अपने मॉडल का दृश्य बदलना चाहते हैं, तो आप सर्वर को एक ही डेटा भेजते रहते हैं और बस क्लाइंट, जावास्क्रिप्ट घटकों को बदलते हैं, उस डेटा को एक दृश्य में बदलते हैं। कल्पना कीजिए, आपके पास एक सर्वर है जो मोबाइल उपकरणों के साथ-साथ डेस्कटॉप ऐप्स तक डेटा पहुँचाता है।

इसके अलावा, यह दृष्टिकोण उत्पादकता बढ़ाता है, क्योंकि सर्वर और क्लाइंट कोड एक ही समय में बनाए जा सकते हैं, कभी भी उस फोकस को खोना नहीं चाहिए जो तब होता है जब आप js से PHP / JAVA / आदि पर स्विच करते रहते हैं।

आम तौर पर, मुझे लगता है कि ज्यादातर लोग सर्वर साइड पर जितना संभव हो उतना करना पसंद करते हैं क्योंकि वे मास्टर जेएस नहीं करते हैं, इसलिए वे इसे जितना संभव हो उतना बचने की कोशिश करते हैं।

मूल रूप से, मेरे पास उन लोगों के समान राय है जो कि कोणीय पर काम कर रहे हैं। मेरी राय में वह वेब ऐप्स का भविष्य है।

— ramaralo
स्रोत
हां मैं आपसे पूरी तरह सहमत हूं। हालांकि जब संवेदनशील जानकारी का संबंध है तो मैं ज्यादा से ज्यादा सर्वर साइड करूंगा। यदि आपको परिणाम की प्रतिक्रिया के आधार पर अलग-अलग प्रतिक्रिया करने के लिए क्लाइंट की आवश्यकता है तो मैं json का उपयोग करूंगा अन्यथा मैं html का उपयोग करूंगा।
— फाई हौरन
9

मेरे पास कुछ दिलचस्प है जो मुझे लगा कि मैं जोड़ सकता हूं। मैंने एक ऐसा एप्लिकेशन विकसित किया है जो केवल एक बार पूर्ण दृश्य लोड करता है। उस बिंदु से आगे यह केवल सर्वर के लिए वापस AJAX के साथ संचार किया। इसे केवल एक पृष्ठ लोड करने की आवश्यकता थी (इसके लिए मेरा कारण यहां महत्वहीन है)। दिलचस्प हिस्सा यह आता है कि मुझे जावास्क्रिप्ट में संचालित होने के लिए कुछ डेटा वापस करने की विशेष आवश्यकता थी और एक आंशिक दृश्य प्रदर्शित किया जाना था। मैं इसे दो कॉल में दो अलग-अलग एक्शन विधियों में विभाजित कर सकता था लेकिन मैंने कुछ और मज़ेदार चीज़ों के साथ जाने का फैसला किया।

इसकी जांच - पड़ताल करें:

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

RenderPartialViewToString () क्या आप पूछ सकते हैं? यह ठंडक की यह छोटी सी डली है यहीं:

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();
     }
}

मैंने इस पर कोई प्रदर्शन परीक्षण नहीं किया है, इसलिए मुझे यकीन नहीं है कि यह JsonResult के लिए एक एक्शन विधि और ParticalViewResult के लिए कॉल करने की तुलना में किसी भी अधिक या कम ओवरहेड को सम्मिलित करता है, लेकिन मुझे अभी भी लगा कि यह बहुत अच्छा था। यह बस एक आंशिक दृश्य को एक स्ट्रिंग में क्रमबद्ध करता है और इसे एक पैरामीटर के रूप में Json के साथ भेजता है। मैं उस पैरामीटर को लेने के लिए JQuery का उपयोग करता हूं और इसे उपयुक्त DOM नोड में थप्पड़ मारता हूं :)

मुझे पता है कि आप मेरे हाइब्रिड के बारे में क्या सोचते हैं!

— Chev
स्रोत
1
रेंडर किए गए दृश्य और डेटा को एक अनुरोध में भेजने से थोड़ा बेमानी लगता है। यदि आप क्लाइंट-साइड व्यू रेंडरिंग करने की क्षमता रखते हैं, तो केवल मजाक करना, यह अलग-अलग अनुरोधों के रूप में व्यू टेम्प्लेट और डेटा भेजने के लिए बेहतर होगा। इसके लिए एक अतिरिक्त अनुरोध की आवश्यकता थी लेकिन बाद के अनुरोधों के लिए केवल एक बार टेम्पलेट अनुरोध को कैश किया जाएगा। आदर्श रूप से क्लाइंट और सर्वर-साइड व्यू रेंडरिंग के संयोजन का उपयोग करना सबसे अच्छा होगा ताकि आप ब्राउज़र में सर्वर और पार्टिकल्स पर पेज बना सकें लेकिन यदि आप केवल सर्वर-साइड व्यू रेंडरिंग को लागू करते हैं, तो यह एक बुरा तरीका नहीं है।
— इवान प्लाइस
8

यदि प्रतिक्रिया को आगे क्लाइंट-साइड प्रोसेसिंग की आवश्यकता नहीं है, तो HTML मेरी राय में ठीक है। JSON भेजना केवल आपको क्लाइंट-साइड प्रोसेसिंग करने के लिए बाध्य करेगा।

दूसरी ओर, मैं JSON का उपयोग तब करता हूं जब मैं एक बार में सभी प्रतिक्रिया डेटा का उपयोग नहीं करना चाहता। उदाहरण के लिए, मेरे पास तीन जंजीर चयनों की एक श्रृंखला है, जहां एक का चयनित मूल्य निर्धारित करता है कि दूसरे को आबाद करने के लिए किन मूल्यों का उपयोग किया जाना है, और इसी तरह।

— आयनू जी स्टेन
स्रोत
7

IMV, यह डेटा की प्रस्तुति से डेटा को अलग करने के बारे में है, लेकिन मैं पास्कल के साथ हूं, यह जरूरी नहीं है कि जुदाई केवल क्लाइंट / सर्वर सीमा के पार हो सकती है। यदि आपके पास पहले से ही (सर्वर पर) अलगाव है और आप क्लाइंट को कुछ दिखाना चाहते हैं, तो चाहे आप JSON को वापस भेज दें और क्लाइंट पर पोस्ट-प्रोसेस करें, या बस HTML वापस भेजें, पूरी तरह से आपकी आवश्यकताओं पर निर्भर करता है। सामान्य स्थिति में HTML को वापस भेजने के लिए आप "गलत" हैं, यह कहना कि IMV अभी भी बहुत कम्बल है।

— टीजे क्राउडर
स्रोत
6

JSON बहुत बहुमुखी और हल्के प्रारूप है। मैंने इसकी सुंदरता की खोज की है जब मैंने इसे क्लाइंट साइड टेम्पलेट पार्सर डेटा के रूप में उपयोग करना शुरू कर दिया है। मुझे समझाते हुए, जबकि पहले मैं सर्वर साइड पर स्मार्टी और विचारों का उपयोग कर रहा था (उच्च सर्वर लोड पैदा कर रहा था), अब मैं कुछ कस्टम jquery फ़ंक्शंस का उपयोग करता हूं और क्लाइंट ब्राउज़र पर सभी डेटा टेम्पलेट पार्सर के रूप में उपयोग किया जाता है। यह सर्वर रिसोर्स को बचाता है और दूसरी ओर ब्राउज़र हर दिन अपने JS इंजन को बेहतर बनाता है। तो क्लाइंट पार्सिंग की गति अभी एक महत्वपूर्ण मुद्दा नहीं है, इससे भी अधिक, JSON ऑब्जेक्ट्स ususally बहुत छोटे होते हैं इसलिए वे बहुत सारे क्लाइंट साइड रिसोर्स का उपभोग नहीं करते हैं। मैं बहुत लोड सर्वर के कारण सभी के लिए धीमी साइट के बजाय धीमी ब्राउज़र वाले कुछ उपयोगकर्ताओं के लिए एक धीमी वेबसाइट रखना पसंद करता हूं।

दूसरी ओर, सर्वर से शुद्ध डेटा भेजकर आप इसे प्रस्तुति से अलग कर देते हैं, यदि कल आप इसे बदलना चाहते हैं या अपने डेटा को किसी अन्य सेवा में एकीकृत करना चाहते हैं तो आप इसे बहुत आसान कर सकते हैं।

बस मेरे 2 सेंट।

— माइक
स्रोत
जब जावास्क्रिप्ट अक्षम किया जाता है तो आप यह कैसे सुनिश्चित कर सकते हैं कि आपको एक पठनीय पृष्ठ मिले?
— विंको वर्सालोविच
8
यदि JS अक्षम है तो आप html को लोड भी नहीं कर पाएंगे। मेरे Google Analytics आँकड़ों के अनुसार JS 2.3% उपयोगकर्ताओं पर अक्षम है। नीचे जाने का सबसे अच्छा तरीका सभी को खुश करने की कोशिश करना है।
— माइक
4
मैं माइक के साथ 100% सहमत हूं। हर किसी को खुश करने की कोशिश करना असंभव है और इससे आपको नुकसान ही होगा। यदि उपयोगकर्ता JS को बंद कर रहे हैं, तो उनका उपयोग कई साइटों के लिए किया जाना चाहिए जो अब तक उनके लिए काम नहीं कर रही हैं।
— Chev
1
एनालिटिक्स में जावास्क्रिप्ट आँकड़े कैसे प्राप्त करते हैं क्योंकि एनालिटिक्स डेटा को ट्रैक करने के लिए जावास्क्रिप्ट का उपयोग करता है?
— निक
@ अच्छा सवाल है, लेकिन मैंने यह पाया: stackoverflow.com/questions/15265883/…
— रेनन कैवेलिएरी
6

यदि आप एक साफ डिकॉफ़्ड क्लाइंट चाहते हैं, जो मेरी राय में सबसे अच्छा अभ्यास है, तो यह जावास्क्रिप्ट द्वारा निर्मित डोम का 100% होना समझ में आता है। यदि आप MVC आधारित क्लाइंट का निर्माण करते हैं, जिसमें सभी को पता है कि UI कैसे बनाया जाए तो आपके उपयोगकर्ता एक समय में एक जावास्क्रिप्ट फ़ाइल डाउनलोड करते हैं और यह क्लाइंट पर कैश की जाती है। उस प्रारंभिक लोड के बाद सभी अनुरोध अजाक्स आधारित हैं और केवल रिटर्न डेटा हैं। यह दृष्टिकोण सबसे साफ है जिसे मैंने पाया है और प्रस्तुति के स्वच्छ स्वतंत्र एनकैप्सुलेशन के लिए प्रदान करता है।

सर्वर साइड तो बस डेटा पहुंचाने पर केंद्रित है।

इसलिए कल जब उत्पाद आपसे पृष्ठ के डिज़ाइन को पूरी तरह से बदलने के लिए कहता है तो आप वह सब बदल सकते हैं जो स्रोत JS है जो DOM बनाता है, लेकिन संभवतः आपके पहले से मौजूद ईवेंट हैंडलर का पुनः उपयोग करने के लिए मिलता है और सर्वर बेखबर है क्योंकि यह प्रस्तुति से 100% कम है

— लांस कारसियोली
स्रोत
1
मैं सहमत हूं, आप अपने मोबाइल ऐप के लिए भी जोंस का पुन: उपयोग कर सकते हैं।
— एलेक्स शिलमैन
यह स्वीकृत उत्तर होना चाहिए था - पहले 6 - 7 शब्द प्रश्न का उत्तर संक्षिप्त रूप से देते हैं।
— nicholaswmin
इस बात से सहमत। प्रस्तुति (HTML) पर रिटर्न डेटा (JSON) का लाभ यह है कि अब आपके पास एक "फ्री" वेब एपीआई है जिसे अन्य ग्राहकों के लिए फिर से उपयोग किया जा सकता है यह मोबाइल या पूरी तरह से अलग ऐप है जो इस ऐप के कुछ डेटा में रुचि रखता है आदि सर्वर साइड पर एक साधारण वेब फ्रेमवर्क का उपयोग करने वाले मेरे अनुभव में, जो केवल डेटा से संबंधित है, न कि प्रस्तुति अक्सर अच्छे और सरल परिणामों की ओर ले जाती है। आधुनिक ब्राउज़र और सीपीयू इतनी तेज़ हैं कि केवल विशेष मामलों में ही रेंडरिंग एक अड़चन होगी। सबसे बड़ी अड़चन ज्यादातर नेटवर्क और डेटाबेस कॉल है।
— beginner_
4

आपके UI के आधार पर, आपको अपने DOM में दो (या अधिक) विभिन्न तत्वों को अपडेट करने की आवश्यकता हो सकती है। यदि आपकी प्रतिक्रिया HTML में है, तो क्या आप यह पता लगाने के लिए जा रहे हैं कि कहां जाता है? या आप सिर्फ JSON हैश का उपयोग कर सकते हैं।

आप इसे जोड़ भी सकते हैं, JSON w / html डेटा वापस कर सकते हैं :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }
— tchen
स्रोत
JSON भेजने के लिए यह बुरा अभ्यास है अगर आप सभी को कर रहे हैं तो इसे पेज के DOM ट्री में शामिल करना है ... और JSON को HTML के साथ जोड़कर आप इस खराब
— pratice
2

HTML में कई निरर्थक और प्रदर्शित नहीं किए गए डेटा यानी टैग, स्टाइल शीट आदि हैं। इसलिए JSON डेटा की तुलना में HTML का आकार अधिक डाउनलोड करने के लिए बड़ा होगा और समय भी प्रदान करेगा जिससे ब्राउज़र नए डेटा को प्रस्तुत करने में व्यस्त हो जाएगा।

— जॉन समन
स्रोत
1

जब आप एक जावास्क्रिप्ट विजेट को सर्वर से जानकारी के लिए निवेदन करते हैं, जैसे कि एक सूची या एक पेड़ दृश्य या एक स्वत: पूर्ण। यह तब है जब मैं JSON भेजूंगा क्योंकि यह डेटा है जिसे पार्स किया जाएगा और कच्चा उपयोग किया जाएगा। हालाँकि, यदि आपका HTML केवल शो करने वाला है तो यह सर्वर साइड उत्पन्न करने के लिए बहुत कम काम करता है और इसे केवल ब्राउज़र पर दिखाता है। ब्राउज़रों को HTML को आंतरिक HTML में सीधे डालने के लिए अनुकूलित किया गया है = "" इसलिए आप इसके साथ गलत नहीं हो सकते।

— Zoidberg
स्रोत
FWIW, innerHTMLऐतिहासिक रूप से दस्तावेज़ के टुकड़े की तुलना में बहुत धीमा है: coderwall.com/p/o9ws2g/… ।
— नैट व्हिटकेर
0

मुझे लगता है कि यह डिज़ाइन की संरचना पर निर्भर करता है, यह HTML की तुलना में JSON का उपयोग करने के लिए बस अधिक सेक्सी है, लेकिन सवाल यह है कि कोई इसे कैसे हैंडल करेगा ताकि इसे आसानी से बनाए रखा जा सके।

उदाहरण के लिए, मान लें कि मेरे पास सूचीकरण पृष्ठ है जो पूरी साइट के एक ही html / शैली का उपयोग करता है, मैं HTML के उन हिस्सों को प्रारूपित करने के लिए वैश्विक फ़ंक्शन लिखूंगा और मुझे जो कुछ भी करना है वह फ़ंक्शन में JSON ऑब्जेक्ट को पास कर रहा है।

— Methee
स्रोत
0

जब तक आपको क्लाइंट की ओर से कुछ गणना नहीं करनी है, तब तक ज्यादातर मामलों में एचटीएमएल प्रतिक्रिया पर्याप्त है।

— MUBASHIR
स्रोत
0

परिस्थितियों पर निर्भर करता है।

कभी-कभी JSON से बचना आवश्यक है। जब हमारे प्रोग्रामर को js में प्रोग्रामिंग करने में परेशानी होती है, उदाहरण के लिए।

मेरा अनुभव मुझे बताता है कि: इनलाइन JSON की तुलना में बेहतर ajax सेवा का उपयोग करें।

जल्दी या बाद में js एक समस्या बन जाती है

— Alegoric
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.