LibreKAT/Ocideck

Watch

Fork 1

Evalueer webview_flutter_web vervanging (21 maanden stale, zelf-benoemd 'severely limited') #1742

New issue

Closed

opened 2026-08-23 08:37:24 +00:00 by brenno · 2 comments

brenno commented

2026-08-23 08:37:24 +00:00

Owner

Achtergrond

webview_flutter_web (0.2.3+4) is 21 maanden niet bijgewerkt. De README van het pakket zelf beschrijft het als:

severely limited and doesn't implement most of the available functionality

Het is een officieel Flutter-team-pakket (flutter.dev, verified), maar het lijkt in de ijskast te staan.

Gebruik in OciDeck

webview_flutter_web wordt gebruikt voor Mermaid-diagram rendering op het web-platform:

lib/services/mermaid_render_service.dart (regel 19)
lib/services/mermaid_web_renderer.dart (regel 11)

Op native platforms (macOS, Linux, Windows) wordt Mermaid gerenderd via een andere route. De webview_flutter_web is specifiek voor de web-build.

Het probleem

Geen updates in 21 maanden — mogelijk niet compatibel met toekomstige Flutter web-versies
Zelf-benoemd 'severely limited' — de implementatie dekt niet alle WebView-functionaliteit
Voor Mermaid-rendering is alleen evaluateJavascript of loadHtmlString nodig, maar de beperkingen kunnen onverwachte problemen geven
Het pakket staat in dependency_overrides noch als direct dependency — het is een transitive dependency van webview_flutter die we expliciet pinnen met webview_flutter_web: ^0.2.3+4

Alternatieven om te onderzoeken

Mermaid server-side renderen — Mermaid.js heeft een Node.js API. We kunnen Mermaid-diagrammen omzetten naar SVG tijdens het bouwen of bij export, in plaats van runtime rendering op web.
webview_flutter zonder web-backend — op web een iframe gebruiken met Mermaid via CDN (maakt wel een externe afhankelijkheid, wat botst met de 'geen extern' waarde).
Eigen web-bridge — een kleine JS-bridge in index.html die Mermaid laadt en renderen via dart:js_interop (geen webview nodig).
flutter_inappwebview — actiever onderhouden webview-pakket met betere web-ondersteuning.

Wat dit issue moet uitzoeken

Hoe afhankelijk zijn we precies van webview_flutter_web? Alleen Mermaid, of meer?
Werkt de huidige Mermaid-rendering op web überhaupt goed genoeg?
Is server-side Mermaid rendering haalbaar (zonder Node.js dependency in de build)?
Is flutter_inappwebview een veilig alternatief?

Prioriteit

Medium. Het werkt nu, maar 21 maanden zonder updates is een risico voor de web-build op de langere termijn. De bewaker-waarde 'soevereiniteit' speelt hier: we willen niet afhankelijk worden van een CDN voor Mermaid.

## Achtergrond `webview_flutter_web` (0.2.3+4) is **21 maanden niet bijgewerkt**. De README van het pakket zelf beschrijft het als: > severely limited and doesn't implement most of the available functionality Het is een officieel Flutter-team-pakket (flutter.dev, verified), maar het lijkt in de ijskast te staan. ## Gebruik in OciDeck `webview_flutter_web` wordt gebruikt voor Mermaid-diagram rendering op het web-platform: - `lib/services/mermaid_render_service.dart` (regel 19) - `lib/services/mermaid_web_renderer.dart` (regel 11) Op native platforms (macOS, Linux, Windows) wordt Mermaid gerenderd via een andere route. De `webview_flutter_web` is specifiek voor de web-build. ## Het probleem 1. Geen updates in 21 maanden — mogelijk niet compatibel met toekomstige Flutter web-versies 2. Zelf-benoemd 'severely limited' — de implementatie dekt niet alle WebView-functionaliteit 3. Voor Mermaid-rendering is alleen `evaluateJavascript` of `loadHtmlString` nodig, maar de beperkingen kunnen onverwachte problemen geven 4. Het pakket staat in `dependency_overrides` noch als direct dependency — het is een transitive dependency van `webview_flutter` die we expliciet pinnen met `webview_flutter_web: ^0.2.3+4` ## Alternatieven om te onderzoeken 1. **Mermaid server-side renderen** — Mermaid.js heeft een Node.js API. We kunnen Mermaid-diagrammen omzetten naar SVG tijdens het bouwen of bij export, in plaats van runtime rendering op web. 2. **`webview_flutter` zonder web-backend** — op web een iframe gebruiken met Mermaid via CDN (maakt wel een externe afhankelijkheid, wat botst met de 'geen extern' waarde). 3. **Eigen web-bridge** — een kleine JS-bridge in `index.html` die Mermaid laadt en renderen via `dart:js_interop` (geen webview nodig). 4. **`flutter_inappwebview`** — actiever onderhouden webview-pakket met betere web-ondersteuning. ## Wat dit issue moet uitzoeken 1. Hoe afhankelijk zijn we precies van `webview_flutter_web`? Alleen Mermaid, of meer? 2. Werkt de huidige Mermaid-rendering op web überhaupt goed genoeg? 3. Is server-side Mermaid rendering haalbaar (zonder Node.js dependency in de build)? 4. Is `flutter_inappwebview` een veilig alternatief? ## Prioriteit Medium. Het werkt nu, maar 21 maanden zonder updates is een risico voor de web-build op de langere termijn. De bewaker-waarde 'soevereiniteit' speelt hier: we willen niet afhankelijk worden van een CDN voor Mermaid.

