Ontwikkelaar bouwt modulaire browser op basis van javascript

Een ontwikkelaar heeft een alpha uitgebracht van een opensourcebrowser waarvan de interface volledig in javascript geschreven is. De browser is modulair opgebouwd en gebruikers kunnen zelf onderdelen verwijderen, aanpassen of toevoegen.

Breach, zoals de browser heet, bestaat uit drie lagen: bovenop de Chromium-content-api en Node.js ligt de volledig in javascript opgetrokken interface. Die gebruikersinterface bestaat uit losse modules en in feite zijn dit web-apps die de Breach-api kunnen benaderen.

Doel van de ontwikkelaar was eigenlijk om een browser te maken waarvan de status, op gebied van cookies, tabs en extensies, volledig los van de machine waarop de software draait staat, iets dat de ontwikkelaar omschrijft als 'tab-synchronisatie on steroids'. De ontwikkelaar kwam vervolgens op het Exobrowser-platform, waarop de modulaire opbouw van Breach gebaseerd is.

De makers van Breach moedigen niet alleen het maken van nieuwe modules aan, maar promoten ook het naar believen aanpassen van bestaande modules. Het team achter de browser geeft als voorbeeld het maken van horizontale tabs of een aangepaste versie van autocomplete. Het project bevindt zich in de alpha-fase en de makers willen de komende tijd gebruiken om functionaliteiten en api's toe te voegen. De browser is voorlopig alleen beschikbaar voor OS X en Linux.

Reacties (113)

De Firefox-ui was vroeger ook grotendeels opgebouwd uit xml, js en css.
Daar zijn ze langzaam aan wat vanaf gestapt, maar zo heel vreemd is die aanpak toch ook niet? Zolang je de verschillende executiedomeinen maar netjes van elkaar gescheiden weet te houden. Iets wat de core engines toch al heel strict moeten doen.

Dit is een mooi voorbeeld van de wet van Atwood [1]

any application that can be written in JavaScript, will eventually be written in JavaScript.

[1] http://blog.codinghorror.com/the-principle-of-least-power/

Het is 'opzich' ook niet vreemd om het in javascript te doen (zeg ik als javascript developer )

Maar eerlijk is eerlijk, javascript kan simpelweg niet op tegen de performance van c++ etc..
Ook heeft javascript lang niet toegang tot alles van het systeem..

Dat lijken mij de grootste redens te zijn geweest om te switchen..

Maar eerlijk is eerlijk, javascript kan simpelweg niet op tegen de performance van c++ etc..

Kun je graag toelichten waarom dat java script niet tegenop kan van c++? En waarom ze node.js gebruiken.

Hoor het graag van je

[Reactie gewijzigd door Probook8979 op 11 juli 2014 22:44]

Tsja.. Gezien Javascript geen low level language is, wordt er een heleboel 'voorbewerkt' en 'nabewerkt' zodat de taal makkelijker te schrijven is.. Denk aan de automatische garbage collection etc, die moet ook draaiende gehouden worden.. In c++ wordt verwacht dat je zelf je geheugen 'cleaned', javascript wordt dat voor je gedaan, doormiddel van een interval controle of een variable/object nog gelinked is aan 'iets'..

Ik zou verders niet vergeten dat Javascript zo 'log' is geweest, omdat het ook geen nut had om super snel te maken.. Nu heeft dat het wel, vandaar dat b.v. de v8 engine zo gigantisch hard pushed op performance..

Buiten dat merk je dat de taal steeds meer 'to the metal' gebruikt wordt en het dus niet meer zo zeer als een 'scripting' taal gebruikt wordt.. Veel mensen denken jQuery = javascript en andersom... Maar steeds vaker wordt javascript voor veel meer gebruikt dan een plaatje tonen/verbergen, waardoor het (in mijn mening) ook geen scripting taal meer te noemen is.. Hij wordt namelijk niet meer alleen als scripting taal gebruikt..

Nodejs wordt gebruikt om meer controle over je systeem te hebben.. Nodejs 'is' in feite je systeem zover ik het begrijp, niet simpelweg een browser.. Het heeft dus volledige toegang tot je file system etc etc..

