কেন আমি ইনলাইন স্ক্রিপ্টিং এড়ানো উচিত?

Question

একজন জ্ঞানী বন্ধু সম্প্রতি একটি ওয়েবসাইট দেখেছিলাম যা আমি প্রবর্তন করতে সহায়তা করেছি এবং "খুব শীতল সাইট, উত্স কোডের ইনলাইন স্ক্রিপ্টিং সম্পর্কে লজ্জা" এর মতো কিছু মন্তব্য করেছিলেন।

আমি অবশ্যই ইনলাইন স্ক্রিপ্টিংটি যেখানে ঘটে তা সরিয়ে ফেলার মতো অবস্থানে রয়েছি; আমি অস্পষ্টভাবে অবগত যে এটি "একটি খারাপ জিনিস"। আমার প্রশ্ন: ইনলাইন স্ক্রিপ্টিং এর সাথে আসল সমস্যাগুলি কী? কোনও উল্লেখযোগ্য পারফরম্যান্সের সমস্যা আছে, বা এটি বেশিরভাগ ক্ষেত্রে কেবল ভাল স্টাইলের বিষয়? আমার উর্ধ্বতনদের কাছে আমি যখন ইনলাইন স্ক্রিপ্টিংয়ের সামনে তাত্ক্ষণিক পদক্ষেপের ন্যায্যতা প্রমাণ করতে পারি, তখন সেখানে কাজ করার অন্যান্য জিনিসগুলি সাইটে আরও স্পষ্ট প্রভাব ফেলতে পারে? যদি আপনি কোনও ওয়েবসাইটের দিকে টানেন এবং উত্স কোডটি দেখেছেন তবে কী কারণগুলি আপনাকে "এইচএমএম, পেশাদার পেশাগত কাজ এখানে" বলতে বাধ্য করবে এবং কী কারণে আপনি সম্ভবত অপেশাদারী কাজ থেকে পিছিয়ে পড়বেন?

ঠিক আছে, সেই প্রশ্নটি লেখার একাধিক প্রশ্নের মধ্যে পরিণত হয়েছিল। তবে মূলত, ইনলাইন স্ক্রিপ্টিং - কী চুক্তি?

Comments

পুনরায় ব্যবহার এবং নকশাটি বাস্তবায়ন থেকে পৃথক করা আমার মাথার উপরের অংশটি ইনলাইন না করার দুটি কারণ।

— মাইকেল টড

এখানে কিছু প্রসঙ্গ নিখোঁজ - "ইনলাইন স্ক্রিপ্টিং" বলতে কী বোঝ?

— গ্রেফ্যাড

হ্যাঁ, এটি কি পৃষ্ঠার ভিতরে সিএসএস, পৃষ্ঠায় জেএস, বা অন্য কিছু?

— মাইকেল কে

@ গ্রেফ্যাড, মাইকেল: আচ্ছা, আমার বন্ধুটি নির্দিষ্ট করে নি, তাই ধরে নেওয়া যাক এটি উভয়ই। আসুন আরও জেএস হিসাবে বলি, যেহেতু এটি আমার দায়িত্বের ক্ষেত্রের খুব কাছাকাছি থাকে ...

— থানসনেভারেটস

আপনি যদি অপ্রয়োজনীয় কোড না তৈরি করেন তবে আমি এটিতে কোনও সমস্যা দেখছি না। আপনার যদি প্রচুর পরিমাণে কোড ইনলাইন থাকে তবে এটি অসম্পূর্ণ দেখাচ্ছে। তবে আমি কল করার জন্য স্ক্রিপ্ট ব্লকে কোনও ফাংশন লেখার চেয়ে কনফার্মস ইনলাইন ব্যবহার করি।

— SoylentGray

Answer 1

ইনলাইন স্ক্রিপ্টিং এর সাথে আসল সমস্যাগুলি কী? কোনও উল্লেখযোগ্য পারফরম্যান্সের সমস্যা আছে, বা এটি বেশিরভাগ ক্ষেত্রে কেবল ভাল স্টাইলের বিষয়?

সুবিধাগুলি পারফরম্যান্স ভিত্তিক নয়, এগুলি (মাইকেল তার মন্তব্যে উল্লেখ করেছেন) দৃষ্টিভঙ্গি এবং নিয়ামককে পৃথক করার ক্ষেত্রে আরও কিছু করা উচিত। এইচটিএমএল / সিএসএস ফাইলটিতে আদর্শভাবে কেবল উপস্থাপনা থাকা উচিত এবং আলাদা স্ক্রিপ্টগুলির জন্য পৃথক ফাইল ব্যবহার করা উচিত। এটি আপনার (এবং আপনার সমবয়সীদের) ভিজ্যুয়াল এবং কার্যকরী উভয় দিকই পড়া এবং বজায় রাখা সহজ করে তোলে।

