Ինչու են ծրագրավորողները կրկին ընտրում իրենց սեփական կոդը վեբ-հարթակի փոխարեն

Պատմություն և սովորույթ

Բրաուզերի ֆունկցիաների օգտագործման առավելության համար սեփական JavaScript-ի փոխարեն հիմնական արգումենտներն են արդյունավետությունը, գործածելիությունը և հասանելիությունը, բայց դրանց ներդրումը միշտ հեշտ չի եղել: Վեբի պատմության մեծ մասի համար բրաուզերները հետ էին մնում ավելի լայն վեբ-էկոհամակարգից: jQuery-ի նման գրադարանները լրացնում էին կարևոր բացակայությունները, և ծրագրավորողները հաճախ սպասում էին հին բրաուզերների, օրինակ IE6-ի, հնանալուն, նախքան նոր API-ներ օգտագործելը: Այդ միջավայրում բրաուզերի վրա կառուցումը տրամաբանական պատասխան էր: Սովորույթը կրկին նշանակություն ունի. React-ի ծրագրավորողները, ովքն միշտ սովորել են որոնել կոմպոնենտներ npm-ում, կարող են փնտրել փաթեթ՝ նախքան CSS-ի կամ բրաուզերի API-ի քննարկումը: Wrapper-ները անծանոթ հարթակի ֆունկցիաները ավելի հասկանելի են դարձնում, իսկ փաթեթի փաստաթղթավորումը հաճախ ավելի հեշտ է գտնել, քան վեբ-հարթակի համար տարածված տեղեկությունները: MDN-ը ավելի ուշ դարձավ կենտրոնական փաստաթղթավորման ուղղություն, իսկ web.dev-ը ներկայացվել է որպես Google-ի ավելի նոր կրթական ջանք:

Կառուցման գրավչությունը

Որոշ ծրագրավորողների համար ինքնուրույն իրականացումը բավարար է: Մոդալ երկխոսությունը կարող է սկսվել տեսանելի դիրքավորմամբ և ֆոնի ոլորմամբ, այնուհետև կարիք գա Escape կոճակի մշակման, ֆոկուսի որոգայթի և ֆոկուսի վերականգնման: Մշակողները կարող են ավելացնել անիմացիաներ, թեմաներ կամ փակման կոճակ՝ նախքան արդյունքը նորին օգտագործելի փաթեթ դարձնելը: Աղբյուրը սա IKEA-ի ֆեկտով է անվանում, քանի որ ձեռքով գրված կոդը կարող է արթնացնել դրա պահպանման և հատուկացման ցանկությունը: Սեփական գործիքները նաև ուսուցման ճանապարհ կարող են լինել. Հեղինակը աշխատել է IndexedDB-ի, WebSQL-ի և PouchDB-ի հետ կապված պահեստավորման գործիքների վրա, ավելի ուշ ներդրելով իր ներդրումը IndexedDB-ի սպեցիֆիկացիայի մեջ: Հարթակի վաղ շրջանի խնդիրները նպաստում էին polyfill-ներին, shim-ներին և գրադարաններին, ինչը օգնում էր ստեղծել հարթակի մասնագիտական գիտելիքներ:

AI-ը կարող է փոխել հավասարակշռությունը

AI-ի վրա հիմնված ծրագրավորումը կարող է այս պահվածքը երկու ուղղություններով էլ քաշել: Օպտիմիստական դեպքն է, որ մեծ լեզվական մոդելերը կարող են ապավինել լայն հարթակի գիտելիքներին, ընտրել համապատասխան բնական API-ները խառնված պահանջներից և թեստավորումից հետո ավելի արագ և ճիշտ հարթակի ֆունկցիաներին առավելություն տան: Քանի որ ծրագրավորողները ավելի քիչ կոդ են գրում, սեփական իրականացումների նկատմամբ կախվածությունը կարող է թուլանալ: Պեսիմիստական դեպքն է, որ մոդելերը կարող են նորից ստեղծել արդեն առկա օգնականները, խուսափել հարթակի կոնվենցիաներից և բավարար թեստավորում անելու առանց բարդ լուծումներ գեներացնել: Հեղինակը տեսնում է երկու արդյունքները և չի կարող ասել, թե ո՞րն կդառնա դոմինանտ, երբ մոդելերը և ծրագրավորման գործիքները կատարելագործվեն: Եզրակարգությունն այն է, որ հարթակի օգտագործումը դեռ արժեքավոր է, բայց պատմությունը, սովորությունը, փաստաթղթավորման թերությունները, կառուցման հաճույքը և անլրիվ հասկացողությունը բացատրում են, թե ինչու ծրագրավորողները կրկին ընտրում են իրենց սեփական կոդը: