di  -  lunedì 8 agosto 2011

Qualche giorno prima di partire per l’EuroPython tenutosi a Firenze, mi è capitato di leggere un interessante articolo di ARS Technica che, però, mi ha messo parecchio in agitazione.

In estrema sintesi, alla prima dimostrazione pubblica di Windows 8 s’è parlato delle nuove API per le funzionalità introdotte con questo s.o., ma la notizia che ha fatto gelare il sangue a parecchi programmatori è stata che la nuova piattaforma di sviluppo sarebbe stata basata su HTML5 e Javascript (e i CSS, ovviamente).

Potete immaginare la valanga di indignazione e le rimostranze di cui è stata oggetto Microsoft, perché giustamente gli sviluppatori hanno visto compromessi anni spesi, oltre che per il lavoro, per l’acquisizione del necessario known-how, richiesto a nuovo cambio di API (dalle famose e sempre presenti Win32 alle ultime WPF ne sono state introdotte diverse).

Personalmente non ho lavorato molto a diretto contatto con le API fornite dalla casa di Redmond, avendo preferito per tanti anni i prodotti della Borland (Delphi in particolare, che le incapsulava nel suo stupendo framework VCL), e con qualche progetto sviluppato per VisualBasic 5 (che incapsulava anch’esso il necessario nei suoi controlli).

Da neo-sviluppatore Windows Phone 7, però, mi sono preoccupato molto. Ho lavorato poco su applicazioni web (celebri in azienda sono quelle “scritte nere su sfondo bianco” facenti uso di HTML puro, con giusto qualche misera riga di Javascript; giusto per rendere l’idea), perché è un settore che non m’è mai piaciuto e, fortunatamente, poche volte mi è stato richiesto di cimentarmi (il fortunatamente è principalmente per i malcapitati utilizzatori delle mie “opere d’arte”).

L’idea di passare ad HTML5 + CSS + Javascript (HCJ per comodità) non mi va proprio giù. Nella maniera più assoluta. Diversi sono i fattori che mi portano a questa presa di posizione (condivisa da tanti altri):

  • ambiente di sviluppo (VisualStudio in generale, e la versione per Windows Phone 7 nello specifico)
  • Silverlight (un sottoinsieme di WPF, Windows Presentation Foundation)
  • .NET (con le sue centinaia di classi a disposizione)
  • C# (per Windows Phone 7; per Windows c’è, oltre a questo, una pletora di linguaggi a disposizione)

Ognuno di questi elementi contribuisce a migliorare la produttività e a rendere decisamente comoda la scrittura del codice e la realizzazione dell’interfaccia utente (per quest’ultima c’è addirittura un’applicazione ad hoc, Expression Blend, che ne permette la progettazione in un ambiente totalmente grafico).

Anche pensando di realizzare un IDE “di spessore” per il nuovo ambiente di sviluppo, non si riuscirebbe in ogni caso a colmare l’enorme gap con quanto disponibile finora. Tra l’altro è anche il motivo per cui Silverlight è nato: offrire un’alternativa allo sviluppo di “Rich Internet Application”, senza quindi passare dalla tripletta HCJ.

Tornare indietro sarebbe, quindi, un clamoroso e inspiegabile (per i programmatori) passo indietro. Un po’ come tornare alla clava primordiale dopo avere imparato a usare arco e frecce.

Non v’è dubbio che Microsoft con Internet Explorer 9 (che sarà integrato col prossimo, corposo, aggiornamento di Windows Phone 7) abbia fatto un ottimo lavoro, mettendo a disposizione un’implementazione di HTML5 (standard ancora da definire, sia chiaro), un nuovo e veloce engine Javascript, ma soprattutto l’accelerazione grafica sfruttando le GPU (che, purtroppo, manca a WPF & Silverlight), ma non è un buon motivo per buttare l’eccellenza di quanto fatto finora e che non trova eguali nella concorrenza.

A confondere ancor di più la situazione è arrivato un altro articolo un po’ di giorni dopo, dov’è saltato fuori che alle Win32 sono state affiancate nuove e potenziate API (WinRT) con nuove funzionalità e miglioramento nella gestione di alcuni compiti delle precedenti, .NET & WPF & Silverlight sono stati aggiornati, ed è, manco a dirlo, spuntata una terza piattaforma chiamata HTA (HTML Application) che consente di sviluppare applicazioni anche con la tripletta HCJ.

Quest’ultima non sarà una Cenerentola, relegata a modesti ambiti, ma a quanto pare è da considerarsi “first class“, al pari delle altre due, tant’è che sarà possibile effettuare chiamate al sistema operativo. e, in generale, uscire dal tipico isolamento in cui vegeta un’applicazione web. Probabilmente HTML e/o Javascript saranno estesi allo scopo, similmente a quanto realizzato da Apple per il suo ecosistema mobile (è possibile scrivere applicazioni in HTMl5, infatti); non sarebbe altrimenti possibile tutto ciò.

Da sviluppatore è una situazione troppo caotica, che mi spiazza. In primis perché, nonostante queste notizie, la dichiarazione di cui parlavo a inizio articolo non è stata smentita tuttora, per cui permane l’idea che .NET & compagnia possano perdere il prestigioso ruolo che faticosamente si sono conquistati finora, a favore del nuovo nato HTA.

Secondariamente, la presenza di tutte queste piattaforme (con Win32 rinvigorita da WinRT) rende più difficile la scelta di quale utilizzare per lo sviluppo di un’applicazione. La difficoltà è dovuta anche al fatto che il tempo a disposizione per acquisire know-how rimane limitato, e padroneggiarle tutte, data anche la vastità di ognuna, non è praticamente possibile.

La mia opinione su HTA è controversa. Da una parte è chiaro che HTML5 e Javascript potranno attirare nuovi sviluppatori, ma vale anche il viceversa: offrire strumenti “standard” potrebbe invogliare ad abbandonare Windows e rivolgere le proprie attenzioni verso altre piattaforme.

L’ago della bilancia sarà rappresentato da quanto Microsoft riuscirà a “imbrigliare” HCJ nel suo ecosistema, ma di sicuro slegarsi da quanto realizzato finora attorno a .NET farebbe perdere parte della propria “identità” a Microsoft, cosa che non reputo sensato ancorché possibile (ma nella vita tutto può succedere).

Attendiamo settembre per vedere se arriveranno finalmente informazioni più chiare sulle piattaforme di sviluppo. I programmatori, si sa, hanno bisogno di certezze per poter lavorare, e al momento la situazione sembra tutt’altro che ben definita…

