A HTML mint UI leiro nyelv - gyakorlatilag hasznalhatatlan modern webapp fejlesztesre

Amire korabban is ravilagitottam, most kicsit jobban osszeszedettebben:

"I know I'm dating myself, but I come from a background of Windows desktop development long before there even was 'Web development'. Say what you will about desktop development (or even Native development for devices these days) when it comes to providing consistent APIs and tooling to make it easier to build sophisticated UIs, native apps are doing a much better job.

HTML is not like the desktop so it can't be expected to behave the same, but compared to desktop applications and APIs HTML is just very, very sparse. Some will take that as a positive, but I'm pretty sure that many are realizing that this lack of an underlying platform architecture causes a lot of the friction I describe above in the development process.

It sucks to have to continually re-invent the same thing over and over again and when you have no real baseline model on which to build a custom implementation. You can't extend functionality that isn't there in the first place, so you often have to literally build from scratch.

...

When I think back on those days one thing that stands out to me is how easy and fast it was to develop functional UIs for these applications due to a plethora of pre-made components, easy to use visual tools that allow easy placement and visualization of content. And maybe more importantly a well defined underlying UI API that supported creation of common controls that addressed the most common use cases.

HTML based UI development is lacking in all of these areas.

In these desktop environments you had an lots native controls that were built in to the base framework along with extensive tooling that allowed a rich design time experience. Controls like date pickers, comboboxes, grids, tree viewers, auto-selectors, menus, context menu, popups, even more custom things like masked input filters, validators and scroll viewers and so on were just there because they are part and parcel of the platform.

But even more importantly these UI frameworks came with something that HTML can only dream about: An actual well-defined and extensible object model that allowed you to easily extend or create new controls of your own relatively easily. Not only could you create your own controls because it was relatively easy to use base components and enhance them, but it was also relatively easy for many third parties to build third-party controls that were for sale (or in some cases free - remember this is long before OSS and free became the norm). Tons of third party controls were also available both for pay and for free.

None of that exists in HTML today. In HTML the only model you have is basically extend by composition of the limited base controls that you have.

Having a base set of components provides a more solid base line for building applications without having to run out and build or find a third party component each and every time you need even a slightly complex controls.

I often hear arguments that HTML is different than desktop because HTML layout is very fluid and that's why the model has to stay lean.

I don't really buy that argument. WPF/UWP/XAML on Windows also uses a compositional layout model and it's quite capable of supporting a rich component API along with a base set of controls. I'm not a huge fan of WPF and XAML, but it is good example of what is possible in terms of a rich API that works both as a compositional layout engine and provides the core needed for extensibility as well as a lot of built in components.

There's no reason that HTML can't do something similar."

https://weblog.west-wind.com/posts/2018/May/31/Web-Code-is-a-solved-Pro…

Kicsit hosszu cikk, de erdemes elolvasni, es melyen elgondolkodni, hogy hogy sikerult ennyi idon at hulyiteni a webfejlesztoket azzal, hogy valami jo, modern, eloremutato, hasznalhato platformot kalapalnak a mindennapokban... Nem is beszelve arrol, hogy mennyire beetettek az embereket ezzel a HTML5 hurraoptimizmussal, hogy az majd most aztan mindent IS megold!

( therion | 2018. 06. 04., h – 14:42 )

Ennyit tudnak az úgynevezett „nyílt szabványok”. (Amúgy már a megnevezés is hazug, hiszen a W3C-nek nincs kompetenciája szabványokat alkotni.)

Annak idején a Microsoft nem ott rontotta el, hogy évtizedekig ignorálta ezt a rakás szerencsétlenséget, hiszen a saját webes technológiái is gyakran évtizedeket (!) vertek az akkori W3C specifikációkra. Inkább ott, hogy a monopol piaci helyzetük tudatában nem voltak képesek fejlődni és ahogy egyre igényesebbek lettek a weblapok az IE használata rémálommá vált.

Egy leíró nyelvet amit szöveges dokumentumok közötti linkelgetésre terveztek sose szabadott volna alkalmazásfejlesztésre használni.