আমার উর্ধ্বতনদের কাছে আমি যখন ইনলাইন স্ক্রিপ্টিংয়ের সামনে তাত্ক্ষণিক পদক্ষেপের ন্যায্যতা প্রমাণ করতে পারি, তখন সেখানে কাজ করার অন্যান্য জিনিসগুলি সাইটে আরও স্পষ্ট প্রভাব ফেলতে পারে?

না, সম্ভবত না। খাঁটি রক্ষণাবেক্ষণ কাজের যে শক্তিগুলি তা বোঝানো খুব কঠিন হতে পারে, যদি আপনি বিশ্বাস করেন যে এটি দীর্ঘকালীন তাদের অর্থ সাশ্রয় করবে। যদিও এই ক্ষেত্রে, আমি মনে করি না যে এটি এত গুরুত্বপূর্ণ যে আপনার সমস্ত কিছু বন্ধ করা উচিত এবং আপনার ইনলাইন স্ক্রিপ্টিং থেকে মুক্তি পাওয়া উচিত। পরিবর্তে, কেবলমাত্র নিশ্চিত হয়ে নিন যে আপনি অন্যান্য কারণে তাদের উপর কাজ করার সাথে সাথে অঞ্চলগুলি সংশোধন করার জন্য সচেতন প্রচেষ্টা করেছেন। রিফ্যাক্টরিং কোডটি এমন কিছু হওয়া উচিত যা আপনি নিয়মিত করেন তবে একবারে কিছুটা হলেও।

যদি আপনি কোনও ওয়েবসাইটের দিকে টানেন এবং উত্স কোডটি দেখেছেন তবে কী কারণগুলি আপনাকে "এইচএমএম, পেশাদার পেশাগত কাজ এখানে" বলতে বাধ্য করবে এবং কী কারণে আপনি সম্ভবত অপেশাদারী কাজ থেকে পিছিয়ে পড়বেন?

এক নম্বর ফ্যাক্টর যা আমাকে বলবে যে এটি পেশাদার নয় তা হ'ল টেবিল বা ডিভের অতিরিক্ত ব্যবহার। এখানে কেন একটির অতিরিক্ত ব্যবহার করা উচিত তা ব্যাখ্যা করার জন্য একটি নিবন্ধ এখানে দেওয়া হয়েছে ।

Answer 2

আমি শয়তানের উকিল হতে যাচ্ছি না, তবে অপেশাদারী কাজ এবং ইনলাইন জাভাস্ক্রিপ্টের মধ্যে কোনও কঠোর সম্পর্ক নেই। আসুন কয়েকটি সর্বাধিক পরিচিত ওয়েবসাইটগুলির উত্স কোডটি দেখুন:

• গুগল,
• উইকিপিডিয়া,
• মাইক্রোসফট,
• অ্যাডোবি,
• ডেল,
• আইবিএম।

তাদের প্রতিটি হোম পৃষ্ঠাগুলি ইনলাইন জাভাস্ক্রিপ্ট ব্যবহার করে। এর অর্থ কি এই যে সমস্ত সংস্থাগুলি অপেশাদার লোকদের তাদের হোমপৃষ্ঠাগুলি তৈরি করতে নিয়োগ করে?

---

আমি সেই সকল বিকাশকারীদের মধ্যে একজন যা এইচটিএমএল-এর ভিতরে জাভাস্ক্রিপ্ট কোড রাখতে পারি না। আমি যে প্রকল্পগুলিতে কাজ করি তার মধ্যে আমি কখনই এটি করি না (সম্ভবত কিছু কলগুলি এমন <a href="javascript:...">প্রকল্পগুলির মতো যেখানে প্রথম থেকেই নিরবচ্ছিন্ন জাভাস্ক্রিপ্টের প্রয়োজন ছিল না, এবং আমি যখনই অন্য কারওর কোডটি রিফ্যাক্টর করি তখন আমি সর্বদা ইনলাইন জাভাস্ক্রিপ্ট সরিয়ে ফেলি But তবে এটি চেষ্টা করার মতো নয়) এতটা নিশ্চিত না?

পারফরম্যান্স-ভিত্তিক, একটি পৃথক ফাইলে জাভাস্ক্রিপ্ট স্থাপন করার সময় আপনার সবসময় আরও ভাল পারফরম্যান্স থাকে না। সাধারণত, আমরা সেই ইনলাইন জাভাস্ক্রিপ্ট বর্জ্য ব্যান্ডউইদথ বিবেচনা করতে প্ররোচিত হই, যেহেতু এটি ক্যাশে করা যায় না (আপনি যখন স্ট্যাটিক ক্যাশেবল এইচটিএমএল নিয়ে কাজ করেন তা বাদে)। বিপরীতে, একটি বাহ্যিক .js ফাইলটি একবারে লোড হয়।

বাস্তবে, এটি কেবলমাত্র একটি অপ্রকালীন অপ্টিমাইজেশান : আপনি সম্ভবত ভেবেছিলেন যে জাভাস্ক্রিপ্ট বহিরাগত করা আপনার ওয়েবসাইটকে দৃten় করবে, তবে আপনি সম্পূর্ণ ভুলও হতে পারেন:

