आखिर तक native, जब तक text की ज़रूरत न पड़ जाए

 (justsitandgrin.im)
2 पॉइंट द्वारा GN⁺ 12 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS पर केवल SwiftUI से Markdown chat UI बनाया जाए तो बुनियादी performance कुछ हद तक मिल जाती है, लेकिन पूरे document को select करना support करना कठिन होता है
  • NSTextView और TextKit 2 पर जाने से SwiftUI में किया गया testing और performance work खो जाता है, और streaming input में CPU spike आता है
  • NSCollectionView के साथ दोबारा implement करने पर cells flicker करते रहते हैं, और pure TextKit 2 में performance ठीक होने पर भी streaming integration अच्छा नहीं है
  • WebKit में Markdown rendering, performance, typography और control level कुल मिलाकर अच्छे से मेल खाते हैं, और Electron में भी text handling डिफ़ॉल्ट रूप से काम करती है
  • लंबे chat और rich text में SwiftUI और Apple native SDK सीमाएँ बन जाते हैं, जबकि web-based तरीका text·rendering model में ज़्यादा फायदेमंद हो जाता है

native macOS Markdown chat UI की सीमाएँ

  • केवल SwiftUI से Markdown support करने वाला simple chat बनाया जाए तो बुनियादी performance कुछ हद तक संभव है, लेकिन SwiftUI primitives से बने Markdown document का पूरा selection नहीं किया जा सकता
  • NSTextView पर जाने से TextKit 2 support तो मिलता है, लेकिन SwiftUI में किया गया ज़्यादातर testing और performance work खो जाता है, और यह SwiftUI के साथ भी अच्छी तरह फिट नहीं बैठता
  • model response को streaming तरीके से NSTextView में डालने पर CPU spike होता है
  • NSCollectionView से दोबारा implement करने पर भी cells लगातार flicker करते हैं, और design के हिसाब से इसे टालना मुश्किल रहता है
  • pure TextKit 2 prototype में performance ठीक है, लेकिन streaming अब भी खराब है और modern components के साथ इसकी संगति अच्छी नहीं है
  • SwiftUI को पूरी तरह हटाकर केवल AppKit इस्तेमाल करने पर भी बढ़ते हुए text fragments को manually संभालना पड़ता है, और बहुत कुछ टूटने के बाद ही text selection संभव हो पाता है
  • macOS के बुनियादी behavior जैसे स्तर तक पहुँचने के लिए context menu, dictionary lookup, selection, accessibility और text interaction जैसी वे सुविधाएँ फिर से मिलानी पड़ती हैं जिनकी users स्वाभाविक रूप से उम्मीद करते हैं