Maar in de begin tijden van Firefox (waar de reactie op gebasseerd is), was er nog geen nodejs, dus javascript had een minder 'compleet' pakket te bieden tegen over c++..

Maar iets doet mij vermoeden dat je gewoon even iets wou horen.....

Dankjewel voor je duidelijke uitleg,
Nee ik wist niet wat de verschillen zijn of waren. Vandaar.

Je legt het goed uit. Mijn dank.

Geen dank, excuses voor de laatste regel.. Gezien de vele bashes tegen javascript die ik hier las als reacties, begon ik te vrezen dat je me zelf wou laten uitleggen wat er slecht aan javascript was

Als je meer wilt weten dan plaats je maar een reactie Vind het leuk (en belangrijk) om de talen in een goed perspectief naast elkaar te zetten

Klopt helemaal, Javascript komt steeds dichter "to the metal" zoals jij dat beschrijft. Je ziet het met NodeJS waar je relatief makkelijk bindings kan maken met andere talen zoals C, C++ en Python. NodeJS is een systeem waar alles op kan draaien. Je zou zelfs een compleet OS kunnen maken op basis van NodeJS als je wil.

Je ziet steeds meer programma's en vooral opensource programma's draaien met een interne NodeJS terwijl je daar als gebruiker niks anders aan voelt dan een gewone programma. Terwijl het gewoon HTML / CSS waar je tegenaan kijkt!!

Volgens mij is de hele GU-interface van Windows XP destijds geschreven in HTML. MAar kan het mis hebben hoor

Zou het niet durfen zeggen, maar stel voor dat het wel zou was... Geloof je serieus dat heel windows xp langs een javascript parser ging om zijn 'html' te renderer....??

Je zou zelfs een compleet OS kunnen maken op basis van NodeJS als je wil.

Misschien een beetje een late reactie, maar ik las dit nog en vroeg me af of dit echt zo is? Ik bedoel; je kan toch niet direct in NodeJS booten of een kernel bouwen met NodeJS?

Het ding is (denk ik...), dat je de V8 Javascript engine opgestart moet zien te krijgen.. En dat lijkt mij geen makkelijke opgave haha.

Maar vanaf daar kun je alles opbouwen volgens mij

De vraag die mij dan wel gelijk opkomt! Wat handelt de drivers af...??
Het idee dat je videokaart wordt aangesproken door middel van 1 of andere javascript driver is wel heel scheef

Nodejs wordt gebruikt om meer controle over je systeem te hebben.. Nodejs 'is' in feite je systeem zover ik het begrijp, niet simpelweg een browser.. Het heeft dus volledige toegang tot je file system etc etc..

Begrijp ik je goed dat deze browser dus ook toegang heeft tot je filesystem? Daar word ik dan weer niet zo blij van...

Hmmm het is natuurlijk de vraag of de 'browser' toegang heeft, neem aan dat er wel een laag tussen is gezet die dat voorkomt.. Nodejs zelf heeft wel toegang, maar alle programma's die je installeert op je computer hebben toegang, dus ook chrome,firefox etc...

Alleen de 'website' die getoond heeft, heeft geen toegang.. Alleen de onderlinge API van de javascript browser heeft dat...

Maar neem het met een korreltje zout, want heb het niet geschreven uiteraard

Ook heeft javascript lang niet toegang tot alles van het systeem..

En dat is waarschijnlijk de reden dat ze node.js gebruiken ;p

Het lijkt me dat ze met FirefoxOS wel weer een web-UI hebben, gezien het allemaal op HTML5 draait?

Denk aan WebOS. Dat concept is hetzelfde als ChromeOS. Dit algehele concept is de toekomst. Linux wereld groeit daar ook naar toe. Je kunt al je complete UI in sommige distro's aanpassen in CSS

Offtopic: Chrome is gebaseerd op Chromium, wat open source is right? Waarom lijkt het alsof er niemand bezig is met een Chrome-fork die door een community ontwikkeld wordt? Of is dat gewoon zo? Weet wel dat er SRware Iron is maar dat is ook maar een lousy project.

Waarom lijkt het alsof er niemand bezig is met een Chrome-fork die door een community ontwikkeld wordt?

Goede developers kosten veel geld, en de kleine groep aan idealisten die voor niks willen werken, werken liever aan Firefox.