• আপনার ব্যবহারকারীদের বেশিরভাগ যদি খালি ক্যাশে নিয়ে আসে?
• আপনি কি বিবেচনা করেছেন কোনও বাহ্যিক .js ফাইলের সাথে, ওয়েবসাইটটি সঠিকভাবে কনফিগার করা হয়নি (এবং সাধারণত, এটি হয় না), প্রতিটি পৃষ্ঠার অনুরোধে এই ফাইলটিতে একটি অনুরোধ করা হবে,
• .Js ফাইলটি আসলেই ক্যাশেড (আইআইএস সহ, এটি এত সহজ নাও হতে পারে)?

তাই অকালে অপ্টিমাইজ করার আগে আপনার দর্শনার্থীদের সম্পর্কে পরিসংখ্যান সংগ্রহ করুন এবং ইনলাইন জাভাস্ক্রিপ্ট সহ এবং না করে পারফরম্যান্সগুলি মূল্যায়ন করুন।

তারপরে চূড়ান্ত যুক্তি আসে: আপনি নিজের উত্সে জাভাস্ক্রিপ্ট এবং এইচটিএমএল মিশ্রিত করেছেন, তাই আপনি স্তন্যপান করেন। তবে কে বলেছে আপনি দুজনেই মিশলেন? ব্রাউজার দ্বারা ব্যবহৃত উত্স কোডটি সর্বদা আপনার লেখা উত্স কোড নয়। উদাহরণস্বরূপ, সোর্স কোড, সংকুচিত হতে পারে minified, বা একাধিক সিএসএস বা জাতীয় ফাইল একটি ফাইলে পরিনত হতে পারে, কিন্তু তার মানে এই নয় যে আপনি কি সত্যিই নামে আপনার ভেরিয়েবল a, b, c... a1, ইত্যাদি বা যে আপনি লিখেছেন একটি ফাঁকা স্থান বা নিউলাইন ছাড়াই বিশাল সিএসএস ফাইল। একইভাবে, আপনি সহজেই সংকলন সময়ে বা পরে টেমপ্লেটগুলির মাধ্যমে এইচটিএমএলে বহিরাগত জাভাস্ক্রিপ্ট উত্স কোডটি ইনজেক্ট করতে পারেন।

---

উপসংহারে, আপনি নিজের লেখার উত্স কোডটিতে জাভাস্ক্রিপ্ট এবং এইচটিএমএল মিশ্রণ করেন, আপনার ভবিষ্যতের প্রকল্পগুলিতে এটি না করার কথা বিবেচনা করা উচিত। তবে এর অর্থ এই নয় যে যদি ব্রাউজারে প্রেরিত উত্স কোডটিতে ইনলাইন জাভাস্ক্রিপ্ট থাকে তবে এটি সর্বদা খারাপ।

• এটা খারাপ হতে পারে।
• বিপরীতে এটি একটি চিহ্ন হতে পারে যে ওয়েবসাইটটি পেশাদারদের দ্বারা লেখা হয়েছিল যারা পারফরম্যান্সের বিষয়ে যত্নশীল হন, নির্দিষ্ট পরীক্ষা করেছিলেন এবং নির্ধারণ করেছিলেন যে তাদের ক্লায়েন্টদের জাভাস্ক্রিপ্টের অংশগুলি ইনলাইন করা দ্রুত হবে faster
• বা এর অর্থ মোটেও কিছু নয়।

ওয়েবসাইটটি কীভাবে করা হয়েছিল সে সম্পর্কে কিছু না জেনে ব্রাউজারে পাঠানো উত্সটি দেখে কেবল "সোজা কোডের ইনলাইন স্ক্রিপ্টিং সম্পর্কে লজ্জা" বলে সেই ব্যক্তির জন্য বরং লজ্জাজনক

Comments

গবেষণা এবং চিন্তাশীল হওয়ার জন্য +1। বাস্তবতাটি এমন বিল্ড সরঞ্জাম রয়েছে যা পৃথক ফাইলগুলিতে কোডগুলি বিকাশিত কোডগুলিকে সত্যতার পরে ইনলাইনে তৈরি করতে পারে। এইচটিএমএল + সিএসএস + জেএস হ'ল ওয়েবের সমাবেশের ভাষা language জিনিসগুলি যেভাবে সরবরাহ করা হয় (মাইনাইফড, কম্পোজিট করা হয়) সেগুলি কীভাবে তৈরি হয় তার সাথে কোনও সম্পর্ক নেই।

— ইভান মরান 16

Answer 3

