Egy korszak vége - mi lesz az Adobe Flash után?

Microsoft, Windows

Aki esetleg lemaradt volna róla, az Adobe bejelentette, hogy jelenlegi tervei szerint 2020 végén befejezi a Flash Player frissítést, terjesztését, azaz megöli azt. A Microsoft Edge webböngésző fejlesztői reagáltak a hírre és felvázolták az Edge és Internet Explorer Flash-sel kapcsolatos terveit. A részletek itt.

( Hevi v | 2017. 07. 26., sze – 10:24 )

Kinyiratni volt eszuk a Googleeknek, de valami akar csak picit is megkozelitoen hasznalhato webes editor/fejlesztoi kornyezetet viszont azota se sikerult osszeizzadniuk.

Sajnos nem nagyon volt itt flame, nemhogy war :(

Pedig olyans szivesen beszelgettem volna meg arrol is, hogy a bongeszoben az EcmaScript 4-et hanyagoltak, mert...

... ellenben az ActionScript 3-mal (June 27, 2006), ami az EcmaScript 4-en alapul.

De mit is tudott volna az EcmaScript 4 2008-ban / mit is tudott az ActionScript 3 2 evvel korabban?

classes,
a module system,
optional type annotations and static typing, probably using a structural type system,
generators and iterators,
destructuring assignment, and
algebraic data types.

Jelenleg a bongeszoben az EcmaScript 6-nal tartunk 2015-ben, es meg mindig nem teljes a tamogatasa. Mit is hozott ez? (vastagon szedve a kozos reszeket)

The 6th edition, officially known as ECMAScript 2015, was finalized in June 2015. This update adds significant new syntax for writing complex applications, including classes and modules, but defines them semantically in the same terms as ECMAScript 5 strict mode. Other new features include iterators and for/of loops, Python-style generators and generator expressions, arrow functions, binary data, typed arrays, collections (maps, sets and weak maps), promises, number and math enhancements, reflection, and proxies (metaprogramming for virtual objects and wrappers). The complete list is extensive.

Annyira cuki, hogy a JavaScripteseket 9 evig szopattak azzal, gyakorlatilag hazudtak nekik, hogy valami ertelmes nyelvet hasznalnak, hogy vegulis vegeredmenyben sikeruljon egy szar ActionScript 3 utanzatot letrehozniuk. Es meg minket hulyeztek anno, mikor azt mondtuk, hogy a JS alapjaiban van elbaszva, es alapvetoen alkalmatlan komoly munkara.

Szerk: a fentebbi linkbol:

It should therefore be no surprise that the HTML 5 draft reads like a laundry list of past Flash features (video, audio, sockets, drawing apis, etc...).

To sum up, ActionScript 3 isn't changing and we are not going to dumb down future versions or ActionScript. We are going to continue to innovate on the web with the Flash Player, and push the web forward, as we have done for over a decade. August 14, 2008

Hajra HTML5, hajra frontend!!!!11111

Ertem, hogy a hatterben dolgozo rendszerben voltak nagyon eloremutato dolgok, de ami az emberek 99%-at erinti, a felhasznaloi elmeny... Na hat nem veletlenul halt ki. (Nem tudok copy-pastelni belole? Engem el is vesztettek. A vakok/gyengenlatok nem tudjak felolvastatni/nagyobbra, kontrasztosabbra venni a betumeretet? Jo nagy kocsogseg es bizonyos esetekben illegalis is. Valahogy ugy kinalta magat a rendszer, hogy minden harmadik verpistike kepes legyen rendszerlassito, ventillator porgeto csiricsoda menuk es reklambannerek letrehozasara. A biztonsag is kozismerten legendas volt.)
A felhasznaloi oldallal miert nem foglalkozott az Adobe? Miert nem nyitotta jobban meg, miert nem engedte ki a flash animaciot a kis zart teglalapbol, hogy az lehessen "az uj HTML"? Licenc bevetelek?

> Nem tudok copy-pastelni belole? Engem el is vesztettek. A vakok/gyengenlatok nem tudjak felolvastatni/nagyobbra, kontrasztosabbra venni a betumeretet? Jo nagy kocsogseg es bizonyos esetekben illegalis is.

Ezt a .jpg is tudja, mégis egy csomóan azt használják statikus szöveg megjelenítésére a weben. :)

