কেন এন-টায়ার বিকাশের কোড-বেসগুলিতে এখন জাভাস্ক্রিপ্ট কোডটি সমান পরিমাণ, যদি না হয়?


32

আমি এখন দীর্ঘকাল ধরে ওয়েব প্রোগ্রামিং করে চলেছি, এবং কোথাও, আমরা আজ আমরা যা করছি তা কেন (বা আমরা কীভাবে এভাবে জিনিসগুলি করতে এসেছি) এর ট্র্যাক হারিয়ে ফেলেছি?

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

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

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

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

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

প্রাক-জিকুয়েরি যুগে, আমি প্রচুর ডায়াগ্রাম দেখেছি যেখানে এন-টায়ার ডেভলপমেন্টে এমভিসিতে এম, ভি এবং সি এর মধ্যে একটি স্পষ্ট, ধারণাগত লাইন ছিল। পোস্ট-জিকুয়ারি, এই লাইনগুলি কোথায় আঁকা? মনে হচ্ছে এমভিসি এবং এমভিভিএম ঠিক আছে ঠিক আছে সেখানে জাভাস্ক্রিপ্ট কোড, ক্লায়েন্ট-সাইড।

আমি যা জানতে চাই তা হ'ল, আমরা কেন এমন রূপান্তর করেছি (সার্ভার-সাইড প্রোগ্রামিংয়ের জোর থেকে শুরু করে ক্লায়েন্ট-সাইডে, সংকলিত ভাষাগুলিকে স্ক্রিপ্টিং ভাষাগুলিতে সমর্থন করা থেকে অপরিহার্য থেকে কার্যকরী প্রোগ্রামিং পর্যন্ত, এই সমস্তগুলি একই সাথে ঘটেছিল বলে মনে হয়) ) এবং এই রূপান্তর / শিফ্ট কোন সমস্যার সমাধান করেছে?


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

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

1
আমি নেটিভ ইংলিশ স্পিকার না, তবে শিরোনামটি পরিষ্কার করা যেতে পারে?
বিগস্টোনস

1
জাভাস্ক্রিপ্ট একটি অগ্রগতি আছে? ভাষাটি এখনও ES5 (11/2014)। বেশিরভাগ অগ্রগতি মনে হয় সরাসরি জাভাস্ক্রিপ্ট না ব্যবহার করার চেষ্টা করছেন: ডার্ট, টাইপসক্রিপট, এটিস্ক্রিপ্ট ইত্যাদি
ডেন

1
কারণ বিতরণকৃত / মোবাইল ডিভাইসগুলিতে এখন পর্যাপ্ত সিপিইউ শক্তি রয়েছে যে তারা স্থানীয়ভাবে এমন কাজ করতে পারে যা বৃহত কেন্দ্রীয় সার্ভারের ওম্প প্রয়োজন ph
কিলিয়ান ফট

উত্তর:


62

সার্ভার এবং ক্লায়েন্টের মধ্যে কম্পিউটিং লোড স্থানান্তর করা একটি চক্রীয় ঘটনা এবং বেশ কিছু সময়ের জন্য এটি ছিল।

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

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

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

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

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

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


1
As the computers became increasingly more powerful, divisions of labor became possible [...] you have lots of choices about where you can execute your processing power, both on the client and on the server.- আমি বলব যে এই দুটি পয়েন্ট একসাথে সার্ভার এবং ক্লায়েন্টের মধ্যে ভারসাম্য রক্ষার জন্য একটি দুর্দান্ত ক্ষেত্রে তৈরি করেছে: এগুলি প্রতিটি নির্দিষ্ট কাজের পক্ষে উপযুক্ত এবং সেই কাজগুলি এখন সুস্পষ্টভাবে সংজ্ঞায়িত এবং সহজেই কার্যকর করা হয়েছে।
জেস টেলফোর্ড

5

