Mozilla wil ondersteuning XUL-opmaaktaal uit Firefox halen

Mozilla overweegt afscheid te nemen van zijn XML User Interface Language. Door de ontwikkeling van het web zou de opmaaktaal overbodig zijn geworden. Mozilla twijfelt nog wel hoe van de taal afscheid moet worden genomen.

Mozilla bouwde de XML User Interface Language, kortweg XUL, onder meer voor zijn Firefox-browser en Thunderbird-mailclient. De standaard beschrijft diverse elementen, zoals vensters, widgets en scripts. Met XUL kunnen ontwikkelaars makkelijker en sneller een interface bouwen.

XUL werd ooit ontwikkeld om de 'gaten' te vullen die html achterliet in webapplicaties. Dat schrijft Dave Camp, Mozilla's Director of Engineering. Volgens hem is de webtechnologie echter dusdanig verbeterd dat Mozilla's opmaaktaal overbodig zou zijn geworden. Datzelfde zou gelden voor XBL, voor het opmaken van xml-documenten.

"Omdat XUL en XBL geen webtechnologieën zijn, krijgen ze niet dezelfde aandacht die html krijgt. Prestatieproblemen worden niet opgelost, wat tot veel onnodige complexiteit in de Gecko-layoutengine leidt", meent Camp. "Het staat verder van het web af - en dat helpt niemand."

Camp streeft ernaar dat Mozilla de XUL- en XBL-ondersteuning uit Firefox haalt. Hoe en wanneer dit precies moet gebeuren, weet hij nog niet. "De discussie daarover bevindt zich nog in een vroege fase. Er zijn nog veel onbeantwoorde vragen, zoals welke technologieën we moeten gebruiken om ze te vervangen."

In een mail roept hij ontwikkelaars op om na te denken over de 'fundamenten' van het toekomstige Firefox. Camp meent dat dit wel even gaat duren. Dat is ook niet vreemd: het verwijderen van de XUL- en XBL-ondersteuning kan grote gevolgen hebben voor onder meer de makers van extensies.

Reacties (23)

Toch raar. Het lijkt me dat met HTML+CSS je veel meer boilerplate nodig hebt om in een extension bijv een simpel preferences dialogue te maken. XUL is juist heel erg gericht op de UI, en biedt daar een mooie gestructureerde manier van schrijven voor. Verglijkbaar met Qt or XAML of al-die-andere-UI-talen.

HTML is niet geschikt voor de GUI van een applicatie. Je kunt het er wel voor gebruiken, maar zo kun je soep ook wel met een vork gaan eten.

Als je enkel HTML+CSS gebruikt dan heb je inderdaad veel code nodig om een mooie GUI te maken. Maar als je een framework gebruikt zoals www.polymer-project.org of www.semantic-ui.com dan kan je met beknopte, gestructureerde code ook een mooi resultaat bekomen!

