ವೆಬ್ ಅಭಿವೃದ್ಧಿ ಲೋಕವು ಒಂದು ದಶಕದ ಬಹುಪಾಲು ಸಮಯವನ್ನು ಬ್ರೌಸರ್ ಎಲ್ಲಾ ಭಾರೀ ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕು ಎಂದು ತನ್ನನ್ನು ತಾನೇ ನಂಬಿಸಿಕೊಳ್ಳುವಲ್ಲಿ ಕಳೆದಿದೆ. ನಾವು ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಮತ್ತು ಫಾರ್ಮ್‌ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿದೆವು, ನಂತರ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವನ್ನೂ ಕ್ರಮೇಣ ಕ್ಲೈಂಟ್‌ನತ್ತ ಸ್ಥಳಾಂತರಿಸಿದೆವು. Routing, state management, data fetching, rendering logic, ಮತ್ತು GraphQL ಮೂಲಕ ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕೂಡ ಇದರಲ್ಲಿ ಸೇರಿವೆ — ಇವೆಲ್ಲವೂ JavaScript bundles ಒಳಗಡೆ ಚಲಿಸಿವುವುವು, ಮತ್ತು ಪ್ರತಿ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಅವುಗಳ ಗಾತ್ರವೂ ಹೆಚ್ಚುತ್ತಾ ಹೋಯಿತು. Frameworksಗಳು ಹೆಚ್ಚಾದವು, build pipelinesಗಳು ಸಂಕೀರ್ಣವಾದವು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಲಿ ಎಂಬ ಉದ್ದೇಶದಿಂದ ಪ್ರಾರಂಭವಾದ ಈ ಪ್ರಕ್ರಿಯೆಯು, ಮೆಗಾಬೈಟ್‌ಗಳಷ್ಟು ಕೋಡ್ ಡೌನ್‌ಲೋಡ್ ಆಗಿ, ಪಾರ್ಸ್ ಆಗಿ, ಮತ್ತು ಎಕ್ಸಿಕ್ಯೂಟ್ ಆಗುವವರೆಗೆ ಒಂದು ಪುಟವು ಒಂದು ಅರ್ಥಪೂರ್ಣ ಪಿಕ್ಸೆಲ್ ಅನ್ನು ಸಹ ತೋರಿಸಲಾಗದಂತಹ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಗಿ ಬದಲಾಯಿತು.

ಈ ಬದಲಾವಣೆಯು ನೈಜ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿತು. ಸ್ವಲ್ಪ ಪ್ರಮಾಣದ jQuery ಹೊಂದಿದ್ದ ಸರ್ವರ್-ರೆಂಡರ್ಡ್ ಪುಟಗಳು, ಬಳಕೆದಾರರು ನಿರೀಕ್ಷಿಸುವ ಸುಗಮವಾದ, ಅಪ್ಲಿಕೇಶನ್‌ನಂತಹ ಪರಿವರ್ತನೆಗಳನ್ನು (transitions) ನೀಡಲು ಹೆಣಗಾಡುತ್ತಿದ್ದವು. Single Page Applications ನಮಗೆ ತಕ್ಷಣದ ನ್ಯಾವಿಗೇಷನ್, ಸ್ಥಿರವಾದ ಸ್ಟೇಟ್ (persistent state) ಮತ್ತು ಶ್ರೀಮಂತ ಸಂವಹನಗಳನ್ನು ನೀಡಿದವು. ಆದರೆ ಇದರ ಬೆಲೆ ಹೆಚ್ಚಾಯಿತು. ಈಗ ತಂಡಗಳು ಸಂಕೀರ್ಣವಾದ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸ್ಟೇಟ್ ಸ್ಟೋರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ, ಬೃಹತ್ JavaScript bundles ಗಳನ್ನು ನಿಭಾಯಿಸಬೇಕಾಗುತ್ತದೆ, ಸೂಕ್ಷ್ಮವಾದ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಲೇಯರ್‌ಗಳನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಬಾರಿ ಅವುಗಳೇ ಒಂದು ಪೂರ್ಣಾವಧಿ ಕೆಲಸದಂತೆ ಭಾಸವಾಗುವ build pipelines ಗಳನ್ನು ಡಿಬಗ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ನಾವು ಒಂದು ರೀತಿಯ ಸಮಸ್ಯೆಗಳ ಬದಲಿಗೆ ಇನ್ನೊಂದು ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಮತ್ತು ಅನೇಕ ಡೆವಲಪರ್‌ಗಳು ಈಗ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಕೂಡ ಈ ತೆರಿಗೆಯನ್ನು (tax) ಪಾವತಿಸಬೇಕೇ ಎಂದು ಕೇಳುತ್ತಿದ್ದಾರೆ.

