ஒவ்வொரு தயாரிப்புக் குழுவும் இறுதியில் ஒரே ஒரு இக்கட்டான முடிவெடுக்க வேண்டிய நிலையைச் சந்திக்கிறது. iOS மற்றும் Android-க்காகத் தனித்தனியாக Swift மற்றும் Kotlin codebase-களை எழுதுவீர்களா, அல்லது React Native அல்லது Ionic மூலம் ஒரே ஒரு cross-platform திட்டத்தில் உங்கள் வாய்ப்புகளைப் பந்தயம் கட்டுவீர்களா? இரு தளங்களுக்கும் ஒரே codebase-ஐ வழங்குவதாகக் கூறும் கருவிகள் உண்மையான ஈர்ப்பைக் கொண்டுள்ளன. அவை உங்கள் ஆரம்ப காலத் திட்டக் காலத்தைக் குறைக்கலாம், வெளியீட்டுச் செலவுகளைக் குறைக்கலாம், மேலும் இணையத் தொழில்நுட்பத்தில் நிபுணத்துவம் பெற்ற ஒரு குழுவினால், தளத்திற்குத் தனித்துவமான மொழிகளைக் கற்காமலேயே மொபைல் செயலிகளை வெளியிட அனுமதிக்கலாம். அந்த நன்மைகள் உண்மையானவை, மேலும் சில திட்டங்களுக்கு அவை தீர்மானிக்கும் காரணிகளாக அமைகின்றன. ஆனால், உண்மையான பயனர்கள் உண்மையான சாதனங்களில் செயலியைப் பயன்படுத்தத் தொடங்கும் போது, வெளியீட்டிற்குப் பிறகு சில சவால்கள் (trade-offs) வெளிப்படத் தொடங்கும். Native மேம்பாட்டிற்குத் தொடக்கத்திலேயே அதிக நேரம் மற்றும் நிபுணத்துவம் தேவைப்படுகிறது, இருப்பினும் cross-platform frameworks-ஆல் ஈடுகட்ட முடியாத பல விஷயங்களில் அது அந்த முயற்சியைத் தகுந்த முறையில் ஈடுசெய்கிறது.

Abstraction-ன் செயல்திறன் பாதிப்பு

Native செயலிகள் நேரடியாகத் தளத்தின் SDK-க்கு எதிராகத் தொகுக்கப்படுகின்றன (compile). இதன் விளைவாகக் கிடைக்கும் binary, இடையில் எந்த ஒரு interpreter அல்லது இடைத்தரகரும் இன்றி நேரடியாக இயக்க முறைமையின் (operating system) மொழியில் பேசுகிறது. அவை வேகமாகத் திறக்கின்றன, மென்மையாகச் சுழல்கின்றன (scroll) மற்றும் குறைந்த நினைவகத்தைப் (memory) பயன்படுத்துகின்றன. RAM குறைவாக உள்ள மற்றும் thermal throttling பொதுவாக நிகழும் குறைந்த திறன் கொண்ட சாதனங்களில், அந்தத் திறன் ஒரு செயலி பின்னணியில் (background) இயங்குவதற்கும் அல்லது பயனர் ஒரு பணியிலிருந்து மற்றொரு பணிக்கு மாறும்போது சிஸ்டம் அதை உடனடியாக நிறுத்திவிடுவதற்கும் இடையிலான வித்தியாசமாக இருக்கலாம்.

React Native ஒரு மாறுபட்ட பாதையைத் தேர்ந்தெடுக்கிறது. இது தர்க்கங்களைக் (logic) கையாள ஒரு JavaScript thread-ஐ இயங்க வைக்கிறது, மேலும் அந்த thread ஒரு bridge மூலம் native UI modules-உடன் தொடர்பு கொள்கிறது. எளிய திரைகளுக்கு, இந்தத் தாமதத்தை உணர முடியாது. ஆனால் அதிக அதிர்வெண் கொண்ட (high-frequency) மாற்றங்களைக் கையாளச் சொல்லும்போது, அந்த bridge ஒரு தடையாகிவிடுகிறது (bottleneck). நேரடி சென்சார் தரவு (Live sensor data), வரைபடத்தை உருவாக்கும்போது (map rendering) ஏற்படும் விரைவான மாற்றங்கள் அல்லது சிக்கலான பட்டியல் அனிமேஷன்கள் (list animations), JS மற்றும் UI threads-ஐ ஒருங்கிணைப்பற்ற நிலைக்கு (out of sync) கொண்டு வரலாம். இதன் விளைவாக, native code-இல் இல்லாதவாறு, திரையில் சட்டென்று சட்டென்று மாறுவது (dropped frames) மற்றும் தடையற்ற இயக்கம் இல்லாத (janky interactions) நிலைகள் ஏற்படுகின்றன.