Opera is Chromium based en waarschijnlijk de belangrijkste andere variant naast Chrome en Chromium zelf. En hier nog een hele rij met browsers: http://en.wikipedia.org/w...rowsers_based_on_Chromium

Voor een game ofzo, ja - maar bij een browser, die ongeverifieerde javascript en html code van het grote, boze internet uitvoert, wil je eigenlijk juist niet dat het native is met directe toegang tot low-level OS en hardware functionaliteit, maar dat het in een mooie managed code omgeving draait.

Laat javascript nu juist net niet mooi en ordelijk zijn. Dan had het wel object georiënteerd programmeren gekend en had je wel types kunnen definiëren.

Niet mee eens, alle talen moeten volwassen worden..

Door als een boer met kiespijn alleen te lopen zeuren gaat het ook niks beter worden...
C++ etc (of welke taal dan ook) was vanaf zijn eerste begin dagen nou ook niet bepaald een pareltje..

Geef het wat tijd mensen, er steken ook een hoop voordelen aan. Of wou je liever je website in c++ in elkaar gaan zetten?? Be my guest

Het probleem is dat bij EMCAscript heel veel verkeerde keuzes zijn gemaakt. Onder andere ==, bitshift operators (WTF, waarom?), eval, void, with, moeilijk het verschil te maken tussen Array en Object, function/method overloading, geen simpele inheritance [geen super(), enkel "object uitbreiding"], laat staan multiple inheritance en polymorphisme.

Nu wordt er geprobeerd om die fouten glad te strijken, maar het kwaad is gewoon al geschied.

Sowieso vind ik het gebruik van weak-typing een slechte keuze.
Je moet altijd in de comments of in de variablennamen zelf zetten wat voor type het zou moeten zijn, terwijl je bij strong typing gewoon al kan zien watvoor type het is.

Overigs is interactive websites schrijven tegenwoordig makkelijker en veiliger dankzij FastCGI en smart pointers in C++11.

Helemaal eens!

Zelf doe ik ontzettend veel in JavaScript, en was er persoonlijk helemaal klaar mee dat je niet op een fatsoenlijke manier Class-Based kunt programmeren in JavaScript (sorry @kewin, maar dat prototype vind ik juist helemaal niks). Ieder zijn eigen

Maar goed, door deze "frustratie" heb ik wel een leuk library-dingetje opgezet wat class-based programming wel weer mogelijk maakt in JavaScript, tot zeker hoogte ivm limitaties in de taal. Website: http://joii.zone/

Ik kan daarom ook niet wachten tot ECMAScript6 (ES6) als nieuwe 'standaard' wordt gebruikt, aangezien hier eindelijk gebruik wordt gemaakt van de reserved keyword "class". Het is echter nog maar afwachten wat hier daadwerkelijk mee gedaan gaat worden. (bron: https://people.mozilla.or...tml#sec-class-definitions)

Hey ik heb even gekeken, ziet er goed uit!! Hoe zit het met compatibility richting ecma6...?? Gaat deze library niet confilicten krijgen als ecma6 eenmaal uit is, vanwege de reserverd name 'Class', of vermoed je dat ze met een hoofdletter vrij houden..??

Thanks

[Reactie gewijzigd door Anoniem: 513559 op 12 juli 2014 18:01]

Waarschijnlijk wel, mits je zelf je eigen namespace opgeeft.

Zoals in de documentatie aangegeven kun je een "data-ns" attribuut meegeven aan het <script> element wat je gebruikt om de library mee te laden. Op die manier kun je een eigen "prefix" voor de functies neerzetten, zodat het bijvoorbeeld "MijnApp.Class" wordt ipv gewoon "Class"

#edit: Oh ja, en voor nodejs gebruik je wellicht gewoon module-prefixes, dus dat zou als het goed is out-of-the-box al goed moeten gaan.

[Reactie gewijzigd door MokaNi op 14 juli 2014 11:13]

Elke taal heeft zo zijn voor en nadelen. Javascript doet echter ook wel weer veel goed of heeft voor sommige zaken weer als model gestaan voor andere talen.

Mee eens!! Er zitten een hoop quirks in.. Maar dingen als prototyping vind ik juist super handig. Kun je een taal opnoemen die alles goed heeft dan?

Een taal hoort op zijn minst object georiënteerd en event driven te zijn met onder steuning van multithreads. Leercurve mag wat hoger liggen maar het kan je handen vol werk besparen.

Tuurlijk zouden we dat allemaal willen, zou ook wel willen of waren er nooit buffer overflows mogelijk geweest en het tcp/ip protocal altijd met encryptie..

We hadden daar dus ook maar meteen mee moeten stoppen?? Nogmaals, geef het wat tijd, javascript had eerst andere dingen te fixen.. Namelijk dat jij hier normaal een bericht kan posten bijvoorbeeld... Je kunt niet verwachten dat alles in 1x goed is.. Dat is met niks zo. Als er grote behoefte aan is, dan komt het er ook wel..:)

