Web Programming and Interpreted Languages are the same thing.
Client side web programming and interpreted languages are the same thing. Each runs on top of a platform that provides a layer between the operating system and the application you write. Each requires the user to download (or have already installed on their machine) some sort of "virtual machine" that intreprets text directly or some form of middle language (CL in .NET, bytecode in Java, etc.). The only real difference (and it is a biggie) is that Internet Explorer or Firefox is effectively installed on every machine connected to the internet. Both of them sufficiently support a content language (HTML), a positioning language (CSS), and a scripting language (Javascript). Why aren't we writting application servers that deliver code (in a text form, like HTML is delivered) to the browser that can then be interpreted by a plugin for the specific scripting language it's intended for (Perl, Python,Lisp,Ruby,etc.)? This would give you the centralization available with web applications, and the GUI reaction speed of an interpreted program running on your local machine. Am I the only one who thinks this would make the delivery of programs really easy while also making them user friendly?
posted by Josh at 12:07 PM
1 Comments:
No, you're not the only one.
I've been thinking about this too and, to a limited extent it is possible; the client can request Javascript functions in the form of JSON which it can then eval on the fly. The main problem is that it would only work with individual functions and so would only be useful for fairly short, self contained tasks.
Post a Comment
<< Home