brenno added the

enhancement

label

2026-08-23 08:37:54 +00:00

brenno commented

2026-08-23 08:40:33 +00:00

Author

Owner

Licentie- en taalonderzoek

Huidige package

Package	Licentie	Taal	Opmerking
webview_flutter_web	BSD-3-Clause	Dart (100%)	Officieel Flutter-team pakket (flutter/packages monorepo). Web-only implementatie, geen native code. Ondersteunt alleen `loadRequest` en `loadHtmlString`.

Overwogen alternatieven

Package	Licentie	Taal	Opmerking
flutter_inappwebview	Apache-2.0	Dart (57.1%), C++ (18.8%), Swift (12.1%), Java (9.3%), HTML, CMake, TypeScript, +rest	Multi-platform met uitgebreide native implementaties. Veel zwaarder dan webview_flutter_web. Ondersteunt inline webview, headless webview, in-app browser.

Eigen-code alternatief (server-side Mermaid)

Als we Mermaid server-side renderen in plaats van via een webview, hebben we alleen de packages die we al hebben:

Package	Licentie	Taal	Opmerking
markdown	BSD-3-Clause	Dart (100%)	Officieel Dart-team pakket (dart-lang/tools). Al in gebruik in OciDeck.

Conclusie

webview_flutter_web: BSD-3-Clause, pure Dart. Licentie compatibel met EUPL.
flutter_inappwebview: Apache-2.0, maar brengt aanzienlijke native code (C++, Swift, Java) mee — veel zwaarder dan wat we nu hebben. De Apache-2.0 licentie vereist NOTICE-file bij distributie.
Eigen codec met markdown: BSD-3-Clause, pure Dart, geen nieuwe afhankelijkheid. Licentiegewijs de schoonste optie.

De licenties zijn geen obstakel voor welke route dan ook. De keuze hangt af van architectuurvoorkeur: minimaal blijven (eigen bridge) of een volwassen webview-pakket nemen (flutter_inappwebview).

## Licentie- en taalonderzoek ### Huidige package | Package | Licentie | Taal | Opmerking | |---|---|---|---| | **webview_flutter_web** | BSD-3-Clause | Dart (100%) | Officieel Flutter-team pakket (flutter/packages monorepo). Web-only implementatie, geen native code. Ondersteunt alleen `loadRequest` en `loadHtmlString`. | ### Overwogen alternatieven | Package | Licentie | Taal | Opmerking | |---|---|---|---| | **flutter_inappwebview** | Apache-2.0 | Dart (57.1%), C++ (18.8%), Swift (12.1%), Java (9.3%), HTML, CMake, TypeScript, +rest | Multi-platform met uitgebreide native implementaties. Veel zwaarder dan webview_flutter_web. Ondersteunt inline webview, headless webview, in-app browser. | ### Eigen-code alternatief (server-side Mermaid) Als we Mermaid server-side renderen in plaats van via een webview, hebben we alleen de packages die we al hebben: | Package | Licentie | Taal | Opmerking | |---|---|---|---| | **markdown** | BSD-3-Clause | Dart (100%) | Officieel Dart-team pakket (dart-lang/tools). Al in gebruik in OciDeck. | ### Conclusie - **webview_flutter_web**: BSD-3-Clause, pure Dart. Licentie compatibel met EUPL. - **flutter_inappwebview**: Apache-2.0, maar brengt aanzienlijke native code (C++, Swift, Java) mee — veel zwaarder dan wat we nu hebben. De Apache-2.0 licentie vereist NOTICE-file bij distributie. - **Eigen codec met markdown**: BSD-3-Clause, pure Dart, geen nieuwe afhankelijkheid. Licentiegewijs de schoonste optie. De licenties zijn geen obstakel voor welke route dan ook. De keuze hangt af van architectuurvoorkeur: minimaal blijven (eigen bridge) of een volwassen webview-pakket nemen (flutter_inappwebview).