Buffer overflow/underflow zijn technieken voor om tegen te gaan.
Is zie even niet de relevantie van javascript dingen moest fixen zodat ik hier een bericht kan posten? Dat kon 10 jaar terug ook al.

Het gaat erom internet is al een tijd volwassen maar de script talen voor websites niet. Misschien dat java meer potentie heeft maar daar ben ik niet in thuis.

Doormiddel van een volle page refresh en een form... Neem aan dat je daarmee zelf wel snapt wat er dan dus veranderd is in 10 jaar...

U zei? https://developer.mozilla...bject-Oriented_JavaScript
Dat is 1 van de momenteel 7 miljoen resultaten over OO Javascript.

Je kunt Javascript zo mooi en ordelijk maken zoals je zelf wilt. Dat je het uiteindelijke resultaat uglified zodat het sneller laad en sneller verwerkt wordt is niet erg, maar je kunt tegenwoordig mooie dingen doen.

Ik ben daar al eens diep ingedoken maar uiteindelijk merk je dat het behoorlijk onvolledig is en het niet ten goede komt van nette code. Ze dragen ook beetje meer van alternatieve oplossingen aan omdat het niet anders of beter kan bij javascript.
Kortom het is eigenlijk een bron van irritaties als je echte OOP gewend bent.

Veel dingen moet je anders doen dan je gewend bent, maar dat wil niet zeggen dat het per definitie slecht is. De irritaties komen dan ook vooral vanwege het feit dat het nieuw en anders is. Niet omdat het zoveel slechter is. Elke taal heeft wat tijd nodig om aan te wennen.

Het uiteindelijke doel van OOP is om code beter te structureren, beter te laten begrijpen (ook door andere programmeurs aan je project) en minder herhaling en grotere herbruikbaarheid toe te passen. Die zaken zijn zeker haalbaar bij Javascript, maar mogelijk wat anders. Object Georienteerd Programmeren is daarbij dus een methode om dat te bereiken maar moet niet een doel op zichzelf zijn.

Mooi gezegd. OOP is inderdaad zo 'fijn' omdat het voordelen heeft tegen over je structuur. Wat als men nu bij wijze van, een OOP v2 bedenken.. Maakt dat ALLES van OOP v1 dan meteen slecht??? Nee, want het heeft zijn voordelen geboden.

Zo heeft javascript zijn prototype, zelfde doel, werkt anders. Maar dat maakt het niet per definitie 'slechter' of 'beter'. Het heeft simpelweg zijn voor en nadelen (zoals ongeveer alles in het universum)

Javascript is object-oriented. Sterker nog, ieder aspect van JS is object-oriented, in tegenstelling tot de meeste andere talen (zelfs een string of functie is bijvoorbeeld een object). Het is alleen geen classical inheritance-model, maar een prototypical inheritance-model.

Nou hey precies wat je daar zegt, vraag ik mij ook regelmatig af.

Want gezien alles in javascript behandeld wordt als een object en dus alles chainable etc.. Is dat technisch gezien toch ultiem OO ??! Het is zelfs wat de prototyping voortbrengt..

Is het niet net zo, zoals je zelf ook al aangeeft, dat iedereen zou moeten zeggen dat het de classical way of programming ontbeert. En niet OO??

Maar goed, vanaf ECMA6 wordt de reserved word 'class' ook eindelijk naar het strijdveld gebracht

