Slashdot Mirror
The Next Browser Scripting Language Is — C?
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."
Is that a pirate copy? Just curious...
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.
primary? ummm... I thought the primary point of layers is so that you can do a lot with only a few simple function calls
http://en.wikipedia.org/wiki/Jury_nullification
So Flash can simulating computing as it was back in 1998? Super....
This is the NFL, which stands for "Not For Long" if you keep making those bulls*** calls.
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.
Give me Classic Slashdot or give me death!
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).
How so? That's like saying sushi bars are there to try to get away from fishing.
Well, it must work because I've never had to catch a fish to eat sushi.
When our name is on the back of your car, we're behind you all the way!
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.
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).
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.
#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.
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
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.
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.