OK, so a couple of people have managed to run this monstrosity and get the message.
Of course, no, I did not write it manually. Potatohead was on the right track with Smile. This is Jsfuck and you can read all about it and try your own code here; http://www.jsfuck.com/ Or checkout the command line toys here: https://github.com/aemkei/jsfuck
Moderators: Sorry about the "f" word there, apart from self censoring a really interesting thing. I don't know what to do with it.
you pobably could change the "uc" to "**" and anyone with 1/2 a brain could figure it out or ask for clarification. Don't use the word and don't want to see it in the forums.
...you pobably could change the "uc" to "**" and anyone with 1/2 a brain could figure it out
Yes but...the logic of that escapes me.
Everybody would immediately know what the bad word is. Therefore the "coded" version of the bad word is equivalent to the actual bad word. Therefore one might as well use the original bad word.
Strangely enough there are worse bad words in English that don't get bleeped out by the forum software. No, I won't give examples.
Everybody would immediately know what the bad word is. Therefore the "coded" version of the bad word is equivalent to the actual bad word. Therefore one might as well use the original bad word.
Strangely enough there are worse bad words in English that don't get bleeped out by the forum software. No, I won't give examples.
That's part of my issue with the "bad word" - it's lost all meaning in the language. In younger generations, it's even lost the shock value it used to have. Now it's like "um" and "uh" - it's filler when you don't know what to say or can't come up with a word. If it doesn't communicate anything then don't use it (not the case here since it is part of the name of a thing). Language should be expressive and communicate ideas - this word has lost all value along those lines.
Of course, the other problem I have with the word is I just don't talk like that - it's generational and my sheltered upbringing more than likely!
But again, it's someone's poor choice for a language name, so we are stuck with it.
Yes, I don't like to hear such words thrown in every sentence as a filler. In fact all such fillers are annoying. There used to be a time when people could not speak with out a "you know" every five seconds. Recently I have noticed a lot of guys giving presentations have to put a "right" or "ok" on the end of every utterance.
I'm not sure about the generational thing, ever hear of "FUBAR"? It dates from 1944!
In the case of brainf*** and jsf*** I think they are very aptly named given what they are and that common meaning of the f word.
Making some controls in the browser may not be so simple, but it's not going to be horribly hard either. A ready made solution might be great. Do you know of one?
None of what I'm suggesting here is restricted to Google or Chrome. This all works in FireFox and IE as well. Version 11 anyway. I believe it works on Safari on the Mac as well.
I don't see the JavaScript/HTML thing failing anywhere. "web apps" seem to be sprouting up all over the place.
No idea about Chrome OS. Only last I heard the Samsung Chromebooks were best sellers on Amazon for a while.
No idea about the "thin clients" mantra either. Web apps can be pretty fat and work locally as well. All seems like a plan to me. In a project like the one that is the topic of this thread that is going to be networking anyway an HTML5 solution seems ideal.
Not that I'm ready to give up my Debian yet:)
Chrome OS usage is increasing, but is pretty miniscule:
I'm currently making a living writing financial market data applications for the Web and mobile platforms, so obviously Web apps aren't failing. But I think the rich Internet apps have constantly been oversold by their proponents. This is a common behavior among computer programmers who tend to advocate for their niche technology. Consider how Forth programmers really like Forth and see it as the solution, while Javascript programmers also see it as the solution. Meanwhile I had a CS professor who insisted it would all be a better world if we used Snobol!
Consider how Forth programmers really like Forth and see it as the solution, while Javascript programmers also see it as the solution.
JavaScript programmers see Forth as the solution? Never heard that before:)
I guess we could easily make a Forth interpreter in JS though.
..rich Internet apps have constantly been oversold
No idea what you mean by "rich" and no idea about who has been doing the oversellling. But clearly web browsers are being asked to do more and more as thier part in networked aplications. Gmail, Evernote, Github, Cloud9, Facebook.... I don't see this trend slowing down any time soon.
You are right. Every new generation finds a new "silver bullet" to rally around. The older generation always sniffs and says it's a fad and whatever it was they used is all you need.
Just as well this happens else we would still be sitting at card punch machines and waiting all night for the operators to get our compilations run.
On the other hand perhaps your CS Prof was right:)
Rich Internet app is the buzzword terminology for Javascript applications running in the browser. Google Wave and Docs would be high profile examples, while Gmail has some RIA features well. The people doing the overselling are Gartner and Forester research who convince senior management that everything will be done in the browser by 5pm next Wednesday, which always seems a week away.
Rich Internet app is the buzzword terminology for Javascript applications running in the browser
No, it is not.
RIA is all about FLASH or Silverlight perhaps even that awful Java stuff. Not HTML5/JavaScript apps. From the wikipedia description:
Users generally need to install a software framework using the computer's operating system before launching the application, which typically downloads, updates, verifies and executes the RIA.[5] This is the main differentiator fromHTML5/JavaScript-based alternatives like Ajax that use built-in browser functionality to implement comparable interfaces.
Luckily the young hipsters who actually do a lot of this JavaScript stuff and give presentations about it at places like JSConf call what they do "web apps" or "single page apps". Much more sensible and descriptive.
Gartner and Forrester should be taken out the back of the wood shed. We are here to discuss how brlliant JavaScript is. Facts not fiction.
Well I've heard it applied to any application where the majority of the code runs in the client's browser, independent of the implementation language. Flash is programmed in ECMAscript with an XML markup language, so frankly it's a similar technology. Silverlight was pretty decent, but Microsoft only reacts to other vendors, they have no strategy and dropped it once Apple declared war on Flash.
Last year I went to a Gartner seminar because my boss's boss couldn't go. The lunch was fantastic, but the presentations were typical hype cycle stuff.
Lunch, hmm..may be the Gartner/Forrester thing has purpose in life after all.
The RIA thing is annoying, I just have a downer on this current fad to say "Rich" go'dam everything.
Having "Rich" and "Forrester" in mind at the same time reminds of "The Bold and the Beautiful" the most nausea inducing export from the USA since agent orange.
I don't love or hate JavaScript/JQuery programming. To me, JavaScript is a tool in my toolbox. I love paychecks and the amount of those paychecks is influenced by how well I can swing my JavaScript tool.
For client side Web programming, both MS and Google are working on replacing Javascript. Typescript is interesting in that in compiles to Javascript, so it's compatible with the installed browsers, but adds real classes and access modifiers. I haven't tried Google's replacement because it is not backwards compatible.
As usual the alternative, the answer to all our problems is....Yet Another Frikken Language (YAFL)
This the the answer I hate the most. Having been gainfully employed programming sine 1980 I have had to use YAFL on pretty much every project I have worked on. Or so it seemed.
Of course in every project you are using a different OS and different libraries etc. Yet Another Frikken Library (YAFL).
Now we have YAFL squared!
Mostly these YAFL's do much the same as the previous YAFL's. A whole new way to learn, to do the same stuff. A whole bunch of new tools, to do the same stuff. A huge waste time.
I am totally sick of YAFL.
P.S. pretty much any language you like can now be "transpiled" to JS and run in a browser of under node.js. It will run nearly as fast as compiling to native code. Just hook it up to your browser API and off you go. See the Propeller WEB tool framework thread for an example. Uses the openspin compiler (C++) in the browser.
I think the problem is that browsers pull source and run it. Which is OK for small tasks like form validation, but problematic as the code grows in size. So programmers developed hacks like minimizing code to speed download time, as well as things like Google's V8 engine which JITs Javascript.
If browsers had a virtual machine and pulled byte code from the server then both the speed problem and language war problem would be solved. It's the browser's insistence to specify a specific language and pull source code that's the problem
@Heater, imagine a parallel universe where Forth was chosen as the browser scripting language, and to write client side code people kept asking you to write Forth. Every program you wrote made you hate it just a little bit more, and you kept hoping that it would go away. That's how Javascript feels to people who hate it.
I think the problem is that browsers pull source and run it. Which is OK for small tasks like form validation, but problematic as the code grows in size.
Have you ever heard of caching?
Pulling source is a brilliant answer to the problem of endlessly having binaries that don't happen to run on the machine you are sitting in front of at the time.
Also a brilliant answer to avoiding the problem of having to install some plugin, FLASH, Silverlight, Java that does not happen to run on the machine you are sitting in front of at the time.
So programmers developed hacks like minimizing code to speed download time,
Hardly a hack. minimizers can be quite sophisticated, in fact they have to be. Why would you not want to minimize download time?
...as well as things like Google's V8 engine which JITs Javascript.
And speeding up an interpreter is a bad thing in which way? Implying that V8 is a "hack" is just silly.
If browsers had a virtual machine and pulled byte code from the server then both the speed problem and language war problem would be solved.
Your memory is failing you. We did that already. Remember Java applets? Big, slow, and unusable. One of the biggest failed software projects in the history of computing.
But hey, you can still use Java Applets if you like. And can tolerate the way everyone will laugh at you.
It's the browser's insistence to specify a specific language and pull source code that's the problem
There is no problem. A standard for this is a jolly good thing. Logically we don't need binaries or bytecodes. Just give me the source.
...imagine a parallel universe...Forth... That's how JavaScript feels to people who hate it.
I strongly suspect that the very laws of physics prevent such a universe from existing. If physics did allow it then I suspect the equivalent of humans in that world would be like apes trying open nuts by bashing them on rocks, rather than bashing the nut with a rock, to dumb to realize that doing things backwards does not work so well. Progress for them would be impossible.
JavaScript is like whisky. At first it tastes horrible and causes you feel, unbalanced, confused and sick. Gack, why would anyone drink this poison? Keep at it and you acquire the taste. Begin to appriciate it's finer points. Become very popular at social gatherings and make lot's friends. Soon you can't understand why anyone would drink anything else.
That only leaves the unbalanced and confused part:)
Those sad and lonely users of Forth and other primitive HLLs, with no social skills, sitting by themselves in the corner at parties and drinking glasses of water, will never understand what this "whisky" thing is all about or why they are avoided by the happy party people.
Heater, compiling source to binary or byte code both minimizes and increases speed, while sending source code over the wire doesn't. Everything you do to improve sending source code is a hack to improve on the initial bad idea. Sure V8 is impressive, but it wouldn't be needed if the architecture was better in the first place.
Applets died because Sun sued MS over their extensions to the JVM, so MS pulled support for them out of IE. At that point it required downloading Sun's JRE which killed the technology. But the MS JVM was actually pretty decent and it used ZIP files to distribute binaries which was fairly effective. We used it for streaming data applications until 2006. We used Flash and Silverlight after that and also achieved pretty decent performance.
The politics don't speak to the underlying merits of the technical approach, and if you recall the performance of Javascript with DOM manipulation was even worse during that era.
If you want to see Google's confidence in their own technology, go to Google Finance and look at an interactive stock chart. Guess what technology Google uses for interactive charts? It isn't Javascript.
Sorry this is going to be rather long as you have managed to squeeze a lot of false and/or off topic statements into a small space.
You have tried very hard to steer the debate away from JS the language to other only marginally related topic like the implementations. But whilst we are here:
...compiling source to binary or byte code both minimizes and increases speed,
Really? This is not true. I can demonstrate. For example:
$ file /opt/parallax/bin/openspin.linux
/opt/parallax/bin/openspin.linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=faa12cdf239f686794bff798e2c872c9710d7571, stripped
$ file openspin.js
openspin.js: ASCII text, with very long lines
$ ls -lh openspin.js
-rw-r--r-- 1 heater heater [B]546K[/B] Mar 12 16:26 openspin.js
$ ls -lh /opt/parallax/bin/openspin.linux
-rwxr-xr-x 1 heater heater [B]650K [/B]Apr 13 20:54 /opt/parallax/bin/openspin.linux
The JavaScript source code of openspin is 16 percent smaller than the natively compiled binary of openspin!
Of course if openspin were written in JS originally, rather than C++, it would be a lot smaller still.
I'll give the speed advantage of natively compiled code. Although it is not very great now a days.
But more fundamentally one could imagine building a compute engine that is designed to run JS. Perhaps with no compilation in software step at all. Your assertion that a compile to binary step is essential is flawed.
..while sending source code over the wire doesn't.
In order to do what we expect browsers to do some kind of code has to be sent over the wire. As demonstrated above sending it as JS source code is more efficient than the legacy binary compilations.
Everything you do to improve sending source code is a hack to improve on the initial bad idea
A false premise. The initial "bad idea" turns out to be a very good idea for saving bandwidth. That openspin.js, for example is already 16 percent smaller than the compiled to binary version. Did I mention it has not been minimized in any way or gzipped yet?
Sure V8 is impressive, but it wouldn't be needed if the architecture was better in the first place.
Another false premise. The architecture is provably superior. See above. Arguing that the V8 interpreter should not be optimized is as silly as say we should not have bothered JITing and optimizing the Java bytecode interpreter, or the Perl run times or the Lisp/Scheme run times or Forth or Spin or many others.
Applets died because Sun sued MS over their extensions to the JVM, so MS pulled support for them out of IE. At that point it required downloading Sun's JRE which killed the technology. But the MS JVM was actually pretty decent and it used ZIP files to distribute binaries which was fairly effective.
A good summary of the history. Does not mean that Applets were not a pile of chicken entrails that nobody wanted anyway.
We used it for streaming data applications until 2006. We used Flash and Silverlight after that and also achieved pretty decent performance.
You don't get much fun at work do you?
The politics don't speak to the underlying merits of the technical approach, and if you recall the performance of Javascript with DOM manipulation was even worse during that era.
Politics have no place in a language war debate. We can discuss the technical merits, which are demonstrably better for JavaScript (See example above again).
Ah, the DOM. The DOM has nothing to do with JS the language. Yes the DOM can be slow and the API is horrible. And everyone hates it. The DOM is specified by a bunch of monkeys in a totally different standards committee. Still, if you can update 16000 DOM elements 30 times a second, which you can, I'd say it was quite fast enough.
If you want to see Google's confidence in their own technology,...
That's tying to diverting from the topic with a false premise thrown in. JavaScript is not a Google technology. It's an ECMA standard. Even if the V8 engine is Googles.
...go to Google Finance and look at an interactive stock chart. Guess what technology Google uses for interactive charts? It isn't Javascript.
So? Google uses a ton of different technologies. That says nothing. For sure those interactive charts can be done in JS now a days. The charts are done in FLASH, probably so that people with ancient MicroSoft browsers can see them.
That's the same FLASH that Adobe has consigned to the graveyard already. Great example. Expect Google to move away from FLASH at some point soon.
Ignoring the DOM is ignoring the principal use case for Javascript, and compiling a single program doesn't prove anything. Compiling to native code includes the runtime which means that the program can stand alone, when you compile to bytecodes the runtime isn't embedded in the binary, nor is it in your original source. So you are comparing an Apple and an Orange. A fair size comparison would be compiling to bytecodes that target a VM, or a native binary versus the source and interpreter.
In financial market data no one uses Javascript because everyone who tries fails hard. That's because in the real world you have to consider all major browsers and get it to work on all of them. It's write once, debug everywhere, and never ship. Particularly in the area of streaming where browser leaks memory as you continuously update the DOM. Maybe in the land of Plato's ideal forms Javascript is decent, but not in the real world.
Options Express still uses applets for development, and we use Silverlight even though we know it is a dead technology. Everyone is waiting for something better to come along in the browser space. Fortunately mobile apps got hot, and we back burned browser development.
Oh and on the server side we were able to talk our way out of the Node.js mandate, so I'm free from Javascript pain for the present time.
Ignoring the DOM is ignoring the principal use case for Javascript...
Actually, ignoring the DOM is exactly what I do:) I can do what I do by drawing on the canvas, or with WEBGL, or with SVG. I can talk to my servers via websockets. I let the other guys worry about where and how they are going to stick that in the DOM.
Well all right. A big part of JS usage involves the DOM. Especially of you are making "web apps". Seems this is not a problem for the likes of Google, Facebook, Github and increasing numbers of others.
...and compiling a single program doesn't prove anything.
Sure it does, I just showed you that the download is smaller. Perhaps a sample of one is not satisfying. I'll work on some more. The propeller loader in propgcc is next up.
Compiling to native code includes the runtime which means that the program can stand alone, when you compile to bytecodes the runtime isn't embedded in the binary, nor is it in your original source.
Yeah so? The point is that for doing what we want a browser to do of course we don't want a run time included in the download. Iv'e already got one running in the browser. What we want is smaller downloads and hence a faster network turn around.
By the way, that openspin.js does actually include a C run time implementation. All that standard C library stuff, printf, fopen, bla, bla is in there.
A fair size comparison would be compiling to bytecodes that target a VM, or a native binary versus the source and interpreter.
That might be "fair" in some way, but it's also a useless comparison. I want a small download. I all ready have the browser and the JS interpreter up and running anyway.
In financial market data no one uses Javascript because everyone who tries fails hard. That's because in the real world you have to consider all major browsers and get it to work on all of them.
I have no doubt that is true.
The HTML5 stuff that you need to get anything interesting done is pretty new and has not matured yet. The MicroSoft world is holding everyone back by imagining that they have to support IE6 or whatever ancient old Smile.
None of this is the fault of JS. It will change in time. FLASH is dead. Adobe is going HTML5. XP and old browsers are falling off the "supported" lists.
It's write once, debug everywhere, and never ship.
Oddly that is not a problem for the aforementioned Google, Facebook, Github and many others. Perhaps the devs in the financial sector are just incompetent
Particularly in the area of streaming where browser leaks memory as you continuously update the DOM.
Only if you are doing it wrong. Or perhaps on an ancient browser. As I said you can update 16000 DOM elements at 30 odd frames per second. No memory leaks there.
Oh and on the server side we were able to talk our way out of the Node.js mandate, so I'm free from Javascript pain for the present time.
Google, Facebook, and Github are primarily text applications that don't stream data. But even Facebook has had problems with fancy pants Javascript development:
Now maybe the developers on my team are incompetent, but to paraphrase a former defense secretary "you write software with the development team you have, not the one you want or need." I don't want to work nights and weekends working around obscure IE bugs.
Comments
Of course, no, I did not write it manually. Potatohead was on the right track with Smile. This is Jsfuck and you can read all about it and try your own code here; http://www.jsfuck.com/ Or checkout the command line toys here: https://github.com/aemkei/jsfuck
Moderators: Sorry about the "f" word there, apart from self censoring a really interesting thing. I don't know what to do with it.
Everybody would immediately know what the bad word is. Therefore the "coded" version of the bad word is equivalent to the actual bad word. Therefore one might as well use the original bad word.
Strangely enough there are worse bad words in English that don't get bleeped out by the forum software. No, I won't give examples.
Scares the pants off me sometimes but in this case luckily I let the machine write that code for me.
Now, the mind of the author of that program...terrifying!
That's part of my issue with the "bad word" - it's lost all meaning in the language. In younger generations, it's even lost the shock value it used to have. Now it's like "um" and "uh" - it's filler when you don't know what to say or can't come up with a word. If it doesn't communicate anything then don't use it (not the case here since it is part of the name of a thing). Language should be expressive and communicate ideas - this word has lost all value along those lines.
Of course, the other problem I have with the word is I just don't talk like that - it's generational and my sheltered upbringing more than likely!
But again, it's someone's poor choice for a language name, so we are stuck with it.
I'm not sure about the generational thing, ever hear of "FUBAR"? It dates from 1944!
In the case of brainf*** and jsf*** I think they are very aptly named given what they are and that common meaning of the f word.
These clips come to mind...
http://www.youtube.com/watch?v=iJMZDBEL8Tg
http://www.youtube.com/watch?v=epDS0h48qRk
C.W.
...let's not forget "SNAFU" also a product of "the Greatest Generation". Soldiers and sailors are a colorful bunch!
As Patton said: "You can't run an army without profanity; and it has to be eloquent profanity. "
Chris, I don't ever remember getting soaped for anything.
Anyway, sorry to distract from the thread, none of this has to do with programming.
On with the debates!!
I got the Ivory soap treatment a couple of times...
On topic, I really like using JavaScript.
My current work project involves doing some pretty cool drag and drop stuff using GoJS.net.
C.W.
Chrome OS usage is increasing, but is pretty miniscule:
https://gigaom.com/2014/02/20/chitika-chrome-os-web-usage-share-doubles-but-is-still-minuscule-overall/
I'm currently making a living writing financial market data applications for the Web and mobile platforms, so obviously Web apps aren't failing. But I think the rich Internet apps have constantly been oversold by their proponents. This is a common behavior among computer programmers who tend to advocate for their niche technology. Consider how Forth programmers really like Forth and see it as the solution, while Javascript programmers also see it as the solution. Meanwhile I had a CS professor who insisted it would all be a better world if we used Snobol!
I have a recent Chrome OS VM.
It's better than the one it replaced, but it's still dog-slow.
I was however able to program my ActivityBot via the S6B with ChromeOS using the webtool developed by Heater and msrobots.
I guess we could easily make a Forth interpreter in JS though. No idea what you mean by "rich" and no idea about who has been doing the oversellling. But clearly web browsers are being asked to do more and more as thier part in networked aplications. Gmail, Evernote, Github, Cloud9, Facebook.... I don't see this trend slowing down any time soon.
You are right. Every new generation finds a new "silver bullet" to rally around. The older generation always sniffs and says it's a fad and whatever it was they used is all you need.
Just as well this happens else we would still be sitting at card punch machines and waiting all night for the operators to get our compilations run.
On the other hand perhaps your CS Prof was right:)
No, it is not.
RIA is all about FLASH or Silverlight perhaps even that awful Java stuff. Not HTML5/JavaScript apps. From the wikipedia description:
Users generally need to install a software framework using the computer's operating system before launching the application, which typically downloads, updates, verifies and executes the RIA.[5] This is the main differentiator fromHTML5/JavaScript-based alternatives like Ajax that use built-in browser functionality to implement comparable interfaces.
Luckily the young hipsters who actually do a lot of this JavaScript stuff and give presentations about it at places like JSConf call what they do "web apps" or "single page apps". Much more sensible and descriptive.
Gartner and Forrester should be taken out the back of the wood shed. We are here to discuss how brlliant JavaScript is. Facts not fiction.
Last year I went to a Gartner seminar because my boss's boss couldn't go. The lunch was fantastic, but the presentations were typical hype cycle stuff.
The RIA thing is annoying, I just have a downer on this current fad to say "Rich" go'dam everything.
Having "Rich" and "Forrester" in mind at the same time reminds of "The Bold and the Beautiful" the most nausea inducing export from the USA since agent orange.
What's the alternative?
How would you....why would you......oh......nevermind!
For client side Web programming, both MS and Google are working on replacing Javascript. Typescript is interesting in that in compiles to Javascript, so it's compatible with the installed browsers, but adds real classes and access modifiers. I haven't tried Google's replacement because it is not backwards compatible.
This the the answer I hate the most. Having been gainfully employed programming sine 1980 I have had to use YAFL on pretty much every project I have worked on. Or so it seemed.
Of course in every project you are using a different OS and different libraries etc. Yet Another Frikken Library (YAFL).
Now we have YAFL squared!
Mostly these YAFL's do much the same as the previous YAFL's. A whole new way to learn, to do the same stuff. A whole bunch of new tools, to do the same stuff. A huge waste time.
I am totally sick of YAFL.
P.S. pretty much any language you like can now be "transpiled" to JS and run in a browser of under node.js. It will run nearly as fast as compiling to native code. Just hook it up to your browser API and off you go. See the Propeller WEB tool framework thread for an example. Uses the openspin compiler (C++) in the browser.
I try really hard to avoid it. But like pollution it get's everywhere. Some times exposure is inevitable. Causes sickness and diarrhea.
If browsers had a virtual machine and pulled byte code from the server then both the speed problem and language war problem would be solved. It's the browser's insistence to specify a specific language and pull source code that's the problem
@Heater, imagine a parallel universe where Forth was chosen as the browser scripting language, and to write client side code people kept asking you to write Forth. Every program you wrote made you hate it just a little bit more, and you kept hoping that it would go away. That's how Javascript feels to people who hate it.
Pulling source is a brilliant answer to the problem of endlessly having binaries that don't happen to run on the machine you are sitting in front of at the time.
Also a brilliant answer to avoiding the problem of having to install some plugin, FLASH, Silverlight, Java that does not happen to run on the machine you are sitting in front of at the time. Hardly a hack. minimizers can be quite sophisticated, in fact they have to be. Why would you not want to minimize download time? And speeding up an interpreter is a bad thing in which way? Implying that V8 is a "hack" is just silly. Your memory is failing you. We did that already. Remember Java applets? Big, slow, and unusable. One of the biggest failed software projects in the history of computing.
But hey, you can still use Java Applets if you like. And can tolerate the way everyone will laugh at you. There is no problem. A standard for this is a jolly good thing. Logically we don't need binaries or bytecodes. Just give me the source. I strongly suspect that the very laws of physics prevent such a universe from existing. If physics did allow it then I suspect the equivalent of humans in that world would be like apes trying open nuts by bashing them on rocks, rather than bashing the nut with a rock, to dumb to realize that doing things backwards does not work so well. Progress for them would be impossible.
JavaScript is like whisky. At first it tastes horrible and causes you feel, unbalanced, confused and sick. Gack, why would anyone drink this poison? Keep at it and you acquire the taste. Begin to appriciate it's finer points. Become very popular at social gatherings and make lot's friends. Soon you can't understand why anyone would drink anything else.
That only leaves the unbalanced and confused part:)
Those sad and lonely users of Forth and other primitive HLLs, with no social skills, sitting by themselves in the corner at parties and drinking glasses of water, will never understand what this "whisky" thing is all about or why they are avoided by the happy party people.
Applets died because Sun sued MS over their extensions to the JVM, so MS pulled support for them out of IE. At that point it required downloading Sun's JRE which killed the technology. But the MS JVM was actually pretty decent and it used ZIP files to distribute binaries which was fairly effective. We used it for streaming data applications until 2006. We used Flash and Silverlight after that and also achieved pretty decent performance.
The politics don't speak to the underlying merits of the technical approach, and if you recall the performance of Javascript with DOM manipulation was even worse during that era.
If you want to see Google's confidence in their own technology, go to Google Finance and look at an interactive stock chart. Guess what technology Google uses for interactive charts? It isn't Javascript.
Sorry this is going to be rather long as you have managed to squeeze a lot of false and/or off topic statements into a small space.
You have tried very hard to steer the debate away from JS the language to other only marginally related topic like the implementations. But whilst we are here: Really? This is not true. I can demonstrate. For example: The JavaScript source code of openspin is 16 percent smaller than the natively compiled binary of openspin!
Of course if openspin were written in JS originally, rather than C++, it would be a lot smaller still.
I'll give the speed advantage of natively compiled code. Although it is not very great now a days.
But more fundamentally one could imagine building a compute engine that is designed to run JS. Perhaps with no compilation in software step at all. Your assertion that a compile to binary step is essential is flawed. In order to do what we expect browsers to do some kind of code has to be sent over the wire. As demonstrated above sending it as JS source code is more efficient than the legacy binary compilations. A false premise. The initial "bad idea" turns out to be a very good idea for saving bandwidth. That openspin.js, for example is already 16 percent smaller than the compiled to binary version. Did I mention it has not been minimized in any way or gzipped yet? Another false premise. The architecture is provably superior. See above. Arguing that the V8 interpreter should not be optimized is as silly as say we should not have bothered JITing and optimizing the Java bytecode interpreter, or the Perl run times or the Lisp/Scheme run times or Forth or Spin or many others. A good summary of the history. Does not mean that Applets were not a pile of chicken entrails that nobody wanted anyway. You don't get much fun at work do you?
Ah, the DOM. The DOM has nothing to do with JS the language. Yes the DOM can be slow and the API is horrible. And everyone hates it. The DOM is specified by a bunch of monkeys in a totally different standards committee. Still, if you can update 16000 DOM elements 30 times a second, which you can, I'd say it was quite fast enough.
In financial market data no one uses Javascript because everyone who tries fails hard. That's because in the real world you have to consider all major browsers and get it to work on all of them. It's write once, debug everywhere, and never ship. Particularly in the area of streaming where browser leaks memory as you continuously update the DOM. Maybe in the land of Plato's ideal forms Javascript is decent, but not in the real world.
Options Express still uses applets for development, and we use Silverlight even though we know it is a dead technology. Everyone is waiting for something better to come along in the browser space. Fortunately mobile apps got hot, and we back burned browser development.
Oh and on the server side we were able to talk our way out of the Node.js mandate, so I'm free from Javascript pain for the present time.
Well all right. A big part of JS usage involves the DOM. Especially of you are making "web apps". Seems this is not a problem for the likes of Google, Facebook, Github and increasing numbers of others. Sure it does, I just showed you that the download is smaller. Perhaps a sample of one is not satisfying. I'll work on some more. The propeller loader in propgcc is next up. Yeah so? The point is that for doing what we want a browser to do of course we don't want a run time included in the download. Iv'e already got one running in the browser. What we want is smaller downloads and hence a faster network turn around.
By the way, that openspin.js does actually include a C run time implementation. All that standard C library stuff, printf, fopen, bla, bla is in there. That might be "fair" in some way, but it's also a useless comparison. I want a small download. I all ready have the browser and the JS interpreter up and running anyway. I have no doubt that is true.
The HTML5 stuff that you need to get anything interesting done is pretty new and has not matured yet. The MicroSoft world is holding everyone back by imagining that they have to support IE6 or whatever ancient old Smile.
None of this is the fault of JS. It will change in time. FLASH is dead. Adobe is going HTML5. XP and old browsers are falling off the "supported" lists. Oddly that is not a problem for the aforementioned Google, Facebook, Github and many others. Perhaps the devs in the financial sector are just incompetent
http://blog.ness.com/spl/bid/82156/Facebook-Abandoned-HTML5-Should-You
Now maybe the developers on my team are incompetent, but to paraphrase a former defense secretary "you write software with the development team you have, not the one you want or need." I don't want to work nights and weekends working around obscure IE bugs.