ಎರಡು ಬೆಳವಣಿಗೆಗಳು ಆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತಿವೆ.

HTMX ಮತ್ತು Hypermedia ನ ಮರಳುವಿಕೆ

ಮೊದಲನೆಯದು HTMX. ಮೇಲ್ನೋಟಕ್ಕೆ ಇದು ಒಂದು ಸಣ್ಣ ಲೈಬ್ರರಿಯಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಇದರ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಪರಿಣಾಮ ದೊಡ್ಡದಿದೆ. HTMX, HTML ಅನ್ನು JavaScript ಮೂಲಕ ವಿಸ್ತರಿಸಬೇಕಾದ ಒಂದು ಸ್ಟ್ಯಾಟಿಕ್ ಶೆಲ್ ಆಗಿ ಪರಿಗಣಿಸುವ ಬದಲು, ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್‌ನ ನೈಸರ್ಗಿಕ ಫಾರ್ಮ್ಯಾಟ್ ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇಲ್ಲಿ ಏನು ಬದಲಾಗುತ್ತದೆ ಎಂದರೆ: ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ, ಬಳಕೆದಾರರು ಹೆಚ್ಚಿನ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡಲು ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಫ್ರಂಟ್‌ಎಂಡ್ ಒಂದು fetch ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, JSON ಪೇಲೋಡ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ, ಅದನ್ನು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ ನಾರ್ಮಲೈಸ್ ಮಾಡುತ್ತದೆ, ಅದನ್ನು ಕಾಂಪೊನೆಂಟ್ ಟೆಂಪ್ಲೇಟ್ ಮೂಲಕ ರನ್ ಮಾಡುತ್ತದೆ, virtual DOM ಅನ್ನು ಡಿಫ್ (diff) ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಪುಟವನ್ನು ಪ್ಯಾಚ್ ಮಾಡುತ್ತದೆ. HTMX ಈ ಸರಪಳಿಯನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸುತ್ತದೆ. ಬಟನ್‌ನಲ್ಲೇ ಯಾವ ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ಕಳುಹಿಸಬೇಕು ಮತ್ತು ಯಾವ ಪುಟದ ಎಲಿಮೆಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕು ಎಂದು ತಿಳಿಸುವ ಅಟ್ರಿಬ್ಯೂಟ್‌ಗಳಿರುತ್ತವೆ. ಸರ್ವರ್ ಒಂದು HTML ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ — ಕೇವಲ ಹೊಸ ಕಾಮೆಂಟ್‌ಗಳು, ಒಂದು div ಒಳಗೆ ಸುತ್ತಲ್ಪಟ್ಟಿವೆ. ಬ್ರೌಸರ್ ಅದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಯಾವುದೇ JSON ಇಲ್ಲ, ಯಾವುದೇ ಫ್ರಂಟ್‌ಎಂಡ್ ಸ್ಟೇಟ್ ಟ್ರೀ ಇಲ್ಲ, ಯಾವುದೇ ರೀಕನ್ಸಿಲಿಯೇಶನ್ ಅಲ್ಗಾರಿದಮ್ ಇಲ್ಲ ಮತ್ತು UI ಅನ್ನು ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ ಮಾಡಲು ಯಾವುದೇ ಇಂಪೆರೇಟಿವ್ JavaScript ಇಲ್ಲ.