> All of this points to how bad the W3C 'design by committee' process is at bringing new features to the browser. Not only is it slow, but it's also bringing almost duplicated features that for the casual observer are not even easy to differentiate at a glance. It would have been nice to have CSS Grid and Flexbox as a single spec since there is so much feature overlap, but no - two separate but similar standards just to make things a more difficult to decide.

https://en.wikipedia.org/wiki/Design_by_committee

:)

Szerk:

> Egy leíró nyelvet amit szöveges dokumentumok közötti linkelgetésre terveztek sose szabadott volna alkalmazásfejlesztésre használni.

Nagyon igy van! De sajnos a weben mindig sikerult a nagyobbik rosszat valasztani az evolucio soran. Amit el lehetett rontani, azt elrontottak. Igazi allatorvosi lo.

"Amúgy már a megnevezés is hazug, hiszen a W3C-nek nincs kompetenciája szabványokat alkotni."
Már hogyne lenne. Minden szabványügyi szervezet arról szól, hogy X ipari partner összeáll, azt mondja, hogy kidolgozunk közösen egy szabványt, és mindenki követheti azt.
Amely szabvány simán lehet valamelyik ipari partner már meglévő fejlesztése, termékének leírása.

A lényeg, hogy a szabvány egy olyan, gyártófüggetlen leírása egy terméknek, amely leírás alapján bármely másik gyártó képes kompatibilis terméket előállítani.
A szabványok teljesen iparügyi dolgok, viszont mivel gyártófüggetlen leírások, beilleszthetők a jogrendszerbe, lehet rájuk gond nélkül hivatkozni.

Az egy dolog, hogy vannak olyan szabványügyi szervezetek (pl. ISO), amelyekben államok vesznek részt, mert a saját jogrendszerükbe akarják ültetni a szabványokat.
Viszont vannak olyan szabványok, amelyek nem része a jogrendszernek, csak iparági megállapodás az iparági szereplők között. Attól még ugyanolyan szabványok azok is. Csak épp a jogrendszer nem, csak a piac az, ami kikényszerítheti a használatát.

Például van ISO szabvány (az OSI, ISO/IEC 7498-1) a hálózatokra, mégis mindenki az IETF szabványait használja.

( persicsb | 2018. 06. 04., h – 16:39 )

Erre találták ki a Web Components dolgot.

"Ah yes, Web Components: the mythical solution to all of the Web's problems for the last 7 years.

Web Components sure sound promising. Always have since there was the initial discussion in the early 2011 timeframe.

Much like application frameworks like Angular and React etc., Web Components are meant to to create small self-contained islands of UX and functionality that can be reused.

...

That sounds great and it might solve the problems I've described so far in providing a richer base line of base controls that can be reused. Even so Web Components sure could benefit from a larger set of built-in base controls to start from.

But...

Just wait another 2 years and everything will be awesome!

The way things stand only Chrome has support for all the required WebComponents sub-features. Most other browsers are a sea of red...

Again, I have to ask this question: We know Web Components is a vital feature that everybody wants and the Web needs to move forward. All camps have been advocating Web Components for many years. So, why the heck are we 7 years into this technology without even a possible adoption date in sight?"

