GET /browser.exe

http://blog.ezyang.com/2012/10/get-browser-exe/

by mikexstudios • 14 years ago

139 89 14 years ago

blog.ezyang.com

So the internet should just be a simplified app store and hypervisor/VM?

I like the text based internet! The fact that I can go to a website, right click and view source is the greatest part of the internet!

derleth3• 14 years ago

> The fact that I can go to a website, right click and view source

"What, and steal mah codez?! Damn you to hell!"

MBAs don't use precisely those words, but the spirit is the same.

tedchs• 14 years ago

Congratulations to the author on trying to re-invent either Java Applets or ActiveX.

Smudge• 14 years ago

Or, for practical purposes, Flash.

dredmorbius2• 14 years ago

What could possibly go wrong?

bitwize• 14 years ago

I'm imagining Steve Summit -- the comp.lang.c FAQ maintainer, my former boss and a security stickler -- saying this and loling.

mSoft• 14 years ago

Hmmm, an article that seems to pine for the days of true client/server applications...

Wait, what's this? http://research.microsoft.com/en-us/people/howell/

> microsoft.com

...oh.

cyrus_• 14 years ago

> research.microsoft.com

MSR is a different beast from Microsoft itself.

camus2• 14 years ago

that's why there is microsoft in the domain name ?

idle_processor• 14 years ago

More room for vulnerabilities, less consistent user experience, and all the other annoyances Flash and Java applets bring to the table. Sounds great.

acuozzo3• 14 years ago

Web-apps (and the WWW browsers making them possible) were supposed to be the solution to the portability problem. They're not and layering more crap on top of them is not the solution either.

Leaving other (e.g., security) issues aside, this plan would make things far worse. Would new processors be second-class citizens? Would WWW browsers have to (incompatibly) transform themselves into emulators/VMs for the different kinds of "native code" found on the Wild Wild Web?

Most importantly: Would this be the first step toward a closed/proprietary WWW? "View Source" is still useful in this regard, despite the amount of useless JavaScript obfuscation we're seeing today.

ezyang12• 14 years ago

New processors are already at a huge disadvantage; one problem is that it takes a huge amount of engineering effort to match the performance of existing processors, even if you do a lot better, another problem is, well, you actually have to convince people to buy your shit when no one is actually cross-compiling to it yet. It's not that big of a difference.

You're misunderstanding: the browsers are the native code living on the WWW.

A platform like this would enable people to create proprietary websites, much the same way people can implement systems like Steam as native applications.

bzbarsky2• 14 years ago

A question always worth asking: Had this system been implemented in 1995, would we have ARM-based devices today? Why or why not?

Note that ARM never attempted to compete with x86 on performance, and indeed still can't. That doesn't mean that it wasn't useful for other purposes.

So yes, new processors are at a huge disadvantage unless they bring something to the table that none of the existing ones have. But the question is whether you want to prevent a processor that _does_ bring something new from being usable by making it impossible to use the web on it.

acuozzo3• 14 years ago

> A platform like this would enable people to create proprietary websites, much the same way people can implement systems like Steam as native applications.

... and that is a __BadThing__.

sp332• 14 years ago

I like this idea! It reminds me of this page http://mozilla.github.com/pdf.js/web/viewer.html which loads a JS-based PDF reader and then uses it to render a PDF in your browser. It could be expanded to do a lot more than static documents - in fact it seems to echo the ideas that Alan Kay has been working on for decades. http://www.drdobbs.com/architecture-and-design/interview-wit... "Binstock: Still, you can't argue with the Web's success.

Kay: I think you can... go to the article on Logo, can you write and execute Logo programs? Are there examples? No. The Wikipedia people didn't even imagine that, in spite of the fact that they're on a computer.... Go to a blog, go to any Wiki, and find one that's WYSIWYG like Microsoft Word is. Word was done in 1974. HyperCard was 1989. Find me Web pages that are even as good as HyperCard. The Web was done after that, but it was done by people who had no imagination. They were just trying to satisfy an immediate need.... what you definitely don't want in a Web browser is any features.