[Reactie gewijzigd door Anoniem: 513559 op 15 juli 2014 17:06]

Vet.
Hopelijk binnenkort een windows versie

Zal wel snel komen lijkt me. NodeJS en Chromium doen het ook prima op Windows. Ik denk dat het vooral te maken heeft met enkele dependancies of het installatieproces an sich dat het nog even duurt, maar komt gerust.

Moet idd niet al te lang duren voor een windows port.

Ik heb hem net even gedownload en geprobeerd, en ik ben eigenlijk wel onder de indruk. Het ziet er lekker clean en duidelijk uit, websites laden retesnel en het modulaire en html5 spreekt mij als developer ook wel aan. Toen ik aankwam bij het feit dat er geen refreshknop is ben ik afgehaakt.

Maar ik ga het zéker in de gaten houden!

Doet me een beetje denken aan de Atom text-editor, die ook volledig in HTML5 is gebouwd.

[EDIT]
Ik had er even bij moeten vermelden dat F5 het niet lijkt te doen. Cmd+R doet het wel! Verder neem ik aan dat die refresh-knop snel genoeg zal komen. En wanneer het zover is zal ik deze browser zéker een paar dagen uitproberen.

@wartercoolertje - Natuurlijk kan ik een refreshknop bouwen, maar ik heb genoeg projecten waar ik aan kan en wil werken, dat een refreshknop voor een nieuwe browser op dit moment redelijk onderaan de lijst staat..

@Martinspire
Een back en forward knop zit er beiden wel in, dus dat is geen probleem.

[Reactie gewijzigd door kramer65 op 11 juli 2014 17:57]

Op Mac Os X kan ik bevestigen dat het refreshen met CMD + R gewoon werkt. Er zit dus wel een refresh functionaliteit in. Lijkt dus een kwestie van een goede key bind zoeken.

Snelle browser inderdaad, ook "gewoon" met de Chrome (ofwel Chromium) developer toolbar. Browser met potentie voor ontwikkelaars in iedereen geval.

Toen ik aankwam bij het feit dat er geen refreshknop is ben ik afgehaakt.

F5?

Kan je dat dan niet zelf inbouwen als developer?

Natuurlijk wel, maar het is toch wel een redelijk cruciale functie. Ik snap dat nog niet alles erin zit, maar refresh en een back-knop moet toch wel te doen zijn?

Refresh is niet nodig in een Node/JS gebaseerde omgeving. Dit kan realtime worden gedaan. Maar dan moeten de websites natuurlijk ook wel zo zijn opgebouwd.

[Reactie gewijzigd door DutchStoner op 12 juli 2014 11:24]

Refreshen met F5 is eigenlijk ouderwets idd. Het content moet zichzelf refreshen.

Steeds meer programma's draaien op hetzelfde idee.

Namelijk:
-Webkit/Blink
-V8 engine van Google
-(Dit bij elkaar CEF Chromium Embedded Framework)
-GTK wrapup van dit alles
-Ingebouwde NodeJS server welke net zoals de Client op de V8 engine draait.

Nog een bekende is Node-Webkit en er zijn er heel veel van die vaak ook specifiek gemaakt zijn voor een bepaald project zoals:
-Brackets.io deze editor is gemaakt in een Brackets shell welke op dezelfde manier ongeveer werkt met CEF, V8 etc etc... Allemaal javascript.
-Atom.io deze editor is gemaakt in een atom shell ook custom gemaakt door hen zelf.

De custom shells hebben vaak beperkingen en enige doel om hun eigen programma verder te helpen. Node-Webkit is meer een shell opzich om programma's te maken zoals Popcorn Time en Spotify programma.

Als je een beetje oplet in deze wereld zie je dat deze "javascript" wereld enorm hard aan het groeien op basis van opensource technologie. Laat staan straks als "web components" eraan komen. Eens een kijkje nemen naar de Polymer library die gebruikt maakt van Web Components op een juiste manier.

Het zou nog wel eens kunnen zijn dat programma's helemaal straks uit Javascript zullen bestaan. Je kan altijd in NodeJS nog NPM's aanmaken met bindings naar C en C++ en python etc.