Ionic முற்றிலும் ஒரு WebView-க்குள் இயங்குவதால், ஒரு பிரவுசர் இன்ஜினின் கூடுதல் சுமையை (overhead) சுமக்க வேண்டியுள்ளது. கனமான கணக்கீட்டுப் பணிகள் (computational tasks), அதிக நினைவக ஒதுக்கீடு அல்லது நீண்ட asset pipelines ஆகியவை garbage collection இடைவெளிகளைத் தூண்டி, இடைமுகத்தை (interface) முடக்கக்கூடும். ஒரு native toolkit-இல் நொடிக்கு அறுபது பிரேம்கள் (sixty frames per second) வேகத்தில் இயங்கக்கூடிய அனிமேஷன்கள், சாதனம் அதிக சுமையில் இருக்கும்போது தடுமாறக்கூடும் (stutter).

பயனர் அனுபவம் மற்றும் தள மரபுகள்

Apple மற்றும் Google தங்களின் இடைமுக மொழிகளை (interface languages) மேம்படுத்த பல ஆண்டுகளைச் செலவிட்டுள்ளன. Native மேம்பாடு அந்தத் தொகுதிகளுக்கான (toolkits) நேரடி அணுகலை உங்களுக்கு வழங்குகிறது. இயற்பியல் சார்ந்த ஸ்க்ரோலிங் (physics-based scrolling), தொடு உணர்வு சார்ந்த ஹேப்டிக் பின்னூட்டம் (tactile haptic feedback) மற்றும் பயனர்கள் அந்தத் தளத்தில் எதிர்பார்ப்பது போலவே செயல்படும் ஜெஸ்டர் நேவிகேஷன்கள் (gesture navigations) ஆகியவற்றை நீங்கள் பெறலாம்.

Cross-platform frameworks இந்த நடத்தைகளைப் பின்பற்ற முயற்சிக்கின்றன, ஆனால் அந்தச் சுருக்கம் (abstraction) பெரும்பாலும் முழுமையற்றதாகத் தோன்றும். ஒரு React Native செயலி சரியாகத் தோன்றலாம், ஆனால் ஒரு edge-swipe gesture அந்த framework-இன் navigator-உடன் மோதும்போது அல்லது கீபோர்டு அனிமேஷன் திரையின் மற்ற பகுதிகளை விடச் சில பிரேம்கள் பின் தங்கியிருக்கும் போது அதன் குறைபாடு தெரியவரும். Ionic செயலிகள் இணையத்தின் input event மாதிரியைக் கொண்டுள்ளன, இது விரைவான டாப் (tap) வரிசைகளின் போது விரல்களால் உணரக்கூடிய நுட்பமான தாமதத்தை (latency) ஏற்படுத்தக்கூடும்.

வங்கி, ஆரோக்கியம் அல்லது உயர்தர உற்பத்தித் திறன் (premium productivity) சார்ந்த செயலிகளுக்கு, பயனர்கள் அதிக எதிர்பார்ப்புகளைக் கொண்டுள்ளனர். உடனடியாகச் செயல்படும் பயோமெட்ரிக் முறைகள், தொட்டவுடன் பதிலளிக்கும் பொத்தான்கள் மற்றும் உந்த விதிகளைப் பின்பற்றும் மாற்றங்களை (transitions) அவர்கள் எதிர்பார்க்கிறார்கள். ஒரு ஸ்பிரிங் அனிமேஷனின் damping ratio முதல் ஒரு ஹேப்டிக் பல்ஸின் (haptic pulse) துல்லியமான நேரம் வரை, ஒவ்வொரு நுண்-தொடர்புகளையும் (micro-interaction) முழுமையாகக் கட்டுப்படுத்த native code உங்களுக்கு வழிவகை செய்கிறது. அத்தகைய நேர்த்தியை ஒரு translation layer மூலம் மீண்டும் உருவாக்குவது கடினம்.