Binstock: "Any features?"

Kay: Yeah. You want to get those from the objects. You want it to be a mini-operating system, and the people who did the browser mistook it as an application. They flunked Operating Systems 101.... I mean, look at it: The job of an operating system is to run arbitrary code safely. It's not there to tell you what kind of code you can run."

evv• 14 years ago

Aha! That last quote puts it best. The OS should be a browser.

The core point here is that the OS should be able to run foreign applications without an 'install' process, just like I don't need to install a webpage to use it. I assume the OP is not suggesting that we strip all of the useful APIs from the web as we know it.

agumonkey• 14 years ago

I think Alan Kay made a comment of the same kind about the current web. Compared to an old tradition to embed an 'interpreter' ahead of any data.

sadga• 14 years ago

So, Native Client?

iSnow• 14 years ago

So instead of writing Javascript, we would build our own browsers to download alongside the HTML? Or failing that would have to offer some prepackaged browser.

And every device, from a smartphone to a 30" screen running on an octo-Xenon would have to be able to execute the same native code.

And each vendor of a browser kit would try to establish their own web standards to go with their home-grown engine.

I am pretty sure this is not the future of the web, and this seems like a great thing.

And it's not like this is a completely novel idea. None of the proprietary sandboxed browing environments of the past (Flash, Silverlight...) made anything really easier. They sometimes enabled us to do things that were impossible with HTML+JS, but they were all both a pain in the lower back for developers and users and had glaring security holes.

lmm2• 14 years ago

Did silverlight have a history of security holes? It certainly looked like a joy for developers, at least compared to javascript.

acuozzo3• 14 years ago

"Sorry, this website requires MMX. Go buy a new computer, kid."

This is the danger of writing a blog post before reading up on computer history.

makmanalp3• 14 years ago

I think the internet is just trying to find the right abstraction level. And with html5/css3/js/webgl and the newest generation of standards, we almost found it.

We did used to download random binaries from the internet and run them. It took too much effort to get up and running and there were compatibility issues between systems, not to mention dependencies (java / c++ runtimes etc.), dll hell, having to support myriad different OSes and OS versions. When it broke, it broke badly and usually you had 0 chances of debugging, save sending a core dump back over the internet, if the user let you.

Meanwhile, standards came and improved, and finally we realized that we already had a UI toolkit that ran reasonably across all platforms, didn't require any dependency installations, ran "programs" instantly without any download and installation procedure. This alone is as large a marketing win as it is a tech win. Remind you of something? It's the web we know and love today. And you get logs when it breaks. And you can watch your users using it, page by page and get stats. And the limited nature of the abstraction layer means that if it breaks, it doesn't fail as catastrophically, there is less chance of a big fat ugly core dump message, there is more of a chance you almost instantly know. And the hard abstraction layer means that there is a clearer understanding of security implications. Web apps, generally speaking, can't access my files. Can Java applets or ActiveX components? A bit more hazy. Can executables? Yeah. Can this proposed system? Maybe?

The modern web (browser and standards together) is a universal VM and an SDK rolled into one. It's the only one we have that works reasonably well enough and strikes a decent balance between capability and ease of development.

The point of this person's system, which is the proposed freedom from browser restrictions and incompatibilities, is a complete fallacy. Is Microsoft going to recreate this new system for every system under the sun? No. People (and companies like Apple, Google) will have to create their own, and thus incompatibilities will prevail. Open standards are good. Established open standards are better.

Many people tried to create alternatives, and failed miserably. It works. Don't fuck with it.

unoti• 14 years ago

> Many people tried to create alternatives, and failed miserably. It works. Don't fuck with it.

Although you made some insightful points here, I swear I'm not kidding when I tell you that I've had people tell me almost the exact same thing about IBM's 3270 terminal protocol.

makmanalp3• 14 years ago

Okay, maybe it was some of that slow-brewing anger that made it to the end of the post. What I don't want fucked with, rather, is a set of very open standards, with competing implementations that already exist for a myriad of different platforms. The standards used to come slow but are now evolving faster than ever, and the implementations update themselves automatically without user interference.

