Google komt met Native Client-sdk
Google heeft een sdk voor Native Client uitgebracht. Ook zit de software in de laatste bèta van Chrome. Met Native Client kunnen ontwikkelaars gecompileerde code in een webbrowser laten draaien, met snelheidswinst tot gevolg.
Aan de opensource-Native Client wordt al sinds 2008 gewerkt. Het moet ontwikkelaars de mogelijkheid bieden om, in tegenstelling tot javascript, native x86-code te laten draaien in onder andere de Chrome-browser van Google. Dit kan zowel op 32bit- als 64bit-besturingssystemen. Door het draaien van native code kunnen de prestaties van webapplicaties en -games flink verbeteren. Native Client wordt op termijn ook geschikt gemaakt voor het draaien van native code op ARM-processors.
Native Client is inmiddels opgenomen in de bèta van Chrome 10, zo meldt Christian Stefansen, product manager bij Google. In Native Client zijn diverse veiligheidsmechanismen ingebouwd die het uitvoeren van kwaadaardige code in de browser moeten verhinderen, waaronder een sandbox en een auto-updatesysteem, zo stelt Google.
De zoekgigant spoort ontwikkelaars die in C of C++ programmeren nu aan om webapplicaties te bouwen met de nieuwe sdk. Native Client ondersteunt onder andere audiobewerkingen en 2d-versnelling; api's voor onder andere 3d-graphics, p2p-communicatie en local storage moeten in de komende maanden beschikbaar komen.
Reacties (49)
ActiveX, maar dan beter?
en Java, en flash/air.
Ik dacht dat we juist af wilden van die vendor-lockin dingen, en webapplicaties gingen bouwen.
Bovendien komt wegens privacy issues software van google toch echt m'n systemen / netwerken niet in.
Ik dacht dat we juist af wilden van die vendor-lockin dingen, en webapplicaties gingen bouwen.
Bovendien komt wegens privacy issues software van google toch echt m'n systemen / netwerken niet in.
Als je de moeite neemt door te klikken naar een van beide links, zul je zien dat het open source technologie en een open standaard is. De bedoeling is dat alle partijen hiermee kunnen werken. Het zou voor Google zelfs ronduit onlogisch zijn om het gebruik te beperken tot hun eigen omgeving.Ik dacht dat we juist af wilden van die vendor-lockin dingen
Beetje jammer alleen dat je hierdoor weer voor elke architectuur/ABI weer binaries moet genereren, en ik zie het al gebeuren dat men dat alleen voor LLP64 x86-64 en ILP32 x86 gaat doen (lees: Windows). Het web zou juist platformonafhankelijk moeten zijn.
When in doubt, check the source.
Daar wordt duidelijk gesproken over Linux, Darwin en Windows (Windows cygwin om precies te zijn).
Ik zie ook helemaal geen reden waarom dit platform-afhankelijk zou moeten zijn; de makkelijkste manier om een sandbox te maken is om rechtstreekse calls naar het OS botweg te blokkeren en alles via je eigen code door te sturen (die, na security checks, alsnog OS calls kan doen, maar dan zit je in de browser zelf en die code is toch al anders per OS).
Daar wordt duidelijk gesproken over Linux, Darwin en Windows (Windows cygwin om precies te zijn).
Ik zie ook helemaal geen reden waarom dit platform-afhankelijk zou moeten zijn; de makkelijkste manier om een sandbox te maken is om rechtstreekse calls naar het OS botweg te blokkeren en alles via je eigen code door te sturen (die, na security checks, alsnog OS calls kan doen, maar dan zit je in de browser zelf en die code is toch al anders per OS).
Geen FreeBSD, geen NetBSD, geen OpenBSD, geen DragonFly BSD, geen Solaris, geen HP-UX, geen AIX, geen Tru64, geen IRIX, geen OpenVMS, geen OS/2, geen VxWorks, geen GNU/Hurd, enz. En ook, geen PowerPC, geen MIPS, geen ARM (alhoewel ze aangekondigd hebben dat wel toe te gaan voegen), geen MicroBlaze, geen VAX, geen Alpha, geen IA-64, geen AVR, geen PA-RISC, geen m68k, etc. En dan dus wat ik al eerder noemde, dat er zelfs op dezelfde instructieset meerdere verschillende ABI's gebruikt kunnen worden voor dezelfde programmeertaal. Denk bijvoorbeeld aan LP64 versus LLP64, of calling conventions voor C code (welke registers moet je saven, welke kan je clobberen, etc).
Dit is allemaal wel in de SDK te verwerken tezijnertijd, maar waar ik in mijn post het meest op doelde is dat ik zie dat bedrijven die deze SDK gaan gebruiken simpelweg de moeite niet zullen nemen om voor alle mogelijke platformen binaries te genereren. En dat is ook heel begrijpelijk verder, maar dat doet dus afbreuk aan de platformonafhankelijkheid die het web traditioneel hoort te hebben.
Dit is allemaal wel in de SDK te verwerken tezijnertijd, maar waar ik in mijn post het meest op doelde is dat ik zie dat bedrijven die deze SDK gaan gebruiken simpelweg de moeite niet zullen nemen om voor alle mogelijke platformen binaries te genereren. En dat is ook heel begrijpelijk verder, maar dat doet dus afbreuk aan de platformonafhankelijkheid die het web traditioneel hoort te hebben.
Maar wel weer een zogenaamde nieuwe standaard... Binnenkort kunnen we het web wel compleet weggooien om alles in al die nieuwe standaarden opnieuw te bouwen... en zoals 10 jaar terug werkt dan alles weer alleen in specifieke browsers en/of op specifieke devices.
Alles wordt weer heerlijk incompatible van al die nieuwigheid waarbij de maker alleen aan zichzelf denkt...
Alles wordt weer heerlijk incompatible van al die nieuwigheid waarbij de maker alleen aan zichzelf denkt...
In jou linux (of bsd) systemen zit ook code die google gedoneerd heeft, dus wat dat betreft zou het me niet verbazen als je al software draait die van google afkomstig is.Bovendien komt wegens privacy issues software van google toch echt m'n systemen / netwerken niet in.
in ieder geval nieuwer en open. Of het ook daadwerkelijk beter zal zijn moet nog blijken. Als we straks weer verwend worden met van die irritante nag-screens e.d. dan voelt het weer alsof we in 2006 aanbeland zijn ;-)
Ik zie in iedergeval, mits goed uitgewerkt, een aantal zeer mooie mogelijkheden! Javascript is de laatste jaren dan wel wat meer volwassen geworden en computers zijn tegenwoordig krachtig genoeg om flinke lappen aan javascript code goed te kunnen uitvoeren, maar ik heb nog regelmatig problemen wanneer ik bijvoorbeeld een kaar met alle wijkcentrales in een keer wil tonen. Nou zijn daar ook wel weer truukjes voor te verzinnen, maar dat zou niet nodig zijn indien de viewer in native code geschreven kan worden.
ik ben benieuwd :-)
Ik zie in iedergeval, mits goed uitgewerkt, een aantal zeer mooie mogelijkheden! Javascript is de laatste jaren dan wel wat meer volwassen geworden en computers zijn tegenwoordig krachtig genoeg om flinke lappen aan javascript code goed te kunnen uitvoeren, maar ik heb nog regelmatig problemen wanneer ik bijvoorbeeld een kaar met alle wijkcentrales in een keer wil tonen. Nou zijn daar ook wel weer truukjes voor te verzinnen, maar dat zou niet nodig zijn indien de viewer in native code geschreven kan worden.
ik ben benieuwd :-)
Inderdaad Javascript is flink verbeterd de laatste jaren simpel weg door steeds een stapje verder te gaan in de optimalisatie van de VM waar binnen het zich begeeft. Maar dat kun je niet blijven doen op een gegeven moment kom je toch echt tegen een probleem aan. Immers de code die je leest moet je nog steeds interpreteren en dat kost nu eenmaal tijd in computer termen veel tijd.
Als je native kunt werken dan hoef je die tijd niet te besteden en kun je gebruik maken van de volle kracht van de lokale computer. Dit kan ook voor problemen zorgen immers je zult nu rekening moeten gaan houden met welke computer er aan de andere kant staat. Als dat een mobile telefoon is dan heb je ARM code nodig als het een oude pentium is dan kun je geen SSE gebruiken en als het een nieuwe AMD chip is dan heb je weer andere instructies. Je moet dan dus je pagina gaan compileren voor elke architectuur aan de andere kant van het draadje iets wat dus automatisch veel veel werk betekend en veel mogelijkheden tot rare bugs die je niet zou tegen komen als je gewoon met Javascript werkt.
Ik weet het zo net nog niet met deze techniek...
Wat betreft de truckjes die je noemt pas ze gewoon toe en maak daarna pas gebruik van native code als het dan nog steeds niet werkt. Gewoon het probleem op lossen door er meer hardware tegen aan te smijten is geen oplossing. Immers je kunt er niet van uit gaan dat iedereen maar een beter systeem aanschaft als jij besluit naast de wijkcentrales ook de signaal sterkte en de groep kasten te tonen...
Programmeren is niet code zo schrijven dat je met een krachtige machine het allemaal goed kunt zien maar juist de code zo opbouwen dat je met alle machines de data zo goed mogelijk kunt zien als mogelijk is met die hardware.
Als je native kunt werken dan hoef je die tijd niet te besteden en kun je gebruik maken van de volle kracht van de lokale computer. Dit kan ook voor problemen zorgen immers je zult nu rekening moeten gaan houden met welke computer er aan de andere kant staat. Als dat een mobile telefoon is dan heb je ARM code nodig als het een oude pentium is dan kun je geen SSE gebruiken en als het een nieuwe AMD chip is dan heb je weer andere instructies. Je moet dan dus je pagina gaan compileren voor elke architectuur aan de andere kant van het draadje iets wat dus automatisch veel veel werk betekend en veel mogelijkheden tot rare bugs die je niet zou tegen komen als je gewoon met Javascript werkt.
Ik weet het zo net nog niet met deze techniek...
Wat betreft de truckjes die je noemt pas ze gewoon toe en maak daarna pas gebruik van native code als het dan nog steeds niet werkt. Gewoon het probleem op lossen door er meer hardware tegen aan te smijten is geen oplossing. Immers je kunt er niet van uit gaan dat iedereen maar een beter systeem aanschaft als jij besluit naast de wijkcentrales ook de signaal sterkte en de groep kasten te tonen...
Programmeren is niet code zo schrijven dat je met een krachtige machine het allemaal goed kunt zien maar juist de code zo opbouwen dat je met alle machines de data zo goed mogelijk kunt zien als mogelijk is met die hardware.
Vroeg of laat komt er ongetwijfeld een compiler die in 1 klik alle beschikbare architectures voor je doet.
FYI:
Die cross compilers bestaan er allang, GCC kan dat al en Apple maakt daar dankbaar gebruikt van Als je een programma voor een apple schrijft kan dat native op zowel PowerPC en op Intel architecturen draaien.
Zie: http://en.wikipedia.org/w...GCC_and_cross_compilation
Die cross compilers bestaan er allang, GCC kan dat al en Apple maakt daar dankbaar gebruikt van Als je een programma voor een apple schrijft kan dat native op zowel PowerPC en op Intel architecturen draaien.
Zie: http://en.wikipedia.org/w...GCC_and_cross_compilation
JIT compiling kost helemaal niet zo enorm veel tijd, en kan zich prima meten met native gecompileerde apps. Kijk maar naar Java en .Net. Het performanceprobleem van javascript zit 'm echt niet in het feit dat het geïnterpreteerd wordt, maar juist omdat de taal zo enorm dynamisch is. Elk object is feitelijk gewoon een geassocieerde datastructuur, en je kunt op elk moment properties en functies (in JS feitelijk dezelfde dingen) toevoegen en reassignen. Hierdoor is static linking niet meer mogelijk. In C++ weet de compiler dat als je object->member doet, dat 'member' op een vaste offset staat vanaf het beginadres van 'object' - in JS moet je naar 'member' gaan zoeken in 'object', en als die niet wordt gevonden dan moet je in de prototype van 'object' kijken, en dan weer in de prototype daar weer van, etc., en dit allemaal @ runtime. Plus het feit dat het niet sterk is getypeerd, bij iets als 'a+b' weet de compiler in C++ precies wat ie moet doen, maar in JS zal at runtime eerst naar de typen van a en b gekeken moeten worden of het bijv. een optelling van getallen of een string concatenatie is.Immers de code die je leest moet je nog steeds interpreteren en dat kost nu eenmaal tijd in computer termen veel tijd.
[Reactie gewijzigd door .oisyn op maandag 21 februari 2011 12:52]
ActiveX was een raamwerk welke juist programmeertaal onafhankelijke functionaliteit gaf. Google geeft je nu de mogelijkheid om native C/C++ code te kunnen draaien. Dat is dus wel ff wat geavanceerder dan bagger ActiveX.
[Reactie gewijzigd door bobwarley op maandag 21 februari 2011 09:01]
uhmm.. juist omdat ActiveX programmeertaal onafhankelijk was, was het geavanceerder dan deze native SDK.. Het concept van ActiveX is gewoon perfect, de uitwerking kan alleen iets beter.. In principe is deze native sdk niets anders dan een nieuwe versie van ActiveX..
Het concept om met add-ons te werken die dezelfde rechten krijgen als de browser zelf is allerminst perfect. Of deze ontwerp-beslissing zich in het domein van "concept" of "uitvoering" bevindt is een semantische discussie, maar we kunnen het er wel over eens zijn dat sandboxing per definitie veiliger is.
Toen ActiveX werd ontwikkeld, was men nog niet zo ver met de softwareconcepten dus Microsoft valt niet zo veel te verwijten. Ze hebben onbedoeld het kwetsbare oppervlakte vergroot. De verschillen zijn in ieder geval wel principieel, maar ik ben het met je eens dat een programmeertaal onafhankelijke oplossing leuker geweest zou zijn.
Toen ActiveX werd ontwikkeld, was men nog niet zo ver met de softwareconcepten dus Microsoft valt niet zo veel te verwijten. Ze hebben onbedoeld het kwetsbare oppervlakte vergroot. De verschillen zijn in ieder geval wel principieel, maar ik ben het met je eens dat een programmeertaal onafhankelijke oplossing leuker geweest zou zijn.
ActiveX had een "paar" veiligheidsrisico's maar was in feite natuurlijk een stuk flexibeler dan een tool die enkel een beperkte subset van de beschikbare functionaliteiten op het intel platform weergeeft. Nee, geavanceerder is het niet, wel (hopelijk) veiliger.
Maar in feite wil je dit natuurlijk helemaal niet. Web gebaseerde code moet gewoon op elke computer draaien. Of dat nu een ARM, Itanium, Power 7 of intel x86 processor bevat. Laten we hopen dat het geen succes wordt.
Maar in feite wil je dit natuurlijk helemaal niet. Web gebaseerde code moet gewoon op elke computer draaien. Of dat nu een ARM, Itanium, Power 7 of intel x86 processor bevat. Laten we hopen dat het geen succes wordt.
Zoiets. In principe is het besturingssysteem verantwoordelijk voor het scheiden van programma's. Indien het besturingssysteem erin voorziet code in een afgeschermde omgeving te draaien is er geen enkele reden voor gevirtualiseerde machines zoals Java en .NET bieden.
De fout die ActiveX maakte was dat ActiveX-controls rechtstreeks toegang hadden tot de WIndows-API, waarmee veel gevaarlijke dingen mogelijk zijn. De veiligheid zat 'm bij ActiveX vooral in het digitaal ondertekenen van de plugins, zodat je alleen "vertrouwde plugins" gebruikte. Dat is erg zwak gebleken.
Als je de x86-code op een degeleke manier af kunt schermen van de normale API's, is er geen reden om geen x86-code vanuit de browser toe te staan. Het nadeel is de processorafhankelijkheid van x86-code, maar dat is een afweging die aan een webontwikkelaar overgelaten kan worden.
De fout die ActiveX maakte was dat ActiveX-controls rechtstreeks toegang hadden tot de WIndows-API, waarmee veel gevaarlijke dingen mogelijk zijn. De veiligheid zat 'm bij ActiveX vooral in het digitaal ondertekenen van de plugins, zodat je alleen "vertrouwde plugins" gebruikte. Dat is erg zwak gebleken.
Als je de x86-code op een degeleke manier af kunt schermen van de normale API's, is er geen reden om geen x86-code vanuit de browser toe te staan. Het nadeel is de processorafhankelijkheid van x86-code, maar dat is een afweging die aan een webontwikkelaar overgelaten kan worden.
Yes. We krijgen nu eindelijk een versmelting van WebApps en NativeApps =) WebApps maar dan met de performance van native apps.
[Reactie gewijzigd door bobwarley op maandag 21 februari 2011 08:56]
Alleen webapps draaien wel op alle platformen die de laatste browsers ondersteunen, deze apps draaien alleen op de platformen waar de apps voor geschreven zijn...
En native apps met de hoeveelheid virussen en trojans van webapps. Dit worden zoveel overuren voor de virusscanner dat ik gok dat er netto weinig van die performance boost overblijft.
Indeed.Yes. We krijgen nu eindelijk een versmelting van WebApps en NativeApps =) WebApps maar dan met de performance van native apps.
Dat is precies wat Google wil.
Web Apps die niet meer te onscheiden zijn van native apps.
Geen Microsoft meer nodig. Geen Citrix.
Webapplicaties voor (bijna) alles.
Zeg dan maar ActiveX 2. Of de volgende versie van Flash. Een systeemafhankelijke taal op het web - het maakt niet uit welke reincarnatie van of variant op het onzalige ActiveX (hoe heette die allereerste implementatie van MickeySoft ook al weer? Voordat het ActiveX heette. Iemand?) het is en blijft een slecht idee.
De Java weg zie ik nog steeds als de juiste. En met een klein beetje meer ondersteuning zou dit zoveel kansen hebben.
De Java weg zie ik nog steeds als de juiste. En met een klein beetje meer ondersteuning zou dit zoveel kansen hebben.
OLE 2.0, als ik me niet vergis.Voordat het ActiveX heette. Iemand?
Die kansen zie ik tegenwoordig steeds kleiner worden met Oracle nu aan het roer van Java. Tevens ben ik nooit een grote fan geweest van Java, veel te log en de VM's waren vaak veel te traag. Tevens zijn het meestal flinke CPU/geheugen intensieve processen wat dan weer nergens voor nodig is.De Java weg zie ik nog steeds als de juiste. En met een klein beetje meer ondersteuning zou dit zoveel kansen hebben.
Dat ligt waarschijnlijk aan de code dan, vermoed ik. Wij beheren hier talloze sites die op Java draaien, en behoorlijk hoog-volume sites bovendien, en de CPU usage is niet bepaald ernstig te noemen.Tevens zijn het meestal flinke CPU/geheugen intensieve processen wat dan weer nergens voor nodig is.
sites die op java draaien of java applets?Wij beheren hier talloze sites die op Java draaien
Ik ging er in bovenstaande post vanuit dat het om applets ging. Sites draaiende op java zijn stukken efficienter. Jullie servers zullen tevens ook geoptimaliseerd zijn voor Java, iets wat client computers vaak niet (goed) zijn.
Applets zijn wat mij betreft ook vrij kansloos. Het duurde altijd gewoon veel te lang voordat je een response zag. Tevens is het door de krachtiger javascript oplossingen van tegenwoordig ook niet nodig om een Applet te bouwen.
Ik zou dan persoonlijk niet kiezen voor native code, maar iets als llvm bytecode (http://www.llvm.org). En dan JIT op de client kant compileren.
Maar goed, zoiets kan met .net of flash ook. Nieuwe ronde wielen uitvinden dus.
Maar goed, zoiets kan met .net of flash ook. Nieuwe ronde wielen uitvinden dus.
maar zijn minder krachtige mobieltjes daar krachtig genoeg voor? Lijkt me dat een Nokia 3310 bij wijze van uiteraard wel native code kan draaien , maar is zo'n mobieltje ook snel genoeg voor jit-compilers/interpreters?
[Reactie gewijzigd door bobwarley op maandag 21 februari 2011 09:08]
Ja, is goed punt. Meeste optimalisaties doe je voor je naar bytecode compileert, maar er zijn wel degelijk nog wel optimalisaties die je daarna wil doen. Ik denk echter dat je wel een redelijk eind komt. Ik zie het dan ook niet zo zeer voor een nokia 3310, maar meer voor de smartphones die nu al rond de ghz draaien.
Maar blijkbaar is het al mogelijk om met llvm flash bytecode te maken, zie:
http://labs.adobe.com/technologies/alchemy/. Lijkt me dan toch wel een betere en veiligere oplossing dan domweg native code van het web te gaan runnen, zonder enige controle van de code.
Maar blijkbaar is het al mogelijk om met llvm flash bytecode te maken, zie:
http://labs.adobe.com/technologies/alchemy/. Lijkt me dan toch wel een betere en veiligere oplossing dan domweg native code van het web te gaan runnen, zonder enige controle van de code.
Tsja, maar de optimalisaties die je daarna nog doet zijn weer erg generiek omdat je de hardware waarop het uiteindelijk draait niet kent. Een JIT compiler kan dus weer meer optimalisaties toepassen dan een statische compiler. "Een eind komen" is dus een understatement (mits er natuurlijk een JIT compiler is en die nadenkt over de exacte hardware eigenschappen) Je kan verder komen dan met native code 
@barfieldmv: Daar heb je nu waarschijnlijk nog gelijk in. Maar in situaties waarin je complete applicaties in een browser gaat draaien hoeft dat niet meer op te gaan. Op dat moment is het net zo zinvol om een krachtige JIT compiler te gebruiken als het nu is voor een losse Java applicatie.
@barfieldmv: Daar heb je nu waarschijnlijk nog gelijk in. Maar in situaties waarin je complete applicaties in een browser gaat draaien hoeft dat niet meer op te gaan. Op dat moment is het net zo zinvol om een krachtige JIT compiler te gebruiken als het nu is voor een losse Java applicatie.
[Reactie gewijzigd door humbug op maandag 21 februari 2011 15:56]
In de browser draait meestal de code '1' keer. (een relatieve 1 keer) waardoor JITten ontzetten veel tijd kost verhoudings gewijs.
Volgens mij is het ook zo dat de JIT engine in een browser nogal 'optimistisch' gebruikte code weer weg gooid om zijn geheugen gebruik zo laag mogelijk te houden en omdat code nogal eens een kleinbeetje afwijkt van de vorige gecompilede code.
Volgens mij is het ook zo dat de JIT engine in een browser nogal 'optimistisch' gebruikte code weer weg gooid om zijn geheugen gebruik zo laag mogelijk te houden en omdat code nogal eens een kleinbeetje afwijkt van de vorige gecompilede code.
Zit er een x86 processor in je mobiel dan?
Het idee van LLVM bytecode is dat het naar iedere ISA gecompileerd kan worden, waardoor je dus niet aan x86 vast zit. Dat was juist de hele achterliggende reden om LLVM voor te stellen.
Jit compiling gebeurt maar 1 keer, dus het kost hooguit wat bij startup. Daarna is het gewoon native gecompileerde code dat direct uitgevoerd kan worden.maar is zo'n mobieltje ook snel genoeg voor jit-compilers/interpreters?
Ik moet zeggen dat ik het ook een beetje vreemd vind dat ze dit met native code gaan doen. Belangrijk argument van hun schijnt te zijn dat je bestaande applicaties op deze manier 'web-enabled' kan maken. Maar ja, volgens is er geen enkele app die je 1 op 1 zo kan inzetten.
Ze hadden beter naar Silverlight kunnen kijken. En dus in hun geval een kleine runtime van java kunnen maken en die gebruiken. De gebruiker hoeft dan dus geen Java te installeren, en bergen apps die dan ook ineens 'web-enabled' zijn(en dit zeg ik als .Net freak
)
Niks mis met C/C++, maar voor webdevelopment veel te omslachtig, mijn inziens.
Ze hadden beter naar Silverlight kunnen kijken. En dus in hun geval een kleine runtime van java kunnen maken en die gebruiken. De gebruiker hoeft dan dus geen Java te installeren, en bergen apps die dan ook ineens 'web-enabled' zijn(en dit zeg ik als .Net freak
)Niks mis met C/C++, maar voor webdevelopment veel te omslachtig, mijn inziens.
Ik denk dat de bedoeling van deze api niet is om maar gewoon wat mooiere animaties wat sneller te laten lopen door het helemaal in native code te schrijven, daar hebben ze toch al dingen als canvas en WebGL voor die snel evolueren. Het lijkt me meer dat er bepaalde dingen die echt te zwaar zijn voor geïnterpreteerde talen als Javascript met native code worden gedaan, maar daar dan alleen een 'library' voor gemaakt wordt die verder aangeroepen kan worden door JS.
En waarom zou iemand een native applicatie binnen een browser willen draaien? 1-click deployment daar kan ik in komen. Maar een browser is en blijft een browser en daar moet je mee kunnen browsen, meer niet, het is geen OS. Verder ook een slecht idee omdat we al talen als Java en .NET hebben.
Ehm, in Google Chrome OS is de browser wel het OS. 
Het moet maar eens afgelopen zijn met Flash fimpjes, online office pakketten en HTML5 animaties, gedistribueerde source control, etc. Achterhaalde troep.Maar een browser is en blijft een browser en daar moet je mee kunnen browsen, meer niet
Overigens is .NET geen taal, maar een OS specifiek framework.
Google kan ontwikkelaars wel aansporen, maar ik denk dat het zeer beperkt gedaan wordt. Immers, iedere bezoeker zal dan tenminste Chrome 10 beta moeten gebruiken en dat is toch alles behalve een meerderheid van de browsende mensheid. Nu duurt het natuurlijk nog wel even voordat dit alles final wordt etc. , maar ik kan me heel goed voorstellen dat de webwereld dit maar heel sumier gaat toepassen. Niet iedereen heeft medewerkers en tijd over om naast een applicatie te maken met huidige technologie, ook nog eens een aangepaste versie te maken met dit gebeuren.
Is dit soms een manier om hun nog niet van de grond komende ChromeOS te pushen?
Die moet immers alles vanuit de browser draaien met alle beperkingen van dien.
Door nu native apps in de browser te kunnen draaien omzeil je die tekortkoming en kun je je doel, een browser OS toch verwezenlijken
Die moet immers alles vanuit de browser draaien met alle beperkingen van dien.
Door nu native apps in de browser te kunnen draaien omzeil je die tekortkoming en kun je je doel, een browser OS toch verwezenlijken
Volgens mij is dit gewoon een volgende stap van Google voor hun chrome os. Op deze manier kunnen zij de zwaardere services hosten maar toch bepaalde processen laten uitvoeren op de laptop of andere machine waardoor het sneller klaar is.
Eigenlijk creëer je dan wat Apple wil creëren met apps in iOS: volwaardige programma's opgesloten in een sandbox en dan hopen dat niemand nog "echte" apps wil. Want dat is het probleem van Chrome OS: je kunt geen applicaties installeren, alles is één grote "web-ervaring".
Dit is duidelijk een zet van google om hun google-os native-byte-code te kunnen laten uitvoeren. Voor de normale desktop PC's met een full-featured-OS zie ik weinig reden om native applicaties te laten uitvoeren.
Voordeel van javascript is de grote portabiliteit. Dat de performance minder goed is zal uiteindelijk door de betere javascript-engines en snellere hardware weggewerkt worden.
Slimmer zou zijn om javascript-api meer uit te breiden zodat er minder zaken in uitgecodeerd moet worden, en dus meer zaken door de native-browser gedaan kan worden. Maar daarvoor ligt de compabiliteits-problematiek tussen de verschillende browsers dwars...
Desalniettemin mijn voorlopige conclusie:
- Ja, dit is een soort renewal/verbetering van activeX-componenten
- Nee, het www/web gaat hier niet beter van worden. Voor de chrome surfers gaan er echter wel snellere apps opduiken.
Voordeel van javascript is de grote portabiliteit. Dat de performance minder goed is zal uiteindelijk door de betere javascript-engines en snellere hardware weggewerkt worden.
Slimmer zou zijn om javascript-api meer uit te breiden zodat er minder zaken in uitgecodeerd moet worden, en dus meer zaken door de native-browser gedaan kan worden. Maar daarvoor ligt de compabiliteits-problematiek tussen de verschillende browsers dwars...
Desalniettemin mijn voorlopige conclusie:
- Ja, dit is een soort renewal/verbetering van activeX-componenten
- Nee, het www/web gaat hier niet beter van worden. Voor de chrome surfers gaan er echter wel snellere apps opduiken.
Voordeel van javascript is de grote portabiliteit.
Native code kan ook portable zijn hoor. Immers, het is code dus het kan automatisch vertaald worden. Wat het lastig maakt is de API met het OS. Maar dat heeft google al onder controle.
Slimmer zou zijn om javascript-api meer uit te breiden zodat er minder zaken in uitgecodeerd moet worden, en dus meer zaken door de native-browser gedaan kan worden.
Volgens mij is het helemaal slim als google ons onze eigen javascript interpreter/compiler laat maken, en eventueel onze eigen browser. Deze kan dan gewoon draaien in de native client omgeving. In 1 klap zijn dan alle compatibiliteitsproblemen waar web-ontwikkelaars al jaren mee kampen gewoon weggevaagd.
Native code kan ook portable zijn hoor. Immers, het is code dus het kan automatisch vertaald worden. Wat het lastig maakt is de API met het OS. Maar dat heeft google al onder controle.
Slimmer zou zijn om javascript-api meer uit te breiden zodat er minder zaken in uitgecodeerd moet worden, en dus meer zaken door de native-browser gedaan kan worden.
Volgens mij is het helemaal slim als google ons onze eigen javascript interpreter/compiler laat maken, en eventueel onze eigen browser. Deze kan dan gewoon draaien in de native client omgeving. In 1 klap zijn dan alle compatibiliteitsproblemen waar web-ontwikkelaars al jaren mee kampen gewoon weggevaagd.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