வன்பொருள் அணுகல் மற்றும் பிளகின் தாமதம்

புதிய சென்சார்கள் அல்லது கேமரா வசதிகள் அறிமுகப்படுத்தப்படும்போது, அவை முதலில் native SDK-களில் தான் வரும். LiDAR depth mapping அல்லது மேம்பட்ட computational photography pipelines போன்ற வசதிகள் Swift மற்றும் Kotlin டெவலப்பர்களுக்கு முதல் நாளிலேயே கிடைக்கும். மற்ற அனைவரும் ஒரு bridge plugin-ஐ உருவாக்கவும் சோதிக்கவும் சமூகத்தையோ அல்லது framework விற்பனையாளரையோ காத்திருக்க வேண்டியிருக்கும். அந்தத் தாமதம் பல மாதங்கள் வரை நீடிக்கலாம். வெளியீட்டிற்குப் பிறகும், அந்த plugin முழு API-இன் ஒரு பகுதியை மட்டுமே வழங்கக்கூடும், இதனால் வன்பொருள் வழங்கும் துல்லியமான கட்டுப்பாட்டைப் பெற முடியாமல் போகலாம்.

இந்த வசதிகளை native code மூலம் அணுகுவது எளிதானது மற்றும் நம்பகமானது, ஏனெனில் நீங்கள் உற்பத்தியாளரின் frameworks-ஐ நேரடியாக அழைக்கிறீர்கள். ஒரு இடைநிலை wrapper தலைப்புகளைச் (headers) சரியாகப் பகுப்பாய்வு செய்யும் என்று நம்பியிருக்காமல், ஆவணப்படுத்தப்பட்டபடி நீங்கள் exposure matrices, depth buffers அல்லது spatial data ஆகியவற்றைத் துல்லியமாகத் தயார் செய்யலாம்.

பிளகின்கள் பராமரிப்புப் பொறுப்பையும் (maintenance liability) உருவாக்குகின்றன. ஒவ்வொரு முக்கிய OS புதுப்பிப்பும் ஒரு குறுக்கு-தளச் சார்பை (cross-platform dependency) உடைக்கும் அபாயத்தைக் கொண்டுள்ளது. அதை யாராவது பேட்ச் (patch) செய்து, சரிபார்த்து, புதிய பதிப்பை வெளியிட வேண்டும். அதன் அசல் ஆசிரியர் விலகிச் சென்றிருந்தால், உங்கள் குழு அந்த வேலையை ஏற்க வேண்டியிருக்கும் அல்லது மாற்றாகத் தேட வேண்டியிருக்கும். நேட்டிவ் மேம்பாடு (Native development) இணக்கத்தன்மைப் பணிகளை (compatibility work) நீக்காது, ஆனால் மற்றவர்களின் கால அட்டவணை சார்ந்த பாதிப்புகளைப் பெருக்கும் கூடுதல் மறைமுக அடுக்கை (indirection layer) இது நீக்குகிறது.

பாதுகாப்பு மற்றும் சார்புப் பரப்பு (Security and the Dependency Surface)

நேட்டிவ் செயலிகள் நேரடியாகத் தளத்தின் பாதுகாப்பு மாதிரியுடன் (security model) ஒத்துப்போகின்றன. iOS-இல், நீங்கள் அங்கீகார டோக்கன்களை (authentication tokens) அல்லது கிரிப்டோகிராஃபிக் பொருட்களை Keychain-இல் சேமிக்கிறீர்கள். Android-இல், நீங்கள் Keystore அமைப்புடன் இணைந்து செயல்படுகிறீர்கள் மற்றும் சாதனம் ஆதரிக்கும் இடங்களில் வன்பொருள் சார்ந்த குறியாக்கத்தை (hardware-backed encryption) கோருகிறீர்கள். இவை பிரத்யேக சிலிக்கான் மூலம் ஆதரிக்கப்படும் மற்றும் தள விற்பனையாளரால் தணிக்கை செய்யப்பட்ட முதன்மையான APIs ஆகும்.