> Nem tudok copy-pastelni belole? Engem el is vesztettek.

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flas…

A Boolean value that indicates whether the text field is selectable. ... The default value is true.

Dev hulyeseg. Altalaban menu itemek nem selective-k voltak, viszont az informacio igen. Legalabbis remelem, hogy odafigyeltem erre akkoriban, mar megfakultak az emlekek. (Ellenben erdemes ranezni a dokumentaciora. Ilyenrol akkoriban almodni se mertunk, hogy lesz egyszer JavaScripthez.)

> A vakok/gyengenlatok nem tudjak felolvastatni...

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flas…

Azt azert tudjak.

> Valahogy ugy kinalta magat a rendszer, hogy minden harmadik verpistike kepes legyen rendszerlassito, ventillator porgeto csiricsoda menuk es reklambannerek letrehozasara

A reklamiparnak mindig is szuksege volt figyelemfelkelto, animalt, szines-szagos, interaktiv mediumra. A bongeszoben default jelenlevo HTML + CSS + JS olyan elmaradott volt a kor technologiai szintjehez kepest, hogy keptelenseg volt vele eloallitani megfelelo reklamanyagot. Ne aggodj, miota elkezdett felzarkozni a bongeszo a modern megoldasokhoz, itt is megjelentek a kikerulhetetlen popupok, a scrollozas kozben felugro "subscribe to our mail" dialogok, a reklam miatt le majd fel csuszo tartalommal biro oldalak, automata videolejatszas, stb. A reklam mindig is meg fogja probalni minel jobban magara vonni az ember figyelmet, ez fuggetlen a technologiatol.

Az eroforras zabalassal nagyreszt egyetertek, mondjuk szerintem az is inkabb PEBKAC volt developer oldalrol (ilyet meg JS-ben is el lehet kovetni, ugye).

> A biztonsag is kozismerten legendas volt.

Azert ebben a bongeszo se feltetlen jeleskedett, mig nem sandboxoltak.

> A felhasznaloi oldallal miert nem foglalkozott az Adobe?

Mire gondolsz?

> Miert nem nyitotta jobban meg, miert nem engedte ki a flash animaciot a kis zart teglalapbol, hogy az lehessen "az uj HTML"? Licenc bevetelek?

Ezt en is sokat kerdezgetem. Nem hinnem, hogy a bevetelek lennenek az egyeduli okai, lehet, hogy ok is licenceltek valahonnan valamit a Player kodjaban, es azt mar nem lehet kiadni opensourcekent. Hiszen az Adobe mar korabban is adomanyozott az opensource kozossegnek (Flex, Tamarin (AVM2)). Ha maskor nem, mostmar ideje lenne meglepni, ha a penz miatt lenne, de nem ugy tunik, hogy ez meg fog tortenni, szoval mas lehet a hatterben.

Szerk:

De ha mar penz. A Google-nek nem is az volt az elsodleges baja a Flash-sel, hogy a vakok es gyengenlatok nem tudjak olvasni, hanem az, hogy az o scraperjei sem, igy indexelni se tudta, deeplinkelni se, ebben meg akkor hogy keressen, hogy csinaljon belole penzt?

> Nem tudok copy-pastelni belole? Engem el is vesztettek

Na peldaul az iOS-es Slack ilyen. Nem kijelolheto a szoveg. Meg a 3D touchot se tamogatja, de mondjuk nem is csodalom, biztos valami szipiszupi Ionicos, JavaScriptes szornyszulott, mint az Electronos desktop valtozata, na mindegy.

Igazabol masolni lehet a szoveget hosszu tappal, de sajnos az iOS-nek van egy olyan josaga, hogy a szot kijelolve ra lehet keresni a szotarban, ami nekem gyakran egesz hasznos. Na ezt nem lehet megcsinalni ezzel...

Egyreszt igen, azert az ActionScript2 -> 3 valtas egy baromi jo otlet volt, nem is beszelve az OOTB API-krol.