ಇದು ಆಧುನಿಕ ಅಭಿವೃದ್ಧಿಯ ತಿರಸ್ಕಾರವಲ್ಲ. ಇದು ಅನಗತ್ಯ ಅಬ್ಸ್ಟ್ರ್ಯಾಕ್ಷನ್‌ನ (abstraction) ತಿರಸ್ಕಾರವಾಗಿದೆ. ಆಧುನಿಕ ಎರ್ಗೊನಾಮಿಕ್ಸ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಿದಾಗ, ಆರಂಭಿಕ ವೆಬ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡಿದ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಶೈಲಿಯಾದ hypermedia, ಇಂದಿಗೂ ಅತ್ಯಾಧುನಿಕ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಬಲ್ಲದು ಎಂದು HTMX ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಕೇವಲ ಫಾರ್ಮ್‌ಗಳು ಮತ್ತು ಲಿಂಕ್‌ಗಳು ಮಾತ್ರವಲ್ಲದೆ, ಯಾವುದೇ ಎಲಿಮೆಂಟ್ ರಿಕ್ವೆಸ್ಟ್‌ಗಳನ್ನು ಮಾಡಬಹುದು. ಯಾವುದೇ ಇವೆಂಟ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಟ್ರಿಗ್ಗರ್ ಮಾಡಬಹುದು. ಡೇಟಾ ಮತ್ತು ಪ್ರೆಸೆಂಟೇಶನ್ ಎರಡಕ್ಕೂ ಸರ್ವರ್ ಒಂದೇ ಮಾಹಿತಿಯ ಮೂಲಾಧಾರವಾಗಿ (source of truth) ಉಳಿಯುತ್ತದೆ.

Chrome ನ Declarative Partial Updates

ಎರಡನೆಯ ಬದಲಾವಣೆಯು ಹೊಸದಾಗಿದೆ ಮತ್ತು ಇದು ಬ್ರೌಸರ್‌ನ ಒಳಗೇ ಇರುತ್ತದೆ. Chrome ಈಗ Declarative Partial Updates ಅಥವಾ DPU ಅನ್ನು ಪರಿಚಯಿಸುತ್ತಿದೆ. ಈ ಫೀಚರ್ ಬ್ರೌಸರ್ ಅನ್ನು HTML ಅನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಲು ಮತ್ತು ಬೈಟ್‌ಗಳು ಬಂದ ತಕ್ಷಣ ಪುಟದ ಗುರಿಯಿತ ಭಾಗಗಳಿಗೆ ನೇರವಾಗಿ ಸೇರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

DPU ಗಿಂತ ಮೊದಲು, ನೀವು ವೆಬ್ ಪುಟಕ್ಕೆ ಲೈವ್ ಡೇಟಾವನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಲು ಬಯಸಿದರೆ, ಸಾಮಾನ್ಯವಾಗಿ WebSockets, Server-Sent Events ಅಥವಾ ಮ್ಯಾನುಯಲ್ DOM ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ ಜೊತೆಗೆ long-polling ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತಿತ್ತು. ಫ್ರಂಟ್‌ಎಂಡ್ ಕನೆಕ್ಷನ್ ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಿತ್ತು, ಪೇಲೋಡ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಬೇಕಿತ್ತು ಮತ್ತು ಮಾರ್ಕಪ್ ಅನ್ನು ಹೇಗೆ ಮತ್ತು ಎಲ್ಲಿ ಇಂಜೆಕ್ಟ್ ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಬೇಕಿತ್ತು. DPU ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು 'declarative' ಮಾಡುವುದರ ಮೂಲಕ ಸಮೀಕರಣವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಡೆವಲಪರ್ ಒಂದು ಟಾರ್ಗೆಟ್ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ಬ್ರೌಸರ್ ಉಳಿದದ್ದನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವುದು, ಫ್ರಾಗ್ಮೆಂಟ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುವುದು ಮತ್ತು ಪೂರ್ಣ ರೆಸ್ಪಾನ್ಸ್ ಮುಕ್ತಾಯಗೊಳ್ಳುವ ಮೊದಲೇ ಅದನ್ನು ಸರಿಯಾದ ಜಾಗದಲ್ಲಿ ಇರಿಸುವುದು.

ಸರ್ವರ್ ಲಾಗ್‌ಗಳನ್ನು ತೋರಿಸುವ ಮಾನಿಟರಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅಥವಾ ರಿಯಲ್ ಟೈಮ್‌ನಲ್ಲಿ ಅಪ್‌ಡೇಟ್ ಆಗುವ ಸಪೋರ್ಟ್ ಕ್ಯೂ ಅನ್ನು ಯೋಚಿಸಿ. DPU ನೊಂದಿಗೆ, ಬ್ಯಾಕೆಂಡ್ ಅವುಗಳು ಜನರೇಟ್ ಆದ ತಕ್ಷಣ ಪ್ಲೇನ್ HTML ಚಂಕ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಲಾಜಿಕ್‌ನ ಒಂದು ಸಾಲು ಇಲ್ಲದೆಯೇ ಬ್ರೌಸರ್ ಅವುಗಳನ್ನು ಟೇಬಲ್ ಬಾಡಿ ಅಥವಾ ಫೀಡ್ ಕಂಟೇನರ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ. ಇದರ ಜೋಡಣೆ ನೈಸರ್ಗಿಕವಾಗಿ (natively) ನಡೆಯುತ್ತದೆ.