এইচটিএমএল এবং জেএসকে সাধারণত আলাদা করে রাখার চেষ্টা করা ভাল। এইচটিএমএল দেখার জন্য, জেএস অ্যাপ্লিকেশন যুক্তির জন্য। তবে আমার অভিজ্ঞতায় এইচটিএমএল এবং জাভাস্ক্রিপ্টের চূড়ান্ত ডিকোপলিং (বিশুদ্ধতার জন্য) এটি আরও রক্ষণাবেক্ষণযোগ্য করে তোলে না; এটি আসলে কম রক্ষণাবেক্ষণযোগ্য হতে পারে।

উদাহরণস্বরূপ, আমি ইভেন্ট হ্যান্ডলারগুলি স্থাপন করতে কখনও কখনও এই প্যাটার্নটি (এএসপি নেট থেকে নেওয়া) ব্যবহার করি:

<input type="button" id="yourId" onclick="clickYourId()" />

অথবা

<input type="button" id="yourId" onclick="clickYourId(this)" />

ঘটনাটি ঘটতে যা ঘটছে তা নিয়ে কোনও রহস্য নেই। কারণটি হ'ল ছয় মাস পরে আপনি উপাদানটি পরিদর্শন করতে পারেন (উদাহরণস্বরূপ, ক্রোমে) এবং জাভাস্ক্রিপ্ট ইভেন্টটি ট্রিগার হয়েছে তা অবিলম্বে দেখতে পারেন।

অন্যদিকে, কল্পনা করুন যে আপনি অন্যের কোডটি পড়ছেন, যা এক লক্ষ লক্ষ লাইন, এবং আপনি একটি যাদুবিদ্যার উপাদানটি পেয়ে যা জাভাস্ক্রিপ্ট ইভেন্ট বন্ধ করে দেয়:

<input id="yourId"  />

আপনি কীভাবে সহজেই আমাকে বলতে পারেন যে এটি কোন জাভাস্ক্রিপ্ট পদ্ধতিটি কল করছে? ক্রোম এটিকে আরও সহজ করে তুলেছে তবে সম্ভবত ইভেন্টটি আইডির সাথে আবদ্ধ বা সম্ভবত এটি ধারকটির প্রথম সন্তানের সাথে আবদ্ধ। সম্ভবত ইভেন্টটি প্যারেন্ট অবজেক্টের সাথে সংযুক্ত রয়েছে। কে জানে? ভাগ্য ভাল এটি। :)

এছাড়াও, আমি যুক্তি দিয়ে বলব যে জাভাস্ক্রিপ্ট পুরোপুরি ডিজাইনারের কাছ থেকে গোপন করা তাদের কোনও আপডেটে ভাঙ্গার সম্ভাবনা বাড়িয়ে তুলতে পারে। যদি কেউ যাদুবিদ্যামূলকভাবে সক্রিয় উপাদানটির জন্য কোড সম্পাদনা করে তবে কোডটিতে কী ইঙ্গিত রয়েছে যা তাদের জানাতে পারে যে এটি পৃষ্ঠায় একটি সক্রিয় উপাদান?

সুতরাং সংক্ষেপে, সেরা অনুশীলন হ'ল এইচটিএমএল এবং জাভাস্ক্রিপ্ট পৃথক করা। তবে এগুলিও বুঝতে পারি যে থাম্বের নিয়মগুলি কখনও কখনও চূড়ান্তভাবে চালিত হলে প্রতিবিজাতীয় হয়। আমি মাঝারি রাস্তার পদ্ধতির জন্য তর্ক করব। বিপুল পরিমাণে ইনলাইন জেএস এড়িয়ে চলুন। আপনি যদি ইনলাইন ব্যবহার করেন তবে ফাংশনের স্বাক্ষরটি খুব সাধারণ হওয়া উচিত:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

Comments

ভাল যুক্তি! দুর্দান্ত উত্তর।

— জুলিয়ান

সত্যিই, দুর্দান্ত উত্তর। যতক্ষণ জেএস সংযুক্ত শ্রোতাদের সন্ধানের পক্ষে এটি এতটা কঠিন করে তোলে ততক্ষণ ইনলাইন স্ক্রিপ্টটি বজায় রাখা আরও সহজ হতে থাকবে।

— জনক

এটি আমার মতে সেরা উত্তর। চরম কিছু করার জন্য প্রায়শই এটি "ওভার ডুয়িং" করা হয়।

— 14

Answer 4

একটি যুক্তি যা আমি এখানে মিস করছি তা হ'ল ক্রস সাইট স্ক্রিপ্টিং আক্রমণগুলির বিরুদ্ধে সুরক্ষা বাড়ানো ।

সামগ্রী সুরক্ষা নীতি মাধ্যমে আধুনিক ব্রাউজারে ইনলাইন জাভাস্ক্রিপ্ট কার্যকর করা অক্ষম করা সম্ভব । এটি আপনার সাইটের এক্সএসএসের শিকার হওয়ার ঝুঁকি হ্রাস করেছে। আপনার ম্যানেজমেন্টকে ইনলাইন স্ক্রিপ্ট সরিয়ে বিনিয়োগে বিনিয়োগ করার পক্ষে এটি আরও দৃ conv় যুক্তিযুক্ত হতে পারে।