Grappig, deze css frameworks kende ik nog niet. Ik denk wel dat de grootste jongens op het moment Bootstrap (http://getbootstrap.com/) en Foundation (http://foundation.zurb.com/) zijn

Ik gebruik momenteel Susy (http://susy.oddbird.net )met SASS, Gulp e.d.
Bekijk deze grid/framework ook eens, mocht je deze nog niet kennen! Heeft veel SASS-mixins en functions die gebruikt kunnen worden. Binnen no-time heb je een strakke pagina gelay-out, zonder gebruik te maken van teveel overbodige code (Bootstrap, ahem).

edit: URL

[Reactie gewijzigd door Anoniem: 563860 op 8 juli 2015 10:56]

Steeds meer systemen stappen over naar HTML + CSS. Zo kun je ook je volledige linux desktop omgeving wijzigen d.m.v. wat CSS regels te wijzigen.

Het grootste nadeel? Het is relatief traag. Het grootste voordeel? De user interfaces zullen qua ontwerp een stuk omhoog gaan. Veel ontwerpers kunnen namelijk wel met de CSS + HTML combi overweg.

"Steeds meer systemen stappen over" is geen reden om ook maar over te stappen. Daar moet je een weloverwogen reden voor aan kunnen geven, en (dus) de nadelen ervan hebben afgewogen t.o.v. de voordelen.

Het grootste nadeel in mijn ogen is de grote hoeveelheid boilerplate die nodig gaat zijn om met HTML een GUI te bouwen. Met "gewoon wat html en wat css" ben je er nog niet. Een framework om met HTML een GUI te bouwen, is allesbehalve simpel - novh voor de developer, noch als voor de gebruiker (van dat framework). HTML en CSS zijn daarbij veel te vrij. Je kunt als developer de boel veel te makkelijk de kak op laten gaan. En voor Mozilla is het nog steeds een hels karwei om alles in goede banen te laten glijden - hetgeen met XUL net zo goed moet gebeuren.

Het voordeel dat veel ontwerpers met HTML+CSS om kunnen gaan is niet alleen niet waar (er vanuit gaande dat je web developers en ontwerpers niet op één hoop veegt, want dan zou ik me beledigd voelen), ook is het niet echt een goeie reden om dat maar te gaan gebruiken. Het is niet het einde van de wereld om een taaltje te leren. XUL is niet echt moeilijk, en er werd al (een subset van) CSS gebruikt om het te stylen. Dus wat dat betreft is het niets anders dan SVG: dat is ook XML-based en kun je stylen met CSS, maar doen ontwerpers dat? Nee.

Geloof me, ik ben wel een van de laatste die het verschil niet weet tussen een webdeveloper en een webdesigner. Echter door al die open source pakketten als Wordpress e.d. zijn er veel ontwerpers die met gemak die templates kunnen opzetten, zonder dat ze zelf kunnen programmeren of überhaupt met backend talen overweg kunnen. Op design opleidingen is basis html + css steeds vaker standaard, zelfs wanneer je puur DTP studeert.

Wat voor applicatie? Waarom niet?

Wat voor applicatie: een add-on bijvoorbeeld. Of iets wat in de volksmond een "app" heet.

Waarom niet: _Thanatos_ in 'nieuws: Mozilla wil ondersteuning XUL-opmaaktaal uit Firefox halen'

Maarja XUL mag dan misschien wel handig zijn, maar het werkt dus alleen op 1 browser en 1 mailclient, en daarmee beperk je jezelf toch wel heel erg. Ik zou dus niet firefox gaan installeren omdat 1 'applicatie' dit nodig heeft..

En HTML met CSS en JS is perfect voor de GUI van een applicatie, (tja het is geen native applicatie dus beperkingen heb je dan altijd wel).. Aan de andere kant, deze jongen moet het (helaas) nog steeds doen met VB6 en de windowsapi, maargoed, het werkt en blijft voorlopig nog werken op windows.. LOL..

Je aanname is niet helemaal correct.
Als je een applicatie schrijft met een XUL user interface, lever je niet de .xul en .js files.
Je levert, net zoals Firefox en Thunderbird, een executable die gebruik maakt van de xul files.

Ik snap waarom je HTML zou willen gebruiken. Ik ben er niet van overtuigd dat dit de handigste optie is, maar ik zie niet in waarom het bezwaarlijk zou zijn.

Ik vraag me wel af hoe ze overlays zouden doen in HTML. Daarnaast lijkt security (sandboxing) wat lastig met pure HTML. Ik neem aan dat ze wat custom spullen zullen moeten toevoegen om dit voor elkaar te krijgen.

Dus Firefox gaat ook de HTML kant op voor opmaak. Mogelijk met NodeJS backend? Hopen dat ze de snelheid ook in orde krijgen, dat wil nog wel eens mank gaan.

Lijkt me wel dat het dan makkelijker wordt om plugins te poorten naar diverse browsers toe als vrijwel alle nieuwe browsers daar gebruik van gaan maken. Vraag me alleen wel af of ze dan niet teveel op elkaar gaan lijken.

Maar goed, prima stap van Firefox imo. Nu hopen dat ze ook zorgen voor goede overgang en niet ineens alle plugins nutteloos worden.

[Reactie gewijzigd door Martinspire op 7 juli 2015 21:05]

De desktop applicaties die op NodeJS draaien gebruiken meestal Chromium's WebKit als engine. Gecko is een tegenhanger van WebKit en zit dus nog een laag onder NodeJS, het zou dan ook niet echt werken om zo'n layout engine in JavaScript te schrijven: je wil hier juist performance voor hebben, het hoeft niet modulair te zijn omdat het alleen een standaard implementeert.

Het is een logische stap om hun hele interface naar HTML5 over zetten en XUL compleet uit Gecko verwijderen.

WebKit is alweer verleden tijd, het is al een tijdje Blink.

Hmm, ja, maar applicaties als Popcorn Time gebruiken dan weer node-webkit wat NodeJS en Chromium's layout engine (maar een oude versie ervan, waarschijnlijk toen het nog webkit was dus) combineert.

Dan is het nu ook weer zo dat WebKit een JS implementatie heeft die Chromium niet gebruikt, Chromium heeft een eigen V8 JS engine. Die V8 engine wordt dan weer door NodeJS gebruikt.

Ja, WebKit bestaat uit twee delen: WebCore (layout/rendering/DOM engine) en JavaScriptCore (JS engine), waarvan Chromium dus alleen WebCore gebruikte en dat later als Blink geforked heeft.

Blink is Google's fork van Webkit, Webkit is oorspronkelijk van Apple en op zijn beurt weer een fork van KHTML.

Google is niet de enige leverancier die Webkit heeft omarmd, en nog lang niet iedereen gebruikt Blink.

Je kunt prima Webkit als achterliggend framework gebruiken maar toch Gecko als renderengine.
NodeJS heeft prima performance, maar de meeste frameworks daarbij zijn nog vrij nieuw en kunnen beter. Bij Atom.io zie je ook elke release de performance verbeteren.

De manier waarop NodeJS is opgezet, kunnen ze echter ook overnemen. Ik zou er niet van staan te kijken als straks Mozilla een NodeJS alternatief maakt en deze breed omarmt. Google is er eigenlijk niet echt met volle overtuiging mee bezig en ook andere partijen verliezen de grip een beetje (niet altijd slecht overigens). Mozilla kan prima dat gat op gaan vullen.

Je kunt prima Webkit als achterliggend framework gebruiken maar toch Gecko als renderengine.

Hoe bedoel je? WebKit parsed HTML, CSS, JS, houdt de DOM bij, doet de layout en rendering, en Gecko doet ook precies dat.

JS wordt gigantisch goed geoptimaliseerd, dat zeker, maar ik zou niet zeggen dat het in de buurt komt van gecompileerde talen als C++.

Ik zou het echt zonde vinden als Mozila ervoor zou kiezen om XUL te schrappen, ik gebruik het dagelijks met veel plezier! Het is enorm handige manier om een userinterface te bouwen.

Zal wel met de nieuwe browser Edge van Windows 10 wellicht te maken hebben en hebben ze er nog eens over nagedacht...

Het heeft eerder te maken met het feit dat XUL buiten Mozilla nooit aangeslagen is, en nu een obscure technologie is waar ook bugs lang in open blijven staan. Het is een last geworden.

Plus dat Mozilla in Firefox OS een browser heeft gemaakt die puur met webtechnologie gebouwd is en Gecko daar dus nu de techniek voor ingebouwd heeft zitten.

Zie: https://developer.mozilla...API/Using_the_Browser_API

Natuurlijk is dat maar een deel van het verhaal; je wil voor de Desktop Firefox niet zomaar allerlei legacy plugins weg gaan gooien.

Zie ook: https://github.com/mozilla/browser.html