Masreszt azert a XXI. szazadban mar nem meno UI-t _kodolni_, azt mar a Swinggel se szerettek az emberek. Nem ertem, hogy a webdevek miert oromkodnek amiatt, hogy a munkajuk tok feleslegesen olyan bonyolult amilyen, (tudomasom szerint) minden valamennyire magara is ado platform rendelkezik UI designerrel (nem is rosszakkal).

Persze, ha a HTML5 nem lenne annyira elbarmolt szabvany, ha a CSS viszonylag normalis lenne, es ha a browser nem text alapon, hanem canvas alapon mukodne, akkor lehetne ehhez is normalis fejlesztoi kornyezetet irni, de valahogy a web evoluciojaban mindig a rosszabbik megoldast tudtak valasztani, ami csak meg melyebbre loki az egesz okoszisztemat a pocegorodben.

Azzal egyetértek, hogy fejlesztőeszközökben van még hová fejlődni. De szerintem az így van jól, hogy a html text alapon működik, mivel így sokkal jobban igazodik/igazítható a megjelenítő eszközhöz. Pl. a responsive design sem abban merül ki, hogy mobilon máshogy van elrendezve az oldal mint desktopon, mert a html struktúra nem módosítható css-ből. Viszont ennek az az előnye, hogy a jó responsive design bármilyen eszközön jól skálázódik, nem csak azon a néhányon, amin tesztelték.

Igen, abban igazad van, hogy ez jol skalazodik reszponzivan, ezzel nincs is gondom weboldalak eseten. De webalkalmazas fejlesztesehez ez a modszer nem idealis. Amugy CSS eseten is szinte 2-3x kell implementalni a UI-t (legalabbis ha jol gondolom, hogy hogy mukodik ez manapsag), a kozos reszek meg mas modszernel is konnyeden kiemelhetoek.

Viszont annak koszonhetoen, hogy a HTML nem dinamikus, hanem statikus generalasra lett kitalalva, vagyis a DOM szerkeszthetosege nem volt kezdetben szempont (foleg, hogy ez a kifejezes akkor meg nem is letezett), illetve szimpla, egyszeru szoveges oldalak letrehozasara (vo: iFrame navigacio, table-design), igy peldaul olyan alapveto koncepciok hianyoznak belole, mint pl. a komponens alapusag, vagy egy rendes layout kezeles. Igen, igen a shadow-dommal jonnek majd a "komponensek", viszont elegge takolas szaga van annak is, masreszt peldaul olyat, hogy

<HorizontalAlign padding-top="10" padding-left="10"> <VerticalAlign align="$(Align.CENTERED)"> <WeightCalendar selectedDate="${today}"/> </VerticalAlign><VerticalAlign> <WeightInput /> </VerticalAlign> </HorizontalAlign>

nem tudom mikor fogok latni...

szerk: illetve azt se felejtsuk, hogy a HTML hianyossagait szerver oldali rendereles eseten jol lepleztek a kulonbozo templating enginek (es mindenki azt hitte, hogy ez igy van jol), mig a JS ternyeresevel nem kezdett el igeny lenni a kliens oldali DOM manipulaciora is. Ekkor jottek olyan szornyszulottek, mint a Mustache meg HandlebarJS, amik a szereny elerheto eszkozeikkel probaltak megoldani egy elegge surgeto problemat ...

Viszont annak koszonhetoen, hogy a HTML nem dinamikus, hanem statikus generalasra lett kitalalva
Szerintem ezen már bőven túlhaladtunk. Évek során én is álmodoztam HTML-t leváltó és világot megváltó nyelvekről, de a valósághoz kell sajnos alkalmazkodni.
A kódodat nem igazán értem. Valami XML szerű nyelvel akarsz megjelenést leírni? Ez tudja a HTML úgy hogy cserélhető a megjelenés (CSS). Nagy nehezen kiszervezték a formázást a HTML, inkább ne hozzuk vissza. Én amúgy kliensoldali templatezést nem tartom jó ötletnek. Na jó egy bizonyos mértékig lehet értelme, de csak nagyon indokolt esetben. Egy CMS munkáját pl nem kellene a kliensoldalra kitolni.

> Szerintem ezen már bőven túlhaladtunk.

Epp errol van szo, hogy tulhaladtunk, es emberes leptekkel haladunk a szakadek fele.