:(

Ebben csak az a bosszanto, hogy ez megint semmi ujdonsag, semmi innovacio, hanem a 10-15-20 eves technologiai lemaradast sem kepesek behozni ezen a Nagyszeru platformon, ami a web...

Lehet meg kellett volna hagyni a plugineket, mig valamennyire rendbe nem szedik ezt a szemetdombot, mert ami most megy webfejlesztes cimen az... remelem komoly, mert viccnek azert durva.

Amíg úgyis a Chrome diktál (ÉLJEN), addig ne várjunk semmit. Nincs jelenleg piaci verseny a böngészők között. Van a Chrome, ők kitalálnak valamit, a többiek meg követik.
És mindenki issza a szavaikat, mert a Google jócég.
Persze, amikor a MS diktál, akkor a MS szarcég.

Mindegy, nem értem én az embereket, hogy az egyik gigavállalat miért jobb, mint a másik, mikor mindkettő ugyanúgy szar.

Amúgy a JS-sel talán elérnek oda tudásban, amit a Flash és a Java appletek kb. 15-20 éve tudtak. De most legalább szabványosan! A lényeg, hogy nem egy cégnek lesz a felelőssége, hogy minden platformra kompatibilis megoldást fejlesszen minden böngészőhöz, hanem több browser vendor fogja szépen inkompatibilisen támogatnia a dolgokat, hiszen az úgy jó. Agyrém a webes platform.

Van valami forrásod arra vonatkozóan, hogy a Chrome/Jócég diktál? A WHATWG keretein belül tömörül az Apple, Microsoft, Google, Mozilla, Opera, ezen vállalatok nyomására alakult át a HTML és a CSS living standardé.

Ami jelenleg a HTML-el és a CSS-el történik az mind az Apple, Microsoft, Google, Mozilla és az Opera közös eredménye. Ők diktálnak közösen, miután bojkottálták a W3C-t, mert a lassú szabvány releasekkel nem tudták követni a megnövekedett elvárásokat és igényeket a HTML-el és a CSS-el szemben.

> The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML, and apparent disregard for the needs of real-world web developers.

Fasza. Ezeknek koszonhetjuk, hogy az XHTML-t kukaztak vegul :(

De meg ha csinalnanak is valami ertelmeset, de neeeeem, inkabb csak szetturjak azt is, amiben esetleg lehetett volna fantazia.

Az a baj, hogy már ideje korán elkezdődtek az XML-el a hitványkodások, és ma már gyakorlatilag baj is lenne sokaknak, ha lenne.
Nem is tudom így hirtelen, hogy hány kezemen tudnám megszámolni azon oldalakat amik úgy tömörítik a markupjukat, hogy az "elhagyható" lezárótageket is törlik, hogy méginkább kisebb legyen a forrás.
Ez alatt pedig nem pistike oldalakat értek. Ez az igénytelenség az XHTML elterjedtebb időszakában is folyton tetten érhető volt, amikor az egész értelmét elvették azzal, hogy nem deklarálták rendesen a Content-Typeot.
Siralmas, hogy ekkora kihívást jelentett a weben egy XML alapú szabvány.

Köszi a forrásokat.

Mindazonáltal a WHATWG közös megegyezés alapján dolgozik, legalábbis ezt állítják. Nyilván nem látok bele a folyamatokba, így csak azt tudom mondani ami le van írva, az alapján pedig "a többség akarata érvényesül".

Viszont mélyen lesújtó, hogy milyen egyöntetű, pozitív fogadtatást kapott a fent linkelt változás a hozzászólásokban.

Igen, itt én is néztem, hogy nagyon ködösen van megfogalmazva a dolog, ezért nem is álltam neki egy ez alapján megfogalmazott ellenvéleménynek, hogy "dehát demokrácia", így elfogadom a forrásaidat, köszi. :) Onnantól szerintem hülyeség vitázni, hogy feltételezések képezik az alapot. Plusz nem is vagyok érdekelt abban, hogy bármelyik gigavállalat megítélését megvédjem. :)

Btw amilyen ideológia van ma a HTML és a CSS mögött, szerintem a szavazásos eljárás sem segítene rajta túl sokat, a legtöbben sorra szopják fel a WHATWG döntéseit. Ez mégnagyobb baj.

( asch v | 2018. 06. 04., h – 18:03 )

Én sem tartom jó ötletnek a HTML általi fejlesztést, nem is értem, hogy miért van annyira beleszerelmesedve az ipar.

