Canvas Native

Mouse+keyboard inputlarni test qilyapman. Bularni qo'shish unchalik ham qiyin bo'lmadi lekin.

https://github.com/diyorbek/canvas-native

Kod yozinglar ey! Nima bo'lopti bera? 🤔🥲

https://t.me/JoshDeveloper/3073

HTMS - Hypertext Markup Stylesheets

Yana bir eksperimental loyiha. SCSS orqali HTML sahifa yasash.

div {
  position: fixed;

  span {
    font-size: 23px;
  }
}

<div style="position:fixed;">
  <span style="font-size:23px;">
  </span>
</div>

P.S. Universitetda "Automata and Grammar" fani uchun qilgan loyiham edi. 4 baho oganman 😬

https://github.com/diyorbek/htms

Bun.js ni Rust tiliga o'tkazisharkan. Bir hafta oldin shunchaki eksperiment qilyapman deb PR ochgan edi Bun.js avtori. Endi esa to'liq Rustga o'tamiz deyapti. Shu paytgacha Zig tilida yozilgan va juda ko'p segmentation fault va memory leak'lar sabab undan voz kechishyptgan ekan.

Shu kodni yozguncha, qo'ling sinsa bo'masmidi? 😑😤😐

EDIT: Agar har bir qatorda xato ko'rmayotgan bo'lsangiz, demak siz ham shunaqa kod yozarkansiz 🥲

Hozir asosan ofisga borib ishlayman. Ba'zida esa uydan ishlash shunaqa bo'ladi.

Aytgancha, AOT compilation - Ahead of Time compilation.

Kompilyatsiya qilinadigan tillar shunaqa deyiladi. Masalan C, C++, Rust, Go.

JavaScript interpretatsiya qilinadigan til bo'lib yaralgan. Lekin ECMA stardarti JavaScript engine'lar shunday ishlashi kerak deb shart qo'ymaydi.

Ya'ni JavaScript interpretatsiya yoki kompilayatsiya qilinishini engine belgilaydi. Shuning uchun JavaScriptga til sifatida interpretatsion yoki kompilyatosion deb ta'rif berish to'g'ri bo'lmaydi.

Ammo, tildagi (ECMAScript spetsifikatsiyasi) ba'zi konstruksiyalar engine'ni interpretatsion bo'lishiga signal berishi mumkin. Masalan "eval", "Function" orqali yangi funksiya yasash, "Proxy" kabilar. Lekin spetsifikatsiya ularning ishlash prinsipini belgilaydi xolos. Chunki bu konstruksiyalar uchun engine aynan interpretatsion bo'lishi shart emas. Shunchaki ish sal qiyinlashadi.

Xullas kalom, JavaScript kompilyatsiya bo'lishi ham mumkin. AOT-compiled JS enginelar ham bor. Misol uchun Perry va Porffor.

Yuqoridagi so'rovnomada barcha javoblar to'g'ir deb qabul qilsak ham bo'ladi.

Qaysi mavzularda post/maqola yozay?

Material UI Performace

Ba'zi frontenchiladan Material UI da perfromance yomon, og'ir ishlaydi, bundle size katta degan gaplarni eshitganman.

Ha, MUI shunday. Lekin ishonch bilan ayta olamanki, dasturning sekin ishlashi bu kabi "battle-tested" kutubxonalardan kelmaydi. Balki uni noto'gri ishlatish yoki uning ustida "musor" kod yozishdan keladi.

Shunday ekan aybni oldin o'zingizdan qidiring!

Shu paytgacha men ustida ishlagan dasturlar ichida hech qachon MUI bottleneck bo'lmagan.

P.S.

BILLZ da ham MUI v5 ishlatib kelinadi. MUI ni upgrade qilish, shu bilan birga balki undan voz kechish masalasini tezt tez yuzaga chiqib turardi. Anchadan beri MUI dan voz kechmaslik kerakligini, shunchaki undan togri foydalanib, "normalniy" dizayn sistema qurishni aytib kelardim. Bu safar aniq sonlar bilan bu mavzuni yopdim.

Erinmasdan Chrome Dev tools da bir necha marta turli case'larda performace test qildim. Eng og'ir ishlaydigan modullarni analiz qilib chiqdim. Dastur sekin ishlashiga asosiy sabab baribir MUI bo'lib chiqmadi.

Natijalari:


Page 1:
- long task ~158ms
- JSS + plugins ~12ms
- больше времени уходит в native DOM/layout, React, react-input-autosize, Emotion, AG Grid

Page 2:
- long task ~141ms
- JSS + plugins ~9ms
- больше времени уходит в native DOM, react-input-autosize, React, AG Grid, Emotion/MUI system

Page 3:
- long task ~93ms
- JSS + plugins ~12ms
- основной cost снова в native DOM/layout + распределен между React/app/MUI/Emotion

Page 4:
- long tasks ~94ms и ~66ms
- JSS от <1ms до ~7ms
- заметно больше AG Grid, native DOM/layout, React

Migratsiya yaxshi yechim emas. Shuning uchun mana shu taklifni - "proposal"ni berdim.

Hayotda ancha, anchaa foydasi tegadigan lekin biz unchalik mensimaydigan ko'nikmalar

- yozishdagi aniqlik
- gapirishdagi aniqlik