Slashdot Mirror
Trying To Bust JavaScript Out of the Browser
eldavojohn writes "If you think JavaScript is a crime against humanity, you might want to skip this article, because Ars is reporting on efforts to take JavaScript to the next level. With the new ECMAScript 5 draft proposal, the article points out a lot of positive things that have happened in the world of JavaScript. The article does a good job of citing some of the major problems with JavaScript and how a reborn library called CommonJS (formerly ServerJS) is addressing each of those problems. No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"
it's just sometimes, it's a resource hog.
I actually wish JavaScript and other client-side browser scripting would be done away with completely, but JS is not a particularly 'good' language. The only advantage I can see is that thousands of Web developers can now write desktop applications. Is that necessarily a good thing? or will it just lead to more inefficient crapware?
Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.
It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it. Things change when you realize how useful something actually is.
JavaScript is already out of the browser, but unofficially or rather unstandardized. Look at languages such as JavaScript in Flash, or the use of JavaScript in Acrobat PDF Reader, etc. Microsoft allowed their JScript (variant of JavaScript) to be used on the server side years ago in classic Active Server Pages - so I coded JavaScript on the server several years back.
However I am in support of a more official representation of JavaScript on the server.
As somebody who's attempted to write object-oriented Javascript code, my response would be GOD NO.
No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"
If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get? I'm a developer and I can't think of anything MORE front then the front end...
If you're talking about Taking Javascript and making it more integrated with the actual web page display, AJAX already handles most of that. We don't need Javascript to become like PHP, where you're using PHP to write your HTML inside of your PHP script tag inside of an HTML body.
I've been a big user of BSH ever since it came out, and before that a hacked Rhino/Spidermonkey fan for building system automation components that were scriptable via javascript.
I say bring it on.
While JavaScript has a good thing going with the web scripting niche, it has a long road to catch up with established players in the heavyweight "everything and the kitchen sink" language category currently filled by C# and Java. It is very difficult to see mainstream platform developers selecting JavaScript as their general purpose language in favor of C#, Java, or even C or objective C (for the Linux and Mac developers respectively). JavaScript would do better to reduce its footprint and burnish its credentials as a web scripting language because that is what we need it to be; after all, we already have good languages in the general purpose category that are NOT suitable for web scripting.
Javascript is a beautiful, elegant, small and generally well-formed language. It has a couple of warts, but what language doesn't.
However, the way that Javascript interacts with web browsers, web pages and all other things web-like is a disgusting, crufty, bloated piece of shit. The DOM bindings are horrible, as far as they go, and they're woefully incomplete. The browser deficiencies in their implementations of the DOM bindings, and the browser-specific work-arounds needed to circumvent said deficiencies, are Lovecraftian nightmares.
(The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))
Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript.
Why doesn't the gene pool have a life guard?
KILL IT WITH FIRE
I think everyone can agree what we really need is web-executable COBOL.
When things get complex, multiply by the complex conjugate.
the Johnny Knoxville of programming languages
"I disapprove of what you say, but I will defend to the death your right to say it." - Evelyn Beatrice Hall, re Voltaire
... the browser might just as well support GWBasic. However fancy javascript may be , it doesn't take the worlds most advanced scripting language to to do pop up windows ,mouseover events and selective loading.
Instead of trying to makd the browser a cut down OS as both MS and Firefox coders seem to be headed for, they should go back to basics and make the browser a simple reliable graphics display program with some user I/O thrown in. Not some bloated monstrosity that has all the reliability of a 20 year old unserviced Trabant. Having to support an ever more complex OO interpreted language doesn't help this reliability.
I'm not sure why anyone would want JavaScript anywhere else. I believe that the only reason why JavaScript is "popular" in the first place is because it is the only option available for client-side processing on the web.
A lot of the pain of JS, like its inconsistent experience across browsers, can't really be held against it. Each browser has to implement JS according to its own interpretation of the standard, virtually guaranteeing a non-consistent experience across the board. I understand that. But what truly kills JavaScript for me is the lack of development tools and a solid reference. Debugging JS with an alert window is a horrible experience.
Again, why anyone would want this stuff everywhere is beyond me. I was shocked a long time ago when Palm Pre decided it was a good idea to use JavaScript for app development. Shocked I tell you. And look where that went. Like I said, the only reason I would consider JS "popular" on the web is because there is no other way to do client-side processing. It's literally our only choice (VBScript doesn't count).
If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get?
Repeat after me: Javascript is not Java. Don't confuse the two, they are completely different technologies.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
C'mon. Perl has them. Lua has them. Ruby has them. Sheesh -- even Python has them. I'd guess even PHP has lexical closures these days. Advanced? You just disqualified yourself. Under which kind of rock have you been living the last 30 years?
Besides, I'd rather compare Javascript to a Gingko fruit. The stink is similar ;-D
[wow: captcha was "discord". This slashcode is developing some prescient intelligence, I fear]
it's just sometimes, it's a resource hog.
A bad workman always blames his tools
Summation 2
As a Java coder who wants to go back to C++ I'm appalled. But, as a developer who gets beat up over the cost of my work, I can see that a scripting language could lower costs. It's not for me though.
Sure a JavaScript engine may have shipped on "every computer ever" but it's been embedded into a browser. So the next step is to decouple it from that browser-based engine and use it to create local apps?
What would you run this script engine in? A Virtual Machine? Some kind of embedded OS Framework? A behind-the-scenes browser instance (shudder).
Either way, I don't get it, what magical app could I write only with JavaScript that I couldn't write with something else? Actually I do kind of get it, there are probably a lot of JavaScript hackers out there that would want to write desktop apps but are afraid to jump into something like Java or .NET.
crazy dynamite monkey
3) Are you a developer, or a guy who makes web apps?
Wait, since when is there a difference? I consider myself a developer, but my applications are only available on the web..
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
A lot of the comments are pointing out the problems in Javascript, and ignoring the problems in the big heavyweight languages like Java and C#.
It's not really in praise of Javascript, but a very good read is Joel's article 'Can Your Programming Language Do This?' It accurately points out a number of ways in which Java development very quickly takes up a lot of lines of code compared to more lightweight approaches. I personally prefer the light weight approach for many applications.
http://www.joelonsoftware.com/items/2006/08/01.html
I don't think it's fair to call JavaScript a crime against humanity -- most humans aren't software developers...
I would say that JavaScript has potential, just like Luke Skywalker. Both had the ability to do great things and both had/have the ability to do terrible things.
Question is... who is.. Who's JavaScript's father? And will he lead him down the dark side?
The idea of Javascript is nice. In practice it's hardly what you describe.
Consider how closures work in Javascript. It's totally retarded and the scoping doesn't work like you think it would.
Lua has basically the same semantics as Javascript but it much simpler, faster, and you get a better design (eg. closures work like they should). Lua is a better Javascript than Javascript.
It's a tolerable front end language for browsers. It's not as flexible or as fast as C++, but here's a newsflash to the "I'm living in Mom's basement crowd." It doesn't have to be.
It can suck up resources and not be especially fast and not be able to manipulate pointers or be much good for creating new classes and....
(sing it with me now) IT DOESN'T MATTER AND 99.99% OF WEB DEVELOPERS DON'T CARE.
Not all languages are C++, or Ruby, or Java or anything. Nor should they be. Use the right tool for the right job.
Please do not read this sig. Thank you.
I agree; JS should be taken out of the browser... but not how the article suggests. It should NOT be brought to the desktop, and it should be obsoleted in the browser.
Its a steaming pile who's replacement is long overdue.
Scripts are fine for small mundane tasks, they're NOT good for building applications.
What have you done?! Put it back! Put it BACK!
This is the book that'll make you realise Javascript is OK:
http://oreilly.com/catalog/9780596517748
It's not afraid to call out the bad parts, and to show you how to work around them. That's down to a rushed standardization process.
It doesn't deal with the DOM at all - after all, that's not part of JS.
It leaves you thinking JS is pretty neat, if you use it right.
This is madness!... This is Javascript!
I fully support running JavaScript outside the browser. I think that will only drive more optimization and fixes. My main problems with JavaScript come from the fact that it is running in the browser and the interactions with DOM and security considerations that brings.
I really wish the browsers provided more detailed controls for configuring the JavaScript environment so I could tune it to my tastes and kill any naughty scripts.
What is the difference between a 'script' and an 'application'?
Just make the damn thing behave exactly the same way in every browser and I'll be sound as a pound!
/* No Comment */
System architect: "Here's my design. It will work in any language."
Coder wanting to add a notch to his belt: "I know just the thing for this distributed ERP system: JavaScript! It's the latest technology and we'll be cutting edge.
The architect - who hasn't been keeping up with languages and thinks Java and JavaScript are one in the same: "Sounds great."
Oh, yeah! There's a team I would want to contract on - billable hours gallor!
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
Javascript is already used for building desktop applications, the most popular probably being Firefox.
Many desktop applications already use scripting languages. For example see the following list of python gtk applications.
Nowadays you can easily write the parts of an application that requires high performance in C and the rest of the program, including the interface, in an interpreted language.
The problem Javascript has to face, though, is that it has very few libraries available for desktop or web applications. And the existing libraries are specifically written for one or the other task. CommonJS would be a common library for all environments and would allow porting code from one to another a lot more easily than it is today.
I work with PHP and Javascript/HTML all day long, and for anything beyond simple Javascript effects with AJAX, and some form manipulation, I find it to be an annoying bitch.
Compared to the simplicity of PHP, it just seems to get in the way of regular web development. I think it's mainly because you have to worry about casting your numbers to strings and things like that. I love how PHP lets you concatonate strings with '.' or add things together with a '+', whereas in Javascript, you're always using the '+' for both concatination and addition, and it just gets all ambiguous and tedious.
In PHP, it just seems to work, whereas Javascript, I spend too much time hunting around, trying to figure out why an event (like a button click) isn't triggering.
I think if you're developing large frameworks, or just more critical code in general, then sure Javascript's advanced features will pay off for you, but for general web development where you just "need to get things done", I wouldn't want to use it much more than I have to.
the browser is the os. or rather, the browser will become the os. anything and everything of any value to 99% of us in the modern internet-centered world will be interacted with through the browser
so instead of talking about jailbreaking javascript, the more relevant subject should be jailbreaking the browser. such that when joe user turns on his computer in 2015, he gets a browser, and only a browser, and nothing but a browser. native javascript implementation then continues merrily chugging along in the browser, as it always has, otherwise completely oblivious to the fact that it is now the only game in town
note that i'm talking about the computer using experience for the average user. please don't object to my depiction of this scenario from the point of view of the exotic user blocks that plenty of slashdot readers belong to, but don't describe the reality of computer use for the average user
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
If you think JavaScript is a crime against humanity,
In other words “If you can’t program, or if you can’t tell JavaScript from Java or Python,”.
The new versions of JS are really sweet. But most “web-developers” can’t even write proper code in the old one. Which is quickly visible, if you enable strict warnings, and force the interpreter to the newest version. Most scripts throw warnings or fail after that.
I say JS and Python are on par with each other. But they use very different paradigms. JS uses prototypes. And that is what most people do not understand. See it like this: Everything is an object (including functions, which allows really powerful functional programming), everything can be written literally (including objects with functions), and everything has a prototype on which it is based and can be the prototype for other objects/prototypes.
So you build your object, and then use it as a prototype to create other objects with added functionality or changed data.
The elegance of this is, that inheriting and instantiation really becomes the same thing. And in my eyes, the less rules a language needs, while still having all the power, the better and more elegant it is.
It’s crazy how, with the newest version, I can write it nearly 1:1 like I would write it in Haskell! You can’t imagine how happy I was, when I noticed that I would practically a “scriptable Haskell in the browser”. Of course it does not have the type strictness of Haskell. But that is kinda the point.
It even has regular expression literals.
What’s a bit messy, is DOM. Perhaps because it’s a “design by committee with no own sense of reality” (= no leadership) API.
Then again, I’m all for more languages in the browser. Python, Ruby, Lua, Erlang, Haskell and Java are good candidates. C/C++ and Perl are not. (Perhaps Perl 6 in 2051. ^^)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
> efforts to take JavaScript to the next level
This one goes to 11.
Bark less. Wag more.
It needs threads. I know the unwashed masses don't know what to do with them, but if you *do* know, then they can really be used to make much simpler code.
Like all pain, suffering is a signal that something isn't right
We already have a good number of established scripting languages that fill the niche. What does Javascript brings into this world that makes it interesting to work again on compilers, module platforms, optimizers, etc.?
The arguments posted in the article about what changed to consider moving javascript out of the browser, are in my opinion, pretty weak:
* We discovered AJAX: besides doesn't having anything to do with the argument, we might say that more than AJAX, browsers started to be a *little* more standard compliant, so designing complex HTML application became less painful. AJAX is really a so simple thing that I really don't believe is the responsible for our buzzed web 2.0 (besides... we always had iframes). Heavy support for CSS, fixing of layout issues, etc., that's what probably brought our web interfaces as we know them today.
* Its included on every consumer computer: Yes, in the browser. You will not use the browser to run these javascript programs, since there are limitations, and for a reason, on what you can do from the browser. Probably, you will need to download a javascript runtime to execute this new javascript programs anyway.
* Designers know how to program javascript: And that is why it's in the browser and not running on your server or free on your computer. Have you ever looked at the average javascript source code? People program as if they needed to save every byte on their source code, avoiding white space and having tons of a,b,c variables. Have they never heard of minimizers? And if size is such a problem, standarize an optimized intermediate representation instead.
What remains is that javascript is cool. That's probably right if you feel cool when you write ugly hacks to make things work.
And regarding problems with javascript to be used on large applications and not as glue code, I would say prototype programming is one of my main concerns. Weakly typed languages already have the disadvantage of lacking compile time type checking, and the difficulties to perform automated refactoring since you don't know to what a variable will refer. But with prototype languages you also add the difficulty to know what's the structure of an object.. In other dynamic languages you can also do it (ie. changing the structure of a class during runtime), but, being there and doing that, it's a probable road to "WTF is going on" (with exceptions, of course).
Santiago
>> The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example...
Not really nasty to implement at all:
get document all() {
return document.getElementById.apply(document, arguments);
}
That's interpreted code, of course, not native code. But if you're in the business of writing parsers and compilers, rolling that into native code is about a 10-minute operation.
Now... I might agree with you that it's misleading to newbies to design a language such that a potentially ubiquitous and expensive call to an external technology (the DOM) is hidden behind a seemingly innocent property lookup. But there again, expensiveness of such a call is an artifact of how browsers are coded, not a deficiency in design.
In principle, there's nothing wrong with providing a associative-array-like API to an action which performs a flat lookup within a namespace of unique keys [albeit admittedly unenforced in this case]. Python, Ruby, JavaScript and most other functional languages offer this functionality as standard fare.
Pick a different example....
it's just sometimes, it's a resource hog.
A bad workman always blames his tools
When you are given a screw driver to drive a nail, blaming the tool makes sense!
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
In addition to all the other things JavaScript is, it is also a hosted language. "ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment." - ECMA-262 3rd Edition.
People seem to forget there is a distinction between JavaScript, the Browser Object Model (BOM), and the Document Object Model (DOM). JavaScript has no native input or output functionality. These capabilities must be provided by the host. When the host is the web browser, there is a fairly well followed standard for JavaScript, there is a partially followed standard for the DOM, and there is no standard for the BOM.
The reason that people still hate JavaScript is not because of the inconsistent implementations of JavaScript. In fact, JavaScript has been implemented fairly consistently. No, the reason people hate JavaScript is because of the inconsistent implementations of the BOM and the DOM.
If you look in the ECMAScript specification, there is no method named alert. Where does it come from? The host environment. If IE 9 changed the name of the alert method to displayMessage, there would be an uproar that Microsoft "broke" JavaScript. When, in fact, they would have broken an unwritten BOM standard that said the browser would provide a host-based method named alert. It's a subtle, but important distinction.
What is broken is the implementation of the DOM. Some parts of the DOM are implemented consistently. Some parts are horribly different. In IE 8, Microsoft (allegedly) worked on fixing problems with their implementation of CSS. Their implementation of the DOM, however, is basically unchanged from IE 6. This is why web developers still hate IE. Not JavaScript, but the DOM.
As mentioned in other posts above, JavaScript has already broken out of the browser. But is has landed in other hosted environments. ActionScript in Flash is just JavaScript with the "Flash Object Model" instead of the BOM/DOM. You can use JavaScript in Photoshop using the "PhotoShop Object Model" to script the manipulation of images.
The effort here is to provide a "System Object Model" to JavaScript so that JavaScript can interact with the OS more directly. The success of that effort will be based on how well they design the host objects for JavaScript to work with and how consistently those standards are followed. Not on the fact that they're using JavaScript.
And JavaScript on the server is nothing new. I've got an old copy of "Pure JavaScript" by Wyke, Gilliam, and Ting published in 1999 that discusses server-side JavaScript on the Netscape web server. It includes objects to work with form data, files, databases, and e-mail servers.
Am I condoning the efforts to expand the use of JavaScript? No. I just want people that "hate JavaScript" to understand a little better what it is they hate. And I want the proponents of breaking JavaScript out of the browser to realize there are people who went before them and if they stop and look around for a second, there are lessons to be learned before the repeat old mistakes.
I void warranties.
Do away with client side browser scripting entirely and replace it with applications written in Javascript. I like languages, more are better. I don't like the requirement that I have to allow most websites to run essentially arbitrary code on my machine in order to view them. I know I don't have to go to those websites, but it is increasingly required to view just about anything. I don't trust my browser to protect me, and I resent having to switch to my virtual machine to browse, and then always having that notion that my virtual machine is probably a pox ridden compromised bit bucket that I should really empty at least once a week.
refactor the law, its bloated, confusing and unmaintainable.
Only clueless script kiddies use javascript. It has no use on either the web or as a (horror of horrors) stand alone language.
See subject-line, because that is what javascript also entails, since it is typically the delivery mechanism utilized by malicious website or ads that cause malware infestations today.
Gnome-shell, which will be GNOME 3.0 main UI, is written in JavaScript and works pretty well. JS is capable of much more than flashy web site.
:wq
I distinctly recall writing Server Side Java Script back when Netscape had a web server product. Netscape was really pushing it as the future. It was slow and lacked features in the Netscape implementation.
I think you need to retake basic CS if you don't know the difference between script and compiled languages, and how either can be used to build an application.
it's just sometimes, it's a resource hog.
A bad workman always blames his tools
The logical fallacy in this cliche has always irritated me.
- If all bad workmen blame their tools, does it follow that all workmen that blame their tools are bad ones?
- If all dogs are animals with four legs*, does it follow that all animals with four legs are dogs?
* Excluding accidents and birth defects
I find the nagative, un-informed, comments revealing. It reveals most of are unaware of current developments and about a decade out of step with modern techniques. Please all of you, do yourselvs a favour and actually get a clue before responding with general idiocy.
This has already been done in a way: http://en.wikipedia.org/wiki/Server-side_JavaScript
I did an implementation with Netscape's LiveWire back in 2000 or so. It was a nightmare.
Javascript is elegant and IMHO a great language, I would love to see new features and performance improvements, but as far as moving this to the desktop? Why? Aren't there enough platforms already?
Scripting languages are not interchangeable. While JavaScript hackers may hate me for this and while JavaScript has some nice features, I think prototype-based OOP and JavaScript scoping have turned out to be bad ideas. There are worse languages than JavaScript out there, but I won't be switching if I can help it.
That people are doing it doesn't mean its a good idea. Also, I use exactly zero of the applications, and 99% of the i never even heard of.
As for writing applications, I've always found myself to be way more productive with compilied code instead of scripting, which always seems fragile to begin with.
The problem JS has is that it sucks. When I can do: myDom.madeUpProperty = 'bleh'; and things chug along just fine, that's a problem.
The logical fallacy is only because the quote has gotten distorted severely over the years. The original saying, translated to English from Old French, reads "Bad workers will never find a good tool." This version makes much more sense.
Source: http://www.answers.com/topic/a-bad-workman-blames-his-tools.
Check out my sci-fi/humor trilogy at PatriotsBooks.
You haven't addressed the part where document.all needs to return a special collection type that breaks the object model in several different contexts (when passed to toBoolean, it should evaluate to false, which breaks the object model, and there are a couple of contexts where it should evaluate to undefined...).
Understand the example...
Nerd rage is the funniest rage.
While using Java Script on server is (some) option, there is also other way around - see GWT or Pyjamas. As browser is becoming a full-fledged platform, it is screaming for support of other languages along side with JS. While it is possible to compile other languages into JS, it's a kludge. The whole situation screams for splitting JS into lower level instruction set (along with object model implementing cool JavaScript features, like first class functions, prototypes and functional programming features) and JS language implementation on top of that. Other languages would compile to this intermediate representation as well. I would like to use my LISP for implementing in-browser code (Scriptjure does it but it is still in its infancy and it will become kludge, like GWT anyway)
I remember a long time ago, I used to use javascript within the browser with useless home pages that did pretty much all my coding formatting for me. I would use a template type schema for building my sql queries, or even try to filter text returns based on entry in the textbox, because it was just quicker to code then opening a full visual studio interface etc...etc..
It definitely has its uses, and is by far a very effective language to do what you want with, with regular expressions as advanced as perl, and object oriented model within the dom that is way further advanced then some other languages ....I have to say I am interested in what will develop from this.
maybe you should reread what you wrote.
Tell that to all the Python developers... This is not meant as flame-bait, only pointing out the fact that yes, interpreted languages are perfectly suited to developing applications.
Michael J. Ryan - tracker1.info
Well, I used javascript for a puzzle game when there was no Ajax; I used an iframe for loading data instead of xmlhttprequest, and things were called dhtml for dynamic html. Game is still essentially working without modifications in modern browsers: http://hylzee.sourceforge.net/hylZee/
(Preview; The full version is meant to be downloaded and hacked.)
On the other hand, somehow, in ff+addons the victory advancement to next level doesn't work and the loss message is hidden/misplaced.
Hey don't blame me, IANAB
RIAs that work well on IE and FireFox (the predominant browsers used in commercial sectors) are being developed today in JavaScript with jquery, gwt or dojo. And crappy client-side applications are being written as well. But anyone with a modicum of work experience knows that the responsibility of writing shitty applications rest squarely on the developer.
Some of the crappiest, worst code I've seen had been written on Java, C# and C++. And also, some of the clearest, most maintainable and elegant pieces of code I've seen were written in FoxPro and JavaScript. Every single language sucks in one aspect or another.
A good software professional, a pragmatic one, he looks at the language, at the tool, works around the problems and gets the stuff done with it in a clean manner.
Shitty programmer OTOH will screw it up no matter what.
And coding divas will get all emotionally attached to a given language, throwing subjective infantile rants towards whatever language they don't like recalling anecdotal memories mixed with technical impressions too superficial to be called "first-hand educated knowledge".
I don't like JS global scoping and lack of namespaces, but I do love it's object prototyping capabilities and support for functional programming. You can write some really complex client-side, browser-running systems with a brevity and clarity you cannot match with Java or C#.
That is the reality. It is a perfect tool? Nope. It is a good tool for what it is intended to? Yes. You can't get emotional against a tool, specially if you have never been able (or are incapable or have never assigned) to create a good NON-TRIVIAL application with it.
Palm's WebOS. I'd prefer perl there, but it is what it is.
See http://cappuccino.org/ Objective-J
That is an indication of the power and elegance that Javascript might have outside the browser.
"Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript."
I would think getting javascript out of the browser would be the best thing that could possibly happen to the browser. The language is painful, like some sort of transvestite it passes itself off as a C type language, but underneath tries to be more like a functional language like Lisp and fails at both.
I do understand the example. They want document.all for *only* two reasons. 1) So old code can check "if (document.all)" and proceed accordingly, as a form of poor man's browser sniffing, and 2) So old code written against document.all can still run.
Neither one of those reasons is violated by my posting, which in essence says that there's nothing wrong with the spirit of document.all, just the implementation(s).
Cheers....
Yes, but your implementation completely fails to address the html5 specification, which is the issue, not that the lookup hides an expensive call.
Nerd rage is the funniest rage.
DUH, Actionscript is way more powerful than JS, and has flash and flex as well..
Now I know why some simple development tasks and interfacing become so convoluted and unmanageable at my work, some of you negative nannies probably work here!
I've been using JS + DOM + JSON + other junk for some cool browser stuff for a few years now and no, it's not perfect. And yes, it had gotten better. Debugging is not friendly, but to a programmer that knows how to modularize and reuse code (any of those here?) it's not hard to isolate a problem.
I don't like browser inconsistencies, who does? I wish everyone would at least follow W3 html box model. There's so many things I wish, but it's easy to use and can do some interesting stuff in almost any popular browser.
I would not be surprised in the least to see a browser/visitor report for slashdot and see the amazingly high count for lynx.
Are you guys really having such major problems using this simple technology? Do the rest of us a favor and stick to CoBol. Give me any language, flaws and all and I'll get the most out of it.
"You can't get emotional against a tool,..."
Not so sure about that. I've known many a tool in my day and it is very difficult not get emotional if not down-right pissed.
Inability to perform CPU-intensive computations due to these dynamic types of yours
The dynamic types really don't slow it down that much, and it depends on your implementation. Google's V8 does well enough to run an NES Emulator at comfortable speeds.
lack of threading or any other explicit or implicit parallelism support
Parallel execution is actually pretty easy in a browser context using setTimeout and setInterval, though synchronization is a bit of an issue. But if you really want threads, hop on Rhino and pull from Java.
no library facilities to modern 2D/3D graphics libraries
In the context of a browser, Canvas actually gives you a lot. But outside of that, Rhino gives you everything Java's got.
Tweet, tweet.
Language designers need to think big from the get-go. When they don't, people suffer.
Or they learn to use the language.
Namespacing in Javascript isn't hard, you define a global object that becomes your namespace and everything else you implement becomes a property of that object.
Block scoping? Easy-peasy, if you really need it. Make an instantly-called anonymous function.
Global variables? Know your scoping rules and use them appropriately. This is the same solution as one has to apply in most of the languages out there, from C to Python.
Javascript has some warts, but these aren't it.
Tweet, tweet.
All IMNSHO (I don't know JS, but I do know a lot of other languages)
How does JS compare to a good, modern language - like Python or D?
I'll give you the lack of threading.
Why? For many uses, the asynchronous/parallel execution you get from setTimeout and setInterval work great. And if you're working on Mozilla's Rhino, you can use Java's threads.
2D/3D libraries
I think your larger point that many languages don't have this built in by default is a good one, but I wanted to point out there's some great stuff emerging on top of the canvas tag and SVG, and again, if you're not working in the browser, you're welcome to help yourself to anything Java's got by using Rhino.
Tweet, tweet.
Awesome. I wish I had mod points for you.
This thread will bring out all the "The language is beautiful and misunderstood" comments, and whilst there is some sympathy with that sentiment, the basic fact remains - people still struggle with it. Look at the crap the current generation of web-dev-tards produce - no matter how much they speed up the JS engines, the cruftiness of the code, and the fact people program with it like it was C, means more suckage in our day-to-day experience of all things Javascript.
That is all.
Shameless plug
I've been working on a web server that exposes a file manipulation API via AJAX with an automatically-generated JavaScript wrapper. What I found is that some kinds of operations really need some form of server-side business logic; so I added server-side JavaScript with automatic generation of an AJAX wrapper. In essence, I have a form of server-side JavaScript with a transparent RPC system for in-browser JavaScript.
http://objectcloud.com
What I've found is that server-side JavaScript is still in its infancy. (My Alpha Server likes crash a bit too much...) The point, however, is that server-side JavaScript allows for rapid development of applications because it lends itself naturally to a JSON-based RPC system that practically eliminates the complexities of serialization from languages like C, C#, Java, PHP, ect. This is especially useful because things like database queries can be pumped directly to the browser without having to write lots of data access code. Likewise, server-side JavaScript lets me quickly write glue code where my server's API would require too many back-and-forth calls; or where extending my server's API is a poor design choice.
No, I will not work for your startup
I think it is a great idea to bring javascript out of the browser. If they can keep it out too, it would be even greater. Maybe they should just take it out behind the shed and put it out of it's misery once and for all.
It's what they did with Rhino.
Personally I'm less concerned with its elegance as a language, or what a capable programmer can do with it, and more concerned about what a malicious programmer might do - like the vast ocean of exploits for everything - not just Netscape and IE, but Firefox, Opera, Safari/OSX, Adobe Acrobat, and so on... Virtually any language will have its abuses, but I think they'd be better served by dumping Javascript and starting from scratch - it's a toss-up whether it or ActiveX is the more dangerous scripting language to allow...
Ahhh, did you read the example he pointed you at? Your "implementation" completely fails every one of the special case "unusual behaviors" that I believe the OP was talking about when saying it was nasty. To quote:
Where have you been? WSH and ASP have been capable of running client- and server-side JScript (outside the browser) for more than a decade! Someone hit the snooze alarm, this is old news ... wait, it's the ECMA standards group ... oh, now it matters.
tldr squared!
Requiem for the American Dream
Bullshit.
If you do know what you're doing with threads, I'll grant that you can mostly avoid making things worse than unthreaded code. But I'm sorry, I don't buy that threading makes things simpler -- race conditions, deadlocks, corruption due to forgetting to lock, synchronization in general is a bitch.
Now, if you mean better performing code, I agree -- if you've got multiple cores. Even then, processes are generally a better model -- and certainly in an imperative Algol-derivative like Javascript, it's going to be much simpler to go with some form of cooperative multitasking.
Don't thank God, thank a doctor!
I did not know about snapshot, thanks! I do use noscript, but who to allow? Even fortune 500 are getting compromised left and right. The VM is so I can allow pages I don't really trust (like gamespot for instance), and still check my balance if I want outside the sandbox. As far as running the javascript applications outside the VM, it would depend on the level of trust. Part of the problem is using code for things that could be done using a document format. My paranoia is justified I think. And its not that I have anything I'm worried about losing, I just hate the thought of becoming the cause of another annoyance in a few thousand people's day as they click delete on the spam my machine sent them.
refactor the law, its bloated, confusing and unmaintainable.
I'm not quite understanding the analogy. Could you compare this to a pizza?
Javascript was designed to be a scripting language, using it as a host language is quite possible.
I am using Google V8 implementation as a scripting language for C++ application. It's like using SQLite, it's VM read SQL language and run it while the database engine is C. There are many things you can do with it:
1. You can easily expose C++ functions to Javascript, since the host C++ application already build and compiled, using Javascript can customize the app behavior, such as combining several functions into one batch.
2. You can save app settings and options directly to Javascript and just run it, you don't even need a parser to read config file this way. I have not found a way to let Javascript do heavy lifting, for example here is a CRC function expose to Javascript, the file reading and calculation threads are C++, Javascript just feed in the filenames and wait for the result. The only namespace concerns me is C++ namespace. I am not side-stepping the performance issue, scripting is just the way it is.
3. If you expose variables, you can access them inside Javascript space as well. With it's simple, no non-sense and concise syntax, you can write an entire test suite for your application in Javascript with ease.
4. You can modify the language: say I have a tokens() function in C++ which can be called in C++ and Javascript with tokens( "a string", delimiter ). Now I can modify the Javascript language like the following:
String.prototype.tokens = function( delimiter ) .,;:-_/\\|\n\r" );
{
if ( typeof( delimiter ) == "string" )
return tokens( this, delimiter );
else return tokens( this, "
}
Running this from RC file, I can now do something like "hello how are you?".tokens() in Javascript. I am no Javascript expert, but this is quite flexible.
5. There is NO DOM.
You app is the DOM, or whatever you design it to be.
6. There is no access to the outside world. You cannot even read/write a file, I have to provide my own library for it, but then I am in total control. While in C++, you use fopen, iostream or even boost::filesystem access anyway. You can just bind a fopen()/fread()/fclose() or iostreams to a Javascript function and then you have all the access you need. You have access to anthing the host language or external libraries provides, with a simple binding you can access them inside Javascript as well.
The combination of Javascript and C++ is very light weight and very fast ( at least with V8 ). I imagine doing the save with pure Java would cost 3 times more memory and no scripting capability, but of course I have no proof. But if you Java GUI it will certainly consume much much more memory.
Either you add features to your application, or using Javascript as a job-control language, sometimes scripts are one-time throwaway. Sure you can do most of the above mentioned with some other language, but Javascript syntax is clear, concise, no "let's just do something different" syntax like using "\" in path kind of thing. For newbie, a clearly structured language is MUCH easier to learn. For C/C++ or Java programmer, Javascript is dead easy to lean. Big companies like Adobe are using it on all their apps, or some variations of Javascript. Why shouldn't you?
Sure, there are no "standard" libraries in 2D/3D, OpenGL, GUI or what's not, but if you can connect them to C/C++, you can expose them to Javascript. But you should think about if using Javascript as a host-language is really what you want in the first place. I have no prior programming experience in Javascript, just looking for a concise, simple language for scripting applications, preferably C-like. All the duct-tape shell scripting languages are less flexible, there are a few C-like scripting languages but too slow and development are slow. Newer languages suffer from weird syntax and structureand pure bad tastes. I choose Javascript for what it provides, not because it is being used in browsers.
Stop the insanity and use Scala, EVERYONE!!
Scripts are fine for small mundane tasks, they're NOT good for building applications.
A lot of the very largest applications are scripted (in various languages). If you've got a choice between writing a million lines of script or a hundred million lines of C, it's a real no-brainer.
Well, in fact the massive apps use a mix of different languages, typically crafting components in a low-level language that the high-level scripting language composes to create the overall application. That tends to be the most productive approach; the alternative "One True Language" method is silly.
"Little does he know, but there is no 'I' in 'Idiot'!"
Javascript is much fun to debug. Even with firebug it is so hard to find errors sometimes.
Javascript is too dynamically typed. In my experience, testers constantly find bugs caused by [...], misspelled variable names, or other basic things that a compiler could have detected.
It's not impossible to do static analysis of code written in interpreted, dynamically typed languages. (There's such a thing for python.)
Or rather, it's not more impossible---see Rice's theorem---than it is for compiled, statically typed languages.
It's just that (apparently) nobody knows or uses a good static javascript analysis tool. Maybe because it doesn't exist; I don't know.
Use the right tool for the right job.
Okay. Let's see. I want to deliver rich applications over the web (with all the good properties of universal accessibility and no user administration) that do heavy client-side processing. I have to write in a programming language that virtually all browsers will run.
For that, javascript is the right tool because it's the only tool. It doesn't matter how ill-suited it is for the task at hand, it's all I got.
When you have to get that nail punched in, every tool looks like a hammer.
Oh, you're still here?
When you are given a screw driver to drive a nail, blaming the tool makes sense!
If I was given a screwdriver to drive a nail, I'd be more apt to blame the tool that handed me the screwdriver, or perhaps the one that neglected to ensure a hammer was available for the task.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
I too hate variable scoping in Javascript, even PHP is slightly better in that variables are local inside functions. There are other small annoyances too. But the biggest is: Javascript has been given monopoly on the client side for too long. I wonder how much better can the Web be if there were more competition on the client-side browser language.
JS does not have 'a couple of warts', it's mostly warts with a few nice ideas buried under them.
It clashes with "the right tool for the job". A professional would use the right tools, but if you have the wrong tools you can't point out their inappropriateness?
Brendan Eich's notes about an early draft and "Programming in the large" and a blog post about ECMAScript 5's strict mode (which does far more checking) talk of features that will hopefully give people a better change at dealing with the issues you raised.
OK not so useful to you now but hey...
The speed issue is largely due to the crappy implementations of Javascript
A language is only as fast as its implementations unless you lead a company that is willing to spend millions on a new implementation.
What you probably can't do is compile it to native code and expect it to have the speed of C/C++.
In ECMAScript, as in Lua, the only numeric type is a double-precision floating point number, and the only data structure is an associative array. An associative array from doubles to doubles takes 16 times as much space in the data cache, in RAM, and in the swap file compared to a linear array of tiny integers ("bytes"). At some point, switching from ECMAScript to Java, which provides a richer selection of efficient types, becomes a good idea.
2D/3D libraries - C doesn't have one in its standard, C++ doesn't have one
ECMAScript alone doesn't have the HTML and CSS DOM; that's the job of the web browser that adds libraries to ECMAScript to make JavaScript. Likewise, all three major PC operating systems add OpenGL and GLUT libraries to C++ to make C++-With-OpenGL-Support.
It just doesn't make too much sense having a full fledged 2D/3D library in the browser
Why does it just not make too much sense? What is the appropriate way to provide client-side visualization of information retrieved from a web service without requiring each user to seek administrative approval to install a native app?
And you use a "mission-critical application" written in Javascript running inside a web browser?
Our mission is to make money by providing a desirable product to customers. The step of deploying our application to our consumers is critical to our mission, and this step needs an appropriate platform.
Is it the proprietary plug-in nature of Flash that you don't like?
That and the fact that you still need to spend three figures to use SWF for animations (as seen on Newgrounds) as opposed to applets. Free tools such as swfmill can copy clips from an SWF library into your SWF project, but none of the guides I could find with Google describe a way to create vector-based clips to put into a library in the first place. The authoring tools aren't even up to the level of Flash 3, let alone CS3.
It's the inconsistent implementation of the DOM by Microsoft that's the problem.
You mean was the problem, at least until Google released Chrome Frame. Yes, Google knows you like to develop, so they put a browser in your browser so you can surf while you surf.
Life would be so much easier if browser vendors defined a language-neutral DOM abstraction and allowed scripting languages to be added as plug-ins. Then developers would be free to use <script language="python" src="script.py"... or >script language="java" src="script.jar"...
Web applications would still be coded in ECMAScript to get around blocks on installing third-party scripting language plug-ins imposed by computer administrators and device manufacturers.
Did that joke just go flying over my head?
The issue is that null and void(0) both exist and aren't the same thing. Which of these more cleanly corresponds to None of Python or null of PHP or null of Java?
In Python, strings are sequence types. Like all other sequence types, they coerce to boolean the same way their length does: "true" is true because it has length 4, and "false" is true because it has length 5. If coercing "invisible pink unicorns exist" to true isn't considered evil in Python, why should it in JavaScript?
If I was given a screwdriver to drive a nail, I'd be more apt to blame the tool that handed me the screwdriver
You can blame the substandard tool who gives you substandard tools, but your customers will blame only you because your competitors excel at making do with substandard tools and the substandard tools who provide them.
It's not a 56kb/sec world anymore.
You'd be surprised. There are still parts of Canada and the United States where the phone company won't put a DSLAM within 4 km and the cable company just chooses not to operate. On a mobile phone, "there's a map for that," and if you're not in the 3G zone, expect the Internet connection to become dog-slow as it falls back to EDGE or even GPRS.
We never had a battle of user-side scripting languages. I think one is in order, don't you think?
Good to know. Thanks.
I see you're still peddling your brainsick twaddle. GTFO of here with this shit you twat.
This silly bastard posts this copy-pasta all the time. No one reads it, and those who do go mad. They really just need to ban his ip, cuz it's getting old.
Celebrity worship is a poor substitute for Deity worship and costs more to boot.
The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))
I wasn't aware of this proposal. That's just plain horrible, I wonder what they were thinking. Who in their right mind would create a new HTML 5 document and then use 'if (document.all)' in a script?
You're welcome!