Nekem mondjuk a JavaScript az ősellenségem, el tudom képzelni, hogy ha a HTML objektumokat natív érzettel el lehetne érni valami értelmes (számomra ez a statikusan típusos imperatív nyelvek halmaza, pl Java, C#) programozási nyelvből, akkor azzal lehetne azért hasítani. Az, hogy csak kompozitolni lehet a HTML objektumokat talán nem akkora probléma, ha lehetne azt mondani, hogy itt van egy HTML node, ami mögé egy XY osztályt kell példányosítani, ami akár kompozitolva, akár lightweight control módszerrel "mögé tenné" az implementációt. Ahogy JavaScriptben meg is lehet ezt tenni, csak hát az JS.

Ellenben a programozott komponens alapú GUI-k (pl Qt, JavaFx, stb) CSS általi skin-ezése egész jól tud működni. Persze ezzel is van baj tapasztalataim szerint, de valamennyire használható.

( BaT | 2018. 06. 04., h – 22:08 )

Az alapvető probléma az, hogy a HTML dokumentum leírásra lett kitalálva, nem GUI programozásra. Egy dokumentum esetén nem probléma, ha a megjelenítő program egy picit máshogy rendezi el az elemeket, vagy más GUI widgetet használ ugyanahhoz az elemhez, ezért lehet ugyanazt az oldalt értelmesen megjeleníteni és használni egy 4k TV-n és egy 5"-os mobilon is. Nyilván ennek az az ára, hogy sok mindent nem, vagy nem úgy lehet megoldani, mint egy natív alkalmazásban. Az már ne a nyelv hibája legyen, hogy olyasmire akarják használni, amire nem való.

Pl. ott vannak a szemantikus elemek, amikkel egyszerűen le lehet írni egy híroldalt, egy blogot, vagy egy wiki oldalt. Vajon értelmes leírni velük egy webshopot, egy chatprogramot vagy egy térképet?

Btw a JavaScript környékén sincs minden rendben, itt van pl. ez az agyhalott javaslat, ami nagy valószínűség szerint be fog kerülni a következő EcmaScript verzióba.

Ha meg emlekszel a tavalyira, ott is igazat adtam annak, hogy a HTML tokeletes (hypertext) dokumentumok leirasara. Markdown++

Tokeletesen skalazodik minden eszkozre, ahogy emlited is.

Nekem az ossz problemam (amit te is emlitessz), az az, hogy ezt a technologiat olyanra hasznaljuk, amire nem valo.

Ez a cucc nem UI programozasra, hanem (hyper)text dokumentumok formazasara es linkelesere lett kitalalva. (Sajnos?) mivel ez nyilt szabvany, ezert sokan felelosek a donteshozatalert, ezert bun lassan megy barmi implementalasa, szoval a bongeszo meg mindig nem kepes rendesen application framework-kent viselkedni, a nagy penzre ahitozok meg mindig korbaccsal utik a fejlesztoket, hogy valami ertelmes dolgot kihozzanak a vegen a platformbol.

A legnagyobb gondot itt abban latom, hogy elvesztegettunk egy generaciot, akik szar utmutatasok kozt nottek fel, elhittek, ez igy van jol, ennel nincs feljebb, hogy az eger csak egy gombos lehet (hello '80-as evek Apple-je), stb.

Megtanultak egy csomo olyan dogmat, aminek szoftverfejelesztesben semmi, csak webfejlesztesben van valamennyi igazsagtartalma.

Nem mellesleg, azert a Flash-es idokben soookkkal tobb kreativitas volt az egyszeru Flash oldalakban is, mint a mai, egy kaptafara keszult, bongeszos oldalakban. Lehet nem voltak a legjobbak, de volt sok betegen kreativ is. Nem is beszelve az experimental cuccokrol.

Szoval azt hiszem amugy egyetertunk, csak nekem sarkosabb a velemenyem :)

> Btw a JavaScript környékén sincs minden rendben, itt van pl. ez az agyhalott javaslat, ami nagy valószínűség szerint be fog kerülni a következő EcmaScript verzióba.

Elvileg már benne is van: https://www.ecma-international.org/ecma-262/8.0/#sec-sharedarraybuffer-…
Gondolom sovány vígasz, de a Spectre miatt kikapcsolták mindenhol: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Globa…

Mondjuk szerintem az már önmagában gáz, hogy a böngészők draft-ban lévő feature-t implementálnak meg kitalálnak saját W3C kívüli dolgokat, amire az 4 év után ragasztanak egy v0-s verziószámot és kijönnek egy "ezmostmárténylegjólesz" v1-el: https://developers.google.com/web/fundamentals/web-components/customele…

Tovább rontja a helyzetet hogy a Babel transpiler (és társai) még proposal előtti, stage0-s dolgokat is beraknak néha, ha úgy gondolják.