The Server-First Model

HTMX ಮತ್ತು DPU ಅನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿದರೆ, ನಿಮಗೆ ಒಂದು ಸುಸಂಬದ್ಧ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸಿಗುತ್ತದೆ, ಅಲ್ಲಿ ಸರ್ವರ್ ಸ್ಟೇಟ್ ಅನ್ನು ಹೊಂದಿದ್ದು UI ಅನ್ನು ಜನರೇಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ಡಿಸ್‌ಪ್ಲೇ ಮತ್ತು ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Rails, Laravel, Django, Go templates, ಅಥವಾ ASP.NET ನಂತಹ ಬ್ಯಾಕೆಂಡ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತೆ ಪ್ರಾಥಮಿಕ ಇಂಟರ್‌ಫೇಸ್ ಲೇಯರ್ ಆಗುತ್ತವೆ. ಫ್ರಂಟ್‌ಎಂಡ್ ಎಂಬುದು API ಅನ್ನು ಬಳಸುವ ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲ. ಅದು ಸರ್ವರ್ ಉತ್ಪಾದಿಸುವ hypermedia ಇಂಟರ್‌ಫೇಸ್ ಆಗಿದೆ.

ಈ ಮಾದರಿಯು ಅಚ್ಚರಿಯಷ್ಟು ವ್ಯಾಪಕವಾದ ಸಾಫ್ಟ್‌ವೇರ್ ವಿಭಾಗಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಸಾಧಾರಣ SaaS ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. ಇದು ವಿಂಗಡಿಸಬಹುದಾದ (sortable) ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿರುವ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಾಗಿರಬಹುದು. ಫಾರ್ಮ್‌ಗಳು ಮತ್ತು ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಅಡ್ಮಿನ್ ಪ್ಯಾನೆಲ್‌ಗಳಾಗಿರಬಹುದು. ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಒಂದು ಸ್ಥಿತಿಯಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾಯಿಸುವ ಆಂತರಿಕ ಪರಿಕರಗಳಾಗಿರಬಹುದು. ಪಟ್ಟಿಯನ್ನು ತೋರಿಸುವ, ವಿವರ ವೀಕ್ಷಣೆಯನ್ನು (detail view) ಪ್ರದರ್ಶಿಸುವ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಲು ಅನುಮತಿಸುವ CRUD ವರ್ಕ್‌ಫ್ಲೋಗಳಾಗಿರಬಹುದು. ಇದು AI ಇಂಟರ್‌ಫೇಸ್‌ಗಳೂ ಆಗಿರಬಹುದು, ಅಲ್ಲಿ ಭಾಷಾ ಮಾದರಿಯು (language model) ಬಳಕೆದಾರರಿಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಟೋಕನ್ ಅಥವಾ ಪ್ಯಾರಾಗ್ರಾಫ್ ಅನ್ನು HTML ನಲ್ಲಿ ಸುತ್ತುವರಿದು ಸಂಭಾಷಣೆಯ ಥ್ರೆಡ್‌ಗೆ ಸೇರಿಸಬಹುದು. ಇವೆಲ್ಲದಕ್ಕೂ, ಒಂದು ದಪ್ಪವಾದ (thick) JavaScript ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚುವರಿಯಾದ ಅಥವಾ ಅನಗತ್ಯ ಕೆಲಸವಾಗುತ್ತದೆ.