> Évek során én is álmodoztam HTML-t leváltó és világot megváltó nyelvekről, de a valósághoz kell sajnos alkalmazkodni.

Nem almodozni kell, hanem csinalni. Peldaul en is alkalmazkodtam a valosaghoz, ugyhogy olyan messzire menekulok a bongeszotol, amennyire lehet. Egyelore csak backendre tertem at, kozben meg az Apple okoszisztemat tanulom.

> Valami XML szerű nyelvel akarsz megjelenést leírni? Ez tudja a HTML úgy hogy cserélhető a megjelenés (CSS).

Nem csak az XML a lenyeg, de az is fontos. A HTML-nek is volt szabvanyos XML valtozata, az XHTML, illetve a HTML5-tel elindulhattak volna vegre a megfelelo iranyba, de ott is inkabb a taknyolast valasztottak a kisebb ellenallas miatt. Viszont vedd eszre, hogy nem divisionoket, meg paragrafusokat hoz letre az ember ilyen esetben, hanem altala mashol mar definialt sajat komponenseket lehet igy felhasznalni. Tomorebb, atlathatobb, karbantarthatobb. Ehhez kapcsolodoan:

> Nagy nehezen kiszervezték a formázást a HTML, inkább ne hozzuk vissza.

A formazas kiszervezesere a HTML miatt volt szukseg, nem amiatt, mert a layout es a komponensek keverese ordogtol valo lenne. Ha jol sejtem szinte az osszes masik platform inline layoutolast hasznal; es nem azert hasznaljak, mert hozzajuk meg nem ert el a megvilagosodas, hanem mert normalis kornyezetben, komponens alapu leironyelvvel a layout es a struktura keveredese nem gond.

> Én amúgy kliensoldali templatezést nem tartom jó ötletnek. Na jó egy bizonyos mértékig lehet értelme, de csak nagyon indokolt esetben. Egy CMS munkáját pl nem kellene a kliensoldalra kitolni.

Alkalmazasokrol van szo. Kliens oldali templatezes nelkul hogy szeretnel offline hasznalhato appot kesziteni? Amugy baromi erdekes ez is, hogy ez megintcsak a web az amelyik kilog az online first megkozelitesevel, az osszes tobbi eseten forditva tortenik a fejlesztes.

Jó sokszor emlegették már, hogy a HTML szakadék felé megy. Eddig még nem jött össze. Ha lesz helyette jobb ás támogatott megoldás akkor biztos lecserélik.

XHTML-nek úgy látom azért nem volt túl sok értelme, mert senki sem tartotta be igazán. Ezért ugyan úgy kellett értelmezni mint eddig a sima HTML-t. Ebből kifolyólag semmi előnye nem volt a sima HTML-el szemben.

Gondoltam hogy elő fogsz jönni az offline oldalakkal. Igen ott van értelme.

HTML-nek nagyon sok platformon kell működnie, nagyon sok mindenre használják. Nehéz mindenhol megfelelni. Láttam már olyan HTML alapú megoldást ami offline programkánt működött, de nem láttam olyan Java alkalmazást ami dokumentumként is megfelelt volna. :D
Tény hogy teljesen másképpen kell egy weblapot, mint egy HTML alapú alkalmazást.

Amúgy kisebb alkalmazáshoz magam is írtam mini template kezelőt. :D
Én épp tervezek visszatérni a Frontend-hez, csak a mostani munkám eléggé másról.

> Jó sokszor emlegették már, hogy a HTML szakadék felé megy. Eddig még nem jött össze.

Tokeletesen igazad van, a HTML (+ CSS + JS) elni fog meg sokaig. De sajnos nem azert, mert jo megoldas, hanem azert, mert nagyon sok penz van benne. Illetve azert, mert egyelore elkepzelhetetlen egy ossznepi megegyezes valami kozos, normalis szabvanyrol (de errol kesobb).

> XHTML-nek úgy látom azért nem volt túl sok értelme, mert senki sem tartotta be igazán. Ezért ugyan úgy kellett értelmezni mint eddig a sima HTML-t. Ebből kifolyólag semmi előnye nem volt a sima HTML-el szemben.