48 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Valerio
     scrive: 

    Io non vedo problemi, ma solo interessanti novità.
    HCJ relegato allo sviluppo di widget come da windows vista in avanti e nessuno si è mai lamentato.
    Sta per arrivare la più grande novità nel panorama windows dalla sua creazione, ovvero passare Win32 a legacy e sostituirla con WinRT.
    Inoltre :
    “XAML and the WPF-like, Silverlight-like way of developing GUIs are going to be absolutely central to Windows development in the future. Testament to their new importance is a reorganization that occurred at the start of this week. Instead of operating under DevDiv’s roof, the XAML team has been broken into three parts. The group working on XAML and related technology for use in Windows has moved to WinDiv, and the group working on it for Windows Phone, Xbox, and the browser plugin has moved to Windows Phone. Only the group that works on the developer tools—including Visual Studio and Expression Blend—is staying behind in DevDiv. The internal Microsoft e-mail announcing the change notes that the XAML team has been working with the Windows team for the duration of Windows 8’s development; this move simply makes them a formal part of the UI team.”

    Xaml ha un lungo futuro, soprattutto nella forma di silverlight (windows phone, ria/lob) per la maggior parte degli sviluppatori, wpf per quella minoranza di software specifici desktop oriented.
    Nessuno in ms ha chiesto di portare photoshop o autocad in javascript :D

  • # 2
    homero
     scrive: 

    consiglio a cdmauro di vedere il codice di chatzilla scritto in javascript e portatile pratiamente ovunque…..funziona bene e fa il suo dovere…..
    basta vedere adobe che ha messo mano a webkit pur di ottenere applicazioni html5 comparabili con flash…..

    quindi la scelta non è unilaterale ma bilaterale, perchè ovviamente pyton, perl, ribon, ma anche realbasic, e chi piu’ ne ha piu’ ne metta restano fuori da quella che è la patria dell’interpretation mode e dell’open source code……

    io da fun del C e qualche volta del C++ ormai vedo all’orizzonte 2 lineee che correrannoo parallelle, la prima basata sui vecchi sistemi di svilupppo collaudati se ci consentiranno ancora di utilizzarli (su linux sicuramente) e dall’altra HTML5 con javascript in cui si possono programmare una marea di micro applicazioni iphone o winphone che girano su browser etc etc etc…e vendere 0,99 centesimi…..
    il cloud farà il resto….offrendo servizi che a meno di non acquistare un server proprio saranno a pagamento….quindi molte funzioni sarannno possibili esclusivamente server side….
    ora che il quadro ti comncia ad essere chiaro spero che la sua idea sul cluod e su azure cominci a cambiare un pochino….io stesso mi sto adeguando scrivendo applicazioni C-CGI che vengono poi visualizzate ed elaboarate in rete tramite javascript e pagine html+css…..

    esiste un modo per liberarsi di tutto questo?
    attualmente non credo alle rivoluzioni specie quando microsoft+apple+adobe coprono oltre 90% del software web utilizzato dal 90% degli utenti….
    i numeri sono schiaccianti….d’altronde qualcuno ha mai pensato a un pyton plugin da integrare nei browser?

    ormai la strada è segnata dalle corporation e io mi sono già adeguato notando già la classica mancanza di documentazione lacunosa che rallenta lo sviluppo ed una caterva di cose che con html5 non si possono fare……..ma in questo mi viene in aiuto i linguaggi server side php e perl in testa con alle spalle un bel C quando ci vuole il bust di prestazioni e la protezione del codice almeno minima necessaria.

    il futuro lo decidono i programmatori io per scelta non ho mai programmato in .net ed ora scopriamo che .net è stato un aborto….
    non ho mai programato in python e adesso scoprimo che python resterà un linguaggio di secondo piano alla pari di molti linguaggi interpretati…….javascript era il peggiore tra tutti e proprio quello è stato scelto, per il momento mi tengo stretto il C poi tra qualche hanno si vedrà….non è detto che i browser debbbano vivere in eterno….

  • # 3
    richard77
     scrive: 

    Non sono programmatore, ma mi ricordo che quando uscì Win95 i programmi per avere il bollino di compatibilità, dovevano essere testati anche con WinNT (che allora vendeva pochissimo proprio per l’assenza di programmi).

    Ora mi sembra che MS abbia la necessità di spingere la sua proposta per smartphone (mercato in cui soffre la concorrenza Apple in fascia alta, Android in quella medio bassa, e in parte Blackberry in quella aziendale), e forse la mossa di avvicinare/allineare gli strumenti di sviluppo con gli SO desktop (in cui ha il +90% del mercato) è solo una nuova versione della tattica embrace and extend.

  • # 4
    Piotre
     scrive: 

    Per me sono troppo fatalisti su ARS Technica… dopo tutto quello che hanno fatto dal .net 3.5 e 4.0 spingendo forte su XAML e WPF in generale non ci credo che vogliano stringere il passaggio da quella via anche solo di un millimetro

    c’è stato un lavoro faraonico e ben fatto dietro, non si danno colpi di spugna così

    può essere che dal mondo HTA e compagnia bella si aggancino rami interi di API che sono preclusi a chi arriva dal .NET? beh può essere, ma bisogna far la tara anche a cosa si va a fare con questi programmi. può anche essere che la situazione sia temporanea…

    io non ci vedo niente di male nel tenere in piedi una piccola zona franca completamente aliena al .NET e super mutevole in cui lavorare espressamente per web application
    certo che se poi prende piede serviranno i dovuti puntini sulle i, è interesse di MS stessa

  • # 5
    castaldo
     scrive: 

    Finalmente Microsoft non imporrà più strumenti e liguaggi proprietari ma si adeguerà ad usare riconosciuti standard multipiattaforma come Html5 ccs3 e javascript (anche Silverlight e .NET dovevano essere multipiattaforma ma si è visto che fine hanno fatto).
    Per chi sviluppa su smartphone suggerisco di guardare i framework tipo phonegap per lo sviluppo multipiattaforma.
    A chi crede sia la fine dei linguaggi interpretati in particolare python dico solo due cose: Google App Engine e Django

  • # 6
    Valerio
     scrive: 

    Quote homero “il futuro lo decidono i programmatori io per scelta non ho mai programmato in .net ed ora scopriamo che .net è stato un aborto….”

    Non diciamo eresie, nessuno sano di mente si sognerebbe di sostenere una posizione simile.

  • # 7
    Andrea Del Bene
     scrive: 

    Non vorrei sembrare subito troppo caustico, ma non mi sembra una novità il fatto che microsoft confonda gli sviluppatori e cambi le carte in tavola ogni volta che le gira male.
    Lo fa da almeno 10 anni, ossia dalla nascita di .NET, ambiente per il quale quasi ogni nuova versione “ammazza” le precedenti.

    Ma detto questo penso che sulla situazione attuale abbia inciso molto l’evoluzione del mondo client che c’è stata negli ultimissimi anni. Framework come WPF sono nati pensando ai pc con Windows come unico sistema client universale e non si sono posti il problema della portabilità su altri sistemi (anzi!).
    Oggi invece il grosso del mercato delle applicazioni client si sta spostando verso il mobile e lì le interfacce devono essere “portate” almeno in 3-4 sistemi operativi diversi.
    Microsoft per rimanere competitiva ha quindi bisogno di abbracciare un tecnologia client multipiattaforma e che abbia buone probabilità di diventare la tecnologia di riferimento del futuro prossimo.
    Silverlight non è mai diventata una tecnologia main stream e come Flash o JavaFx rischia di essere cannibalizzata da HTML5. Quindi credo che la scelta di abbracciare la terna HCJ sia quasi una necessita per Microsoft e non solo.
    Ciò ovviamente non significa che le altre tecnologie verranno abbandonate, ma è chiaro che quella che è stata la gallina dalle uova d’oro (ossia Windows) non basta più da sola.

  • # 8
    massimo
     scrive: 

    HTML5 + Javascript + (scommettiamo???) SQL.
    Perché cavolo devo usare 3 linguaggi diversi per sviluppare i programmi invece di uno solo, me lo spiegate? Ah e naturalmente come dice homero, anche il C/C++ in una DLL a parte, sottocoperta, quando ci vuole “il burst di prestazioni”… che un codec video in javascript col ca$$o che ce lo implemento… e siamo a quattro.
    Ma a contare non ho finito: i codec video sono oggetti COM, quindi ATL e MFC resteranno in giro anche loro. Un casino.

    Senza contare che in HTML gli errori sono ignorati e il comportamento dei browser quando li trovano non è definito, e questa è una maledizione per chi sviluppa (e una manna per chi scrive malware): se io vedo la schermata HTML5 della mia app su Win8 che esce come dico io, è perché il codice è corretto o perché gli errori non si vedono? E se sul PC del cliente invece si vedranno??? Almeno avessero scelto XHTML che ha una sintassi rigorosa.

    Sono d’accordo che i vecchi linguaggi stile C/C++ da soli non bastano più per i programmi GUI (win, osx, KDE/Gnome ecc.) ma questa è decisamente la strada sbagliata. Imho ma neanche tanto.

  • # 9
    Valerio
     scrive: 

    @Andrea Del Bene

    Silverlight sta invece avanzando moltissimo, sia come base di sviluppatori che come maturità ed innovazione della piattaforma, soprattutto per le applicazioni RIA pesanti, LOB (che stanno spingendo tantissimo) e mobile.
    Sviluppa su Android e poi su Windows Phone per vedere la differenza :D

    Ad ogni scopo il suo strumento, imperativa interoperabilità? => Html.
    Serve una esperienza d’uso più spinta? non puoi battere Silverlight, nè come risultato ne come processo produttivo e manutenzione.
    Devi sviluppare una app desktop con qualche consumo su servizio? Windows app su WPF, devi fare un codec video? c++ e asm e via andare.
    Non esiste uno strumento per fare tutto, ed è giusto che non esista per ora, perchè farebbe tutto ma male :D

  • # 10
    Rocco
     scrive: 

    Microsoft vende SW, e le sue linee di business sono principalmente tre. Windows, Office, e strumenti di sviluppo. Se .NET fosse perfetto, e da sviluppatore credo che stia rasentando tale livello, anche se su alcune cose .net 4 mi fa storcere il naso, a chi venderebbe strumenti di sviluppo ?

    in un esame di economia all’università, il docente ci disse che l’economia ha come scopo di “creare il bisogno di nuovi consumi”

    Microsoft ha imparato molto bene la lezione, e’ maestra nel farlo.
    Ancora una volte confonde le acque, costringe gli sviluppatori ad aggiornarsi, a ri-certificarsi, a comprare nuovi strumenti di sviluppo, a comprare nuovi libri (Microsoft press !!!) ecc…

    E già pletore di manager a fare stime sugli introiti….

    “chi non conosce la propria storia e destinato a ripetersi”
    Microsoft se ne fotte della storia, ripetersi gli porta soldi, tanti soldi.

    Ho buttato via nella mia carriera 5 e forse piu anni di visual basic, vbscript e ASP, dalla 4 alla 6. Poi e’ arrivato .NET e da buon Javista sono passato a C#, poi il susseguirsi di vari framework fino al 4 di oggi, gli ultimi 2 anni di silverlight.
    E forse dovro ancora buttare via tutto o almeno una grossa fetta.

    Bisogna abituarsi a correre, tecnologia e business, tra evoluzioni ed involuzioni, lo fanno da anni.

    comunque non ci vedo niente di nuovo, il solito “liet motif” di Microsoft.

  • # 11
    Z80Fan
     scrive: 

    “offrire strumenti “standard” potrebbe invogliare ad abbandonare Windows e rivolgere le proprie attenzioni verso altre piattaforme.”

    E questo dovrebbe essere un male?
    1) Gli sviluppatori non abbandoneranno mai Windows;
    2) Le applicazioni saranno compatibili anche con altri sistemi.

    Mi sembra una cosa buona (almeno finchè Microsoft non comincia a inserire le sue estensioni proprietarie)

  • # 12
    floc
     scrive: 

    a me invece sembra un’ottima notizia. capisco la frustrazione di chi ha speso tempo e soldi per formarsi, ma ms sta abbracciando standard decismente piu’ interoperabili e questo e’ solo un bene, contrariamente alla chiusura di .net verso la sua piattaforma nativa

  • # 13
    Marco
     scrive: 

    “che un codec video in javascript col ca$$o che ce lo implemento”

    http://blog.nihilogic.dk/2008/04/making-javascript-video-player.html

    E, per i più curiosi:

    http://bellard.org/jslinux/

    Fra non molto, IMHO, anche javascript (che per inciso aborro, date le peculiarità del linguaggio) garantirà prestazioni simili al “codice nativo compilato” (e già ora, giusto per fare un esempio, v8+nodejs forniscono prestazioni superiori alle implementazioni di riferimento di php, python, ruby e perl).

  • # 14
    roberto
     scrive: 

    boh, non so se i vari linguaggi siano “mutually exclusive”…

    nel senso: questo mi pare un “di più” non un “al posto di”

  • # 15
    Cesare Di Mauro (Autore del post)
     scrive: 

    Infatti. :)

    @Valerio: concordo, soprattutto come sviluppatore Windows Phone 7 / Silverlight, con quanto hai scritto. Penso che WPF (e Silverlight) con .NET rappresentino il futuro dello sviluppo dei sistemi Microsoft perché sono strumenti troppo comodi. Dall’altra la nuova piattaforma HCJ ruberà risorse interne all’azienda, e questo potrebbe penalizzare la piattaforma .NET. Le dichiarazioni di quel dirigente, poi, non mi sono proprio andate giù.

    @homero: nonostante l’abbia riletto più volte alla luce dell’articolo, continuo a non capire il senso del tuo commento e come sei arrivato a quelle “conclusioni” (che non sottoscrivo minimamente né mai m’è lontanamente sfiorato nulla del genere). Mi spiace dirtelo, ma Pindaro ti fa un baffo.

    @richard77: non vedo similutudini con l’embrace, extend, extinguish.

    @castaldo: prima di tutto con HTML5 & co. non puoi farci tutto quello che fai con WPF/Silverlight e .NET. Secondo, quel che riesci a fare non lo fai con altrettanta facilità e comodità.

    Riguardo allo sviluppo su mobile, lascia perdere framework come phonegap, per quanto già detto. Tra l’altro i telefonini spesso non hanno a disposizione molte risorse (memoria, CPU, GPU… per chi ce l’ha), e le applicazioni native già faticano a girare: figuriamoci con soluzioni come questa…

    @Andrea Del Bene: .NET è già uno standard da anni, e HTML5 chissà quando sarà approvato. Inoltre puoi portarlo dove vuoi, come dimostra Mono.

    WPF ha il solo “difetto” di non essere diventato uno standard ECMA, ma il team di Mono sta lavorando per integrarlo. L’unico problema qui è il tempo, dovuto al fatto che il team di sviluppo è piccolo, perché di per sé WPF non pone problemi di portabilità.

    Riguardo al mondo mobile, la soluzione migliore è lo sviluppo di applicazioni native, perché i framework universali lasciano molto a desiderare. Una delle poche eccezioni è rappresentata da Unity, ma viene usato soltanto per sviluppare videogiochi.

    @Rocco: se Microsoft dovesse campare coi libri venduti dalla sezione Press, non sarebbe arrivata dov’è ora. Tra l’altro alcuni libri sono pure gratuiti. Ad esempio uno eccezionale (di Charles Petzold) per imparare a sviluppare su Windows Phone 7 lo trovi sul sito in formato PDF, e ti assicuro che vale ogni singola pagina (delle oltre 1000).

    @Z80Fan: le estensioni alla piattaforma HCJ sono state, sono e saranno assolutamente necessarie, come ho già scritto nell’articolo.

    Il motivo è molto semplice: lo standard (quando sarà approvato!) copre soltanto alcune cose / esigenze. Per il resto non soltanto Windows, ma possiamo parlare anche di Windows Phone 7, iOS e Android per il settore mobile, espongono tutti delle API specifiche che… vanno in qualche modo rese accessibili da HCJ per sfruttare le caratteristiche delle piattaforme su cui gira.

    @floc: vedi sopra. A parte questo, .NET non è affatto chiuso. Anzi, è pure uno standard da anni, mentre HTML 5 chissà quando lo diventerà (e non sarà comunque la panacea).

    @Marco: l’accelerazione di Javascript ha fatto enormi progressi, ma non credo che assisteremo a prestazioni comparabili col codice nativo.

    Fra i linguaggi dinamici finora soltanto LUA col suo nuovo compilatore JIT è arrivato a questi livelli, grazie all’estrema semplicità e alle caratteristiche sintattiche del linguaggio. Per gli altri non è ipotizzabile niente di simile.

    Tra l’altro in Javascript nemmeno ha un vero e proprio tipo intero: si usano i double pure per rappresentare gli interi! Anche se internamente coi JIT è possibile ottimizzare ugualmente il codice in molti casi, senza ricorrere ai double, ma ai ben più veloci interi a 32 o 64 bit.

  • # 16
    Marco
     scrive: 

    @Cesare

    “Per gli altri non è ipotizzabile niente di simile.”

    Lo pensavo anch’io… prima di provare V8. Ho visto questo ma in verità, per quanto mi sembri strano, non ho approfondito ulteriormente con dei miei test:

    http://onlinevillage.blogspot.com/2011/03/is-javascript-is-faster-than-c.html

    Il fatto è che, veloce o no, javascript proprio non lo sopporto ;)

  • # 17
    Cesare Di Mauro (Autore del post)
     scrive: 

    E’ un sentimento che condivido. :D

    Quei numeri sono impressionanti, ma è anche vero che quel test è stato fatto apposta per mettere in difficoltà il C (se leggi la documentazione, e dai un’occhiata ai sorgenti). :P

    Comunque non si tratta della norma: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc

    E non penso che la situazione da qui a qualche anno possa migliorare più di tanto. ;)

  • # 18
    Andrea Del Bene
     scrive: 

    @Cesare Di Mauro
    Non metto in dubbio nulla di quello che hai detto ma il punto non è se .NET è portabile o meno o se è meglio o peggio di HTML 5.
    Il mondo sembra viaggiare spedito su HTML 5 (compresa Adobe), Microsoft non dispone di un alternativa valida e altrettanto popolare, ma non può nemmeno restare a guardare e quindi anche lei dovrà adeguarsi alla massa.

  • # 19
    Sergio
     scrive: 

    E’ troppo presto per allarmarsi, bisogna aspettare il Forum Build di Settembre, dove Microsoft scoprirà proprio le sue carte per quel che riguarda la programmazione di Windows 8. Non per niente l’evento è già Sold-Out.

  • # 20
    Valerio
     scrive: 

    @ Andrea Del Bene
    HTML5 non ha padrone, tutti hanno una infrastruttura server che permette di produrre HTML, vedi il fantastico ASP.NET MVC. Il tallone d’Achille di javascript (diciamo nel caso lo si scriva direttamente) per scrivere codice complesso (chissà come mai si chiama *script) è la mancanza di controllo statico del compilatore e della difficoltà di mantenimento del codice nel tempo (passare di mano da uno sviluppatore all’altro per esempio).
    Non a caso google ha uno strumento che permette di sviluppare in java e tradurre poi in javascript, con cui mantiene le sue webapp.
    In caso contrario preferisco lasciare a javascript il suo ruolo di piccoli script (per invocare ajax e jquery :D) e fare il resto con il supporto del compilatore.

  • # 21
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non penso sia la mancanza di controllo statico a livello di compilatore il problema; semmai può essere una delle cause dell’introduzione di bug. Ma non credo sia il più importante, come dimostrano linguaggi come C e C++, che fanno disperare i programmatori con bug subdoli e tante volte difficili da individuare.

    Comunque non voglio addentrarmi in questioni off-topic, e ho già sparato abbastanza su Javascript. :)

    @Andrea: se .NET è molto diffuso in ambito Windows è anche perché risulta molto apprezzato dai programmatori. Che poi tutti su buttino su HTML 5 è da vedere; ad esempio in ambito mobile le rispettive piattaforme native di sviluppo godono di ottima salute, e sono ben distanti da HTML 5.

    Non sono uno sviluppatore web come ho già detto, ma se per il web si sono sviluppate soluzioni alternative qualche ragione ci sarà, non credi?

    @Sergio. Non vedo l’ora!

  • # 22
    Andrea Del Bene
     scrive: 

    @Valerio
    >HTML5 non ha padrone, tutti hanno una infrastruttura server che permette di produrre HTML,

    E questo è per me un grosso punto a suo vantaggio :)

    @Cesare Di Mauro
    Ovvio, i giochi non sono ancora fatti per HTML5, ma quando aziende come Google, Adobe, Facebook ed Apple decidono di investirci è difficile che in futuro non acquisti un ruolo di primo piano.

    >Non sono uno sviluppatore web come ho già detto, ma se per il web si sono sviluppate soluzioni alternative qualche ragione ci sarà, non credi?

    Certo, ma è (anche) per questo motivo che sta nascendo HTML5, per colmare le lacune delle precedenti versioni che richiedevano l’uso di soluzioni alternative.

    Sono sicuro che le piattaforme native saranno utilizzate anche in futuro, ma avendo a disposizione uno strumento che ti permette di scrivere una volta la tua applicazione e farla girare decentemente su tutte le piattaforme (vedi il progetto Jquery mobile), penso che in molti opteranno per questa soluzione.
    E Microsoft non può permettersi di non salire su questo treno.

  • # 23
    Adriano
     scrive: 

    “Quest’ultima non sarà una Cenerentola, relegata a modesti ambiti, ma a quanto pare è da considerarsi “first class“, al pari delle altre due, tant’è che sarà possibile effettuare chiamate al sistema operativo”

    spero che il tutto giri in tripli strati di sandbox perchè vedo rischi alla sicurezza non trascurabili

  • # 24
    Pollo Scatenato
     scrive: 

    I miei 2cents: probabilmente la cosa nasce dalla constatazione che ci sono due macrocategorie di software, che si assomiglano come un razzo a una mela cotogna.

    La prima categoria grossomodo ha bisogno di avere il massimo delle prestazioni usando il minimo delle risorse, e di fare tante cose belle ma pericolose molte delle quali sono il target perfetto per chi scrive malware.
    Gestire l’hardware, rivoltare byte, scrivere file, interagire con i meccanismi di sicurezza del sistema, sono cose che sempre serviranno e per cui i classici linguaggi di programmazione, con tutte le migliorie di sicurezza passiva introdotte nell’ultimo decennio, saranno adatti.

    La seconda categoria non ha bisogno, client side, di niente di tutto questo, per chattare, mostrare foto a bassa risoluzione, giocare ad Angry Birds o (qualcosa)Wars/Ville, scrivere e condividere documenti (la cui sicurezza è nella cloud)…
    Ma sono applicazioni che ultimamente muovono un mercato enorme, perchè piacciono e perchè tutto quello che è online, cioè lontanissimo dal vero possesso dell’utente finale, si presta benissimo a monetizzare con pubblicità o canoni di servizio (nell’ambito professionale) risolvendo in larga parte il problema di incassare il valore delle licenze dei software tradizionali.

    La mossa secondo me vuole corteggiare il secondo tipo di sviluppatori, a cui interessa principalmente avere tempi di sviluppo, test e release più stretti possibile, da qui la scelta di linguaggi più limitati, più semplici, più astratti.

    E’chiaro che sviluppare Photoshop o Crysis o PartitionMagic con questo secondo tipo di approcio non avrebbe molto senso, come non avrebbe senso sviluppare Farmville in C come applicazione rich client.
    Insomma MS sembra avere preso atto di questa che è una delle maggiori dicotomie del mondo dello sviluppo di questi anni è l’ha radicalizzata al massimo, almeno stando ai proclami…

  • # 25
    Gennaro Tangari
     scrive: 

    Io non capisco una cosa: Microsoft si ritrova, a mio parere, il miglior IDE e il miglior framework (.NET) che permettono di sviluppare applicazioni dal mobile all’enterprise. Ha legioni di sviluppatori che già oggi utilizzano questi strumenti e loro se ne escono con un nuovo ambiente i cui vantaggi sono tutti da dimostrare e volente o nolente da un messaggio di sfiducia a milioni di sviluppatori. A che pro?

  • # 26
    homero
     scrive: 

    “ma Pindaro ti fa un baffo.”

    ho scritto quello che sto facendo in questi giorni di ferie per test, ossia programmare applicazioni C-standard ansi CGI che producono a loro volta pagine html5+css+(javascript lo usoin maniera limitata) strutturando l’output a blocchi modulari….
    il lavoro grosso di eleborazione lo fa l’applicazione C mentre le pagine html sono per cosi’ dire il front end dell’applicazioni….questo porta a problemi oggettivi di gestione dei tread perchè per ogni chiamata al server della pagina si apre un tread dell’applicazione cosi’è facile trovarsi con decine di applicazioni aperte quindi di per se la cosa non funsiona tanto oltre a richidere una notevole dose di banda…..ma chiedere ad esempio a javascript di spostare tabelle di migliaia di righe e di riaggiornarle in tempo reale con annessi grafici e quant’altro mi sembra al momento veramente insostenibile….
    a questo punto il vero punto devole che sto notando è proprio apache….che è costretto al super lavoro come ho scritto è un test che sto facendo…..per spostare il front end su browser e lasciare ilkernel dell’applicazione sul server….ma a questo punto hosi cambiano le regole di come vengono trasferite le pagine da e verso i server web oppure il tutto è destinato a naufragare, di scrivere applicazioni solo ed sclusivamente html5+css3+javascript è follia allo stato pure.
    per chi ha usato .net per lavoro cosa dire….poveri voi ma io non vi considero programmatori…..
    per cdmauro….continua ad usare python se ti piace, io ci ho provato ad installare tutto piu’ di una volte sperando che versione dopo versione le cose migliorassero ma come linguaggio proprio non riesco a digerirlo al pari di ruby e java…..
    forse lua ancora ancora ma lo reputo piu’ un esercizio di stile che altro…..
    preferisco essere pindaro lontano da microsoft…..
    e preferisco costruire il mio futuro sulla roccia e non sulla sabbia….

  • # 27
    Valerio
     scrive: 

    @homer
    “per chi ha usato .net per lavoro cosa dire….poveri voi ma io non vi considero programmatori…..”

    “preferisco essere pindaro lontano da microsoft…..
    e preferisco costruire il mio futuro sulla roccia e non sulla sabbia….”

    pardon?

  • # 28
    homero
     scrive: 

    .net era un framework che per chi conosceva o doveva conoscere le api win32 era oltre che superfluo anche scomodo visto che ad esempio per aggiornare un’applicazione su una lan di 48 pc era necessario chiedere l’aggiornamento del framework spesso con problemi di compatiblità con le macchine vecchie ti parlo del 2004 quando mi imbattetti nel .net per cause di forza maggiore…..

    le api win32 sono come una calda coperta che una volta posizionata da le sue belle soddisfazioni al pari delle directx……
    questo per chi programma in windows…..dai tempi di NT…..

    il .net è apparentemente piu’ semplice e veloce ma ad onor del vero quando dovevo programmmare una micro applicazione win32 in un pomeriggio usavo realbasic…..e buona notte….e devo dire che le applicazioni si installano e funzionano alla grande meglio di del .net, e fino ad una certa dimensione non ci si puo’ lamentare specie se devi compilare la medesima cosa anche su linux….

    oggi che mi chiedono che le medesime applicazioni che prima funzionavano su portatile debbano funzionare sul tablet e su iphone……spostare la parte elaboratativa sul server è la prima cosa che mi è venuta in mente…..ma dai primi test il lavoro da fare è enorme e da solo non ce la faccio quindi devo trovare un’alternativa…..ho 2 settimane per pensarci ma credo che tutto passi per la scrittura di un modulo di apache….che io non so fare e quindi è tutto da reinventare…..
    il web2.0 così com’è non funziona….o funziona molto ma molto male…..
    continuo ad usare xhtml+css2.0+ un linguaggio server side perl o php non mi fa molta differenza…..javascript non è il futuro anche se chatzilla scritto in javascript funziona abbastanza bene….
    java non è il futuro per tutti quelli che lo hanno osannnato e fatto studiare all’università….
    qual’è allora il futuro?

    il futuro è quello che i programmatori sceglierannno, i nuovi server cuda con le nuove schede e le nuove librerie di nvidia fanno impazzire molto meno rispetto alle prime versioni e posso dire che sono utilizzabili per alcune tipologie di calcoli sempre su macchine specificatamente configurate,ovviamente linux per varie ragioni…..ed in realtà le gpgpu sono piu’ veloci rispetto a multiprocessor normali il problema grosso cè che bisogna riscrivere integralmente il software da zero e sperare che non bisogna metterci mano ad ogni versione nuova che nvidia produce….quindi la batteria di multicore resta ancora attiva e privilegiata….però nvidia ha fatto un buon lavoro con le sue librerie ci ha messo degli anni pero’ per rendere usabili ai comuni mortali…..

  • # 29
    Valerio
     scrive: 

    @homero
    no comment, il tuo post si commenta da solo, quanta confusione in poche righe, ed evidenzia la bassissima conoscenza del dominio:

    “.net era un framework che per chi conosceva o doveva conoscere le api win32 era oltre che superfluo anche scomodo”

    Questa è effettivamente la più bella, spazzi via 20+ anni di informatica con 3 righe :D
    “ma dai primi test il lavoro da fare è enorme e da solo non ce la faccio quindi devo trovare un’alternativa…..ho 2 settimane per pensarci ma credo che tutto passi per la scrittura di un modulo di apache….che io non so fare e quindi è tutto da reinventare…..”

    “java non è il futuro per tutti quelli che lo hanno osannnato e fatto studiare all’università….”

    Nessuno linguaggio “è il futuro”, ma solo strumenti. Per tua informazione Java è forse il linguaggio più usato al mondo ed esiste da 15 anni, fondamenta di molte aziende leader del settoe IT.

    Non vedo cosa c’entrino le applicazioni di number crunching su gpu con applicativi generalpurpose lob o servizi, tanta fortuna ad implementare una applicazione LOB su di un kernel OpenCL.

  • # 30
    Unrealizer
     scrive: 

    @Cesare Di Mauro
    Mi indichi il titolo del libro di Charles Petzold? non trovo alcun pdf gratuito sotto il suo nome

  • # 31
    Andrea
     scrive: 

    @homero
    Sai solo scrivere parole buttate a caso. Ovvio che non puoi digerire linguaggi tipo java o .net in quanto non saresti in grado di rispettare le semplici regole di un linguaggio oop.

    Comunque vedo molti programmatori paranoici… io dico che se uno sviluppatore nel 2011 non ha ancora visto html, javascript, css ed un linguaggio di programmazione web (c#, php ecc…) dovrebbe avere la decenza di aggiornarsi.

  • # 32
    Andrea
     scrive: 

    Ovviamente spero che l’abbiate capito che questo tipo di sviluppo sarà solo per il nuovo overlay grafico. No perchè mi sembra che molti pensino che l’unico modo di sviluppare un’applicazione su win8 sarà per forza utilizzando html e js.

  • # 33
    Gennaro Tangari
     scrive: 

    @Andrea
    Non credo che si tratti di paranoia: passare da un “ambiente” tipo .NET+Visual Studio (per .NET intendo l’intero “carrozzone”) a HTML5+CSS+JS è qualcosa che sa di “tutto nel passato”, a meno che Microsoft non ci stupisca, per quel che sappiamo ora di HTML+CSS+JS + qualche IDE ancora da vedere, la produttività di .NET resta un miraggio. Senza parlare poi del rischio di grossi investimenti persi per strada (tempo per imparare nuove tecnologie, acquisto di strumenti di sviluppo, certificazioni varie…)

    Io continuo a sperare che, il nuovo ambiente “web oriented” sia nient’altro che lo strumento che permette di giocare con i Tile …

  • # 34
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Unrealizer: http://www.charlespetzold.com/phone/ qui trovi tutto, sia il PDF che gli esempi.

    Ovviamente e nonostante le più di 1000 pagine, non copre tutto lo scibile su Silverlight, XNA, e .NET, ma ti spiega le cose più importanti per essere produttivo in poco sia per sviluppare applicazioni che giochi. Un must, da leggere assolutamente (magari proponendosi di realizzare un progettino nel frattempo, in modo da sperimentare).

    @homero: per lo meno adesso ti sei spiegato, ma continuiamo a pensarla molto diversamente. Io vedo i linguaggi, le librerie, i framework, come strumenti che hanno pregi e difetti, per cui scelgo quelli che mi permettono di risolvere i miei problemi col miglior compromesso possibile.

    Dunque uso Python quando posso (perché lo trovo favoloso: semplice, elegante, con un’ottima libreria, e… altamente produttivo e manutenibile), ma anche C#, C, Java, Objective-C, assembly, ecc. E se dico “quando posso” è perché tante volte non posso scegliere, ma vado avanti lo stesso.

  • # 35
    mail9000
     scrive: 

    @massimo
    [Quote=massimo]…io vedo la schermata HTML5 della mia app su Win8 che esce come dico io, è perché il codice è corretto o perché gli errori non si vedono?…[/Quote]

    Non esageriamo.
    Un sviluppatore “DEVE” installare i plugin di sviluppo per il suo browser e sono questi a segnalare la presenza di eventuali errori HTML5 nella app.

  • # 36
    Piotre
     scrive: 

    Massimo: “…io vedo la schermata HTML5 della mia app su Win8 che esce come dico io, è perché il codice è corretto o perché gli errori non si vedono?…”

    mail9000: “Non esageriamo.
    Un sviluppatore “DEVE” installare i plugin di sviluppo per il suo browser e sono questi a segnalare la presenza di eventuali errori HTML5 nella app.”

    ecco… mail9000, quello che tu dici è quello che fa un BUON programmatore oggi. chi è un buon programmatore tuttavia spesso non li ha mai incrociati i cattivi programmatori della nuova generazione. non mi riferisco a te, dico in generale per la mia esperienza.
    io adoro la sconfinata astrazione con cui abbiamo a che fare oggigiorno, sia chiaro, la trovo pratica, garantisce tempi di lavoro relativamente stretti e, soprattutto, dà la possibilità di fare previsioni ragionevolmente precise sulla complessità del lavoro da affrontare.
    MA, prima o ti “comportavi bene” od il software non lo piazzavi… oggi puoi anche fare porcate, tanto se produci front-end web/html qualcosa a schermo ti finisce certamente. una volta che raggiungi un risultato funzionale ai tuoi scopi lo molli lì, ti fai un css che aggiusta le cose per questo quello e quell’altro browser e buonanotte.
    voglio dire… quando ha preso piede la programmazione oop in fase di debug ci dovevi stare attento a leak, porcherie non rilasciate, ridondanze inutili, avevi limitazioni hardware che te lo imponevano e l’abitudine a farlo. se lavori oggigiorno in html certo che puoi lavorare bene… ma puoi anche lavorare male, e nessuno se ne accorge. è una situazione che porta forse vantaggio oggi… ma se non si parte col piede giusto i nodi prima o poi verranno al pettine

  • # 37
    Emanuele
     scrive: 

    Tutto questo non spaventa nessuno, HTA per esempio esisteva sin dai tempi del lancio di Windows XP (2001)

    Se ci fate caso, tutti i pannelli di controllo web based di Windows XP erano già delle hta, per controllare questo, basta cercare tutti i file .hta all’interno del sistema, li vedrete spuntare come funghi

    di fatto penso che l’accoppiata html5, js e css sia solo un altro modo di sviluppare per windows, e nessuno si deve preoccupare più di tanto

  • # 38
    frank2tek
     scrive: 

    Io credo che la scelta di andare verso le interfacce grafiche basate su htlm , css e js sia la soluzione migliore. In futuro, le applicazioni saranno sempre più SOA ( Service-Oriented Architecture )e cioè la computazione verrà getita in cloud sotto forma di servizi. Come molti sparanno , i RESTFul service sono sempre più utilizzati ( ne fanno uso ormai i più grandi social netwok che mettono a disposizione le “comodissime ed efficentissime” REST API ) e danno la possibilità di retituire i dati in qualsiasi tipo di formato. In particolare JSON che ripestto all’xml ( che sta alla base degli ormai “vecchi” servizi SOAP ) ha meno payload e si integra perfettamente con il javascript( JSON = javascript object Notation ). A questo punto viene quasi spontaneo utilizzare l’html ( soprattutto considerando le enormi potenzialità dell’ html5 unito al CCS3 ) come puro strumento per creare le interfacce che hanno il solo compito di “visualizzare” i dati forniti dai servizi web. Stiamo assistendo a una sempre maggiore separazione tra client e server e questo è solo un fatto positivo. Non è un caso che i browser stiano diventando strumenti sempre più complessi sfruttando la poteneza delle schede video per l’accelerazione hardware nel rendering degli elementi html. Usare il WPF ( e quindi XAML ) è sempre meno conveniente. Anche Adobe sta percorrendo rapidamente la strada dell’ html5 e del ccs3 ;-)

  • # 39
    massimo
     scrive: 

    @mail9000
    D’accordo, esempio infelice. Resta però il fatto di usare N linguaggi diversi, i tre del web più altri che saranno necessari di volta in volta a seconda del tipo di applicazione e delle esigenze che ha. IMHO non è giustificato, tanto più che il javascript usato NON sarà standard, a meno di non voler mettere nello standard tutte le estensioni necessarie per esporre le API di win8, quindi l’app non sarà comunque portabile.

    Riflettendo meglio su tutta la questione, io la vedo come il tenmtativo di vendere dei nuovi strumenti di sviluppo, in aggiunta ai vari Visual studio, che ovviamente DOVRANNO essere sul PC di chiunque programma per professione. E in questo numero ora sarà compreso anche chi fa pagine web: la venderanno come l’occasione per fare il salto da semplice webmaster a sviluppatore “vero”.

    Ho come il sospetto che a settembre M$ svelerà una nuova versione di visual studio… magari lo chiameranno Visual Web Studio.
    Mi chiedo com’è andata finora la commercializzazione di VS2010: secondo me, non bene quanto pensavano loro… in effetti c’è parecchia gente che usa ancora VS2008 e ne è pienamente soddisfatta.

  • # 40
    massimo
     scrive: 

    @frank2tek
    Mi hai dato, senza volerlo, la dimostrazione di quanto sostengo: è meglio usare meno linguaggi possibile. Visto che javascript è uno standard e ha un modo standard di trasmettere dati, usare XML per farlo è di fatto inutile, per cui con il tempo JSON sta soppiantando XML in quest’uso.

    E’ parzialmente vero che i browser stanno diventando sempre più delle macchine virtuali in cui eseguire software, delle sandbox insomma, ma non sono in grado di soppiantare tutte le esigenze di elaborazione di un utente, a meno di non diventare uno strato sottilissimo sopra un sistema operativo sempre più ottimizzato verso di loro… magari sarà così nel futuro, ma non ora. Almeno, non nei prossimi 5 anni, diciamo.
    Senza contare che il cloud è utile, certo, ma ha dei limiti precisi, per cui si affiancherà al modello di uso tradizionale basato su app native, ma non lo soppianterà mai veramente, IMHO.

  • # 41
    Marcello
     scrive: 

    Sinceramente non vedo il problema per una volta che MS ha deciso di utilizzare uno standard libero e non controllato da lei per lo sviluppo.

    Ci si preoccupa dell’ambiente di sviluppo che non c’è? Beh, ma secondo voi MS basa tutto lo sviluppo di buona parte delle applicazioni del suo nuovo SO su una tecnologia che non supporterà?

    Secondo me nel nuovo Visual Studio vedremo il supporto a un ambiente di sviluppo JS+HTML5

  • # 42
    Cesare Di Mauro (Autore del post)
     scrive: 

    Anche quando ci sarà, non sarà comodo e produttivo come quelli sviluppati per WPF/Silverlight & compagnia.

  • # 43
    Marcello
     scrive: 

    E perchè dici così? Quando sono uscite fuori Silverlight e le WPF non c’era nessuno strumento creato per queste due piattaforme visto che erano nuove, nessuno si è lamentato mi sembra. Se Microsoft ha intenzione di supportare JS dovrà per forza creare degli strumenti di authoring all’altezza, sennò non sarà un problema di JS o HTML5, ma di Microsoft. Mi aspetto anche che porterà buona parte delle proprie API su JS per l’occasione, in modo da accedere al sistema operativo attraverso quelle e anche un binding delle DX per contrastare WebGL. Inoltre le JS esistono da molto tempo e c’è tanto di quel materiale e librerie da poter usare insieme ad esse che sicuramente la piattaforma ha un vantaggio di partenza ben superiore a Silverlight quando è uscito. E l’interoperabilità eventuale con il Web usando JS sarebbe molto superiore rispetto a Silverlight considerando che quest’ultimo ha avuto un successo piuttosto limitato.

  • # 44
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non è dal successo che si può giudicare la bontà di un prodotto (a meno che non parliamo di marketing).

    Dalla mia esperienza penso che, per quanto si possa realizzare un IDE molto valido per HCJ, non credo che potrà mai competere con quanto Microsoft mette a disposizione per WPF/Silverlight.

    Just my 2 cents.

    Riguardo all’interoperabilità non è certo l’uso di JS che risolve il problema, visto e considerato che già adesso le implementazioni non sono tutte le stesse. La situazione non può che peggiorare se Microsoft, com’è ovvio e giusto che sia, aggiungere API apposite per poter sfruttare quelle della sua piattaforma.

  • # 45
    Marcello
     scrive: 

    Non mi sono mai sognato minimamente che Microsoft avesse intenzione di migliorare l’integrazione della propria piattaforma con quella degli altri (ossia che applicazioni MS o librerie potessero girare sugli altri sistemi), ma più che altro intendevo l’integrazione delle librerie degli altri nel proprio sistema (per quello problemi non ce ne dovrebbero essere).

    Per l’IDE … sinceramente non capisco da dove deriva il tuo dubbio. L’IDE lo fa sempre la microsoft no? La API da allegare a Javascript sarà anch’essa ideata da quest’ultima. Cosa ti fa pensare che non riusciranno a fare il buon lavoro che hanno fatto con Silverlight?

    Ciao

  • # 46
    Cesare Di Mauro (Autore del post)
     scrive: 

    Primo perché Microsoft ha già realizzato strumenti per lo sviluppo web, ma non raggiungono la comodità di Silverlight.

    Secondo proprio perché Silverlight è nato per realizzare RIA… senza far uso di HTML & compagnia, e permette di farlo in maniera molto produttiva (e appagante).

    Silverlight, peraltro, è una costola di Windows Presentation Foundation: uno strumento certamente non nato per uso web, ma che è stato possibile adattare allo scopo perché si tratta di una soluzione ad hoc che viene caricata come componente (adesso non ricordo se è un ActiveX o qualcosa di simile).

    Dunque permettimi di rimanere fortemente scettico. HCS farà strada, senza dubbio, ma saranno altri gli strumenti a rendere la vita più semplice agli sviluppatori.

  • # 47
    Dany
     scrive: 

    http://stadium.weblogsinc.com/engadget/files/Windows_Developer_Preview-Windows_8_guide.pdf

    “Windows Metro style apps using JavaScript leverage the combination of HTML5 and CSS3 to build the user interface, along with JavaScript for app logic. Windows Metro style apps using C++, C#, or Visual Basic use XAML markup for the user interface, with C++, C#, or Visual Basic for app logic. Game developers can build Metro style games using C++ and DirectX 11.1 to take full advantage of graphics hardware, or build casual games
    using HTML5 or XAML. ”

    Quindi si potrà usare tutto quello che ci pare.

  • # 48
    Cesare Di Mauro (Autore del post)
     scrive: 

    La mia preoccupazione è il fatto che stia tutto sopra WinRT. .NET mi sembra che viva di luce riflessa (quella di WinRT, appunto).

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.