আপনি দুটি খুব ভিন্ন ধারণার মিশ্রণ করছেন বলে মনে হচ্ছে:

  1. উপস্থাপনা এবং ব্যবসায়ের লজিক (এমভিসি) => রক্ষণাবেক্ষণযোগ্যতা পৃথক করে
  2. কোনও নোডকে এক্সিকিউশন নির্ধারণ => দক্ষতা বাড়ানো

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

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

  • ক্লায়েন্টের বিলম্বতা বনাম জটিলতা: সার্ভার-সাইড প্রসেসিং সিস্টেমগুলি সহজ রাখে কারণ ক্লায়েন্টে কোনও কোড মোতায়েন / ডাউনলোড করার প্রয়োজন হয় না, যদিও এটি গণনার সময় ক্লায়েন্ট-সাইড ল্যাটেন্সির ব্যয় হয়।

  • সার্ভার লোড বনাম জটিলতা: ক্লায়েন্ট-সাইড কম্পিউটিং সিস্টেমের জটিলতা বাড়িয়ে তুলতে পারে তবে এটি সার্ভার লোড হ্রাস করতেও সহায়তা করতে পারে।

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

এটি অনেক ট্রেড অফের একটি অ-নিষ্ক্রিয় তালিকা।


4

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

জাভা বা সি # এর মতো প্রোগ্রামিং ভাষা ব্যবহার করে বেশিরভাগ ব্যাকেন্ড ডেভলপমেন্ট কেবল একটি আরএসটি-এর মতো ইন্টারফেস তৈরি করা এবং প্রদর্শন, ভিজ্যুয়ালাইজেশন, ডেটা ইনপুট / আউটপুট, ব্যবহারকারীর ইন্টারঅ্যাকশন ইত্যাদির সমস্ত কঠোর প্রচেষ্টা ক্লায়েন্ট- এর মাধ্যমে সম্বোধন করা হয়- পাশের কাঠামো যেমন কৌণিক, ব্যাকবোন, আম্বর, নকআউট ইত্যাদি ...

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


2

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

সার্ভার থেকে ক্লায়েন্ট-সাইড ডেভলপমেন্টের কেন এই চলাচল হয়েছে?

এখানে আসলে দুটি প্রশ্ন রয়েছে:

  1. যেখানে ক্লায়েন্ট-সাইড প্রোগ্রামিং হচ্ছে যেখানে অগ্রগতি হচ্ছে?
  2. অ্যাপ্লিকেশনগুলি সার্ভারের চেয়ে ক্লায়েন্টে চালানোর জন্য কেন লিখিত হয়?

দুটি আসলে আলাদা।

যেখানে ক্লায়েন্ট-সাইড প্রোগ্রামিং হচ্ছে যেখানে অগ্রগতি হচ্ছে?

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

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

এই কারণগুলি ক্রমবর্ধমানভাবে পরিবর্তিত হয়েছে, তারা ধনী ক্লায়েন্ট অ্যাপ্লিকেশনগুলি দ্রুতগতিতে বিকাশ করার জন্য এবং এগুলি ধারাবাহিকভাবে চালনার জন্য একটি গুরুত্বপূর্ণ ভর তৈরি করেছে।

আপনার প্রশ্নের উত্তরে, ততক্ষণ, নতুন ফ্রন্ট-এন্ড প্রযুক্তিগুলি অগ্রগতির দিকে ধাক্কা দিয়েছে এমনটি নয়, যতই তারা বাধা ছাড়িয়েছে এবং ক্লায়েন্টকে ব্যবহারকারীদের আশা-আকাক্সক্ষাকে ধরতে দেয়।

অ্যাপ্লিকেশনগুলি সার্ভারের চেয়ে ক্লায়েন্টে চালানোর জন্য কেন লিখিত হয়?

প্রচুর প্রাক্কলিত কারণ রয়েছে তবে সাম্প্রতিক বছরগুলির মধ্যে সবচেয়ে স্বাতন্ত্র্য হ'ল স্মার্টফোনের উত্থান।

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