Igen, ezert mondtam, hogy a kisebb ellenallas fele haladtak folyamatosan. Az egesz az 1. bongeszo haborura datalhato vissza, mikoris az tortent, hogy a verseny olyan kielezett volt a Netscape Navigator es az Internet Explorer kozott, hogy egyszeruen nem engedhettek meg maguknak azt a luxust, hogy ok diktaljak a szabalyokat a "fejlesztoknek", hiszen ha nem jelenik meg az oldalam A-ban, viszont mivel B nem olyan szigoru a szabvannyal, ezert B-ben megjelenik, akkor B-t fogod valasztani es mindenkinek azt javaslod, hogy B-t hasznaljon. Szoval se A-nak, se B-nek nem volt erdeke a parser error, hanem inkabb megprobaltak valahogy javitani az elrontott szintaxist. Mivel ez nem koordinaltan tortent, ezert a javitasok ad-hoc modon tortentek, ez is eloidezoje volt a cross-browser compatibily problemanak.

Ebbol lathato, hogy az XHTML-nek sajnos semmi eselye se volt a kotottebb szintaktikajaval - meg ha egyszerubb ra parsert is irni, illetve jobban bovitheto - hiszen az a bongeszo, amelyik ezt ki akarta volna kenyszeriteni a helyes szintaxist azzal, hogy hiba eseten nem jeleniti meg az oldalt, hatranyba kerult volna a tobbiekkel szemben.

Lasd mi tortenik itt is egy lezaratlan <em> tag eseten. Az egesz oldal felveszi azt a stilust. Megjeleniti, mert a bongeszo, ha nem talalja meg a lezaro taget, akkor valahogy megporbalja feloldani a dolgot, es ezaltal az oldal alapvetoen megjelenik, ellenben egy szigorubb XML alapu leiro nyelvnel, ahol is rogton parse errort kapsz.

Az elobbi tokeletes megkozelites weboldalak eseten, mikor az a lenyeg, hogy barki kitehesse a statikus kis HTML-jet meg az animgifjeit az egyetemi szerverre, de mikor arrol van szo, hogy komoly alkalmazasokat kellene kesziteni dollar millios uzletek szamara, akkor azert egy kis szigorusag sokkal tobbet hasznalna a karbantarthatosagnak, nem is beszelve az automatizalasrol. Jo par eve, mikor a kozkutak.hu-t csinaltuk a tuhu-rol kellett scrapelnem az adatokat, mert adatbazis hozzaferest sajnos nem tudtak adni; es mar akkor mit meg nem adtam volna, ha valami rendesen parseolhato formatumban lett volna kirakva a dolog. Oke, manapsag a kulonbozo JSON meg Rest APIkkal mar nem olyan veszes a dolog, de azert meg mindig sokszor megvan, hogy az informacio kellene, de API nincs. Tudom, tudom, manapsag mar vannak egesz jo HTML parserek is, de valahogy olyat meg nem lattam, hogy valami HTML-bol generalna osztalyhierarhiat, hogy ne kezzel kelljen felepiteni a page modellt (automatizalt UI teszteleshez tokeletes lenne, foleg ha az osszes UI valtozast tipushelyesen lekovetnek az osztalyok is, igy a fordito szolhatna, ha a tesztjeid out-of-datek).

> Gondoltam hogy elő fogsz jönni az offline oldalakkal. Igen ott van értelme.

Nem kotekedesbol, csak szeretnem pontositani, mert ez nagyon fontos a tema szempontjabol, es nem szeretnem, ha elbeszelnenk egymas mellett. Offline alkalmazasokrol beszeltem. Azert vagyok erre most kulonosen kenyes, es azert hangsulyozom ennyire, mert egy weboldalnak es egy webalkalmazasnak teljesen mas felteteleknek kell megfelelniuk. Egy weboldal (blog, forum, cegismerteto oldal) informativ kell legyen, es foleg szoveges/audiovizualis tartalmakat jelenti meg. Egy webalkalmazas ezzel szemben (gmail, facebook, google maps, hotels.com, jira) egy alkalmazas, egy program, GUI-val, kezeloszervekkel, beallitasokkal, ertesitesekkel, widgetekkel stb. Teljesen mas hozzaallast igenyel. Mert amig egy oldalnal van ertelme divekkel meg paragraphokkal leirni az amugyis nagy esellyel szoveges tartalmat, addig egy alkalmazasnal ujrafelhasznalhato widgeteket akarsz letrehozni, amiket egyreszt tobbszor is felhasznalhatsz, masreszt onalloan tesztelhetsz, tobbeket osszekombnalhatsz. Ezert tartom azt, hogy a HTML nem jo GUI leiro nyelvnek, de nem rossz szoveges tartalmak strukturajanak leirasara, es ezert hangsulyozom ennyire.