ಇದರ ಪ್ರಯೋಜನಗಳು ತಕ್ಷಣದ ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿವೆ. ಮೊದಲೇ ಅರ್ಥಪೂರ್ಣವಾದ ಪೇಂಟ್ (meaningful paint) HTML ರೂಪದಲ್ಲಿ ಬರುವುದರಿಂದ, ಹೈಡ್ರೇಶನ್ ಸೈಕಲ್ (hydration cycle) ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ ಆರಂಭಿಕ ಪೇಜ್ ಲೋಡ್‌ಗಳು ವೇಗವಾಗಿರುತ್ತವೆ. ಇಲ್ಲಿ ಯಾವುದೇ virtual DOM, ಕ್ಲೈಂಟ್-ಸೈಡ್ ರೂಟರ್ ಅಥವಾ ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಲೈಬ್ರರಿಗಳನ್ನು ಕಳುಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ JavaScript ಪೇಲೋಡ್‌ಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ. ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳು ಬಂಡಲ್‌ಗಳನ್ನು ಎಕ್ಸಿಕ್ಯೂಟ್ ಮಾಡದೆಯೇ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ನೋಡಬಲ್ಲವು, ಆದ್ದರಿಂದ SEO ತಾನಾಗಿಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಒಂದು ಕೋಡ್‌ಬೇಸ್ ಮೂಲಕವೇ ರೂಟಿಂಗ್, ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಮತ್ತು ರೆಂಡರಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ ಸಂಕೀರ್ಣತೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಡಿಬಗ್ ಮಾಡುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಏನಾದರೂ ತಪ್ಪಾಗಿ ಕಂಡಾಗ, ನೀವು Network ಟ್ಯಾಬ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಸರ್ವರ್ ಯಾವ HTML ಅನ್ನು ಕಳುಹಿಸಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ನೋಡಬಹುದು. ರಿವರ್ಸ್-ಇಂಜಿನಿಯರ್ ಮಾಡಲು ಯಾವುದೇ ಅಸ್ಪಷ್ಟ (opaque) ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸ್ಟೇಟ್ ಆಬ್ಜೆಕ್ಟ್ ಇರುವುದಿಲ್ಲ.

React ಮತ್ತು ದಪ್ಪವಾದ (Heavy) ಕ್ಲೈಂಟ್‌ಗಳ ಬಗ್ಗೆ ಏನು?

ಇದರರ್ಥ React ಸತ್ತಿದೆ ಅಥವಾ SPAs ತಪ್ಪು ಎಂದಲ್ಲ. ಸಂಕೀರ್ಣವಾದ, ಎಡಿಟರ್-ಗ್ರೇಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇಂದಿಗೂ ದಪ್ಪವಾದ ಕ್ಲೈಂಟ್ ಅಗತ್ಯವಿದೆ. Figma ಬ್ರೌಸರ್‌ನ ಒಳಗೇ WebAssembly ಗೆ ಕಾಂಪೈಲ್ ಮಾಡಲಾದ C++ ಇಂಜಿನ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್ ರೌಂಡ್-ಟ್ರಿಪ್‌ಗಳು ಡ್ರಾಯಿಂಗ್ ಮಾಡುವುದನ್ನು ಅಸಾಧ್ಯವಾಗಿಸಬಹುದು. Canva ಕ್ಲೈಂಟ್-ಸೈಡ್ ಜಿಯೋಮೆಟ್ರಿ ಬಳಸಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಅರವತ್ತು ಫ್ರೇಮ್‌ಗಳ ವೇಗದಲ್ಲಿ ಕ್ಯಾನ್ವಾಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Google Docs ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ಎಡಿಟಿಂಗ್ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು operational transforms ಅನ್ನು ಬಳಸುತ್ತದೆ. ಈ ಪರಿಕರಗಳು ಮೂಲತಃ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ ಮೂಲಕ ತಲುಪುವ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾಗಿವೆ. ಅವು ಮತ್ತೆ ಸರ್ವರ್-ರೆಂಡರ್ಡ್ ಫಾರ್ಮ್‌ಗಳಿಗೆ ಮರಳುವುದಿಲ್ಲ.