Comments

আমি মনে করি এটি এখন সেরা উত্তর ।

— সুপারশার্প

আমার নম্র মতে এটি আরও অনেকগুলি উত্সাহ এবং মনোযোগের দাবি রাখে।

— প্যাট্রিক রবার্টস

বৈধ বিন্দু !!!

— আনশুল

যখন ইনলাইন স্ক্রিপ্টটি স্থির থাকে, তখনই এটি হয় না?

— Ван Ван

Answer 5

এখানে কয়েকটি কারণ রয়েছে।

1. ইনলাইন স্ক্রিপ্টটি ছোট করা যায় না (প্রতীক হ্রাসের মাধ্যমে সংক্ষিপ্ত সংস্করণে রূপান্তরিত)। ব্রডব্যান্ড নিয়ে কোনও উদ্বেগ নয় তবে একটি নিম্ন ব্যান্ডউইথ অঞ্চলে একটি মোবাইল ডিভাইস বিবেচনা করুন বা যে সমস্ত ব্যবহারকারী গ্লোবাল ডেটা রোমিংয়ে আছেন - প্রতি বাইট গণনা করতে পারেন।

2. পৃষ্ঠাটি নিজেই ক্যাশেযোগ্য না হলে ব্রাউজারের দ্বারা ইনলাইন স্ক্রিপ্ট ক্যাশে করা যায় না (যা খুব নিস্তেজ পৃষ্ঠা তৈরি করে)। বাহ্যিক জাভাস্ক্রিপ্ট ফাইলগুলি কেবল একবার পুনরুদ্ধার করা দরকার, এমনকি পৃষ্ঠার সামগ্রী প্রতিবার পরিবর্তিত হয়। নিম্ন ব্যান্ডউইথ সংযোগগুলির পারফরম্যান্সকে গুরুতরভাবে প্রভাবিত করতে পারে।

3. ইনলাইন স্ক্রিপ্টটি ডিবাগ করা শক্ত কারণ কোনও ত্রুটির সাথে যুক্ত লাইন নম্বরটি অর্থহীন।

4. ইনলাইন স্ক্রিপ্টটি অ্যাক্সেসযোগ্যতার (508 / ডাব্লুআইএআই) বিবেচনায় হস্তক্ষেপ করার জন্য খ্যাতিযুক্ত, যদিও এর অর্থ এই নয় যে সমস্ত ইনলাইন স্ক্রিপ্ট সমস্যার কারণ হয়। আপনি যদি স্ক্রিপ্ট পাঠকের সাথে স্ক্রিপ্ট সামগ্রীর ঘোষণা দিয়ে শেষ করেন তবে আপনার সমস্যা আছে! (যদিও এটি কখনও ঘটেনি)।

5. ইনলাইন স্ক্রিপ্টটি এর পৃষ্ঠা থেকে স্বতন্ত্রভাবে পরীক্ষা করা যায় না; বহিরাগত জাভাস্ক্রিপ্ট ফাইলগুলি স্বয়ংক্রিয় পরীক্ষাসহ স্বাধীন পরীক্ষার মাধ্যমে চালানো যেতে পারে।

6. ইনলাইন লিপিটি উদ্বেগগুলির দুর্বল পৃথকীকরণের দিকে নিয়ে যেতে পারে (যেমন অন্যান্য উত্তরগুলির মধ্যে এখানে বর্ণিত)।

Comments

কিছু পৃষ্ঠা স্থিতিশীল এবং তবুও মূল্যবান হতে পারে - এর আগে আজ আমি এটিতে একটি ক্যালকুলেটর সহ একটি পৃষ্ঠা ব্যবহার করছিলাম। ক্যাশেযোগ্য, তবুও দরকারী। আমি সম্মতি দিচ্ছি যে অ-তুচ্ছ জাভাস্ক্রিপ্ট কোনও গতিশীল পৃষ্ঠায় নেই।

— লরেন পেচটেল 8:58

Answer 6

স্ক্রিপ্ট ইনলাইন অন্তর্ভুক্ত না করে ন্যায্যতা দেয় যে একাধিক কারণ আছে:

• প্রথমত, সুস্পষ্ট উত্তর - এটি এমন কোডকে তৈরি করে যা পরিষ্কার, আরও সংক্ষিপ্ত, বোঝা ও পড়ার পক্ষে সহজ।

• আরও ব্যবহারিক দৃষ্টিকোণ থেকে আপনি প্রায়শই স্ক্রিপ্ট / সিএসএস / ইত্যাদি পুনরায় ব্যবহার করতে চান। আপনার সমস্ত ওয়েবসাইট জুড়ে - এই অংশগুলিকে সন্নিবেশ করানোর অর্থ প্রতিবার আপনি যখন একটি ছোট পরিবর্তন করেন তখন প্রতি একক পৃষ্ঠা সম্পাদনা করে।

