Tot frunzărind Internetul ca să aflu ce s-a mai petrecut în ultima vreme, am găsit un material interesant despre WebAssembly . Este un proiect care are cel puţin avantajul de a apărea la momentul potrivit; evident că succesul nu depinde doar de asta, dar măcar e un punct de pornire.
Am mai scris aici despre relativul impas la care propăvăduitorii „cloud”-ului ajung inevitabil. Tehnologia web a fost de la început gândită ca o tehnologie client-server; în care majoritatea calculelor/prelucrărilor sau orice alte operaţii se fac pe server, iar operaţiile care se execută la client (în browser) sunt minimale. Ori, dacă ne gândim să mutăm în cloud aplicaţiile pe care de obicei le aveam pe computerul propriu, va trebui să executăm în browser operaţiuni destul de complexe. Să ne gândim de exemplu la aplicaţia Google Docs.
În această zonă opţiunile pentru dezvoltatori sunt nu numai limitate, dar şi destul de problematice. Există cele două tehnologii majore, Java şi .Net , care au fiecare avantajele şi dezavantajele lor, unele rezultate din controlul pe care îl au companiile care le deţin (Oracle şi Microsoft) şi temerile pe care dezvoltatorii le-ar putea avea relativ la politicile acestora. Oricum, aceste tehnologii nu sunt integrate în browser ci funcţionează ca plugin-uri, ceea ce ar putea ridica diverse probleme.
Singurul limbaj nativ disponibil în principalele browsere este interpretorul de JavaScript. Dar interpretorul de JavaScript a fost gândit de la început ca având un rol periferic ( să coloreze diferit opţiunea selectată sau să ne avertizeze când parolele nu se potrivesc) aşa că problema eficienţei limbajului nu s-a prea pus. Să lucrezi proiecte ample, cu colective mari în aşa ceva este iar destul de dificil. Nu în ultimul rând, fiind un limbaj interpretat, codul sursă este direct accesibil din browser; protejarea codului e practic imposibilă.
Sunt tot felul de artificii care se folosesc pentru a creşte eficienţa JavaScript, însă esenţialul nu prea poate fi schimbat: avem un limbaj interpretat, cu toate dezavantajele care rezultă din asta.
De aceea, dorinţa de a integra un interpretor binar în browser este cât se poate de firească. Însă sunt mai multe obstacole de trecut.
Mai întâi, trebuie ca cel puţin cei trei mari producători de browsere să fie de acord cu integrarea lui, şi mai ales cu integrarea aceluiaşi engine ( vremea când webdesignerii scriau javascript separat pentru IE şi Netscape/Firefox sperăm că a trecut). Evident, specificaţiile trebuie să fie publice, pentru a permite acest lucru.
În al doilea rând, dezvoltatorii înşisi trebuie să se pună de acord cu specificaţiile noului limbaj. Probabil că JavaScript este doar in extremis un punct de plecare; de atunci şi până acum cerinţele s-au schimbat.
În al treilea rând, trebuie ca proiectul să fie funcţional şi folosibil cât mai repede. Poate părea nepotrivit, dar cam aşa funcţionează tehnologia în zilele noastre. Un proiect care întârzie să fie lansat prea mult după momentul său de oportunitate, va eşua cu siguranţă, oricât de bun ar fi. Oamenii au nevoie de soluţii acum, mâine e prea târziu. Din păcate, asta poate duce la aceleaşi probleme pe care le au Java şi .Net: versiuni incompatibile care vor face aplicaţiile dependente de o anumită implementare. Atâta vreme însă cât vorbim despre o tehnologie exclusiv „cloud” lucrurile ar trebui să fie oarecum mai simple: e problema furnizorului să îşi actualizeze tehnologia la nivelul versiunii curente a browserului (acesta deja se cam actualizează automat ); în cazul Java, de exemplu, putem avea şi aplicaţii desktop care ar putea să nu mai funcţioneze.
Bineînţeles, ar mai trebui şi un IDE , şi în general un mediu de dezvoltare, care să permită scrierea de programe complexe. În definitiv pentru programe simple avem deja JavaScript, la câteva linii de cod nu se simte diferenţa.
Și, evident, un pic de noroc. Neprevăzutul are şi el rolul lui în IT , care nu poate fi interpretat de nici un assembler…
Aikido cu mintea si corpul coordonate. Invatati cum sa va relaxati si cum sa va pastrati calmul in conditii de stress. 
De obicei va citesc cu placere si interes dar de data asta…
am citit de doua ori articolul ca sa inteleg ce vreti sa spuneti si tot n-am reusit. In afara de cateva constatari de adevaruri elementare, nimic. Bine ca ati pus link-ul http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/ ca sa aflu si eu ce v-a adus la masa de scris. Poate un rezumat al acelui articol ar fi fost mai folositor citititorilor decat o lamentare stearpa.
Ce sa va zic, nu a fost intentia mea sa para o lamentare… Avem niste idei noi grupate sub numele generic de cloud, care au devenit un fel de „mantra” mai ales pentru cei care nu se pricep – se si pompeaza mult in publicitate, intentia mea a fost sa prezint si dificultatile conceptului si modul in care se incearca depasirea lor folosind exemplul din articolul din ArsTehnica ( articolul e destul de scurt, nu cred ca avea sens sa il rezum, de asta l-am dat in link) . Daca nu a iesit prea bine… se mai intampla, poate data viitoare muza va fi mai generoasa :)
Articolul conţine o ştire: interpretor direct în browser; reacţia mea a fost: asta da chestie tare! pentru că, spre exemplu, va putea pune capăt instalărilor obositoare de soft de astăzi, şi vă dau un exemplu: cumpăraţi un program de contabilitate, peste un timp vreţi să schimbaţi PC pe care e instalat acel program – e un chin pentru utilizator acest transfer, al programului şi al bazei de date; dacă se normează programarea cloud, va fi un mare pas înainte.
Până la urmă cam asta e ideea. Dacă folosiţi Google Docs, de exemplu, aveţi o suită Office în browserul dumneavoastră, fără nici o instalare. Deci avem deja un interpretor în browser, acesta este javaScript. Insă este teribil de ineficient, pentru că lucrează direct cu limbaj de nivel înalt. Unii pun şi comentarii în cod :) E drept, între timp a mai fost optimizat, se poate şi comprima , se mai poate şi cache-ui, dar de la un moment încolo nu prea mai ai ce să faci, atingi limitele limbajului şi basta. În plus, îl cam poate şi citi oricine, deci dacă ai vreun algoritm patentat nu prea e convenabil să îl implementezi într-un asemenea limbaj. Tocmai de asta mi s-a părut interesant materialul. Ideea e destul de evidentă, ne trebuie un interpretor mai avansat; asta ştiam şi eu, dar e mult mai interesant când se implică şi producătorii de browsere, pentru că de ei (de consensul lor) depinde, până la urmă.