iig, javascript is booming. Als je nu nog denkt dat javascript een simpele script taal is om je dom te manipuleren heb je het totaal fout. Dan loop je achter.

Tevens zie je ook in de Linux wereld dat GTK bijvoorbeeld CSS opneemt om hun GUI interface van o.a. linux distro's aan te passen. Web technologie gaat zich helemaal verweven in de toekomst in de Linux wereld.

Waar hebben we dat vaker gezien? Ohjha Chrome OS. Maar Google loopt veeeeel te ver voor op de toekomst. Vandaar dat het nog niet echt een succes is.

[Reactie gewijzigd door Texamicz op 13 juli 2014 09:39]

Doel van de ontwikkelaar was eigenlijk om een browser te maken waarvan de status, op gebied van cookies, tabs en extensies, volledig los van de machine waarop de software draait staat, iets dat de ontwikkelaar omschrijft als 'tab-synchronisatie on steroids'

Kan iemand uitleggen wat hier nu staat? Het is blijkbaar het doel van deze aanpak, maar ik kan er werkelijk geen chocola van maken...

The initial motivation to create Breach was to create a browser whose state (tabs, cookies, extensions, etc...) would be complety untangled from the machine it runs on, so that users could project that state on any machine running Breach easily. The idea was to let users get control of any machine around them transparently by making it very easy for them to push their state onto these machines. Think of it as tab syncing as seen in Chrome, Firefox, Safari, on steroids and built to be used on machines you don't necessarily own (which is a strong limitation in existing systems).

De originele, niet ingekorte, tekst van http://breach.cc/hack/, misschien dat je hier wel chocola van kunt maken.

Door dus de cookies, tabs en extensies los van de core te draaien kun je deze makkelijk op verschillende apparaten syncen.

Uhm, Nodejs is toch gewoon de server versie van de JS engine V8?

Niet echt, Node.js maakt enkel gebruik van V8 zodat Javascript gebruikt kan worden om je (server-side) software bovenop het Node.js platform te bouwen. Het had net zo goed Ruby kunnen zijn.

Ja/nee
Nodejs is eigenlijk gewoon zijn eigen softwareplatform en gebruikt Google's V8 JS engine om code uit te voeren. Dus je kan er domweg applicaties mee/op laten draaien. Dat het toevallig ook een HTTP server heeft betekend niet dat het -alleen- als 'server' moet/kan functioneren. Dat is gewoon iets extra's waarmee je dus inderdaad server-side kan scripten.

De bekende misvatting dat NodeJS een server is. Het is een platform. Geeft niet maar je kan er alles op draaien in principe. Je kan er inderdaad een server module op laten draaien. Het is heel mooi modulair opgebouwd. En de NPM (Node Package Manager) biedt echt gigantisch veel content voor de NodeJS platform waaronder..... een webserver.

Terwijl de meeste browsers kiezen voor snelheid, zal deze browser dit vermoedelijk niet hoog in het vaandel dragen. Extensibility is key here I guess...

Ik hoop dat ze zich toch meer gaan toespitsen op snelheid/browsespeed. Op de website is hier namelijk nog niets over terug te vinden, geen stats of vergelijkingen met andere browser.

Al bij al de node.js implementaties op de desktop die ik al gezien heb, blinken niet echt uit in snelheid.
Brackets is ook een heel mooi voorbeeld hiervan. Best goede implementatie, gebruiksvriendelijke interface, maar soms onverklaarbaar traag in simpele zaken zoals bvb het oproepen van het zoekscherm (ctrl-f).

In het artikel staat duidelijk dat de browser gebouwd is op basis van Chromium.