• আপনি যদি আপনার প্রকল্পের জন্য কোনও এসসিএম ব্যবহার করেন, তবে আপনার বিভিন্ন উপাদানগুলি ভালভাবে পৃথক করা ট্র্যাকিং পরিবর্তন করবে এবং জড়িত প্রত্যেকের জন্য আরও সহজতর প্রতিশ্রুতি দেয়।

আমি যতদূর জানি, পারফরম্যান্স কোনও উদ্বেগের বিষয় হবে না। এটি আপনার ওয়েবসাইটের প্রকৃতি, আপনার সার্ভারের চশমা ইত্যাদির সাথে সম্পর্কিত অনেকগুলি বিষয়ের উপর নির্ভর করবে উদাহরণস্বরূপ, যদি আপনার ওয়েবপৃষ্ঠা জাভাস্ক্রিপ্ট প্রচুর পরিমাণে ব্যবহার করে তবে আপনার ব্রাউজারটি স্ক্রিপ্টগুলি ক্যাশে করতে পারে, যার ফলশ্রুতিতে আরও ভাল পারফরম্যান্স হতে পারে কোডটি একাধিক ফাইলে পৃথক করা হয়েছে। অন্যদিকে, আমি বলার জন্য প্রলুব্ধ হব যে কয়েকটি সার্ভারগুলি একাধিক ছোট ফাইলগুলির চেয়ে দ্রুত একটি একক বৃহত ফাইল পরিবেশন করতে পারে - এক্ষেত্রে কেউ যুক্তি দিতে পারে যে কোডটি পৃথক না করা আরও ভাল পারফরম্যান্স ওয়াইস।

আমি এই অঞ্চলে কোনও আনুষ্ঠানিক পরীক্ষা সম্পর্কে অবগত নই, যদিও সম্ভবত এটি কেউই করেছেন।

শেষ পর্যন্ত, আমি বলব যে এটি যে কোনও কিছুর চেয়ে ভাল অভ্যাসের বিষয়, এবং পাঠযোগ্যতা এবং সংস্থার দিক থেকে সুবিধাগুলি (বিশেষত কব্জি পয়েন্ট 2) কোডটি পৃথক ফাইলে আলাদা করা একটি আরও ভাল বিকল্প হিসাবে তৈরি করে।

Comments

বাহ্যিক ফাইলগুলি অবিচ্ছিন্নভাবে ডাউনলোড করা সম্ভব, যাতে এটি কোনও পরবর্তী পৃষ্ঠার জন্য ক্যাশ করা হয় যাতে দর্শনার্থী পড়ার সময় বা স্ক্রিপ্টটি ডাউনলোড করার সময় পৃষ্ঠা, চিত্রগুলি ইত্যাদি ডাউনলোড করার অনুমতি দেয় - সুতরাং এই কৌশলগুলি চলতে থাকলে পারফরম্যান্স লাভ হতে পারে ব্যবহৃত (ডাউনলোডের সময় কার্যকর করার গতি নয়)।

— FinnNk

Answer 7

উত্তরটি কীভাবে ইন-লাইন কোড (ধরে নিচ্ছে জাভাস্ক্রিপ্ট) ব্যবহার করা হয় তার উপর নির্ভর করে।

আমরা যে প্রভাবগুলি চেয়েছিলাম তা তৈরি করতে এবং অনক্লিক ইভেন্টগুলির জন্য সার্ভারের রিটার্ন ট্রিপগুলি হ্রাস করতে আমরা ইনলাইন কোড, এসএসআই এর (সার্ভার সাইড সহ), জেএস ফাইল এবং সিএসএস ফাইলের সংমিশ্রণটি ব্যবহার করেছি।

সুতরাং কারও পক্ষে কম্বল স্টেটমেন্ট দেওয়ার জন্য যে "ইন-লাইন কোড" এর ব্যবহার খারাপ তা কীভাবে ব্যবহার করা হয়েছে তা পুরোপুরি না বুঝে ভুল হয় যে বিভ্রান্তিমূলক হতে পারে।

যা বলা পরে, যদি প্রতিটি পৃষ্ঠায় একটি জেএস ফাইল ব্যবহার না করে জাভাস্ক্রিপ্ট কোডের একই অনুলিপি এবং পেস্ট করে থাকে তবে আমি বলি যে এটি খারাপ।

যদি প্রতিটি পৃষ্ঠার নিজস্ব অনুলিপি থাকে এবং কোনও সিএসএস ফাইল ব্যবহার না করে সিসিএস বিভাগটি আটকানো হয় আমি বলি এটি খারাপ।

প্রতিটি পৃষ্ঠায় আপনার পুরো জেএস লাইব্রেরি অন্তর্ভুক্ত করার জন্য এটি প্রচুর ওভারহেডও রয়েছে, বিশেষত যদি সেই পৃষ্ঠায় কোনও ফাংশন ব্যবহার করা হচ্ছে না।

Answer 8

