The Next Browser Scripting Language Is — C? 375
mad.frog writes to tell us that in a recent talk by Adobe's Scott Petersen he demonstrated a new toolchain that he has been working on (and soon to be open-sourced) that allows C code to be run by the Tamarin virtual machine. "The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there's some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM's "emulation" of memory to have only a minor overhead over the real thing. The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music."
Where did they get the Zelda on PC? (Score:4, Insightful)
am I the only one bored with the software world? (Score:5, Insightful)
Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!
Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.
Re:Right... (Score:5, Insightful)
Sounds fantastic (Score:2, Insightful)
And highly exploitable as well.
Purpose? (Score:4, Insightful)
This is an interesting hack but it does not do anything for improving either computational theory or improving web application development. Combine C arrays that can be coded within a page like Javascript with a web-browser's security model and you get yourself what exactly? Is this going to improve the speed of development, the security of a thin client, the stability of a browser, the ease of memory usage, the consistency of interfaces or reusability of code? Certainly there will be more features available to a browser client but will there be enough abstraction between the machine and the code to avoid having major security/consistency problems?
It is just not clear to me right now whethere there is a purpose to this beyond satisfaction of an interesting hack.
Ah, the Memories... (Score:5, Insightful)
So Flash can simulating computing as it was back in 1998? Super....
Re:Browser-based OS (Score:5, Insightful)
Well this just underscores how silly the whole web-application thing is. An application running on a browser is a silly idea for the same reason an OS running on a browser is. We already have operating systems to run programs on. Give us native programs, not some horrid mishmash of technologies.
Re:But is it secure? (Score:5, Insightful)
You should email them and tell them about this! Surely they haven't though of such a thing!
Sarcasm aside (sorry, I couldn't help myself), I suspect the VM needs to actually hand you a block of memory, and on accesses it validates that it is within the VM allocated range. Anything less would be silly, however such a thing would provide a huge win (I've tried to do image editing in pure managed code, and then found a massive performance win switching it over to P/Invoke native code).
Re:Right... (Score:5, Insightful)
Well, it must work because I've never had to catch a fish to eat sushi.
bizarre (Score:4, Insightful)
Trying to retrofit C into Tamarin seems bizarre. Why not use an on-the-fly sandboxing native C compiler? Tiny C (tcc) would seem like a good start.
http://bellard.org/tcc/ [bellard.org]
Re:Browser-based OS (Score:5, Insightful)
What the hell are you talking about? Web applications have some really good uses in the real-world (read business world). Instead of updating every computer in the office with a new version of some data management app, it is deployed once.
Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development. Remember visual basic? Thats what web apps do nowadays, and trust me, its better.
As for "your horrid mishmash of technologies" statement, I agree that AJAX is overused, but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.
Re:Browser-based OS (Score:2, Insightful)
Re:Browser-based OS (Score:5, Insightful)
Not really. I do agree that native applications are nicer than web applications, especially if you compare, e.g., Google Docs to Office, or even WordPad.
However what we have discovered is that (1) web applications are easier to write, and (2) it's nice having a consistent platform to develop to, even if that platform is mildly ridiculous (HTML + CSS + JavaScript + Browser-Workarounds + JavaScript canvas thing). Getting stuff to display and layout on this platform is easy, and simple to prettify, far easier than most native platforms have been in the past. There are also a dozen different ways to write the server side of things, and I think for many developers it is nice to be forced to split up the client interface from the meat of the system.
Of course, things are going too far. What should be happening is the simplification of native application programming, with a common platform, etc, without the overhead of having to run a Javascript or HTML rendering engine, and native full-speed canvases. I think that Apple is getting there, QT and KDE4 may be getting there but I haven't really looked into that platform. Java should have gotten there but early design mistakes (AWT, Swing) have killed that off, and SWT is a last-generation UI library. Maybe something like Fenggui on Java might help this platform, but I think Java's dead on the home desktop (and extremely alive and profitable on the server).
Re:Browser-based OS (Score:5, Insightful)
Instead of updating every computer in the office with a new version of some data management app, it is deployed once.
Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time. You get the speed and the portability and the UI consistency and the tech support only needs to support one program.
I agree with you, however, that web apps are the new Visual Basic. They're slow, crappy, and often insecure.
Re:Browser-based OS (Score:4, Insightful)
Web applications have some really good uses in the real-world (read business world). Instead of updating every computer in the office with a new version of some data management app, it is deployed once.
Oh come on, it's not that hard to push an application onto every computer in the office. This is a cop out.
Native programs are optimized for speed, Web Applications are optimized for Rapid Application Development. Remember visual basic? Thats what web apps do nowadays, and trust me, its better.
Then use python with wxwidgets or something. Every bit as easy and portable, a lot faster and safer.
As for "your horrid mishmash of technologies" statement, I agree that AJAX is overused, but believe me it is very nice to be able to do stuff on the server side (think form validation), and then not have to redo on the client-side in javascript.
Frankly, you should be doing everything on the server side.
Re:Browser-based OS (Score:5, Insightful)
#1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.
#2, see #1
#3, everything is done on the server-side, and prior to AJAX, it was redone in Javascript on the clientside for a more responsive user interface. Now, both the client and server use the server-side procedure.
Re:Browser-based OS (Score:3, Insightful)
"Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved."
What if your office runs Windows, Mac OS X, Symbian OS, Debian, Plan 9, Red Hat, MS-DOS and OpenBSD?
I don't know about you, but I'd still rather just update a web application. There are many ways to solve the cross-platform issue, but the web's a particularly zippy one that's very easy to develop for, so why not?
Re:Browser-based OS (Score:5, Insightful)
Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.
That certainly is a simplistic concept. Now, let's talk about largish environments. You know, where the user is running as a limited user, therefore the app can't update itself. Or where windows is required, so we can't use linux's update mechanisms.
Or how about the simple logic that updating one app once is more likely to go smoothly than updating one application 100 times. Or a thousand. No matter how automated, problems crop up.
Honestly, if you are going to argue the point, at least think about your arguments first.
Re:Right... (Score:5, Insightful)
I'm pretty sure the current Linux GUIs owe a lot to to Motif.
Indeed. The violent urge to get rid of Motif has been a driving force in most of the modern GUI development.
Re:Browser-based OS (Score:5, Insightful)
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.
That still doesn't solve the deployment problem. You need rights on the local system to install that software. Why do you need those rights? Because native apps can interact in too many ways, and they can't be trusted, so rights are not automatically granted.
The clever thing about the web platform, and what sets it apart from other platforms, is that the security model by default lets you run any app, even one you don't trust, on any system, without it causing major catastrophes.
The web platform is building on a new concept: ubiquitous internet. The idea is that your applications and data live in the cloud, and are available to you on any device, anywhere, any time. Off-line support is only necessary as a short-term stopgap until the cloud is visible again (like the offline support of google docs).
This is why the web makes sense: it just works. No installs, no administration, no lost data when your local machine fails, no shuttling different versions around on usb sticks. It's true that it's less powerful, but it doesn't matter because the ease of use gained from having the apps and the data "out there" will vastly outweigh the lack of capability for the majority of users.
Re:Browser-based OS (Score:2, Insightful)
What if your office runs Windows, Mac OS X, Symbian OS, Debian, Plan 9, Red Hat, MS-DOS and OpenBSD?
You're fucked either way. Ever tried developing a complex web app that runs on even 7 out of the 8 of the above?
Re:Browser-based OS (Score:4, Insightful)
Well this just underscores how silly the whole web-application thing is. An application running on a browser is a silly idea for the same reason an OS running on a browser is. We already have operating systems to run programs on. Give us native programs, not some horrid mishmash of technologies.
Ideally, web apps should have 3 main advantages over native apps:
1. Easy deploy-ability - No "install" step
2. Vendor-neutral user-interface conventions - Developer only writes to "web standard" and not to Windows nor KDE nor Mac, etc. (X-windows tried to be this, but it is not HTTP-friendly.)
3. Sandbox Security - The web app would not be able to touch local resources, such as user's file system, without explicit permission.
In practice, it has not been quite that simple. For one, standard web interfaces have lack-luster and incomplete widget choices. And, different browsers support JS/DOM differently.
Re:Browser-based OS (Score:3, Insightful)
Or where windows is required, so we can't use linux's update mechanisms.
The truth is that Windows is a corporate OS too (or... in the first place), so it has perfectly working corporate software management mechanism. You just have to be maintain it well and have support from the application developers (who need to stick to good practice while coding their applications - that's usually the most difficult part).
Re:Browser-based OS (Score:3, Insightful)
>Or you could have a sensible package system which does updates (eg, one of the Linux package managers), or have the program itself do the updates (eg, Firefox). Your problem is solved.
There are a couple apps that I will never run outside a browser again.
Mostly Gmail and Google docs.
You literally cannot offer any significant improvement by running it native, and you remove their primary abilities when you do so.
I can access my gmail on virtually every platform, from a PC in my local coffee shop to almost any phone to any "non-mine" computer in the world.
Google apps gets to be the same way--I keep notes on their word-processor (like snippets of code I might need elsewhere), share documents/spreadshets for collaboration, and keep important documents with information that I may need to refer to from elsewhere.
Finally google maps.
All these apps have native alternatives--and I have used them. I never will again.
Although there are issues with the way they are usually implemented--a toolkit like GWT reduces quite a few of the variables since something like a browser incompatibility or security issue can be addressed in one place (within the toolkit) and not in 30 places within your app.
I'm not saying that browser apps are the only way to go--there are obviously issues--but you certainly would block yourself off from a lot of extremely appropriate usage scenarios if you took an absolute stance against them.
Re:Browser-based OS (Score:3, Insightful)
I'm not so sure I'd be willing to call it a "perfectly working corporate software management mechanism".
MSI is a decent format...sorta. However, the format itself allows for all sorts of abuse ( binary executable wrapped up in a MSI? Sure, been there done that ). Further, configuration is often dependent on the developers writing the tools for custom configuration transforms( as apposed to a simple text ini file ).
While MSIs are useful when employed correctly, I'd hardly call it perfectly working. Hell, it'd be a stretch to call it corporate since it doesn't have any built in reporting features.
Re:what? (Score:3, Insightful)
Re:Browser-based OS (Score:3, Insightful)
I lost nearly all respect for RMS after that and the LiGnuX (later gnu/linux) renaming thing. Surely spreading the message to the unconverted is better than bickering with the converted?
Re:am I the only one bored with the software world (Score:3, Insightful)
Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!
Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.
(Clicks reply to this, has text-box open up, clicks quote parent, has parent's comment show up, types comment)
Yeah we all really desperately want to go to the web of 10 years ago.. Are you really saying the web is stagnating?
It's the most quickly developing platform out there, and now more than ever. And thanks to open source it's more open than ever and browser wars are finally about being true to standards and not about breaking them.
(Clicks preview, has comment show up, clicks submit, has comment displayed, continues reading from the comment directly beneath)