Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript. Nothing uniquely qualifies Javascript.
While nothing uniquely "requires' Javascript, replacing it in an existing browser is no easy feat. Look at how much work has gone into making Dart work just in Chrome.
And if any browser is going to replace Javascript, it's going to be Chrome (first), not Firefox - Mozilla is doubling-down on Javascript with both asm.js and FirefoxOS. Google is doubling-down on efforts to replace and/or subvert Javascripts, with both Dart and NaCl.
Nothing uniquely qualifies Javascript now, but being the status quo is a qualification of sorts. Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).
Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).
I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it. It's a real shame we've ended up in a situation where the only API for manipulating the DOM is in js - script tags were not initially intended to be js only. Switching language would be the perfect opportunity to create a proper standard library for the web, by looking at the organic mess which is DOM access, js animation, etc, extracting the good parts, and throwing away all the rest. If it significantly improved dev productivity, and was available as a plugin initially for all browsers, people might be willing to experiment with it.
There are political and technical problems with doing that of course, but it would be a great step forward for web development, and is not at all beyond the reach of a big browser vendor. I agree if it were to be anyone, it'd be Google.
> I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it
You'll get no disagreement from me about the JS stdlib. I was shocked when I found the "correct" way to extract the day of the week from a Date object in Javascript (without third-party libraries): https://stackoverflow.com/questions/4822852/javascript-how-t... [0]
It would be a great feat if/when someone does it. But saying that "Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript" sort of ignores the amount of work required to actually do this (properly).
[0] Of course, this code does already exist internally, as evidenced by (new Date).toString(); you just can't access it.
Many languages have a great stdlib already available, all they need is an improved version of the DOM glue for events and elements (find, adjust, add). It is doable, and the vast majority of script-browser interaction is merely to find and adjust the state of some DOM elements and respond to clicks etc. You could start small and build up and still have something useful, though security and sandboxing might be the hardest issues to cover. New native platform APIs on the desktop or mobile are rewritten from the ground up regularly and those are far, far larger projects (e.g. on Mac OS Classic, Appkit, UIKit, etc).
I think the problem has not been so much that this task is incredibly difficult, but that browser vendors have very little incentive to add a new language in addition to js - it's already a money and time sink maintaining a browser, so they're not going to volunteer to make more work for themselves without a payoff for the corporation paying the bills.
I'm not sure asm.js is a bet on JavaScript, per se. It makes using other languages easier without resorting to a whole new language like Dart, or dependencies on certain platforms with NaCl.
I didn't say it was restricted to a platform, but that it depends on certain platforms, one of which is PNaCl. asm.js does not depend on the existence of such a platform, since it is backwards compatible with JavaScript.
All the API's available in JavaScript are not accessible from asm.js, you can only use asm.js for numerical code. Emscripten has to wrap all those JavaScript libraries. Pepper makes the need for wrapping obsolete, since you just call directly into the functions provided by the sandbox.
GL is easy because it requires no types. Everything that is required is included in the intersection of JavaScript and C++. More highlevel API's are harder, and that's why we don't see any wrappers for e.g. WebRTC in Emscripten.
I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310.
On a serious note, JavaScript and the lack of fragmentation is one of the best features of Web. You don't have to download appropriate browsers (in theory and mostly in practice) to run your website.
> I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310.
But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java. There would be very little difference in the UX between different scripting languages and the current UX w.r.t. media codexes, and the end result would be the same in both cases: there would be some repertoire of languages and codexes that everyone uses and become standard.
The alternative is to forever have to deal with a language that by design cannot even handle integer math or unicode strings properly.
> But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java.
Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in. Dozens of languages? I very much doubt that will happen. Just as we only have a small handful of codexes that actually matter (Flash, Silverlight, H264, maybe ogg) I predict that we will end up with a small number of languages that actually matter: Javascript, Python, Ruby, and Scheme. Maybe CL.
IMHO that would be a better world than the one we currently live in. Javascript is serviceable for its original purpose, but for serious webapps it's broken beyond redemption. NOTE: This is not to say that it is impossible to write serious webapps in Javasceript. Obviously it is possible. What I mean is that at some point the aggregate cost of dealing with Javascript's design flaws becomes greater than the aggregate cost of dealing with multiple browser scripting languages.
> Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in.
That's quite a stretch. There are two browser plugins that are in broad use on the web: Flash, for fallback audio/video support and some casual games, and Silverlight, for Netflix. Both are dead technologies when you consider mobile web; even if you're only thinking about laptops/desktops, both Silverlight and Flash have essentially been abandoned by their creators, and the web platform has almost entirely subsumed their original purpose for existing, currently with the exception of DRM.
Personally, what I'm hoping happens is that we get one, single better compile target, and languages can just target that — giving the web a broader selection of languages without the fragmented nightmare (and security nightmare) of introducing dozens of new plugins. This is something that browser vendors are currently working on: Google with PNACL, and Mozilla (and, to some extent, Google as well) with asm.js. I hope we end up with PNACL, but a sufficiently optimized asm.js would serve the same purpose, albeit with a more difficult debugging / performance optimization story.
Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate?
I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality.
That's not to say the JVM is perfect. I don't like type erasure for instance (I understand C# has 'better' generics). Nevertheless - and this idea comes up frequently - imagine if browsers ran VM bytecode instead of interpreting JavaScript. The browser would be totally language-independent. You could write in any language that compiles to the browser bytecode, and deploy the precompiled bytecode 'object' files. I mean, it is a great idea in theory, and it's exactly what the JVM has succeeded in doing, except that the JVM does it for operating systems and not browsers.
Of course, this is all a fantasy at this point. There's no possible way browser vendors would ever agree on a standardized virtual machine, much less all implement it (see DartVM).
> Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate?
No, I'm not trolling. I was responding to someone who said that the two non-dead browser plugin technologies were flash and silverlight. Java is notably absent from that list. (Can you even interact with the DOM from a Java applet?)
I agree with you that the JVM is the best part of Java, but that's not saying much IMHO.
Java applets had a lot working against them from a technical and UX perspective: they were insecure, and popped up quite scary warning notices about security that had to be clicked through in order to run the applets. Java was also poorly optimized for consumer-facing applications: JIT startup and warmup time was sufficiently long that they felt more sluggish than HTML/CSS/JS, despite the fact that in the long run the JVM outperforms JS by a significant margin.
In an aside, the JVM has only relatively recently been an effective general-purpose compile target, and it wasn't designed as such. The JVM's failure for frontends doesn't give much indication as to where the pitfalls of targets like PNACL or asm.js might be: it died (deservedly) because of reasons that apply to neither technology — slow startup time and lack of effective sandboxing. Both PNACL and asm.js start quickly, lean on hardware-acceleration in the browser to react smoothly, are designed from the start as compile targets, and are sandboxed to the point where browser vendors don't feel the need to pop up warning boxes that scare off consumers.
Incredible amounts of R&D devoted to optimizing its performance, broad hardware and os support, with lots of interesting languages to choose from running on top of it.
>But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java.
For one, if you find it bad, then why would you want to add to this badness with extra web languages? If anything, what you say is a counter-example.
Second, what you describe has stopped happening to 90% of web users for like 5 years or so. Nobody caresa bout Java or Silverlight, and Flash is getting all the more obscure. Heck, major browsers like Safari don't ship it algother, and even YouTube plays without it. At worse, you lose some shitty casual games.
>The alternative is to forever have to deal with a language that by design cannot even handle integer math or unicode strings properly.
Well, we seem to be doing ok even with such a language. Besides, most languages cannot handle unicode strings properly anyway (including Java, Go, PHP, Python, Ruby and several others). There are just too many subtleties.
I don't. (Presuming that by "it" you mean "having a lot of plugins floating around".)
> Nobody caresa bout Java or Silverlight
Netflix uses Silverlight. There are an awful lot of nobodies using Netflix.
> we seem to be doing ok even with such a language
That depends on what you consider "OK". Blub users always think that things are OK.
> most languages cannot handle unicode strings properly
The problem with JS is that the standard requires strings to be represented internally as UTF-16, which cannot cover the entire unicode code point space. So JS's brokenness is worse than other languages because it is actually enshrined in its standard.
What I consider OK is that we have had great growth in the breadth, scope and capabilities of the modern web. I've been on it professionally since 1996, and followed it even before, and I don't think there's anyone who would disagree with such a statement.
From a joke environment based on plain text circa 1993-4, we know have the ability to emulate whole CPUs inside a Javascript VM, AND with usable speed. And then there's ES6 with a whole lot of additions to the language.
>Netflix uses Silverlight. There are an awful lot of nobodies using Netflix.
Well, in the US. The world is 20 times bigger than the US. I'm not even sure why US users put up with Netflix pulling this shit.
>Blub users always think that things are OK.
Well, other's have it worse. They always think that the "blub" concept, a random idea in an essay, is something that's true, universal and settled, were it's just someones opinion. The blub idea, furthermore, is about the "expression problem", and it's condescending to people by assuming that that's all that matters.
People chose to write something in C, C++, Assembly, Lisp, Haskell whatever for lots of reasons, and the success of that undertaking involves a lot more reason than "expression". Things like community, libraries, toolsets, hireability, existing codebase, documentation, speed, heck, even familiarity, play a role as much, or even more, important than the mere "expression" capability of the language.
And, statistically speaking, the oh-so-expression language people don't have much to show for it, whereas the blub C/C++ people have tens of thousands of indispensable programs used by billions. Sure, they are much less, but at one point they were much more (Lisp existed before C/C++), and they also had nice funding going on until the mid-eighties, with not much to show for it. 3-4 C people in AT&T laid the foundation for most of what we use today. Were are the equivalent non-blub people, who had an impact in fields other than PL design?
This is one of the things that baffles me with the somewhat radical things getting added to javascript this go around.
I mean, I can't argue that there are some things that will be nice to have. However, it seems that going with additions that are not addable as a library is contrary to the bloody web.
Or, am I wrong and the new syntactical changes will be ok?
Also... this pretty much exemplifies how/why lisp would have been awesome. Quite literally everything could be done "as a library."
But the parent is really the right answer -- ClojureScript is actually targeted at meeting modern web development challenges and has a thriving ecosystem of powerful tools for the same.
Once you "accept" transpilation,you can use any language in the browser and you stop asking yourself these questions.
You still need to know javascript though. Dart,CoffeeScript,Typescript,ClosureScript... IT's not like people dont have the choice today.And sourcemaps work well when debugging,usually.
You can't simultaneously assert that you can use any language in the browser, and that you still need to know Javascript.
The latter implies that you are always really using Javascript. Which is also borne out by how you list only languages which are thin veneers over Javascript (Dart a possible exception)
Only if every single designer who happens to write some styles has paredit installed. Ditto for every non-technical user who would want to customize some template or something.
Sexps are cool, but you really, really need proper tools to edit them efficiently. Without them it's very easy to make a mistake, which of course will make it to runtime, because it won't be a syntax error in most cases. That's the downside of having so little syntax.
So I think that (for CSS) we'd either build very simple sexp based DSL using macros or we'd just create a compile-to-sexps human friendly syntax. On the plus side, with Lisps, that would be one evening to implement... :)
If you aren't already using templates, then you're probably doing it wrong. If you have a designer doing serious template work and that designer doesn't know anything, then you're probably doing it wrong.
languages like haml and jade are very close to M-expression languages and could work as drop-in replacements for S-expressions just like they are used as <html> replacements at present or s-expr could be used. In addition, in the presence of a lisp language, the code <--> data relationship can be quite convenient.