আমি এখানে ইনলাইন জাভাস্ক্রিপ্ট ধরে যাচ্ছি।

কোডটি না দেখে নিশ্চিত হওয়া শক্ত। আমার সন্দেহ হয় তিনি দুটি বিষয় দুটির মধ্যে উল্লেখ করেছেন:

1. আপনি <script>পুরো পৃষ্ঠা জুড়ে ছড়িয়ে ছিটিয়ে আছেন
2. আপনার সমস্ত জেএস বাহ্যিক ফাইলগুলিতে নয়, পৃষ্ঠার শিরোনামে রয়েছে

প্রথমটি একটি খারাপ ডিজাইনের সিদ্ধান্ত। একটি উৎস ফাইল সর্বত্র স্ক্রিপ্ট ছড়ানো পৃষ্ঠা তোলে অনেক কঠিন বজায় রাখার জন্য, কারণ আপনি একটি প্রদত্ত স্ক্রিপ্টের জন্য অনুসন্ধান করতে হবে। সমস্ত কোডটি এক জায়গায় রাখা ভাল (আমি উত্স ফাইলের শীর্ষে পছন্দ করি)।

দ্বিতীয় হিসাবে - এটি অগত্যা কোনও খারাপ জিনিস নয়। পৃষ্ঠা নির্দিষ্ট কোডটি সেই পৃষ্ঠাতে থাকা উচিত । আপনার যদি পৃষ্ঠাগুলির মধ্যে নকল কোড থাকে তবে আপনার এটি ব্যবহার করে বহিরাগত করা উচিত <script src>। তারপরে আপনি যখন একটি নতুন পৃষ্ঠা তৈরি করতে যান, আপনি কেবলমাত্র সেই ফাইলটি অন্তর্ভুক্ত করতে পারেন এবং সেখানে যে কোনও বাগ আপনি স্থির করেছেন তা পুনর্বিবেচনা করতে হবে না।

Comments

নোট করুন যে স্ক্রিপ্টগুলি ডাউনলোড করা থেকে অন্য জিনিসগুলিকে ব্লক করে, সাধারণত পৃষ্ঠার নীচে রেখে দেওয়া ভাল (যদিও কখনও কখনও আপনি সেগুলি ব্লক করতে চাইবেন, যার ক্ষেত্রে তারা মাথার মধ্যে থাকে)। সিএসএস, যা সমান্তরালভাবে ডাউনলোড করতে পারে কোনও স্ক্রিপ্ট রেফারেন্সের উপরে শীর্ষে আরও ভাল।

— FinnNk

এখানে অসমত। পৃষ্ঠা সুনির্দিষ্ট জাভাস্ক্রিপ্টের জন্য আরও ভাল নকশা (একমাত্র নয়) কেবলমাত্র সেই পৃষ্ঠায় অন্তর্ভুক্ত একটি পৃথক .js ফাইলে পৃষ্ঠা নির্দিষ্ট জাভাস্ক্রিপ্ট থাকা উচিত। এইভাবে, ফাইলটি

— ক্যাচিংয়ের মাধ্যমে

Answer 9

ইনলাইন জাভাস্ক্রিপ্ট ব্যবহার না করার একটি কারণ (বোতামগুলিতে অনক্লিক = "ডটটিস (এটি)" নয়) হ'ল যদি আপনি নিজের ওয়েব অ্যাপ্লিকেশনটিকে একটি ক্রোম অ্যাপ্লিকেশন করতে চান। সুতরাং, আপনি যদি নিজের ওয়েব অ্যাপ্লিকেশনটিকে একটি নেটিভ ক্রোম অ্যাপ্লিকেশনটিতে পোর্ট করার পরিকল্পনা করছেন তবে কোনও ইনলাইন জাভাস্ক্রিপ্ট না করেই শুরু করুন। আপনি যদি "ক্রোম-এটিজ" করতে চান তবে আপনার ওয়েব অ্যাপ্লিকেশন থেকে আপনাকে কী কী পরিবর্তন করতে হবে (ম্যান্ডোরেটরালি) প্রয়োজন তা শুরুতেই এটি ব্যাখ্যা করা হয়েছে।

Answer 10

ইনলাইন স্ক্রিপ্টিং এর সাথে আসল সমস্যাগুলি কী?

ইনলাইন স্ক্রিপ্টিং খারাপ এবং এড়ানো উচিত কারণ এটি কোডটি পড়া আরও কঠিন করে তোলে।

যে কোডটি পড়তে অসুবিধা তা বজায় রাখা কঠিন। আপনি যদি এটি সহজেই পড়তে না পারেন এবং কী চলছে তা বুঝতে না পারলে আপনি সহজেই বাগগুলি স্পট করতে পারবেন না। যদি এটি বজায় রাখা কঠিন হয় তবে সমস্যাগুলি পরে এটি আপনার আরও সময় নষ্ট করবে।