जहाँ WebKit और Electron बेहतर फिट बैठते हैं

  • WebKit से Markdown render करने पर कुछ सावधानियाँ ज़रूर हैं, लेकिन कुल मिलाकर यह अच्छा काम करता है, performance और typography अच्छी हैं, और control level भी पर्याप्त है
  • एक simple Electron project बनाया जाए तो text handling, Markdown rendering और अच्छी typography डिफ़ॉल्ट रूप से काम करती हैं, और वह performance भी मिलती है जिसे pure TextKit 2 implementation में पाना मुश्किल था
  • Electron में भी macOS integration मिलता है, कुछ lines of code से आकर्षक Git diff render किया जा सकता है, और diffs.com जैसे उदाहरण भी हैं
  • SwiftUI, AppKit, TextKit और WebKit सब देखने के बाद भी “Markdown support करने वाला और पूरे message का selection करने देने वाला chat” जैसी simple requirement को सही तरह से पूरा करना मुश्किल है
  • chat, long-form rich text और flexible typography महत्वपूर्ण होने वाले नए apps के web-based होने की वजह अब और स्पष्ट हो जाती है
  • SwiftUI कम scrolling वाली simple screens के लिए उपयुक्त है, और Swift अब भी उन हिस्सों में उपयोगी है जहाँ performance महत्वपूर्ण है
  • Electron या React Native native interoperability के साथ काफ़ी performance हासिल कर सकते हैं, और साथ ही बेहतर text·rendering model बनाए रख सकते हैं
  • लंबे chat के लिए rich text rendering में SwiftUI और Apple native SDK फ़ायदा नहीं, बल्कि सीमा बन जाते हैं
  • संबंधित चर्चा: Hacker News, Lobsters

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 11 시간 전
Hacker News की राय

  • हाल ही में TextKit 2 का इस्तेमाल करने वाला iOS के लिए एक टेक्स्ट एडिटर जारी किया, और 5,000-लाइन फ़ाइलों पर भी परफ़ॉर्मेंस काफ़ी अच्छी निकली
    Project Gutenberg की Moby Dick से टेस्ट किया गया, इसे अगस्त 2025 से अप्रैल 2026 के बीच बनाया गया, और डेवलपमेंट अभी भी जारी है
    हर key input पर 8ms के भीतर फिर से styling हो जाती है, और debouncing या delayed rendering के बिना तेज़ 20 inputs भी हर input के बाद पूरे restyling सहित 150ms में प्रोसेस हो जाते हैं
    tags और boolean search 20ms के भीतर खत्म हो जाते हैं, और सिर्फ़ दिखाई देने वाले हिस्से को render करने पर पूरे document styling की तुलना में 25 गुना तेज़ है, साथ ही 120Hz screen refresh भी support करता है
    app file size 1.0 में 722KB था, और ज़्यादा features वाले 1.1 का आकार भी लगभग 950KB दिखता है
    अगर iOS पर इतना संभव है, तो macOS पर यह लगभग 10 गुना आसान होना चाहिए
    https://www.gingerbeardman.com/apps/papertrail/

    • अगर किसी paid product की core functionality ही editor हो, तो यह समझ में आता है। लेकिन Markdown rendering app की मुख्य functionality भी नहीं है, और 2026 में यह ज़्यादा user-expected convenience feature जैसी चीज़ है। उसके लिए 8 महीने और ongoing development के इरादे से low-level custom implementation करनी पड़े, यह अजीब लगता है
      बात “असंभव है” की नहीं, बल्कि यह समझ आता है कि लोग ऐसी चीज़ों के लिए native की जगह web technologies क्यों चुनते हैं। लोग product बनाना चाहते हैं, system limitations से लड़ना नहीं
    • 2012 में NSString और attributes से interactive fiction बनाया, deprecated low-level glyph API से roguelike बनाया, और SwiftUI में Markdown support वाले 2 chat apps तथा iOS tricks मिलाकर idle game बनाने के अनुभव से देखें तो, इस reaction को आख़िरकार skill issue ही कहना पड़ेगा
    • 5,000 लाइनें सच में बहुत छोटी मात्रा है, इसलिए यह विवरण उलझन पैदा करता है। जिस Moby Dick से टेस्ट करने की बात है वह भी 22,000 लाइनों से ज़्यादा की लगती है, और Windows का default Notepad भी उस आकार की फ़ाइल पर अटकता नहीं
      अगर यह text viewer है, तो कम से कम उससे दो orders of magnitude बड़ी फ़ाइलें संभालनी चाहिए। सैकड़ों हज़ार लाइनों वाली JSON फ़ाइलें आम हैं, और CSV तथा log files उससे भी लंबी होती हैं
    • संभव है कि SwiftUI का Mac implementation अच्छा न हो। ऐसे app के लिए SwiftUI-on-Catalyst बेहतर हो सकता है, लेकिन शायद तब भी दूसरी समस्याएँ होंगी
    • iOS पर हो जाए तो macOS पर 10 गुना आसान होगा, इस बात पर काफ़ी शक है। मुझे तो शायद इसका उल्टा लगता है, और मैं सच में किसी जानकार का अनुभव सुनना चाहूँगा

  • आम तौर पर webview की जगह native API इस्तेमाल करने का कारण performance हुआ करता था, लेकिन अब यह ज़रूरी नहीं लगता
    browser rendering engines काफ़ी mature हो चुके हैं, GPU acceleration भी बहुत है, और 10 साल से ज़्यादा समय तक bloated web apps के ज़रिए इनका stress test हो चुका है
    दूसरी ओर SwiftUI ख़ास तेज़ नहीं लगता। Apple ने जो नया System Settings फिर से बनाया है, उसमें UI को checkbox rows जैसी सादगी तक घटा दिया गया, फिर भी section switching कभी-कभी us-east-1 से web page लोड करने से ज़्यादा अटकता है

    • यहाँ समस्या पूरी native apps की नहीं बल्कि SwiftUI की है
      Qt C++ और QML से native apps बनाए हैं, और दिखाया है कि वे समान web apps से कहीं तेज़ और RAM में भी बहुत हल्के हो सकते हैं
      इसलिए सामान्य रूप से web apps, अच्छी तरह डिज़ाइन किए गए native apps की तुलना में धीमे होते हैं और ज़्यादा resources लेते हैं
      [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
      [2] https://x.com/daniel_nguyenx/status/1734495508746702936
      [3] https://rubymamistvalove.com/block-editor#8-performance
    • फिर भी native apps और सबसे हल्के browser apps के बीच बड़ा अंतर होता है, और low-power devices पर यह और साफ़ दिखता है
      मैं पहले web developer था, लेकिन पिछले 6–12 महीनों में native cross-platform apps बनाना शुरू किया है, और साधारण कामों में भी performance gap काफ़ी बड़ा है
    • browsers पुराने hardware पर बहुत खराब चलते हैं। पुराने Chromebook आम हैं और हल्के काम या खास purpose के लिए उनके specs भी ठीक होते हैं, लेकिन browser उन पर सच में बहुत धीमा चलता है
    • साधारण web app हो तो बात अलग है, लेकिन complex applications में noticeable slowdown होता है। Jira जैसे monster तक जाने की ज़रूरत नहीं, VS Code जैसा अच्छी तरह optimized app भी native app से कम performance ceiling रखता है
    • WebView भी आख़िरकार “native” ही है
      हज़ारों person-years की optimization और real-world में millions of person-years की validation छोड़कर, उससे भी खराब text rendering engine फिर से बनाने की सोच अजीब लगती है

  • macOS पर WebKit एक native OS framework है। Markdown rendering के लिए WebKit इस्तेमाल करना पूरी तरह उचित लगता है
    बेशक हर चीज़ को WebKit से render करना उतना ही बेतुका होगा जितना हर चीज़ को PDFKit से render करना। लेकिन Markdown view के लिए WebKit एक तार्किक विकल्प है, और इसका मतलब यह नहीं कि पूरी तरह Chromium web app पर जाना पड़े

    • अगर HTML engine, UI में render करने की सबसे कठिन चीज़ों में से एक rich text को native UI library से बेहतर render करता है, तो फिर buttons या text fields जैसी आसान चीज़ें भी उसी से क्यों न render की जाएँ?
      और OS X ने बहुत लंबे समय तक DisplayPDF/Quartz से UI render किया था
    • यह समझाने की ज़रूरत है कि WebKit से Markdown render करना क्यों उचित है
    • मूल लेखक शायद “native” को सिर्फ़ Swift/ObjC primitives इस्तेमाल करने के अर्थ में देख रहा है
      क्या WebKit इसलिए cheating है क्योंकि वह दूसरे platforms पर भी मौजूद है? अगर ऐसा है तो फिर Java भी चलना चाहिए
    • मुझे समझ नहीं आता कि rich text render करने के लिए WebKit की अपेक्षा क्यों करनी चाहिए
      अगर HTML/CSS/JS renderer से text render करना “पूरी तरह उचित” है, तो फिर कौन-सा क्षेत्र उचित नहीं है? फिर सब कुछ उसी से क्यों न render किया जाए?
      “text rendering उचित है लेकिन हर rendering बेतुकी है” तक पहुँचने वाली logic समझ में नहीं आती
    • असल में अभी जो solution चल रहा है, वह final Markdown और streaming को WebKit से render करना है
      macOS पर WebKit एक native OS framework है, इस बात से सहमत हूँ, और उस अर्थ में यह “native” है
      लेकिन यह उस बड़े बिंदु को भी मज़बूत करता है कि rich text, Markdown, selection, typography और लंबे formatted content को ठीक से संभालने के लिए web technologies तेज़ी से एकमात्र व्यावहारिक विकल्प बनती जा रही हैं
      Markdown view में WebKit का इस्तेमाल ग़लत नहीं, बल्कि शायद सबसे तर्कसंगत विकल्प है। समस्या यह है कि यहाँ “native” solution असल में web rendering solution ही बन जाता है
      हर WKWebView अपने साथ performance और memory overhead वाला WebKit engine लाता है, इसलिए उसे हर जगह बिखेरकर free native macOS component की तरह नहीं देखा जा सकता
      निराशा इस बात की है कि इस तरह के UI में SwiftUI / AppKit / TextKit, “बस WebKit इस्तेमाल करो” से बेहतर कोई साफ़, modern, composable रास्ता नहीं देते

  • “Markdown वाले chat में पूरे message को select करने देना” जैसी बुनियादी चीज़ भी न हो पाना बेतुका लगता है
    SwiftUI में mature Markdown renderer का उपयोग किया जा सकता है। https://github.com/gonzalezreal/swift-markdown-ui और उसके next-generation replacement https://github.com/gonzalezreal/textual को देखें
    मैंने खुद इस्तेमाल किया है और कोई समस्या नहीं हुई। Swift या SwiftUI पसंद न करने वाला और Objective-C को तरजीह देने वाला मेरे जैसा बेवकूफ़ भी यह LLM मदद के बिना कर पाया

    • आज पहले Textual को आज़माया था, और नतीजे बहुत अच्छे नहीं थे
      static completed Markdown scrolling नया focus probe पास नहीं कर पाया; p95 18.86ms था, जो 16.7ms budget से ऊपर है, और max 232.49ms था
      लंबा real-time Markdown/code update path भी fail हुआ; p95 59.33ms बनाम 16.7ms, max 75.94ms। यह updates के दौरान बड़े rich text surface को संभालने वाला अलग लेकिन जुड़ा हुआ stress case है
      लंबी history expansion तकनीकी रूप से pass करती है, लेकिन इसे smooth frame कहना मुश्किल है: 120 turns p95 21.35ms, 500 turns 23.11ms, 1000 turns 36.77ms
      बुरा नहीं है, लेकिन मेरे solution से थोड़ा धीमा है, और यह gap ज़्यादातर Textual implementation से नहीं बल्कि SwiftUI से जुड़ा लगता है
    • क्या नया text stream होते समय इसे बिना flicker के संभाला जा सकता है?
    • अगर Markdown document सिर्फ़ एक बार render हो, या document साधारण और छोटा हो, तब शायद हो सके
      मैंने पहले app में swift-markdown-ui इस्तेमाल किया था, लेकिन performance wkwebview के आसपास भी नहीं थी। बड़े tables, code blocks, nested quotes जैसे tricky elements वाले बड़े documents को stream करने पर beachball तक दिख जाता था, जबकि wkwebview में ऐसा नहीं हुआ
    • पहली library शायद Claude iOS app में इस्तेमाल होती है, और वहाँ text selection व streaming दोनों संभव लगते हैं, साथ ही performance भी ठीक दिखती है
    • user के नज़रिए से पुरानी non-HTML-based apps अक्सर “rules” फ़ॉलो नहीं करती दिखती हैं। जैसे जो text selectable होना चाहिए वह select नहीं होता, या control/option C से copy नहीं होता
      फिर समझ आया कि browser और उसकी underlying technologies ने UI में एक नया paradigm लाया, और native UI frameworks उसका साथ नहीं दे पाए
      web-based apps से ज़्यादा native apps पसंद करने के बावजूद मुझे भी ऐसा ही लगता है

  • या तो code दिखाओ, या फिर बाहर का रास्ता लो। अभी भी Markdown rendering और streaming text को ठीक से संभालने वाले native Mac/iOS apps बहुत हैं
    बस यह जानना है कि आख़िर बहाना क्या है

    • “मैं SwiftUI primitives से बने पूरे Markdown document को selectable बनाना चाहता हूँ” — यह चाहता कौन है? ऐसा product decision दरअसल document editor बनाने जैसा है, जो दशकों से कठिन क्षेत्र रहा है और LLM chat UI के scope से बाहर लगता है
      ज़्यादातर लोग हर continuous block के भीतर selection support देते हैं, और पूरे message के लिए copy button रख देते हैं
    • अगर webview के बिना संभव है, तो code share कर देना चाहिए

  • दिलचस्प बात यह है कि Apple ने भी पहले ऐसा किया था
    पुराने macOS / AppKit में native NSTextField के भीतर rich text render करने के लिए WebKit इस्तेमाल होता था। text एक कठिन समस्या है
    और native WebView बहुत तेज़ और हल्का है, इसलिए उसे text layout engine की तरह इस्तेमाल करना अजीब नहीं है। table की हर row में अलग WebView लगाने पर भी performance शानदार हो सकती है
    Mac के लिए iMessage ने भी WebView इस्तेमाल किया था, और Adium ने भी। अगर आप rich/markup text render कर रहे हैं, तो HTML पूरी तरह सही tool है

    • यहाँ iOS और Mac OS को गड़बड़ किया जा रहा है
      Mac ने NSTextField rendering के लिए कभी WebKit इस्तेमाल नहीं किया। जब iOS पहली बार बनाया गया था, तब UIKit controls सहित व्यापक रूप से WebKit को text renderer की तरह इस्तेमाल किया गया था, और इसे “sweet solution” कहा जाता था
      लेकिन बाद में यह बहुत भारी और झंझटभरा निकला, इसलिए Core Text/AppKit-style text rendering approach आ गई
    • मूल लेख का flow थोड़ा अजीब है
      पहले यह पता चलता है कि complex native text rendering कठिन है, फिर low-level तरीके से text render करते हुए शिकायत की जाती है कि native interactions दोबारा implement करने पड़ते हैं
      WebKit आज़माया तो बहुत अच्छा चला, लेकिन उसे छोड़कर फिर native interactions दोबारा implement करने की स्थिति में लौट जाते हैं
      मैं व्यक्तिगत रूप से WebKit जहाँ अच्छे से काम करने लगे, वहीं रुक जाता

  • याद है 2015 में junior engineer था, तब iOS app के paragraph के भीतर clickable links render करने का काम मिला था
    Swift अभी नया-नया आया था, इसलिए पूरा stack ObjC/UIKit था, और वह सच में किसी दुःस्वप्न जैसा था। किसी तरह उसे चलाया
    2016 के बाद से iOS को लगभग छुआ नहीं, इसलिए सोचा था कि नए SwiftUI में ऐसी चीज़ें तो obvious रूप से built-in होंगी, लेकिन ऐसा नहीं है — यह काफ़ी पागलपन है

    • इसका नाम ही सचमुच Link है
      https://developer.apple.com/documentation/swiftui/link
      इस बिंदु पर नहीं पता इसे और कितना आसान बनाया जा सकता है
    • Qt में यह 10 साल पहले भी काफ़ी आसानी से हो जाता था
    • क्या NSLinkAttributeName नहीं था?
    • मुझे लगा attributed text यह काम पहले से ठीक करता था, क्या ऐसा नहीं था?
    • paragraph के भीतर clickable links डालने की माँग अपने-आप में ही एक बुरा idea थी

  • “साधारण screens से आगे बढ़ो तो native अब भी इतना immature है” — यह होना स्वाभाविक है
    अगर लोग पर्याप्त मेहनत नहीं लगाएँगे, तो उसके mature होने की उम्मीद नहीं की जा सकती
    ज़्यादा effort web technologies में जाता है, इसलिए लोग उसी से बँधे रहते हैं। फिर native को देखकर कहते हैं “यह काफ़ी विकसित नहीं है”, और वापस web development में और मेहनत लगाते हैं — यही cycle चलता रहता है
    browsers में चीज़ें पहले से “बस काम करती हैं”, इसलिए native को बेहतर बनाने की कोशिश करने वाले लोग बहुत कम हैं

    • फिर भी native UI development kits क्या commercial product नहीं हैं? लोगों का खुद को समझाना काम नहीं है; उन्हें तो दूसरी तरफ़ से लोगों को बेचना चाहिए
      web ज़्यादा mature होने का एक कारण यह भी है कि बड़े commercial OS makers समय के साथ चलने को तैयार नहीं थे। Windows UI kits तो वाकई बहुत खराब हैं
    • सहमत हूँ। आख़िरकार यह शिकायत ही है कि Swift में तेज़ Markdown handling के लिए अभी पर्याप्त effort नहीं गया, लेकिन खुद उसमें contribute करने का इरादा भी नहीं है

  • मेरे AI chat app में भी लगभग यही अनुभव रहा। कुछ भी ठीक से काम नहीं करता
    Markdown rendering धीमी और अटकने वाली है, streaming भी धीमी और अटकने वाली है, और सब कुछ UI को freeze कर देता है
    GitHub पर लोकप्रिय UIKit और SwiftUI text edit components में कम से कम 5 आज़माए, और सब किसी न किसी तरह टूटे हुए, buggy और धीमे निकले। यह बेतुका है

  • यह कठिन समस्या है। Qt C++ और QML से block editor को scratch से बनाते हुए इसे कैसे solve किया, इस पर विस्तार से लिखा है
    discontinuous blocks के बीच selection, cursor के नीचे original Markdown दिखाना, अलग-अलग delegate sizes जैसी मिलती-जुलती समस्याएँ आईं
    वहीं सीखी चीज़ों के आधार पर अब streaming Markdown parser वाला native LLM client बना रहा हूँ
    [1] https://rubymamistvalove.com/block-editor
    [2] https://www.get-vox.com
 
GN⁺ 12 시간 전
Lobste.rs की राय
  • मैं इस बात से सहमत हूँ कि जटिल text layout के लिए WebView सही विकल्प है, लेकिन सिर्फ सुविधा के लिए Electron तक जाना ज़रूरी है या नहीं, इस पर मुझे यक़ीन नहीं है
    Electron मूलतः WebView को लपेटने वाला एक wrapper है, लेकिन यह पूरा Chromium engine साथ लेकर आता है, इसलिए सुविधा की कीमत पर app का आकार बहुत बड़ा हो जाता है
    2001~2002 में मैंने iChat के प्रतीकात्मक speech-bubble text layout को NSTextView और तरह-तरह की तरकीबों से लागू किया था, और AppKit text designer Hideki Itamura की मदद मिलने के बावजूद यह काफ़ी मुश्किल था. अब HTML+CSS से यह काफ़ी आसान हो गया है
    • जब कई systems को support करना हो, तो आख़िरकार simplicity बहुत मायने रखती है
      मैं एक ऐसे app से जुड़ा था जो Tauri इस्तेमाल करता था, और जब उसे Electron में Chromium इस्तेमाल करने के लिए बदला गया, तो वह काफ़ी बेहतर चला. ख़ास तौर पर यह भी महत्वपूर्ण था कि target range win7 से win11 तक बहुत व्यापक थी
      Tauri ecosystem का system WebView इस्तेमाल करना अच्छा लग सकता है, लेकिन Windows पर इसका मतलब Chrome या Edge, macOS पर Safari, और बाकी environments में क़िस्मत पर निर्भर रहना है. आख़िरकार predictability और maturity जीत गए, और किसी अज्ञात कारण से performance भी बेहतर थी
    • मेरे हिसाब से यह व्यक्तिगत चुनाव है. चाहे app size हो या RAM usage, अगर आप सुविधा की कीमत चुकाने के लिए तैयार हैं, तो Visual Studio Code जैसे app के करोड़ों users भी शायद इससे सहमत हैं
      आख़िरकार लोग htop chart को संतुष्ट करने से ज़्यादा बेहतर software चाहते हैं
      blog post का मुख्य बिंदु यह नहीं है कि “सबको Electron चुनना चाहिए”, बल्कि यह है कि अब समझ आता है कि resources और पैसे वाली कंपनियाँ भी आज तक Electron या web technologies क्यों चुनती हैं. कम से कम मेरे मानदंड से देखें तो यह सही जगह पर समझौता करते हुए अच्छा user experience देता है
      Apple के TextKit 2 या दूसरे native text frameworks का बचाव करने वाले बहुत लोग हैं, लेकिन Apple SDK से ही बने लोकप्रिय और high-performance text editors लगभग नहीं के बराबर हैं. Xcode यह काम काफ़ी अच्छा करता है और शायद यही एकमात्र वास्तविक production example के सबसे क़रीब है. Zed, Sublime Text, Visual Studio Code, JetBrains IDE — ये सब किसी वजह से अपने custom text rendering solutions इस्तेमाल करते हैं
  • समस्याओं में से एक यह है कि software बनाने वाले लोग दुनिया के शीर्ष 0.1% स्तर के बेहतरीन computers और phones पर development करते हैं
    इसलिए वे चीज़ों को सबसे ख़राब तरीके से भी बनाएँ, तो अपने environment में सब ठीक लग सकता है
    दूसरी ओर, बहुत कम specs वाले devices इस्तेमाल करने वाले बाक़ी लोगों को लगातार भारी-भरकम और धीमा software झेलना पड़ता है
  • सोच रहा हूँ कि आजकल GTK/Qt जैसी चीज़ों की स्थिति कैसी है. GUI किए हुए बहुत समय हो गया
    • मेरी समझ से यह काम Qt में भी WebView के बिना लागू किया जा सकता है
      हालाँकि लगता है कि लेखक ने यहाँ उस दिशा में ज़्यादा खोजबीन नहीं की
  • सोचने वाली बात है कि Electron की तुलना Flutter से कैसी होगी
    बाहर से देखने पर Flutter ऐसा जवाब लगता है जैसे, “अगर Chromium में से सिर्फ़ renderer Skia को छोड़कर उसे GUI app के लिए इस्तेमाल किया जाए तो?” यह Electron से हल्का लेकिन समान क्षमताओं वाला cross-platform tool होना चाहिए
  • https://github.com/stevengharris/MarkupEditor के लेखक का सुझाव है कि यह लेख मौजूदा संभावित समाधानों में से एक काफ़ी अच्छा समाधान प्रस्तुत करता है: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
    • लेकिन MarkupEditor, TextKit2 नहीं बल्कि WebView इस्तेमाल करता है. README में भी लिखा है कि MarkupEditor एक HTML document के साथ इंटरैक्ट करता है जो एक contentEditable DIV इस्तेमाल करता है, और यह WKWebView के subclass का उपयोग करता है
      विडंबना यह है कि Apple का native text engine HTML DOM tree की तुलना में कहीं बेहतर data model इस्तेमाल करता है, यानी string और run-length encoded style attributes
      DOM में text editing करना लगभग दुःस्वप्न जैसा है, क्योंकि selection range अक्सर कई स्तरों पर फैले कई elements को पार करती है, इसलिए उन्हें बहुत जटिल तरीक़े से तोड़ना और फिर जोड़ना पड़ता है. जब मैंने पहले-पहल contenteditable support वाले Safari build को हाथ लगाया था, तो मैंने बहुत बड़ी संख्या में bug reports दर्ज की थीं, और आज भी कई web rich text editors list items को काटने या paste करने पर टूट जाते हैं
      आख़िर में ऐसा लगता है कि 90~00 के दशक के CISC बनाम RISC जैसी ही स्थिति बनी. ‘कमतर’ architecture में ज़्यादा resources डाले गए, और नतीजे में उससे बेहतर implementation निकल आई