OSDev.org

These times, many popular OS have included support for a new type of applications. These applications are not compiled machine code, nor some kind of bytecode. They are made of only 3 things: HTML markup, CSS rules, and JS code. These applications have one arguably powerful advantage: they are portable, since they are only made of text files, to any imaginable architecture. But the drawback is that these are interpreted languages, which are fundamentally slower than compiled languages (even though V8 makes them quite easy anyways), and provide very easy ways to code a GUI and access the Cloud to provide web-oriented applications.

It all started with Windows Vista including these on a side of the desktop, through the Windows Gadgets. It extended in Windows 7, and now, it has become the Metro apps in Windows 8. Since its beginning, Google's Chrom(e/ium) OS includes such applications, and Mozilla's new mobile system, though not very popular, only has such applications.

So here's my question, in times where computer technology is orienting towards the Cloud, do these applications play such an important roal ? And should a new Operating System support them ?

AbstractYouShudNow wrote:So here's my question, in times where computer technology is orienting towards the Cloud, do these applications play such an important role?

That's a question of speculation.

And should a new Operating System support them ?

Depends on the design of the OS.

Such web languages have no reason to be inherently interpreted.

Somebody could perfectly build a compiler along with an IDE, so that JavaScript code gets natively compiled, and the HTML/CSS gets converted into the application's resource data (be it for Windows or another type of binary).

That of course would be a huge advantage, since now we could use the same JavaScript code for regular web pages as well as for regular applications.

Probably if HTML5 and low-level features such as Typed Arrays (binary data), sound and 3D graphics APIs, Canvas, input, etc., keep becoming more and more capable, somebody or some of the bigger companies (Mozilla, Google, Microsoft...), and not to mention open-source compiling tools, naturally, will realize that turning JavaScript/CSS/HTML/HTML5 into a natively-compiled, all-purpose language, is a must for the industry and to make programmers more productive overall.

Hi,

~ wrote:Such web languages have no reason to be inherently interpreted.

Somebody could perfectly build a compiler along with an IDE, so that JavaScript code gets natively compiled, and the HTML/CSS gets converted into the application's resource data (be it for Windows or another type of binary).