অসুবিধাটি সাধারণত নেস্টেড এনকোডিংগুলি থেকে আসে। কোডের পরবর্তী লাইনে একটি সমস্যা আছে, আপনি এটি স্পট করতে পারেন?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

আদর্শভাবে কোডটি এমনভাবে লেখা হয় যা কোনও ভুল হওয়ার পরে স্পট করা সহজ করে তোলে। জোয়েল স্পলস্কি একটি দুর্দান্ত নিবন্ধ লিখেছিলেন যা 2005 সালে এই বিষয়টিকে জোর দিয়েছিল । কোড উদাহরণগুলি কিছুটা উল্লেখযোগ্য উন্নতি করতে পারে, কারণ তারা তাদের বয়স 9 বছর বয়সী দেখায় তবে অন্তর্নিহিত ধারণাটি এখনও শক্তিশালী: কোডগুলি এমনভাবে লিখুন যাতে বাগগুলি বাছাই করা সহজ হয়।

কোনও উল্লেখযোগ্য পারফরম্যান্সের সমস্যা আছে, বা এটি বেশিরভাগ ক্ষেত্রে কেবল ভাল স্টাইলের বিষয়?

ইনলাইন স্ক্রিপ্টিং পুনরাবৃত্তি বাড়ে। 100 পৃষ্ঠাগুলিকে প্রভাবিত করার জন্য কোডের এক লাইন পরিবর্তন করার পরিবর্তে, আপনার পৃথকভাবে 100 পৃষ্ঠাগুলি পরিবর্তন করতে হবে। এটি দুর্বল পাঠযোগ্যতার সাথে রক্ষণাবেক্ষণকারীর কার্য সম্পাদনকে মারাত্মকভাবে প্রভাবিত করে । প্রোগ্রামিং সময়ের একটি আসল ব্যয় হয় যা বেশিরভাগ কোড অপটিমাইজেশন থেকে কয়েক মিলিসেকেন্ডের চেয়ে দ্রুত ব্যবসায়ের নীচের লাইনে প্রভাবিত করে। অবশ্যই বাধাগুলি অপ্টিমাইজ করা গুরুত্বপূর্ণ, তবে কোডটির পারফরম্যান্স পার্থক্য এক্ষেত্রে নগণ্য।

আমার উর্ধ্বতনদের কাছে আমি যখন ইনলাইন স্ক্রিপ্টিংয়ের সামনে তাত্ক্ষণিক পদক্ষেপের ন্যায্যতা প্রমাণ করতে পারি, তখন সেখানে কাজ করার অন্যান্য জিনিসগুলি সাইটে আরও স্পষ্ট প্রভাব ফেলতে পারে?

না। এটি যদি বোকা এবং এটি কাজ করে তবে এটি বোকা নয়।

এটির জন্য প্রোগ্রামিং করোলারিটি হ'ল: এটি যদি বোকা কোড হয় এবং এটি কাজ করে তবে এটি বোকা কোড নয়। ভাঙা নয় এমন কিছু ঠিক করার চেষ্টা করার আগে আসল সমস্যাগুলিতে মনোনিবেশ করুন। ছয় ঘন্টা, ছয় মাস বা ছয় বছরের মধ্যে যখন ইনলাইন কোডটি শেষ পর্যন্ত কোনও আপডেটের প্রয়োজন হয়, কোডটি এমনভাবে ঠিক করুন যাতে এটির ভবিষ্যতের রক্ষণাবেক্ষণ আরও সহজ করে।

কোন কারণগুলি আপনাকে "এইচএমএম, পেশাদার পেশাগত কাজ এখানে" বলতে পরিচালিত করবে এবং কী কারণে আপনি স্পষ্টতই অপেশাদার কাজ থেকে বিরত হবেন?

আমি কেবলমাত্র "পেশাদার" সংজ্ঞায়িত করতে পছন্দ করি যাঁকে কোনও কাজ সম্পাদনের জন্য অর্থ প্রদান করা হয়, তার চেয়ে বরং তারা যে কাজটি পাচ্ছে তার ক্ষেত্রে তারা কোনও উল্লেখযোগ্য দক্ষতার অধিকারী। অনেক পেশাদার অবশ্যই ভাল কাজ সম্পাদন করতে সক্ষম, তবে প্রায়শই আমি নিজেকে একজন অপেশাদারের সামনে আসা কিছু না করে অন্য পেশাদাররা যে ভয়াবহ কাজটি করেছিলাম তা ভয়াবহ অবস্থায় ডুবে থাকতে দেখি। আজ অবধি আমার বেশিরভাগ কাজ ট্রেন-রেক প্রকল্পগুলি উদ্ধার করে যা প্রাথমিক বিকাশকারীরা পেয়েছিল, তাই আপনার মাইলেজ ভিন্ন হতে পারে।

যা বলা হয়েছে তার সাথে, সাধারণত এন্টারপ্রাইজ মানের প্রোগ্রামিং বেছে নেওয়া সহজ