Het is en blijft een html "website" en de DOM is hellaas niet zo snel. Maar naar mijn idee worden dit soort applicaties wel steeds beter, kijk bijv. naar atom (https://atom.io/) vind deze al vrij netjes draaien.

Op dit moment focused Google zich ook keihard om de DOM sneller te maken. De focus ligt nu wat minder op Javascript. Daarom hebben ze ook Webkit gepakt en een vork gemaakt genaamd blink om dit goed diep aan te pakken.

De DOM gaat sneller worden.

Yo dawg, I heard you like browsers, so we made a browser that can run in your browser, so you can have a sandbox in your sandbox.

Mooi mooi, zoveel te meer we in managed code kunnen krijgen zoveel te mooier deze wereld wordt. Mits het managed platform maar goed in elkaar steekt.

Je bedoelt software draaien bovenop een virtuele omgeving / abstractielaag? Het lijkt me geen vooruitgang, tenzij die wereld voor iedereen volledig open en aanpasbaar is. De afstand tussen de gebruiker en de fysieke hardware wordt zo telkens groter. Vanaf het moment dat daar een commerciele organisatie tussen zit gaat die bepalen wat kan en wat niet kan, afhankelijk van waar het meest aan verdiend wordt en ongeacht wat de hardware werkelijk kan.

Nee? Kijk nu naar .net met de CRL van MS, toch ook een commerciële partij. Toch iets handiger dan in een lowlevel taal per PC/OS een programma te schrijven niet?

[Reactie gewijzigd door Kridri op 11 juli 2014 16:51]

Wat een rare vergelijking.

.net (de code) is dan wel "cross platform" (al kan je dat ook met een korrel zout nemen), de binary is dat zeker niet.

Overigens is C++ gewoon een standaard die op mac/windows/linux werkt. De code mits je enkel de standaard dingen gebruikt! De binary zal je ook weer voor elk platform lost moeten compileren.

Denk dat jij Java bedoelt?

De binary is wel degelijk crossplatform. Maak een random console-app die wat simpele output doet, compileer in VS, kopieer het naar (bijvoorbeeld) een RaspberryPi en run die exe in Mono (wat de manier is om mono-executables te runnen) en je zult dezelfde output zien.

Grafisch is wel ingewikkelder maar daar kun je door GTK# te gebruiken ook alweer een heel end komen om een compile-once-run-anywhere(mits mono) binary te maken.

Just sayin'

ja.. even rekening houden met verschillende versies (mono loopt wat achter), dan zou het moeten werken....

Mijn ervaringen met Mono zijn ronduit slecht. Ik ben nog geen enkele .NET-applicatie tegengekomen die soepel en zonder extra bugs werkt onder Mono.

Dan is het toch veel makkelijk om zo'n Javascript Shell te pakken en je grafische UI te maken in CSS / Javascript?

Daarom is dit de toekomst. Je kan gewoon bindings maken naar C++ en C en Python met NodeJS.

Daarnaast zijn ze hard bezig om Javascript te kunnen compileren naar een binary die in de V8 engine draait. Een zogenaamde "snapshot". Hierdoor draait je gemaakte javascript nog sneller.

Waarbij alles ook nog eens crossplatform is tenzij je in je C++ OS specifieke zaken hebt geprogrammeerd.

En MONO is gebaseerd op technieken uit de Linux wereld. .NET is gewoon een walled garden van Microsoft anders hadden ze zelf wel MONO uitgebracht. Daarnaast werkt niet alles in Mono.

[Reactie gewijzigd door Texamicz op 13 juli 2014 09:54]

Je beperkt jezelf daarmee sowieso tot 1 OS-familie en een API. Daarnaast is wat met Windows + .NET kan slechts een selectie uit de mogelijkheden van een PC. Daarmee heeft MS 2 doelen bereikt: (software-)platform-afhankelijkheid en inspraak en macht in de hardwaremarkt. Met beiden kunnen de vraag naar en de afname van Windows (r) vergroot worden, waar het naar mijn idee dus om draait.

Low-level en machine-afhankelijk programmeren is al jaren niet meer nodig. Ook niet zonder commerciele software.

Dat is natuurlijk niet anders door bijvoorbeeld je software onder een multi-tasking OS te draaien i.p.v. als eigen OS. Het gevaar van een gesloten platform bestaat altijd, dat is niet specifiek voor een managed runtime of abstractielaag.

Mooi mooi, zoveel te meer we in managed code kunnen krijgen zoveel te mooier deze wereld wordt.

Het gaat niet om een browser die in een managed code omgeving Java of .NET is geschreven, het gaat hier om JS.

Ik kan Tweakers.net al niet eens laden in Breach .. Site wordt geladen, en dan ineens is de tab helemaal grijs moet ik CMD+R doen om te vernieuwen, maar hetzelfde.