ಆದರೆ ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್ Figma ನಲ್ಲಲ್ಲ. ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್ ರಿಯಲ್-ಟೈಮ್ ಗ್ರಾಫಿಕ್ಸ್ ಎಡಿಟರ್ ಅಲ್ಲ. ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್ ವರದಿ ಮಾಡುವ ಸ್ಕ್ರೀನ್, ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾನಲ್, ಬುಕಿಂಗ್ ಫ್ಲೋ ಅಥವಾ ಕಂಟೆಂಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಫಾರ್ಮ್ ಆಗಿರುತ್ತದೆ. ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ, ಕೇವಲ ಒಂದು ಮಾಡಲ್ (modal) ಅನ್ನು ಆನ್/ಆಫ್ ಮಾಡಲು ಅಥವಾ ರೆಕಾರ್ಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಲು ನೂರಾರು ಕಿಲೋಬೈಟ್‌ಗಳ JavaScript ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಕಳುಹಿಸುವುದು ಎಂದಿಗೂ ಅರ್ಥಪೂರ್ಣವಾಗಿರಲಿಲ್ಲ. ಸ್ಟ್ಯಾಕ್‌ನ ಅರ್ಥಶಾಸ್ತ್ರವು ಬದಲಾಗುತ್ತಿದೆ. ಎಡ್ಜ್ (edge) ತಂತ್ರಜ್ಞಾನದಿಂದಾಗಿ ಸರ್ವರ್ ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಿರಬಹುದು ಮತ್ತು ಪ್ರತಿ ಬೈಟ್ ಅನ್ನು ಮಧ್ಯಸ್ಥಿಕೆ ವಹಿಸುವ ಫ್ರೇಮ್‌ವರ್ಕ್ ಇಲ್ಲದೆಯೇ ಫ್ರಾಗ್ಮೆಂಟ್‌ಗಳನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಲು ಬ್ರೌಸರ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಸಮರ್ಥವಾಗಿ ಬೆಳೆದಿದೆ ಎಂಬುದನ್ನು ನಾವು ಮರುಶೋಧಿಸುತ್ತಿದ್ದೇವೆ.

ಪೆಂಡುಲಂ ಸಮತೋಲನವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಿದೆ

ವೆಬ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಕಮಾನು ಸರಳತೆಯ ಕಡೆಗೆ ಮರಳುತ್ತಿದೆ, ಆದರೆ ಇದು ತೊಂಬತ್ತುರeಗಳ ಕಾಲಕ್ಕೆ ಮಾಡುವ ಮೂರ್ಖತನದ ಮರಳುವಿಕೆಯಲ್ಲ. ಬ್ರೌಸರ್ ಹೆಚ್ಚು ಬುದ್ಧಿವಂತವಾಗುತ್ತಿದೆ. DPU ನಂತಹ ವೈಶಿಷ್ಟ್ಯಗಳು ಡೆವಲಪರ್‌ಗಳ ಚತುರತೆಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಬದಲಾಗಿ ನಾವು ಕೈಯಿಂದ ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತಿದ್ದ ಮಾದರಿಗಳನ್ನು — streaming, partial updates, targeted DOM insertion — ಅವು ತಾವೇ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನೊಳಗೆ ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತವೆ. HTMX ನಮಗೆ ಫ್ರಂಟ್‌ಎಂಡ್‌ನಲ್ಲಿ ಒಂದು ಸಣ್ಣ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸದೆ ಆ ವರ್ತನೆಗಳನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ಬೇಕಾದ ಶಬ್ದಕೋಶವನ್ನು ನೀಡುತ್ತದೆ.

ನೀವು ಸರಳವಾದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಸ್ಪಂದನೀಯ (responsive) ಬಳಕೆದಾರ ಅನುಭವದ ನಡುವೆ ಒಂದನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಎರಡನ್ನೂ ಪಡೆಯಬಹುದು. ಸರ್ವರ್ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು, ಬ್ರೌಸರ್ ಅದನ್ನು ಜೋಡಿಸಬಹುದು ಮತ್ತು ನೀವು ಬರೆಯುವ JavaScript ಕೇವಲ ಮೂಲಭೂತ ಕೆಲಸಗಳಿಗಿಂತ (plumbing) ನಿಜವಾದ ಇಂಟರ್ಯಾಕ್ಟಿವಿಟಿ ಮೇಲೆ ಗಮನ ಹರಿಸಬಹುದು.

ಮುಂದಿನ ಪೀಳಿಗೆಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು, ಅಡ್ಮಿನ್ ಪರಿಕರಗಳು ಮತ್ತು AI-ಚಾಲಿತ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿಗಾಗಿ, ಅತ್ಯಂತ ಬುದ್ಧಿವಂತ ಕ್ಲೈಂಟ್ ಎಂದರೆ ಕಡಿಮೆ ಕೆಲಸ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಆಗಿರಬಹುದು.