HTML extensibility

What do U guys think of a javascript library that would be able to emulate any programming language?

U would write a code inside tag and call a function to parse and interpret the code found in innerHTML property of . Only necessary thing would be one include inside some javascript src tag that calls specific prebuilt interpreter, so there would be no specific installs like new add-ons for browsers.

So, when U build i.e. Python interpreter, U would (automatically, by provided tool) make a new python.js file (from provided grammar and some sugar besides), include it in html and off U go, modifying html DOM from python.

Theoretically, another markup language could be constructed that would replace HTML, if U want that.

I'm interested would this environment be accepted by programmers. The real question is: how much of programmers are satisfied with HTML + javascript and would they want to use some other combination?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Need more info to form a meaningful response.

It sounds like you're working with a hypothetical idea of browser scripting in something other than Javascript.

(Less-than character '<' must be escaped as &lt;, or else it will be mistaken as HTML tag markup that disappears. I assume that's what happened after "property of" in your post.)

I want to encourage your spark of inventiveness combining imagination and analysis here. The world needs more people thinking about how things might be changed, then working out the details. Concrete details include answers to who, what, why, where, when, and how questions. Even if you never describe all of them at once, you need to have answers to all of them in mind.

Think of each person who makes or interacts with an existing tool now, or who might do so in the future. Browser devs, server devs, end user content devs, language library devs, end users etc. Maybe these are all different hats worn by one person in your envisioned model. So call them roles instead. Then you can worry about how many people correspond to those roles later—one doing everything, one role per person or something else. This mostly addresses the "who?" question.

For each role, what are they trying to do? How is it supposed to work? Where is the activity done? When does this happen and how does order affect different roles? Your question about a Javascript library emulating another programming language is hard to understand without detail about who does what and when, as well as why they care and how it's organized.

Is your idea a server side thing, a browser side thing, or both? Is a new browser needed? (This isn't going to happen.) Which parts are static and which dynamic? How does someone debug behavior, and when and where does this occur? Who writes the JS library mentioned? Who uses it? Is the hypothetical Python syntax server-side or browser-side? When does translation, compilation, or emulation occur between writing code and seeing results in a web page served?

I googled around a bit and

I googled around a bit and got this: Skulpt

That is exactly what I was having in mind - client side python interpreter. So unless there is another popular language to emulate inside <object> tag, I think I'll give up

List of languages that compile to JS

The CoffeeScript wiki has a list of languages that compile to (or otherwise run on) JS, including several other implementations of Python and several parser libraries.

By the way, if you want to embed your source code in an HTML page, I recommend <script type="text/plain"> instead of <object>. The HTML parser treats these differently; the script tag can have the characters & and < without escaping. Just be careful if you need your code to contain <!--, </script, or a carriage return. HTML normalizes newlines.

(If you're using XHTML, somewhat different advice would apply, but I'll leave it at this.)

OMeta

OMeta can be used to implement languages and there's a Javascript version.

About OMeta

There is a thing that makes OMeta unattractive to me. While OMeta advocates PEG, it utilizes classic OOP while classes are easily described by PEG (or CFG) itself.

Consider this set of classes described in standard OOP:

abstract class Scape {}

class GroundScape extends Scape {
    contactType: String;

}

class SeaScape extends Scape {
    hydroplanningAbility: Boolean;
}

class SkyScape extends Scape {
    lightstormShield: Boolean;
}

class Vehicle {
    scapeType: Scape;
    use: String;
}

And this is what intrigues me - somewhat modified CFG (or PEG) language can express these classes in following way:

Vehicle (
    ScapeType {
        GroundScape (
            ContactType {Wheels | Magnet}
        ) |
        SeaScape (
            HydroplaningAbility {Yes | No}
        ) |
        SkyScape (
            LightstormShield {Yes | No}
        )
    },
    Use {
        Transport |
        Tourism |
        Cargo
    }
)

Is it just me, or the bottom code is cleaner than classic OOP? Basically it is just another point of view on OOP, so there is a place for improvement for OMeta, even in custom language defined by OMeta itself. So throw another look on PEG or CFG, look what they can do!

i've been

I've been investigating OMeta recently. Remarkable product.