> HTML-nek nagyon sok platformon kell működnie, nagyon sok mindenre használják. Nehéz mindenhol megfelelni.

Lentebb pont hoztam peldat arra, hogy a Flash/Flex is eleg sok eszkozon hasznalatos volt (meg a telefonokon is az Airnek koszonhetoen). De ott van a Canonical kiserlete az Ubuntu Phone-nal es a Univerzalis UI-jal vagy mi is volt az. Nem ismerem, esetleg olvastam itt rola, nem tudom, de igy latatlanba szerintem az is hasznal valami XML alapu leiro nyelvet, es abban is keverve volt a layout es a struktura. Es ezert mondom, hogy ha a kodot jol lehet szervezni, akkor az ujrafelhasznalhatosag sokkal magasabb, igy 2-3 implementacio nem gond device meretto fuggoen, sot meg talan egyszerubb is karbantartani, meg bugot javitani.

> Láttam már olyan HTML alapú megoldást ami offline programkánt működött, de nem láttam olyan Java alkalmazást ami dokumentumként is megfelelt volna. :D

Ezt fentebb tisztaztam, alkalmazasokrol van szo, az oldalak most nem jatszanak, arra tokeletes a HTML :)

> Amúgy kisebb alkalmazáshoz magam is írtam mini template kezelőt. :D

En is csinaltam valami hasonlot azzal, hogy a JS-t komponens alapuan kezdtem szervezni, es igy sokkal karbantarthatobb lett a kod. Hiaba, a good practice-ok nem veletlen azok :)

> Én épp tervezek visszatérni a Frontend-hez, csak a mostani munkám eléggé másról.

Az biztos, hogy munka az lesz boven, hiszen a web csak tor elore az uzleti piacon, mostmar szinte kikerulhetetlen. Viszont nem vagyok oda erte mint alkalmazas platformert, mert altalaban nem tetszik a UX, mert nem integralodik az OS-be, mert olyan dolgok vannak a bongeszoben, amik egy alkalmazas eseteben jo esellyel ertelmezhetetlenek (elore-vissza gomb, stop, refresh), illetve szerintem szornyu vele dolgozni. Akit ez nem zavar, az jol el lesz a frontenddel, de engem a vilagbol ki lehet kergetni vele.

"Egyreszt igen, azert az ActionScript2 -> 3 valtas egy baromi jo otlet volt, nem is beszelve az OOTB API-krol."

Akinek esetleg nem lenne meg a kontextus:

Az ActionScript es a JavaScript egy torol fakadnak, mindketto ECMAScript. Olyannyira, hogy peldaul a Flash Player ECMAScript engine-nek van nyilvantartva (Tamarin).

Az ActionScript 2 meg nagyban hasonlitott az akkori JavaScripthez, de az Adobe egy hatarozott lepessel megalkotta a visszafele nem kompatibilis ActionScript 3-at, teljesen uj, alapjatol a tetejig objektumorientalt szemlelettel. Jellemzoen baromi egyszeruen lehetett vele dolgozni, szigoruan tipusos nyelv leven picit bobeszedubb, de sokkal atlathatobb kodot eredmenyezett.

Onnantol kezdve elvezet volt a Flash platformra feljeszteni, mert a GUI es a nyelv nagyon jol kiegeszitettek egymast. A Flash alapvetoen egy animacios eszkozkent indult meg a Macromedia alatt, de a web azido tajt a multimedia CD-ktol torteno ternyerese miatt hamar elolepett a Director utodjanak, egy komplett szerzoi rendszernek. Flash-sel alapvetoen multimedia tartalmat lehetett generalni, csili-vili weboldalakat, jatekokat, kep es video nezegetoket, multimedia CD-ket, desktop appokat (de volt kollega aki televizios musorhoz keszitett vele interaktiv overlayt, en meg erintokepernyos terminalon jatszhato jatekot, oktatasi segedleteket, desktop vekonyklienst, stb).