குறுக்கு-தளத் தீர்வுகள் உங்கள் லாஜிக் மற்றும் OS பாதுகாப்பு கூறுகளுக்கு இடையே கூடுதல் அடுக்குகளைச் சேர்க்கின்றன. ஒரு React Native செயலி, உள்ளூர் சேமிப்பிற்கு (local storage) எழுதுவதற்குப் பயன்படும் ஒரு அப்ஸ்ட்ராக்ஷன் மாட்யூல் (abstraction module) மூலம் முக்கியமான தரவைச் சேமிக்கலாம். அந்தப் பிரிட்ஜ் (bridge) அனுமதிகளைப் பாதுகாத்ததா, கிளவுட் ஸ்டோரேஜிற்குத் தற்செயலான பேக்கப் எடுப்பதைத் தவிர்த்ததா மற்றும் லாகிங் (logging) மூலம் தரவை கசியவிடாமல் பார்த்ததா என்பதை நீங்கள் சரிபார்க்க வேண்டும். Ionic செயலிகள் ஒரு WebView-க்குள் இயங்குகின்றன; இதில் உள்ள JavaScript சூழல், உள்ளீடு சுத்திகரிப்பு (input sanitization) தவறாகும் போது கூடுதல் ஊடுருவல் வழிகளை (injection vectors) உருவாக்குகிறது.

ஒவ்வொரு பிளகின் மற்றும் மூன்றாம் தரப்புச் சார்பும் உங்கள் தாக்குதல் பரப்பை (attack surface) விரிவுபடுத்துகிறது. நீங்கள் பணம் செலுத்துதல் (payments), HIPAA-இன் கீழ் வரும் நோயாளி பதிவுகள் அல்லது PCI-DSS தேவைகளுக்கு உட்பட்ட எந்தவொரு தரவைக் கையாண்டாலும், உங்கள் சார்பு மரத்தை (dependency tree) ஒரு கருப்புப் பெட்டியாக (black box) கருத முடியாது. நீங்கள் பதிப்புகளைத் தணிக்கை செய்ய வேண்டும், வெளிப்படுத்தல்களைக் கண்காணிக்க வேண்டும் மற்றும் சில நேரங்களில் குறியீட்டை நீங்களே பேட்ச் செய்ய வேண்டியிருக்கும். நேட்டிவ் மேம்பாடு பாதுகாப்புப் பணிகளை நீக்கிவிடாது, ஆனால் நீங்கள் நம்ப வேண்டிய கூறுகளின் எண்ணிக்கையைக் குறைக்கிறது.

எந்தப் பாதையைத் தேர்ந்தெடுப்பது?

நேட்டிவ் பலங்கள் இருந்தபோதிலும், சில பொதுவான சூழ்நிலைகளில் குறுக்கு-தளத் தீர்வே புத்திசாலித்தனமான தேர்வாக உள்ளது.