brenno referenced this issue

2026-08-23 08:55:07 +00:00

Migreer screen_retriever + window_manager naar nativeapi-flutter (uitfasering aangekondigd) #1741

brenno commented

2026-08-23 16:43:33 +00:00

Author

Owner

Evaluatie

Gebruik in OciDeck

webview_flutter_web wordt uitsluitend gebruikt voor Mermaid-diagram rendering op web:

lib/services/mermaid_render_service.dart (regel 19)
lib/services/mermaid_web_renderer.dart (regel 11)

Op native platforms (macOS, Linux, Windows) wordt Mermaid via een andere route gerenderd. Het pakket is een transitive dependency van webview_flutter die expliciet gepind is.

Risico-inschatting

21 maanden zonder updates: het pakket werkt nu, maar compatibiliteit met toekomstige Flutter web-versies is onzeker
Zelf-benoemd 'severely limited': voor Mermaid is alleen evaluateJavascript/loadHtmlString nodig, dus de beperkingen zijn momenteel geen probleem
Geen security-risico: het pakket draait in de browser-sandbox, geen elevated permissions

Alternatieven

Eigen web-bridge — een kleine JS-bridge in index.html die Mermaid laadt via dart:js_interop. Geen webview nodig. Kleinste diff, maar wel een architecturele wijziging.
flutter_inappwebview — actiever onderhouden, maar zwaarder en voegt een nieuwe dependency toe.
Server-side Mermaid rendering — Mermaid.js heeft een Node.js API, maar dit voegt een Node-afhankelijkheid toe aan de build. Bots met de 'geen extern' waarde.
Mermaid via CDN in iframe — maakt wel een externe afhankelijkheid, wat botst met de 'soevereiniteit' waarde.

Aanbeveling

Medium prioriteit. Het werkt nu, maar het risico groeit. De beste route is optie 1 (eigen web-bridge via dart:js_interop) — dit past bij de 'soevereiniteit' waarde en verwijdert de webview-afhankelijkheid voor web. Plan als aparte sessie/PR.

## Evaluatie ### Gebruik in OciDeck `webview_flutter_web` wordt uitsluitend gebruikt voor Mermaid-diagram rendering op web: - `lib/services/mermaid_render_service.dart` (regel 19) - `lib/services/mermaid_web_renderer.dart` (regel 11) Op native platforms (macOS, Linux, Windows) wordt Mermaid via een andere route gerenderd. Het pakket is een transitive dependency van `webview_flutter` die expliciet gepind is. ### Risico-inschatting - **21 maanden zonder updates**: het pakket werkt nu, maar compatibiliteit met toekomstige Flutter web-versies is onzeker - **Zelf-benoemd 'severely limited'**: voor Mermaid is alleen `evaluateJavascript`/`loadHtmlString` nodig, dus de beperkingen zijn momenteel geen probleem - **Geen security-risico**: het pakket draait in de browser-sandbox, geen elevated permissions ### Alternatieven 1. **Eigen web-bridge** — een kleine JS-bridge in `index.html` die Mermaid laadt via `dart:js_interop`. Geen webview nodig. Kleinste diff, maar wel een architecturele wijziging. 2. **`flutter_inappwebview`** — actiever onderhouden, maar zwaarder en voegt een nieuwe dependency toe. 3. **Server-side Mermaid rendering** — Mermaid.js heeft een Node.js API, maar dit voegt een Node-afhankelijkheid toe aan de build. Bots met de 'geen extern' waarde. 4. **Mermaid via CDN in iframe** — maakt wel een externe afhankelijkheid, wat botst met de 'soevereiniteit' waarde. ### Aanbeveling Medium prioriteit. Het werkt nu, maar het risico groeit. De beste route is optie 1 (eigen web-bridge via `dart:js_interop`) — dit past bij de 'soevereiniteit' waarde en verwijdert de webview-afhankelijkheid voor web. Plan als aparte sessie/PR.

brenno referenced this issue

2026-08-23 16:50:39 +00:00

fix: Flutter 3.47 batch — Impeller, iOS-target, analyzer 13, re_highlight #1750

brenno added the

in-progress

label

2026-08-23 19:54:52 +00:00

brenno referenced this issue from a commit

2026-08-23 20:13:39 +00:00

fix: Wasm web-build werkt — nativeapi achter conditional imports (#1734)

brenno referenced this issue

2026-08-23 20:13:56 +00:00