(Web)alkalmazasok irasara a Flex-t lehetett hasznalni. A Flex projectet alapvetoen Adobe Air (desktop) platformra lehetett publishelni, de volt Flash Player lehetoseg is (illetve az Adobe Air elerheto volt(?) mobilon is). Mig Flashben a UI-t alapvetoen rajzolta/animalta az ember, addig Flexben volt egy UI leiro nyelv, az MXML, illetve az Adobe editoraban mar drag&drop UI editor is volt. Ha az MXML nem is volt a legjobb UI leiro nyelv, de komponens alapu volt, a hatterben AS3 osztalyokra fordult, szoval a kulonbozo UI elemek ugyanugy szarmaztathatoak egymasbol, mint az objektumok, szoval igen jo kis dolog volt.

Mar akkoriban leteztek hozza IoC, ORM implementaciok, igy a kod konnyeden karbantarthato maradhatott. Socket kezelese evekkel a WebSocket megjelenese elott mar volt. Az OOP miatt nem callback, hanem event alapu, az API nagyon konnyen attekintheto, plusz a tipusossag miatt nagyon konnyen lathato, hogy milyen eventekre lehet feliratkozni, es azok milyen parametereket varnak; sajat event letrehozasa annyi, mint egy sajat exception letrehozasa... gyerekjatek. Mindezt tupontos auto-suggestionnel az IDE-ben.

Aki nem fejlesztett Flash platformra, az nyilvan csak a Flash Player hulyesegeivel es bugjaival talalkozott, es baromira csodalkozhat, hogy megis ki vedheti azt a szar platformot. Viszont az a szar platform fejlesztoi es UX oldalrol annyira az ideje elott jart (vo: Java Applet, korabeli szinte nulla JavaScript), hogy ahhoz kepest a mai allapotok elkeseritoek meg mindig. Ha figyelembe vesszuk, hogy az Adobe mar jo 5 eve elengedte a Flex-et, akkor erdemes lehet elgondolkodni azon, hogy ha valamilyen csoda folytan a W3C a HTML + JS + CSS helyett valami hasonlot szabvanyosit, akkor ma hol lennenk alkalmazasfejlesztes teren.

Szerk: amugy vicces, hogy

"Tamarin source code originates from ActionScript Virtual Machine 2 (AVM2)[1] developed by Adobe Systems, as introduced within Adobe Flash Player 9, which implements ActionScript 3 scripting language. ActionScript Virtual Machine 2 was donated as open-source to Mozilla Foundation on November 7, 2006, to develop Tamarin as a high-performance virtual machine, with the support from broad Mozilla community, to be used by Mozilla and Adobe Systems in the next generation of their JavaScript and ActionScript engines with the ultimate aim to unify the scripting languages across web browsers and Adobe Flash platform and ease the development of rich better performing web applications."

Szoval ha ugy vesszuk, a Flash platform nem halt ki, egy resze tovabb fog elni a Firefoxban :) elolvastam a cikket

Azert az se mindegy, hogy az ActionScript3-mal mar 2006(!)-ban bejott a JIT compilation, mig ugye a JavaScript ezt 2008-ban kapta meg a V8 enginenel. Ha figyelembe vesszuk, hogy akkoriban a Flash Player verziok frissitese mar viszonylag gyorsan ment, szoval mire a Chrome megjelent, addigra a Flash hasznalok nagy resze mar vigan hasznalta a technologiat.

Nem beszelve arrol, hogy ugyan baromi nagy elonyekent szoktak emlegetni a JavaScriptnek, hogy funkcionalis paradigmakat is tamogat, de sok ertelme nincs. Igen, az tok jo dolog, csak nem sok ertelme van egy alapvetoen single-thread kornyezetben, ahol a parhuzamositas elenyeszo, es meg az annak tekintheto Web Workerek is inkabb Eventeket hasznalnak Callbackek helyett. A funkcionalis paradigma tokeletesse teszi a JS-t kis, tomor scriptek irasara, de peldaul az immutable objecktek es a tipusossag teljes hianya alkalmatlanna teszi alkalmazasfejlesztesre. GUI programozasara az objektumorientalt megkozelites az idealis, komponens alapu szemlelettel.