நேட்டிவ் மேம்பாட்டைத் தேர்ந்தெடுக்கவும் போது:

  • செயல்திறன் (Performance) மிக முக்கியமாக இருக்கும்போது. Augmented reality, real-time machine learning, அல்லது மொபைல் கேம்கள் பிரேம் டிராப்ஸ் (frame drops) அல்லது பிரிட்ஜ் தாமதத்தைத் (bridge latency) தாங்க முடியாது.
  • ஆழமான வன்பொருள் ஒருங்கிணைப்பு (hardware integration) தேவைப்படும்போது. உங்கள் முக்கிய அம்சம் துல்லியமான கேமரா கட்டுப்பாடு, தனிப்பயன் சென்சார்கள் அல்லது குறைந்த தாமத ஆடியோ (low-latency audio) ஆகியவற்றைப் பொறுத்திருந்தால், நேட்டிவ் APIs பாதுகாப்பான அடித்தளமாகும்.
  • உயர்தர UX மற்றும் அணுகல்தன்மை (accessibility) சமரசத்திற்கு அப்பாற்பட்டது எனும் போது. நிதி, மருத்துவ மற்றும் பிரீமியம் நுகர்வோர் செயலிகள் தொடு உணர்வு (tactile feel) மற்றும் தள மரபுகளைத் துல்லியமாகப் பின்பற்றுவதன் மூலம் போட்டியிடுகின்றன.
  • பாதுகாப்பு கட்டுப்பாடுகள் கடுமையாக இருக்கும்போது. Fintech மற்றும் சுகாதாரத் தயாரிப்புகள், குறைக்கப்பட்ட தாக்குதல் பரப்பு மற்றும் தளத்தின் கீ மேனேஜ்மென்ட் (key management) நேரடி அணுகல் ஆகியவற்றால் பயனடைகின்றன.

குறுக்கு-தள கட்டமைப்பைத் (cross-platform framework) தேர்ந்தெடுக்கவும் போது:

  • ஒரு கருத்தை நிரூபிக்க, தள-குறிப்பிட்ட குழுக்களில் முதலீடு செய்வதற்கு முன், உங்களுக்கு ஒரு வேகமான MVP தேவைப்படும்போது.
  • செயலி அதிக உள்ளடக்கத்தைக் (content-heavy) கொண்டிருந்தால். செய்தி வாசகர்கள், வலைப்பதிவுகள் மற்றும் கேட்டலாக் செயலிகள் பெரும்பாலும் ஸ்க்ரோல் செய்யக்கூடிய உரை மற்றும் படங்களைக் கொண்டவை, இவற்றை இணையத் தொழில்நுட்பம் (web tech) எளிதாகக் கையாளும்.
  • உங்கள் குழுவின் பின்னணி மொபைல் சிஸ்டம்ஸ் புரோகிராமிங்கை விட இணைய மேம்பாட்டில் (web development) இருக்கும்போது.
  • பட்ஜெட் மற்றும் சந்தைக்கு வரும் நேரம் (time-to-market) முக்கியத்துவம் பெறும்போது, மேலும் செயலியின் அம்சங்கள் அந்த கட்டமைப்பின் பலங்களுக்குள் இருக்கும்போது.

உண்மையான முடிவு (The Real Takeaway)

நேட்டிவ் மற்றும் குறுக்கு-தளத் தேர்வு என்பது ஒரு ஃபேஷன் முடிவு (fashion decision) என்று இருக்கக்கூடாது. இது உங்கள் பயனர்கள் செயலியைப் பயன்படுத்துவதைப் பொறுத்த ஒரு பொறியியல் சமரசம் (engineering trade-off). நீங்கள் உள்ளடக்கத்தை மட்டும் வழங்கினாலோ, ஒரு சந்தையைச் சோதித்தாலோ அல்லது ஒரு உள்முக டேஷ்போர்டை (internal dashboard) உருவாக்கினாலோ, React Native அல்லது Ionic உங்களுக்குப் பணத்தையும் வாரக்கணக்கான உழைப்பையும் மிச்சப்படுத்தும். ஆனால் உங்கள் தயாரிப்பு வேகத்தில் போட்டியிடுகிறதோ, முக்கியமான தரவைக் கையாளுகிறதோ அல்லது வன்பொருளுடன் இணைந்து செயல்பட வேண்டுமோ, அப்படியென்றால் நேட்டிவ் மேம்பாட்டிற்கான கூடுதல் செலவு, அப்ஸ்ட்ராக்ஷன் அடுக்குகள் (abstraction layers) எப்போதும் ஏற்படுத்தும் சமரசங்களுக்கு எதிரான ஒரு காப்பீடாகும். உங்கள் தொழில்நுட்பத் தொகுப்பை (stack) பிரச்சனையின் சவால்களுக்கு ஏற்பத் தேர்ந்தெடுங்கள், தற்போதைய காலத்தின் ட்ரெண்டிற்கு (trend) ஏற்ப அல்ல.