কিভাবে এটি অন্যরকম হতে পারে? ভাবুন আপনার স্মার্টফোনটি যদি কেবল বোবা টার্মিনাল হয়। প্রতিটি রাষ্ট্রীয় রূপান্তরকে অ্যাসিনক্রোনাস এবং ফলস্বরূপ হতে হবে। প্রতিটি বিষয়বস্তু লোড মূল্যবান সেন্ট করতে হবে। আপনাকে পাঁচ-নাইন আপটাইম সহ প্রচুর সার্ভার ফার্মগুলিতে বিনিয়োগ করতে হবে। গণনা ব্যয় সরাসরি আপনার দ্বারা ব্যয় করা হবে, তাই জনপ্রিয়তার আকস্মিক উত্সব আসলে আপনার ব্যবসায়কে ঝুঁকতে পারে।

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

এটিকে খুব বিস্তৃত ভাষায় বলতে: ক্লায়েন্ট-পার্স ডেভলপমেন্ট মিড-পাওয়ার পার্সোনাল কমপিউটিংয়ের স্বল্প ব্যয়কে কাজে লাগায় এবং উচ্চ-শক্তি কেন্দ্রিয় কম্পিউটারের উচ্চ ব্যয়কে এড়িয়ে চলে।


-1

আপনি বেশ কয়েকটি প্রশ্ন জিজ্ঞাসা করেছেন, যার মধ্যে ইতিমধ্যে ইতিমধ্যে ভাল উত্তর রয়েছে। কয়েকটি এখনও তাদের উত্তর ছিল না:

আমি যা জানতে চাই তা হ'ল, আমরা কেন এমন রূপান্তর করেছি (সার্ভার-সাইড প্রোগ্রামিংয়ের জোর থেকে ক্লায়েন্ট-সাইডে, ... এই সমস্তগুলি একই সাথে ঘটেছে বলে মনে হয়) এবং এই রূপান্তর / শিফ্ট কোন সমস্যাগুলি সমাধান করেছিল?

রবার্ট হার্ভে একটি দুর্দান্ত উত্তর দিয়েছেন।

... সংকলিত ভাষার পক্ষে স্ক্রিপ্টিং ভাষা,

স্ক্রিপ্টিং ভাষাগুলি সংকলিত ভাষার তুলনায় অনেক সুবিধা ( এছাড়াও ) সরবরাহ করে, যেমন:

  • শেখা এবং ব্যবহার করা সহজ easier
  • সংকলন সময় (দ্রুত উন্নয়ন) অপসারণ
  • আরও বৈশিষ্ট্য সরবরাহ করুন (উচ্চ-শেষ অ্যাপ্লিকেশন নিয়ন্ত্রণ)
  • চলমান কোডে দ্রুত পরিবর্তনের অনুমতি দিন
  • প্রভৃতি

... অপরিহার্য থেকে কার্যকরী প্রোগ্রামিং পর্যন্ত,

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


নীচের ভোটার যদি আমার উত্তর (গুলি) পছন্দ করেন না তবে কোন অংশটি পছন্দ করতে বলার সাহস থাকলে তা পছন্দ করবে?
ফুহরম্যানেটর

পূর্ববর্তী দু'জন ভোটার কেন তা করেছে তা আমি বলতে পারছি না, তবে আমার কারণ হ'ল এটি পূর্বের উত্তরগুলির একটি মন্তবীর মতো দেখতে মনে হচ্ছে , বরং জিজ্ঞাসিত প্রশ্নের সাথে জড়িত ( উত্তর কীভাবে দেখুন )
gnat

@ উপস্থিত আমি প্রতিক্রিয়া প্রশংসা করি। আমি প্রশ্নের বিভিন্ন অংশ (যথা সংকলিত বনাম স্ক্রিপ্ট এবং আবশ্যক বনাম কার্যকরী) উদ্ধৃত করেছি যা অন্য কোথাও উত্তর দেওয়া হয়নি। আমি এটিতে 3 টি upvotes পেয়েছি, তাই আমি দেখতে পাচ্ছি এটি একটি মিশ্র প্রতিক্রিয়া।
ফুহরম্যানেটর
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.