Azert a "gond nelkul" resszel vitatkoznek. Ne felejtsuk el, most az ActionScript 3 a merce, es az hihetetlenul kenyelmes volt GUI es alkalmazas programozasra mindenfele 3rd party framework, meg csillio dependency nelkul is. Nem veletlenul talalt ra a JavaScript is a reg elveszettnek hitt osvenyre, ugyanazokat a feature-oket hozta be vegre a nyelv, amik mar 10+ eve benne voltak a versenytarsban.

A JavaScript azert nyerte meg a nyelvek csatajat, mert a bongeszo nyelve, nem azert mert jobb lenne. Ha forditva lett volna, es a bongeszot lehetett volna ActionScript 3 es MXML alapon, es Flasht lehetett volna JavaScript es HTML-lel programozni, akkor a Flash szerintem sokkal kevesbe terjedt volna el (es vegre orom lenne a bongeszovel dolgozni).

( SzBlackY | 2017. 07. 26., sze – 10:32 )

Rejtett subscribeként gondoltam rákérdezni, hogy vajon a marha nagy iparági összefogás eredményeként beleölnek pár tízezer dollárt, hogy a Shumwayt kicsit kipofozzák 2020-ig [mondjuk a github szerint tavaly március óta nem nyúltak hozzá :(]? Szép és jó dolog, hogy kidöglik a Flash (ideje volt), de aki elég Jason Scott előadást hallgatott végig, az most lehet, hogy kezd aggódni, hogy értelmes runtime nélkül marha sok content fog eltűnni, amik közt lehet megmentésre érdemes (arról nem is beszélve, hogy ami netről húz be fájlokat, azok nagy része bukó lesz, mert előbb-utóbb kihúzzák alóluk a szervereket)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Vicces", hogy random idokozonkent eszembe jut egy (jo esellyel Flash) oldal, ami inkabb muveszi volt, mintsem informativ, hangulatilag valahol Tim Burton es a Limbo kozt volt, hangulatos zenevel. Nem is emlekszem, hogy csak kulonbozo "interaktiv kepek" voltak, vagy egy tortenetet meseltek-e el, de nagyon tetszett. Ez olyan 2002-2004 kornyeken volt, szerintem mar sose fogom megtalalni.

Szerk: ehhez kapcsolodoan:

http://www.simonstalenhag.se

Kellene tole rendes printet is rendelnem. Zsenialis. (Visszafele nezve meg egy tortenet is kikerekedik).

Huhh, koszi, hogy szoltal! 9 perccel a zaras elott :)

Nagyon durva egyebkent, nem is igazan tudok hasonlorol. A hangulat az zsenialis, az ember tobbet akar tudni a tortenetrol. Nagyon szurrealis, de kozben valoszeru.

Mi volt a masik meglepo dolog?

Szerk: es nagyon faj, hogy a szani bezart, pedig epp kezdtem ujra rakapni. Nincs forras most erdekes kontentre :(

> Mi volt a masik meglepo dolog?

Hogy a flash meg egyaltalan letezik. Valamiert ugy remlett, hogy az Adobe egyszer mar eltemette a rendszert.
Mondjuk nem kovetem az esemenyeket, mar nagyon regen nincs is a gepeimen. Ha jol emlekszem mar akkor sem volt (es csak annyit mondtam "Na ugye."), amikor Jobs 2010-ben azt mondta, hogy nincs es nem is lesz Flash iOS-en.

> Szerk: es nagyon faj, hogy a szani bezart, [...]

Ooo, mi az a szani?

( tigrincs | 2017. 07. 26., sze – 16:53 )

Flash, a-ah, saviour of the universe
Flash, a-ah, he'll save everyone of us
Ha ha ha ha ha ha ha ha ha
Flash, a-ah, he's a miracle
Flash, a-ah, king of the impossible