What is wrong with this picture? Really? Are you willing to trade all this away, merely to get rid of the vestigial API cruft, which is mostly already abstracted away by tons of nice tools (coffeescript? bootstrap? etc.)?

I honestly think that it's going to be hard to come up with a better platform since that's a moving target: The web is evolving all the time and is ahead the competition in many respects (see my parent post).

I want to cry when people want to toss this all away when we have it so good right now. I dealt with the web when it was a complete mess. I am thankful for what it is now and the direction it's rapidly moving in.

ezyang12• 14 years ago

Sure, the web has given us an awesome UI toolkit. Ship that to your users.

You're conflating a lot of issues in this post, many of which are orthogonal to Howell's idea, which is making it difficult for us to talk about the core technical idea (which is certainly not perfect, but you're focusing on the wrong things.)

voyou• 14 years ago

Yeah, but Howell's ideas are pretty much orthogonal to the web. A program that allows a number of virtual machines to cooperate in providing an interface to the user isn't an uninteresting idea, but it solves almost none of the problems the web solves (things like, standards for transmitting, displaying, and interacting with hypermedia).

gambler• 14 years ago

No links, no bookmarks, no standard UI conventions and components, no history, no back and forward buttons that work consistently, no mental model of how it all clicks together (page model), no accessibility, no search, no semantic content, no pesky users controlling stuff. Sounds awesome, sign me up.

Sarcasm aside, we're moving in that direction already.

makmanalp3• 14 years ago

Wow, an entire other myriad of issues I wasn't even thinking about while commenting. Great points! Funnily enough, you can see some of this in mobile apps already, but it's gotten a lot better over the last 5 years. No search really bugs the crap out of me. It's impossible to naturally discover an app through search. Also, It's like mobile apps are all their own individual walled gardens and interplay is impossible. Links anyone? All this was invented years ago and seems like a step back.

a1k0n• 14 years ago

But this wouldn't even have, like, font rendering. Input methods. The amount of stuff every single site would have to implement just to show something on the screen is staggering, unless the API in question is no longer small and simple and provably safe.

ezyang12• 14 years ago

You don't need to reimplement it, you just use whatever library you were using before (but linked with the browser). The point is that the stack doesn't change, just who provides it.

infinity• 14 years ago

The next step in the sequence is to get rid of interactivity. We have then reached television.

icebraining• 14 years ago

Yes! How I longed for the days where scraping would be impossible, locking us out of many innovative interfaces and mashups (or even just archiving pages, like e.g. Pinboard does). Where Reddit's Enhancement Suite or the many Hacker News bookmarklets and greasemonkey scripts would be impossible. Where I can't just copy a piece of HTML to my clipboard, just dumb images.

ezyang12• 14 years ago

I recommend checking out Section 4 of the linked technical report, which discusses how to recover traditional interface elements of the traditional web.

sklivvz1971• 14 years ago

Nothing to see here. Noob who hasn't really felt the pain of Flash or Shockwave, reinvents it. Seems like HN is more and more full of people that don't really have a clue... :-/

michael_miller• 14 years ago

The biggest problem with this is that it eliminates OS-specific facilities, such as the clipboard, OS-style text selection, right click menus, window styling, etc. Yes, these features could be reimplemented, but they are very hard to get right, and near impossible if you are trying to match OS behavior on many platforms.

This suggestion is fundamentally no different than exposing a <canvas> element to a page, and saying "OK, implement your own rendering engine and draw whatever you want in this box." Let's say you wanted to implement a modern browser engine in the canvas, like WebKit. Well, you'd need a huge number of OS specific hooks to get things like the ones I listed above. Do you expose those via an OS API? Well, you just opened a huge number of vectors for an attack. Do you replicate these hooks in your own code? Well, you just created a crappy UX since you're never going to match the OS behavior 100%.

ezyang12• 14 years ago

The difference is that in canvas, you have to reimplement a rendering engine; in native code, you just run WebKit. This is key!

Cross-website communication is certainly tricky, check out section 4 of the technical report.

maxerickson• 14 years ago

The comparison to the browser based web seems like a bad way to sell the idea. Not managing a huge stack is a pretty nice feature, and the comparison invites people to imagine managing the whole stack.

Why not just call it a sandboxed environment and delivery mechanism for untrusted native code?

Then a browser implementation demonstrates how great the security model is and how rich/capable the environment is.

takeda64• 14 years ago

I'm sorry, but the suggestion is plain retarded. The author probably is too young and/or clueless to understand what kind of hell Internet was 15 years ago.

If he wants to experience how it feels, he should just start build Flash based websites.

maxdeliso2• 14 years ago

agreed. I was surprised at the number of responses to the contrary. this 'idea' is nothing new, nothing innovative, and has been proven to be a terrible approach by history time and time again.

coliveira• 14 years ago

Isn't this what Java was about? You were supposed to write code that would run on any platform, and that code would download data from the web and display in any way it wanted. The fact that it didn't work just shows that it is much easier to create UIs that use a common set of standards, instead of creating your own ad-hoc UI for every new web site.

ezyang12• 14 years ago

The difference is that Java doesn't let you use WebKit directly, whereas native code lets you use both, if you so please.

drumdance• 14 years ago

Back in the day, this was the original promise of Java. Content would be rendered inside of applets. ISTR a startup called Texture that tried to do this. They provided pixel-level design tools, the result would compile to a .java file

wamatt• 14 years ago

The point of our current ecosystem is that you can write a moderately portable app, (HTML, CSS, JS) and it is able to run on an x86 OSX browser, or an ARM-based Android phone etc

Either you going to write native machine code, in which case you lose portability, or you going to be writing intermediary byte code. That approach has been done before and failed as a ubiquitous open web standard eg the JVM and the .net CLR.

Today's situation is messy, but it works. Every once in a while there is a crazy idea that is actually pretty decent,...'downloading /browser.exe' is not one of them.

ezyang12• 14 years ago

x86 versus ARM is not a big deal at all; all you need to do is have cross-compiling setup, which for any VM you care about is already well supported. (Note that we are not recommending you start coding your web pages in assembly; your stack should largely look the same in the old world order as it does in the new world order.)

bdunbar• 14 years ago

I can see this fixing some problems I've noticed with browser-based apps in the enterprise.

It could also be the next IE6, lying in wait for an unwary developer.

zzzeek2• 14 years ago

This is called "sandboxing" and contrary to being a "radical departure from the original Internet", the Java VM has been doing this in the applet engine since the mid-90's. It's a complicated platform to work with, though some applications do rely upon it, and it's the source of the most high profile security holes found in the Java platform overall (https://www.google.com/search?q=java+sandbox+vulnerabilities).

ezyang12• 14 years ago

The Java sandbox was actually really close to something that worked well. If you look at the Java virtual machine, it's actually quite simple, and very easy to ensure that nothing "bad" happens. Where Java lost the battle was in the provisioning of APIs which, you know, actually let developers do things like draw windows or load trusted code dynamically: here, it suddenly became necessary to trust huge swaths of code to do the right thing, and the Java sandbox got fucked. If you look at all of the sandbox vulnerabilities, they are never "Oh, the JVM was implemented incorrectly" and always "Oh, some API wasn't implemented properly." That's the key observation.

zzzeek2• 14 years ago

and browser.exe would make none of these mistakes because..... ?

dredmorbius2• 14 years ago

The other place Java lost the battle was in sticking to a closed, vendor-dictated implementation, that's slowly getting pulled into the massive hole of suck that is Oracle.

mike_esspe• 14 years ago

There seems to be an empirical law: You can't sandbox code securely :)

CamperBob2• 14 years ago

True, for the same reason that you don't see (m)any programs based on purely functional programming paradigms. Things with no side effects, no vulnerabilities, and no coupling to the outside world tend not to be very useful.

ezyang12• 14 years ago

This post received a lot more attention than I thought it would; if I had known, I might have explained a few things more carefully. If you didn't immediately dismiss it as stupid and found it at least a little thought-provoking, I highly recommend checking out the technical report http://research.microsoft.com/pubs/173709/submitted-nsdi13.p... (PDF), especially Figure 2 (which describes the entirety of the syscall interface), Section 3 (which describes it) and Section 4 (which talks about how to reimplement traditional browser user interface paradigms in this new world.) It's all quite interesting, and at the very least, might say something about how we should take mobile native apps forward.

Locke16894• 14 years ago

It's very interesting, thank you for posting. One question I have is inspired by some of the discussion about WebGL. You know as well as anyone that one of the most obnoxious and pernicious side-effects is non-termination. This is bad enough in the CPU, but when DoS-like attacks are perpetrated on the GPU shaders or other I/O ports, we can create unfortunate lockups and non-responsiveness. Have you heard of any academic work on this issue?

bzbarsky2• 14 years ago

As I understand, there is work on the hardware end going on to allow things like running untrusted GL on only part of the graphics card's processing units, as well as possible preemption of code on GPUs, precisely to deal with these problems...

Sadly, I have no links, only hearsay.

nico• 14 years ago

I like the idea. I think something similar is already in place: there are JS libraries (eg. jquery) which are required for a website to be rendered. If the library is loaded from a central place (eg. google.com, or the creator of the library), then it can be cached and it doesn't have to be downloaded every time. In the same way, there could be different downloadable browsers, and you could require one for your website.

As a developer, it would be amazing if I could make every user run the browser I used to develop and test my website.

cpeterso• 14 years ago

I worked on Microsoft's Windows 2000 team back in the late 1990s. There was an experimental project to sandbox native code using just NT's ACLs. Fortunately, I don't think anything became of the project because it sounds like an infinite game of Whac-a-Mole.

mikeash2• 14 years ago

He says that a minimal environment is required:

"...all you need is a native execution environment, a minimal interface for persistent state, an interface for external network communication and an interface for drawing pixels on the screen..."

Compared to a modern browser, you've lost the ability to upload and download files, the ability to open URLs in other apps (OAuth, anyone?), the ability to play sound, the ability to use hardware acceleration for video or 3D graphics....

He goes on to say: "This is an interface that is small enough that we would have a hope of making sure that it is bug free." I'm guessing that once you add all the extra stuff you need to reach feature-parity with current browsers, you're going to reach bug-parity with them too.

lmm2• 14 years ago

Many people already suggest running your browser under a separate user account or inside a virtual machine for security; this would effectively be a way to automate that.

mikeash2• 14 years ago

Sure, but you might as well just automate it by shipping browsers that run their code inside the proper sandbox, rather than reinventing the browser.

randallu• 14 years ago

Isn't this already invented and called an iPad or Android? (Or more seriously, this is called NaCL).

But you want to have OpenGL (with shader compiler security bugs you could drive a truck through!). You want to read from cameras and disks, and post notifications and go fullscreen and read/write audio samples and do all the other unsafe things that browsers are currently implementing.

The syscall interface that's explored in the paper doesn't do any of those things; software rendering only, etc.

The challenge in this work is exposing the advanced high-end functionality (GL, media, window system, etc) in a way that's secure and can't be abused. The challenge isn't in defining a syscall interface that lets you run all-software apps (NaCL has solved that problem, but so did the JVM and qemu...). I feel like this paper completely ignores the real issues, and focuses on problems that have been solved well enough or are already understood...

ezyang12• 14 years ago

Eratosthenes is basically NaCL taken to the logical extreme. NaCL itself doesn't go far enough, because it still exposes the traditional browser APIs, when really they should also be run in NaCL. They are fundamentally the same approach, but applied with different amounts.

laughinghan3• 14 years ago

Something I don't see anyone else saying: the World Wide Web's primary "language", HTML, being so incredibly un-powerful and reliant on browsers for new features, is an intentional, FOUNDATIONAL design principle, called the Principle of Least Power: http://www.w3.org/DesignIssues/Principles.html

I'm not saying I completely agree with it, but the rationale behind the principle, and its incredible success, are compelling arguments against what the article proposes, that are not addressed whatsoever.

Also, a nitpick I don't see anyone else making: the author doesn't seem to know the difference between the Internet and the World Wide Web, which is acceptable for a mediocre Web developer, but pretty embarrassing for someone proposing a foundational change to the Web (one that, contrary to the provocative "new Internet" gospel in the first paragraph, doesn't affect the Internet Protocol Suite whatsoever).

(And of course, as pointed out by a plethora of other comments, the proposed foundational change is essentially the Java VM.)

Locke16894• 14 years ago

Edward Yang is very much aware of the difference between www and TCP/IP.

http://ezyang.com/ezyang-resume.pdf

Looking at your GitHub your resume is nowhere near as illustrious. Maybe we can go back to the old days where we were just polite and gave our colleagues the benefit of the doubt instead of assuming that lazy terminology is a signal for incompetence?

lucian303• 14 years ago

Lazy terminology is better known as "inaccurate communication" or simply "bad writing." Ironically enough, writing good English (or whatever language one uses) is just as important, if not more so, than writing good code when it comes to building software.

cynicalkane• 14 years ago

The requirement that one have an "illustrious" GitHub account is one of the more surreal ad hominems I've seen.

laughinghan3• 14 years ago

In hindsight my phrasing came across as very insulting and if I could edit it now, I would. Please note that the intent was merely to snarkily question his domain knowledge regarding Web development, and not to assert he was clearly an incompetent.

I also fully admit that as an undergraduate student, I am nowhere near as impressive as the Stanford PhD student (though you could have chosen a more fair comparison than between a copy-edited resume and a skimming of my "GitHub resume"). I do humbly submit that MathQuill is more substantive than any JavaScript project you or Edward Yang has ever created (or than your or his contributions to any JavaScript project).

derleth3• 14 years ago

> Something I don't see anyone else saying: the World Wide Web's primary "language", HTML, being so incredibly un-powerful and reliant on browsers for new features, is an intentional, FOUNDATIONAL design principle, called the Principle of Least Power:

People have been fighting against this since the Web first hit the mainstream circa fifteen years ago now. First it was tables and single-pixel transparent GIFs, then it was a whole lot of Flash and Java and a few sites done pretty much entirely as JPEGs, then those people got their hands on CSS and Javascript, which is pretty much where we are now.

That got us quirks mode, tag soup, and "This website is best viewed with". OTOH, the semantic web never caught on, either, and a lot of great proposals surrounding microformats died due to nobody caring about them.

It's almost a law, really: The Web is never, and will never be, precisely what you want it to be. However, it will likely be good enough.

camus2• 14 years ago

Dream on , there is and forever will be only one way , the js/html way. Because it is a priviledge to execute one's code on a client machine , not a right. And i want to know what code you are executing. So the future is transparent programming. If you want more capabilites ask browser vendors more APIs. Doesnt make html/js a great solution , both are just horrible and broken , but that's what we have to work with.

eurleif• 14 years ago

> And i want to know what code you are executing.

Have you ever actually tried to read JS code that's been through a minifier, or worse, the Closure Compiler? It's not impossible, but neither is reading disassembled machine code. Either way, you don't have anything close to the original source code.

paulirish• 14 years ago

It's disappointing that Microsoft Research is spending resources trying to solve a problem that Microsoft's Internet Explorer is creating: a frustrating cross-browser development process due to longstanding legacy clients.

maxdeliso2• 14 years ago

>Howell knows how to do this

well why doesn't he explain how we safely present a system API to arbitrary code?

the whole point of the browser is to provide a method for cross platform ui, abstracting the display of an application from the underlying OS. if you were to want to support more than one operating system you'd have to recompile your binaries against all the system APIs that you wanted to support, sysV, winnt, darwin, etc...

and if you were to present an abstraction which would transparently handle the system API difference then you're looking at a JVM, which has been painfully demonstrated to be extremely hard to prevent escalations for, time and time again.

othermaciej• 14 years ago

Seems like a bad idea to me. How will my browser do things such as autofill usernames and passwords, allow links to be opened in new tabs, block third-parties from tracking me with cookies, or allow me to globally change my font preferences if each web page actually uses a different "browser" that it downloaded, and whose only connection to the outside is IP and a framebuffer? Or how would a browser be able to give me crisper text on a Retina display with no change to web pages, or provide hardware-accelerated threaded scrolling, or let me play video with hardware-accelerated decoding?

(These are a few of the things that, as a browser engineer, I expect could not be done in this model.)

Also as a Mac user, I expect this would result in many forms in web pages giving me controls that look and act like Windows.

Against these likely disadvantages, the advantages seem slim. We already have good ways to distribute sandboxed native apps. The Web doesn't need to become one of them.

derleth3• 14 years ago

> How will my browser do things such as autofill usernames and passwords, allow links to be opened in new tabs, block third-parties from tracking me with cookies, or allow me to globally change my font preferences if each web page actually uses a different "browser" that it downloaded

"The only thing here that isn't a threat to our business model and/or Design Vision is password autofill. We'll get right on solving that." -- The MBA Voice in my head

foxylad• 14 years ago

Yes, this might make securing your device easier. But more and more, what I value is on the network - not my local hard drive. Be it a local network git repository, my ISP's email system or my cloud based apps (including my bank's internet portal).

So this hypothetical browser.exe with "only" network connectivity still needs just good a security model as today's browser. And how do know the new browser.exe I downloaded today doesn't have a poisoned security model that allows it to sniff and send my internet banking credentials to the bad guys?

javajosh• 14 years ago

No, no no, a thousand times no. The problem with this scheme is that we lose all that juicy parse-ability and addressability that make the internet so useful and powerful.

Let's face it: the open web is a terrible environment to program in. It is messy and arcane and difficult. But some of this difficulty is not acidental complexity. Some of it is the price we pay for writing apps who's outputs and interfaces are themselves addressable, mutable, and usable.

If apps were to become big opaque blobs of binaries again, yes, they would be easier to program. But is that good for us, or good for the world? What is the long-term cost of making the web?

The promise of real, globally shared coding environments is only just starting to get some legs with tools like jsfiddle revolutionizing the way we solve programming problems together. I can't really share Java code of any complexity with people and be assured that they will be run in a suitable context. The path to creating an environment, compiling and executing Java is intense, and jsFiddle literally eliminates all of that work for the people I want to see my code. Learning the quirks of the open web is a small price to pay for that super-power.

And let me also say that there is still plenty of accidental complexity to eliminate! In particular, servers have been doing far too much for far too long, and once they start doing what they are good at and only what they are good at (which is partitioning the sum total of your information into discrete URL-addressable resources) we will all breath a huge sigh of relieve, and focus on the real problem. (Which is, of course, the monstrosity that is CSS).

ilaksh• 14 years ago

.EXEs are for Windows.

How exactly is this supposed to work for clients on different platforms, like 32bit Windows, 64 bit OSX, linux, ARM, etc. etc.?? You

klrr• 14 years ago

So, does the web developer have to develop a browser for each platform then? Do each web dev have to write their own image library etc.? Intresting idea, but there have to be more effective ways of solving this problem.

Aissen• 14 years ago

This is crazy. So crazy and ambitious. Running a full software stack on a very limited syscall set? You're basically re-defining an OS abstraction, much more so than Firefox OS or Chrome OS. It's the logical continuation of android and ios, at the browser level. So now your browser/OS is only comprised of $(curl | exec -) ?

But there are so many problems to solve. Skimming through the paper shows OP has thought of more problems than me, but there are so many more to solve(yet unforeseen) before this could become even a bit usable. But if you succeed, Microsoft should be worried (and kill your project).

GET /browser.exe

Related Stories