From what I understand (I've never tried it but vaguely remember talking to someone that was writing a "subset of JavaScript" compiler) there are parts of the JavaScript language that make it virtually impossible to compile to native code - e.g. "eval()", late binding, dynamic type checking.

This doesn't necessarily mean that you couldn't (e.g.) compile as much as possible to native code, and then have some sort of JIT compiler at run-time to do the remainder.


Cheers,

Brendan

m12 wrote:

AbstractYouShudNow wrote:So here's my question, in times where computer technology is orienting towards the Cloud, do these applications play such an important role?

That's a question of speculation.

I don't mean from a marketting standpoint. What I mean is that such applications allow us to be more productive, and the dynamic nature of these languages allow for very dynamic applications, with very adaptive UIs. Additionnally, this could allow the OS designer to blur the limit between a "Web-Based" application and a Web Page, so that an application could interact with the website, and vice versa. For example, imagine a "MySocialNetwork" application. The website, when open, would open as the application which would interact transparently with the website, and the web pages (with some security considerations, of course) could access their corresponding applications.
Now, imagine a "Google Search" application. It could call upon the google.com website for its searches, and the 'profiling' settings of that site would also apply to the application, hence allowing one to write cloud-oriented apps very easily and productively.

m12 wrote:

AbstractYouShudNow wrote:And should a new Operating System support them ?

Depends on the design of the OS.

That's true, but whatever the OS design is, assuming a general purpose OS, it could always be interesting to be able to quickly and productively create cloud-based applications, since the code would run on anything once written, and users globally switch to the cloud, enforcing us, as OS designers, to review our OS designs to support such usages.

~ wrote: Such web languages have no reason to be inherently interpreted.

Somebody could perfectly build a compiler along with an IDE, so that JavaScript code gets natively compiled, and the HTML/CSS gets converted into the application's resource data (be it for Windows or another type of binary).

As Brendan said, this is possible until you consider the dynamic features of these languages. I think the most we can do is a form of bytecode which gets converted to native code by some JIT compiler, and pre-compiling applications makes them loose their platform-independance, which is one of the main advantages of this kind of programming. On the other hand, runtimes such as Adobe AIR (or Qt, as far as I know, which means not very much ) actively use languages such as JavaScript.

~ wrote: That of course would be a huge advantage, since now we could use the same JavaScript code for regular web pages as well as for regular applications.

Probably if HTML5 and low-level features such as Typed Arrays (binary data), sound and 3D graphics APIs, Canvas, input, etc., keep becoming more and more capable, somebody or some of the bigger companies (Mozilla, Google, Microsoft...), and not to mention open-source compiling tools, naturally, will realize that turning JavaScript/CSS/HTML/HTML5 into a natively-compiled, all-purpose language, is a must for the industry and to make programmers more productive overall.

That's the point of the thing, and the possible applications are just infinite, as long as we give these applications powerful APIs that are secure enough not to be paranoid when running them. As long as wethe OS manages all the security-critical things (for example, we don't enable applications to open an arbitrary file, but instead, we only allow them to call a function that asks the user which file to open, and return an open file descriptor. For the rest, we provide the application a specific API to access its resource files and temporary files. In short, a good API design would definitely eliminate Evilware by just making it impossible for anybody to create them.
For completeness sake, we could also implement a monitor which would watch the app's activity to ensure that nothing potentially harmful i sperformed by the application...

AbstractYouShudNow wrote:
I don't mean from a marketting standpoint. What I mean is that such applications allow us to be more productive, and the dynamic nature of these languages allow for very dynamic applications, with very adaptive UIs. Additionnally, this could allow the OS designer to blur the limit between a "Web-Based" application and a Web Page, so that an application could interact with the website, and vice versa. For example, imagine a "MySocialNetwork" application. The website, when open, would open as the application which would interact transparently with the website, and the web pages (with some security considerations, of course) could access their corresponding applications.
Now, imagine a "Google Search" application. It could call upon the google.com website for its searches, and the 'profiling' settings of that site would also apply to the application, hence allowing one to write cloud-oriented apps very easily and productively.

Applications can already interact with websites and have for years. Larry Ellison had a great quote about all the hype regarding the cloud which went something like "Clouds are water vapor. No seriously it's the same client-server stuff we've been doing at Oracle for years." Which in essence it is, just with a web based front end. The alternative to a web based front end is to just code a native application that communicates over the internet. There's no need for web languages to do this, it's client server and has been done for years.

AbstractYouShudNow wrote: That's true, but whatever the OS design is, assuming a general purpose OS, it could always be interesting to be able to quickly and productively create cloud-based applications, since the code would run on anything once written, and users globally switch to the cloud, enforcing us, as OS designers, to review our OS designs to support such usages.

Once again this basically just comes down to an open or universal API. The web serves this function to some degree, but so do many cross platform libraries. Just about everything that is accomplished by seven layers of web cruft could be almost as easily implemented by a native implementation of one of many widget/application libraries. Qt being a great example.

AbstractYouShudNow wrote: As Brendan said, this is possible until you consider the dynamic features of these languages. I think the most we can do is a form of bytecode which gets converted to native code by some JIT compiler, and pre-compiling applications makes them loose their platform-independance, which is one of the main advantages of this kind of programming. On the other hand, runtimes such as Adobe AIR (or Qt, as far as I know, which means not very much ) actively use languages such as JavaScript.

I don't know about Adobe AIR, but Qt enables the use of an ecmascript derivatives for scripting purposes. Until QML it wasn't coupled very tightly with the language at all. A language having a dynamic or static type system doesn't really make it any more or less portable either. It's the fact that these applications are essentially distributed as source code that tends to make them portable, along with a well defined standard api.

AbstractYouShudNow wrote: That's the point of the thing, and the possible applications are just infinite, as long as we give these applications powerful APIs that are secure enough not to be paranoid when running them. As long as wethe OS manages all the security-critical things (for example, we don't enable applications to open an arbitrary file, but instead, we only allow them to call a function that asks the user which file to open, and return an open file descriptor. For the rest, we provide the application a specific API to access its resource files and temporary files. In short, a good API design would definitely eliminate Evilware by just making it impossible for anybody to create them.
For completeness sake, we could also implement a monitor which would watch the app's activity to ensure that nothing potentially harmful i sperformed by the application...

It's very easy to just propose this, it's much harder or perhaps impossible to actually implement such a thing. People have been proposing this for years and trying to implement it with some success, for example Java and Silverlight. Big problems persist because they're hard to solve, that's why no one has solved the energy crisis with a compost fueled car.

Brendan wrote:Hi,
From what I understand (I've never tried it but vaguely remember talking to someone that was writing a "subset of JavaScript" compiler) there are parts of the JavaScript language that make it virtually impossible to compile to native code - e.g. "eval()", late binding, dynamic type checking.

I know nothing about JavaScript but I've implemented Lisp compilers which have eval and Lisp is a late binding dynamically typed language. Javascript experts will have to correct me where I make wrong assumptions.

First of all, late binding is a hot-linker issue - no different from runtime linking of libraries in conventional systems - and dynamic type checking can easily be done by compiler generated code.

Now eval usually is implemented as an interpreter which the compiled code calls, but I actually implemented it as a compiler which generated the code, passed it on to the hot-linker, and then just did a jump to the address the code was installed at. The compiled eval needs the system to be able to garbage collect code if it is called often. The advantage of the interpreter approach is that you can have this interpreter save execution state and turn it into a interpreter/debugger - imagine that it checked the arguments for user defined breakpoints. So to cut to the chase, a language with an eval like function can be compiled but the runtime needs some way to execute the argument.


Edit: I really need to point out that the theory of all this was sorted out, implemented, and described by the early 1960s. See McCarthy et al, LISP 1.5 Programmer's Manual, MIT Press, 1962. Anybody interested in all these fancy new programming languages can read this book and see how the granddaddy of them all is a vast improvement on most of its successors.

one nice feature of html and js and that html has an object/embed tag as well, who can bind an interface to a c++ object useable in javascript, it's what modern broswer are evolving toward, having some built in or pluging functionality embeded into the browser that are avaible for scripting with javascript, and it can be used to give wide system access from web browser and javascript

even systems like COM or corba was close to this kind of thing to expose some system component to remote application, and it didn't even require web access to make those component avaible, html page in that sense are just a way to create a layout for plugins and make them scriptable, but it's not the most efficient system to achieve this, and it's nothing new in the concept

You can embed Javascript in any application - Google V8 and Mozilla SpiderMonkey, Apple JavaScriptCore, etc. are written in cross platform C++, so you can easily embed them in any application as a scripting language.

Currently, you can't directly execute standalone Javascript applications on most desktop platforms, but you can make a runtime stub using V8 or SpiderMonkey with basic OS-level wrappers (similar to how .Net and JVM have a runtime.) I don't know if there's a general purpose desktop Javascript VM for this, but I do know of some domain-specific ones (such as game frameworks that are designed to run in a browser, on desktop, and mobile.)

Many languages compile to JavaScript including C++ and .Net IL.

On the topic of performance; modern Javascript engines JIT to machine code. Yes, it is not perfect (you can't JIT a script that runs an eval() on a dynamically generated string, for example.) New versions of Javascript (supported in SpiderMonkey and maybe V8) feature static typing - this goes a long way in assisting the JIT compiler to generate high performance code.

There is a subset of Javascript called ASM.JS - it takes the very basics of Javascript (statements, expressions, branches, math operators, functions) and is backwards compatible with any modern JS engine, and is designed to be both; a target language for compilers (e.g. Emscripten for C++), and to be easily optimized by a JIT compiler.

The Unreal Engine has been compiled to ASM.JS/WebGL - on this topic, in many video games, the GPU is more of a performance bottleneck than the CPU - and many have found the performance impact of compiling to ASM.JS is negligible in GPU-heavy applications.

However, remember that most web code doesn't follow best practices, but if you're writing a serious web application then there are plenty of guides out there on what to avoid.

If you follow best practices (avoid dynamic features, avoid thunking between Javascript and C++ too often) then you can get some serious performance out of a modern Javascript engine.