რატომ ირჩევენ დეველოპერები კვლავ საკუთარ კოდს ვებ-პლატფორმის ნაცვლად

ისტორია და ჩვევა

ბრაუზერის ფუნქციების გამოყენების სასარგებლოდ საკუთარი JavaScript-ის ნაცვლად მთავარი არგუმენტებია წარმადობა, გამოყენებადობა და ხელმისაწვდომობა, მაგრამ მათი დანერგვა ყოველთვის მარტივი არ ყოფილა. ვებ-ის ისტორიის დიდი ნაწილისთვის ბრაუზერები უფრო ფართო ვებ-ეკოსისტემას ჩამორჩებოდნენ. jQuery-ს მსგავსი ბიბლიოთეკები ავსებდნენ მნიშვნელოვან ხარვეზებს, და დეველოპერებს ხშირად უწევდათ ძველი ბრაუზერების, მაგალითად IE6-ის, მოძველებას დალოდებოდნენ, სანამ ახალ API-ებს გამოიყენებდნენ. ამ გარემოში ბრაუზერის თავზე აშენება გონივრული პასუხი იყო. ჩვევას კვლავ მნიშვნელობა აქვს: React-ის დეველოპერები, რომლებიც მიჩვეულნი არიან კომპონენტების npm-ზე ძებნას, შეიძლება პაკეტს ეძებონ სანამ CSS-ს ან ბრაუზერის API-ს განიხილავენ. Wrapper-ები შეუცნობელ პლატფორმის ფუნქციებს უფრო გასაგებს ხდიან, ხოლო პაკეტის დოკუმენტაცია ხშირად უფრო ადვილად საპოვნელი იყო, ვიდრე ვებ-პლატფორმისთვის მიმოფანტული ცნობები. MDN-მა მოგვიანებით ცენტრალური დოკუმენტაციის მიმართულება გახდა, ხოლო web.dev წარმოდგენილი იყო როგორც Google-ის უფრო ახალი საგანმანათლებლო მცდელობა.

აშენების მიმზიდველობა

ზოგიერთი დეველოპერისთვის თავად იმპლემენტაციაა დამაკმაყოფილებელი. მოდალური დიალოგი შეიძლება დაიწყოს ხილული პოზიციონირებითა და ფონის სქროლვით, შემდეგ კი საჭირო გახდეს Escape ღილაკის დამუშავება, ფოკუსის ხაფანგი და ფოკუსის აღდგენა. დეველოპერებს შეუძლიათ დაამატონ ანიმაციები, თემები ან დახურვის ღილაკი, სანამ შედეგს ხელახლა გამოსაყენებელ პაკეტად აქცევენ. წყარო ამას IKEA-ს ეფექტს უწოდებს, რადგან ხელით დაწერილ კოდს შეუძლია გააღვიძოს მისი შენარჩუნებისა და კასტომიზაციის სურვილი. საკუთარი ინსტრუმენტები ასევე სწავლის გზა შეიძლება იყოს: ავტორი მუშაობდა IndexedDB-ზე, WebSQL-სა და PouchDB-სთან დაკავშირებულ შენახვის ინსტრუმენტებზე, მოგვიანებით კი IndexedDB-ის სპეციფიკაციაშიც შეიტანა წვლილი. პლატფორმის ადრინდელი ხარვეზები ხელს უწყობდნენ polyfill-ებს, shim-ებსა და ბიბლიოთეკებს, რაც პლატფორმის ექსპერტიზის შექმნას ეხმარებოდა.

ცოდნის ხარვეზები და პლატფორმის ქცევა

ყველა საკუთარი გადაწყვეტა არ ასახავს გააზრებულ კომპრომისს; ნაწილი არასრული ცოდნიდან მოდის. CSS-ის ისეთი ფუნქციები, როგორიცაა float-ები, clear fix და min-width: 0, ძნელი გასაგები იყო, ხოლო ჩვეულებრივი საჭიროებები, მათ შორის ხაზების შეზღუდვა, textarea-ს ზომის შეცვლა და სქროლბარის დამალვა, წლების განმავლობაში პირდაპირი ნატიური გადაწყვეტების გარეშე რჩებოდა. დეველოპერებს სასურველი ქცევის გამოხატვა JavaScript-ში უფრო ადვილად შეეძლოთ. ClickHouse-ის მაგალითმა იგივე შედეგი მოგვცა. ერთმა დეველოპერმა დიდი JSON შეაკუმშა შენახვამდე, ხოლო მეორემ ის ცალკე key-value საცავში მოათავსა და ClickHouse-ში მხოლოდ გასაღები შეინახა. დოკუმენტაციის გადახედვისა და ბენჩმარკინგის შემდეგ მათ აღმოაჩინეს, რომ ClickHouse უკვე აკუმშებს სვეტოვან მონაცემებს და უკეთეს შეკუმშვას იძლევა რიგებს შორის, რაც ცალკე სისტემას უფრო ნელი და მოუქნელი ხდიდა.

AI-მ შეიძლება შეცვალოს ბალანსი

AI-ზე დაფუძნებულმა კოდირებამ შეიძლება ეს ქცევა ორივე მიმართულებით წაიყვანოს. ოპტიმისტური შემთხვევაა, რომ დიდ ენობრივ მოდელებს შეუძლიათ ფართო პლატფორმის ცოდნას დაეყრდნონ, ბუნდოვანი მოთხოვნებიდან შესაბამისი ნატიური API-ები შეარჩიონ და ტესტირების შემდეგ უფრო სწრაფ და სწორ პლატფორმის ფუნქციებს მიანიჭონ უპირატესობა. რადგან დეველოპერები ნაკლებ კოდს წერენ, საკუთარი იმპლემენტაციებისადმი მიჯაჭვულობა შეიძლება შესუსტდეს. პესიმისტური შემთხვევაა, რომ მოდელებმა შეიძლება უკვე არსებული დამხმარეები ხელახლა შექმნან, პლატფორმის კონვენციებს აარიდონ თავი და საკმარისი ტესტირების გარეშე რთული გადაწყვეტები დააგენერირონ. ავტორს ორივე შედეგი უნახავს და ვერ ამბობს, რომელი გახდება დომინანტური, როცა მოდელები და კოდირების ხელსაწყოები დაიხვეწება. დასკვნა ისაა, რომ პლატფორმის გამოყენება კვლავ ღირებულია, მაგრამ ისტორია, ჩვევა, დოკუმენტაციის ხარვეზები, აშენების სიამოვნება და არასრული გაგება გვიხსნის, რატომ ირჩევენ დეველოპერები კვლავ საკუთარ კოდს.