Is JavaScript common because many developers like it, or because it's the built-in language of web browsers, avoiding the need for client-side pluggins. Such browser entrenchment could be seen as a form of QwertySyndrome.
Discussion moved from GreatLispWar:
As far as your UI statements, that's only true because we are stuck with JavaScript in a QwertySyndrome kind of way, NOT because people love JavaScript. True, we sometimes have to learn ugly tools/techniques because of problem standards. I'll give you that one. But, it may not last long because people are hungry for a better client GUI standard than the HtmlStack and would run with joy from it if there was a viable alternative that was more like say Delphi. -t
[We aren't stuck with JavaScript at all. GoogleWebToolkit has been around forever, then there's newer stuff like Dart, CoffeeScript (and friends, like Coco and LiveScript), TypeScript?, and Roy, to name just a few of the most popular. Yet JavaScript, and alternate languages that preserve its semantics (the CoffeeScript family in particular), are still exceedingly popular both in-browser and elsewhere thanks to Node. It's unlikely that we'll be replacing the HtmlStack with some new standard any time soon, but we don't need to; HTML, especially considering all the HTML5 additions, is absolutely expressive enough, and going forward we're almost certainly going to keep extending the HtmlStack standards rather then throw them out in favour of a totally new standard. -DavidMcLean?] {Off-topic: I'd love to see AmberSelf? in the spirit of AmberSmalltalk}
My sense of the industry is that a good many people don't like JS for SystemsSoftware or SystemsSoftware-like uses, such as GUI kits. If that differs from your experience, we'll just have to call it an AnecdoteImpasse and LetTheReaderDecide.
[Well, one of the primary use cases for JavaScript is manipulating the DOM to build more complicated UI widgets, and considering the huge proliferation of jQuery plugins (among other things) it seems to be rather competent at this. There's also things like Angular, Knockout.js, and Ember.js which all build powerful (and very popular) GUI kits on a JS base. In addition, JavaScript is used to build a lot of compilers; it's especially popular for that purpose because you can then easily make "try" pages for your language, like http://learnboost.github.io/stylus/try.html http://jade-lang.com/ http://js2coffee.org/ . I believe you'd also consider http://gruntjs.com/ something that falls under SystemsSoftware, and it's ridiculously popular. You may be unfamiliar with many recent JavaScript projects, but the forefront of Web design makes heavy use of these things. -DavidMcLean?]
A large part of this is that because of client-locked QwertySyndrome, people are forcing JS to be a systems language, and embracing the wrong tool for the job because they have no other real choice.
[But it's not client-locked. As noted, there're a wide assortment of options on the client, including Dart and GoogleWebToolkit which both completely avoid JavaScript. And Grunt, along with the various compilers, is run primarily outside the browser, where there is complete freedom in language choice. -DavidMcLean?]
If you write a new SystemsSoftware-friendly language interpreter/compiler in JS, then technically you may be right, but it's kind of an AbstractionInversion. Most would agree that's not the ideal. It's an ugly solution to an ugly problem. It's like writing a C compiler in Perl when instead you should be writing Perl in C.
[Dart is pretty much a new SystemsSoftware-friendly language that compiles to JS, so yes, that's happened; that wasn't my point anyway, though. My point is that, although there are a wide range of language choices available both in the browser and out, JavaScript itself is still used for widely-used examples of systems software such as Grunt. Surely this is indicative of the language having some actual appeal? If there are no redeeming qualities to JavaScript beyond it being the locked-in choice, why use it for Grunt, or for Jade? Why not use Dart or GWT to build Ember.js, if JS is allegedly so bad at that kind of thing? -DavidMcLean?]
Some? I'm not sure what your point is here in relation to prior statements. It appears to generally repeat prior points. Perhaps we should start a new topic such as JavaScriptPopularity? or the like since we are wondering off topic. However, it will likely be filled with mostly anecdotal info, and our observations and "feeling" for the industry is apparently different. Anecdote-fights are not fun and not welcomed by most WikiZens. Again, I don't sense any general love for JavaScript for systems-software-like uses and any apparent popularity appears to be a direct and indirect result of a form of QwertySyndrome due to its inclusion in web browsers. I suspect if BrainFsck was the imbedded language of browsers, people would be making Grunt interpreters out of BrainFsck. Since God denied my grant to fork Earth, we cannot test that theory. (As a "glue" language for relatively light-duty scripting, most are "okay" with JS there.)
[When would JS have been subject to QwertySyndrome, in terms of that causing its adoption outside the client environment? The client hasn't been locked in since 2006, when GoogleWebToolkit was released - it's older than jQuery, in fact, and hails from the halcyon age of JavaScriptSucksInBrowsers, when on the whole nobody was using JS except for one-off client hacks. JavaScript's recent popularity is just that, recent. If it were caused by the old property of client lock-in, it would've happened a lot sooner. It's far more likely that JS's popularity correlates significantly with Douglas Crockford's book, JavaScriptTheGoodParts?, published in 2008; it's only after that book's release that JS has become popular for servers and other applications (NodeJs, CoffeeScript, and Angular in 2009; Knockout in 2010; Ember in 2011; Grunt in 2012). -DavidMcLean?]
Are you suggesting users should expect to install special browsers or browser add-ons to have client-side code in a particular language other than JS?
[Absolutely not. That may be what AdobeFlash?, MicrosoftSilverlight, and Java applets expected of users, but I don't. GoogleWebToolkit, CoffeeScript, Dart, and so on can all run in-browser without any special extension. -DavidMcLean?]
Then you have the slowness of an AbstractionInversion, including downloading an entire interpreter for each page/site, which is stupid.
[No, you assume that you have the slowness of an AbstractionInversion, including downloading an entire interpreter for each page/site. None of that is necessary. GWT, Dart, and CoffeeScript are compiled. -DavidMcLean?]
How is that different from Java applets?
[Java applets require the Java browser plugin to run. Apps written in GWT/Dart/CoffeeScript don't require any plugins, nor any other extension to the client's browser. -DavidMcLean?]
Most browsers shipped with Java, for a while. But at least the Java pluggin was designed to run Java byte-code, unlike JS, which means the approach you suggest is going to be slow. It's often why JS GUI's are so jittery and unresponsive and jam pages.
[Whether browsers shipped with Java in the past is immaterial. It's still a plugin that users might not have. In terms of performance, first note that for the most part client-side apps are IO-bound rather than CPU-bound, which for NodeJsAndHofDiscussion reasons means that a small performance overhead in the client is negligible. Next, note that all the languages I mentioned are compiled to JavaScript well before they're delivered to the client; compilation can be slow, but all the client actually deals with is clean, well-optimised JS. Which brings me to my final point: JavaScript isn't slow, at least not any more. The JS engines used in both WebKit? and Gecko have phenomenal JustInTimeCompilation, and given a little JavaScriptTheGoodParts?-style discipline it's easily the fastest interpreted language out there. If you're convinced that JavaScript GUIs are on the whole jittery and unresponsive, would you care to provide examples of this? My experience, especially with Google applications, suggests otherwise. -DavidMcLean?]
Either way, you are arguing that JS can be treated like a machine language with another compiled language "running" on top of it. But that's not selling JS for JS's abilities in terms of its language features, which was the original reason JS came up. (Any TuringComplete language can be used to execute other language's machine code or p-code.) -t
[My point was that, while JS can be viewed as the assembly language of the Web and alternate languages used (GWT, Dart) in its place for actual development, for the most part it isn't. You got sidetracked by the means whereby these compile-to-JS languages work; the important thing to consider here is that, although GWT or Dart could have been used to develop Angular, Knockout, and Ember, they weren't; JavaScript was still chosen despite the ever-present availability of choice, which surely indicates that JavaScript's features have merit. -DavidMcLean?]
How do we know that browser entrenchment didn't play a large role in such decisions?
- [Because, like I just said, there's no such entrenchment as a range of languages are and were available in the browser? -DavidMcLean?]
- But that's only if you talk about it in terms of an assembler/machine language and not as an application or SystemsSoftware language from language (coding and syntax) standpoint. So, yes, you can use other languages, but then you are not directly using JS. You are merely taking advantage of the fact that the entrenched browser language is TuringComplete such that it can run other languages also. That's not an advantage specific to JavaScript. One could do the same in COBOL, VB-Script, or BrainFsck.
- [Obviously you aren't using JS nor taking advantage of JavaScript's features if you use it as an assembly language and actually code in something else (I'd argue that if you code in CoffeeScript or its descendants, such as Coco, you are in fact still using JS -- CoffeeScript's slogan is "it's just JavaScript", after all -- but GWT and Dart users are definitely avoiding JS itself). That's irrelevant, because my whole point is that people could use not-JS and could not take advantage of its features. But, critically, they don't. People still use JavaScript itself, taking advantage of its features, despite the fact that it is a perfectly valid option not to use it. -DavidMcLean?]
- Using something else besides JS is often not practical because it ties an organization to an uncommon language stack. Companies want PlugCompatibleInterchangeableEngineers. QwertySyndrome. And to some CoffeeScript may be too much like JS to bother to be somewhat different for similar reasons. If you accept the down-sides of having a different tool stack, you want sufficient up-sides to compensate for these down-sides.
- [An organisation? I'm mostly referring to big open-source projects here -- Angular, Knockout, Ember, Grunt -- since those are clearly-visible examples of JS's popularity; open-source projects don't want PlugCompatibleInterchangeableEngineers. -DavidMcLean?]
- I'm talking from the perspective of a "typical organization" (corporation, gov't, charity, etc.) They probably have different concern priorities than open-source projects.
- [Of course they would, but that's irrelevant to my argument. I'm arguing that JS is popular on its own merits because it's used for big open-source projects like Grunt, and on the whole big open-source projects don't have a PlugCompatibleInterchangeableEngineers consideration when choosing implementation languages. -DavidMcLean?]
- I've considered JS also for open-source projects I've pondered, but it was mostly based on entrenchment. Entrenchment greatly increases the chance of a language being available years down the road.
- [Would browser entrenchment have been enough to convince you to choose JavaScript for your non-browser open-source projects? -DavidMcLean?]
- Yes! Browser entrenchment helps ensure availability in non-browser-apps also. Although, "convince" is probably too strong a word. It's a "big factor", let's just say, in choosing a language.
- [How so? A terrible language that's forced on you by a specific environment is not one anyone would want available outside that environment, no? In any case, language choice primarily is rooted in how well the language solves the problem given, isn't it? -DavidMcLean?]
- What "terrible language" are you referring to?
- [A hypothetical one whose primary "merit" is that one particular environment requires it. Why would it ever be available outside that environment? Why would anyone ever put in the effort to make such a language available outside of the environment that forces it? -DavidMcLean?]
- Sorry, you lost me. Too many pronouns and implied references. Note I never said JS is "terrible" in a general sense. It's just the wrong tool for some jobs.
- [One pronoun, "it", which in every appearance refers to the "hypothetical [language] whose primary merit is that one particular environment requires it". Of course JavaScript is the wrong tool for some jobs, since no tool is perfect for every application ever, but in previous topics you seemed to be suggesting that the only real justification for the language's use is that a common environment (the browser) is forced to use it; this seems clearly erroneous to me, both because I know JavaScript is a tremendously powerful language and because it's currently quite popular even for server-side and for non-Web-app uses, like shell programs. -DavidMcLean?]
- You seem to be arguing that its (alleged) popularity is evidence of its popularity outside of the browser-embedding issue. I don't see how that follows. It seems to be circular logic. And being "powerful" is not evidence of goodness by itself. Lisp is also powerful; I'd argue ever more powerful than JS. (Abstraction power is rarely a top selling point (favored factor) in the paid field for reasons described in GreatLispWar.) Server-side JS usage may likely be a side-effect of browser-entrenchment. You haven't given strong evidence that it's not spill-over. Articles on server-side JS even talk about not having to learn a new/different server-side language for those with client-side experience as one selling point of the idea. -t
- [My argument isn't "JavaScript is popular because it has popularity"; that would indeed be circular logic. I argue that, because it has significant recent popularity both for the server-side and for shell programs, its popularity is most likely unrelated to its "browser entrenchment", since there is no such entrenchment in the server and especially in the shell. (Why not use PerlLanguage, PythonLanguage, or RubyLanguage for shell programs, after all?) Use of JavaScript for server-side does have the contributing factor that aspects of your code may be shared between client and server, since both speak a common language, but this by no means a big enough advantage to justify writing an entire server-side JavaScript platform (NodeJs) in the first place. In addition, there is no such justification for JS's use in the shell. As I noted earlier, it's far more likely that the recent boom in JavaScript's popularity for server-side and shell applications is tied not to its ubiquity in browsers (since that's been the case for a long time, and this popularity boom is critically more recent) but instead to the release of JavaScriptTheGoodParts?, which helped many programmers identify the language's many strengths and warded against its comparatively few warts (primarily: with, eval, and certain aspects of the type system), and was followed by a slew of big, widely popular projects applying the good parts of JavaScript to their full extent. (Also, Lisp is indeed more powerful than JavaScript, and that is definitely evidence of goodness by itself.) -DavidMcLean?]
- You are not presenting any clear evidence that server-side usage growth is mostly unrelated to the entrenchment. Leveraging the existing knowledge pool is very important to most organizations in my experience. It makes it easier to have PlugCompatibleInterchangeableEngineers, a big goal of organizations. Further, the existence of JavaScriptTheGoodParts? is likely related to the entrenchment. Oreilly is not likely to release "BrainFsck The Good Parts", because nobody would buy it.
- [O'Reilly is unlikely to release BrainFsck: The Good Parts because it doesn't have any. My argument that the server-side growth doesn't correlate with browser entrenchment is a temporal one: Ignoring that there really isn't entrenchment because of GWT and Dart for a moment, JavaScript has been the "only" option in browsers for almost twenty years. It's been an option on the server, as NodeJs, for about five. If the limited options in the browser environment led people to develop similar options on the server, why would it take so long? -DavidMcLean?]
- Substitute BrainFsck with a language you like but is not popular. And the fact that JS has been around for so long is likely one of the reasons why its use spread to the server-side. If you want to bet your future on the viable existence of a language, then one that's lasted 20 years is good bet. Even if it fell out of favor tomorrow, the 20 years means there's a lot of existing projects and knowledge to keep the support and knowledge base alive for a while. It has a big "legacy spare fuel tank". You can't say that for something that's been visible for about 3 years. All else being roughly equal, a language that's been visible for 20 years has a big leg up to one that's been visible for 3 when choosing your org's tool base.
- [Hmm. The "bad parts" of HaskellLanguage are almost entirely historical mistakes in designing the standard libraries, rather than any problem with the language itself, and they are exceedingly few (for example, Monad is not defined as a subclass of Applicative, even though mathematically it is one). Moreover, there is no perception in the software community that Haskell is overall a bad language; there have never been JavaScriptSucksInBrowsers-type problems with it, so there's no need for a HaskellTheGoodParts? and I'd be surprised if anyone published one. I'll certainly accept that JavaScript's long-lived nature has contributed to its increase in popularity for alternative environments, but that doesn't really justify why it took so long for the language to be adopted in such environments, especially when taken as a primary factor. -DavidMcLean?]
- I'm not clear on what you are responding to. I did not mention any "bad parts". As far as "why it takes so long", I already explained it. Once a language shows it has "sticking power" it becomes a de-facto standard. Being visible for 15 to 20 years puts JS in that category, making it a safer choice because enough shops and systems will depend on it to keep a maintenance community of both interpreter coders and app coders viable for a while. Based on existing and historical usage, most would agree that in 2030, one is more likely to find a decent JS interpreter for their new iSpeck portable eye-drop interface dot than for say Ruby. If there were any concern over medium and long-term support, a manager wouldn't select Ruby over JS unless it had some compelling feature that noticeably improves here-and-now projects.
- [You didn't outright mention any "bad parts", correct, but you did instruct me to "Substitute BrainFsck with a language you like but is not popular." in the statement that "Oreilly is not likely to release 'BrainFsck The Good Parts', because nobody would buy it.", and it's implicit in a discussion of a book called "the good parts" that it's going to be warding you against the bad parts too, as well as exploring the good parts in depth, as JavaScriptTheGoodParts? does. As for your de facto standard claim? Setting aside that JavaScript isn't just a de facto standard but an actual one, EcmaScript, why would there be any correlation between what language a typical manager would select for its long-term support characteristics and what language DouglasCrockford would select as the subject for his book? There's clear correlation, if not explicitly-established causation, between that book and JavaScript's generally being recognised as a powerful, competent language – which makes sense, given the prior perception of JavaScriptSucksInBrowsers – as is outright indicated by (for example) CoffeeScript's self-description as "an attempt to expose the good parts of JavaScript in a simple way." There is little to no indication that either JavaScriptTheGoodParts? nor CoffeeScript were written simply because JS is what we're stuck with in the browser, and plenty to indicate that both relate to the language's actual expressive power and value. -DavidMcLean?]
- We can only speculate on the publisher's motivation for approving book projects. If you have evidence of "explicitly-established causation", please present it. Otherwise, I'm not interested in repetition of your personal opinion.
- [The publisher's motivation for approving the project is irrelevant; what's more important is DouglasCrockford's motivation for writing the book in the first place. JeremyAshkenas? explicitly describes CoffeeScript, as noted, as "an attempt to expose the good parts of JavaScript in a simple way". Off the cuff, I've no similar evidence for NodeJs, but there's pretty obviously a correlation. -DavidMcLean?]
- But if the publisher doesn't accept the idea, nobody sees those words you quote. Thus, the author's motivation is not necessarily the primary cause of the world seeing the book. The publisher may be receiving many drafts of "Why [obscure language X] is So Great!", but turn most down because of an insufficient audience. Thus, author enthusiasm and opinions are being filtered by publishers, skewing OUR view.
- [I don't see how publisher-filtering could be in any way meaningful or germane to this subject. The fact of the matter is that DouglasCrockford wrote a book, JavaScriptTheGoodParts?, because of the perception that JavaScriptSucksInBrowsers contrary to his own opinion of the language; after this book's release, many many JS projects have started that follow the design principles presented in the book and in some cases explicitly describe themselves as a a way to get at "the good parts" of JS. If publishers received a similar book earlier and accepted it, we'd probably be seeing CoffeeScript and NodeJs a little earlier. Is it really relevant what the publishers' motivations are? -DavidMcLean?]
- Sorry, I'm still not seeing what your point is. A book triggered more JS-related tools? Perhaps. Okay. But, what's that have to do with the general popularity of JavaScript? I contend a given language's entrenchment is more likely to trigger such books. It's kind of "if we are stuck with it, let's leverage it as much as possible".
- [But a) we aren't stuck with it, because GWT/Dart/blah. b) JavaScriptTheGoodParts? was specifically written because of the common perception that JavaScriptSucks, and presents an alternate, JavaScriptRocks perspective, on which most subsequent tools are built. -DavidMcLean?]
- I believe it's largely due to browser-entrenchment. That a book helped people "live with it" better is only saying that a book helped people live with it better.
- [What about the alternatives? We've had GWT much longer than JavaScript has been well-liked. -DavidMcLean?]
- It's not a programming language. Apples to oranges.
- [JavaLanguage is. How's it matter that GWT isn't? -DavidMcLean?]
- I don't know of a many GWT programmers and it's not hard-wired into common browsers.
- [I'm sure you'd be familiar with Java programmers, but it doesn't particularly matter, because the relevant thing is that it exists as an option, not that it's used as one. And of course it's not wired into browsers. Neither is CoffeeScript. Neither is Dart, Dartium notwithstanding. Why would it need to be? -DavidMcLean?]
- Maybe I misunderstood why you mentioned GWT. That JS can be used like a virtual machine language interpreter says very little about JS. Cobol or BrainFsck could also execute byte-code-like instructions, if they were entrenched in browsers.
- [Correct, that JS can be treated as a low-level VM for a higher-level or at least more-strictly-typed language says very little about JavaScript itself or its features. All it says is that you don't have to use it, because you could use GWT. The fact that people do use JS, despite there clearly being alternatives, indicates that there are reasons other than browser entrenchment for its use. -DavidMcLean?]
- Are you talking about Java applet-based solutions? Java applets are failing largely because the technology was poorly integrated with the browser DOM. The same can be said about Flash. JS, Java applets, and Flash are pretty much the only browser-entrenched programming environments. Lack of integration with the DOM, and in Flash's case the proprietary fees associated with development tools are dooming the latter two.
- [No, I'm not talking about Java applets or Flash. As I keep saying, I'm talking about GoogleWebToolkit, Dart, and the like. -DavidMcLean?]
- ANY TuringComplete language can "execute" Java. JS is only used because it's entrenched in browsers. We've been over that already. I don't know what you are trying to get at. I'm growing frustrated with this sub-discussion.
- [Certainly, any TuringComplete language can execute Java code, given appropriate infrastructure. GWT is that infrastructure as applied to JavaScript, but that's not the point; I'm not arguing that JavaScript is special or powerful for being TuringComplete. I'm arguing that, although there are other mature languages available in the browser (such as GWT), for the most part JavaScript itself is still a popular choice, which indicates that there are reasons outside of the platform limiting choice. It's only entrenched in the browser in the same sense x86 assembly is entrenched in x86 processors, and no one codes in x86 assembly directly yet everyone codes in JavaScript directly. -DavidMcLean?]
- Most of the complaints I've seen about GWT is that the API's were poorly designed and awkward to use. It's the "worst of desktop ideas mixed with the worst of web ideas", said one person [paraphrased]. It wasn't easy to use direct Html/CSS coding when it's best and use Java API-controlled Html/CSS when it's best in a mix-and-match way. You were kind of forced to use all of one or other. (There may have been ways to do such, but they were not well-known/familiar among developers.) Further, a good many Java developers were not familiar enough with Html/CSS to use it well, compared to JavaScript programmers. A much higher proportion of Java developers came from a desktop GUI background (Windows-C++, Delphi, VB, Powerbuilder, FoxPro, etc.), and this tended to give GWT apps a bad reputation for not "doing the web right" even though it was caused largely by a background mismatch.
- [Completely accurate points! Indeed, GWT was not without its flaws, and its attempt to (basically) hide the fact that Web apps differ from desktop apps was ultimately unsuccessful. That's absolutely true. It is, however, only true of GWT. CoffeeScript and friends interact with the DOM exactly as JS does, and Dart's got a sophisticated DOM API of its own baked in; all these languages are designed in full awareness of the importance of the standard HtmlStack. -DavidMcLean?]
- CoffeeScript and Dart may have their own shortcomings. Just because they are different than JavaScript does not by itself make them worthy competitors.
- [Everything has shortcomings. Unless you can identify specific reasons that (say) Dart mightn't be a suitable choice for Web applications, it's just conjecture to suggest it's flawed enough relative to JS that it'd be completely ruled out as an option. -DavidMcLean?]
- Something would have to be noticeably better to unseat JS as the target client language. Specific applications can hide much of JS's ugliness behind custom or specialized API's rather than use a relatively unknown language, creating future support risks.
- [I was under the impression you thought much of JavaScript's "ugliness" was either syntactic, or a property of APIs that the language is not powerful enough to abstract out (due to lack of named parameters), as indicated on BradyBunchGridDiscussion. Are you now suggesting it indeed can be abstracted out? If so, what problems even exist with JS? -DavidMcLean?]
- My personal opinions on JS don't matter in this case; it's what the industry wants. My preference for (optional) named parameters is unfortunately not as valued by the general industry, I would note. The industry's main complaint is lack of better compiler-like type and reference checking for non-trivial GUI work.
- [Then how would you explain the relative unpopularity of Dart and TypeScript?, which provide these things? -DavidMcLean?]
- They probably need a "killer" API or framework to kick-start interest, and in the process demonstrate the advantages of static code verification for non-trivial GUI's. JS also has a leg up in that you have plenty of API's/libraries/frameworks to choose from for native JS. It's somewhat comparable to Microsoft's problem competing with Android and Apple in the mobile market: not enough apps. The OS platform is a secondary concern to buyers. You have these main factors competing with each other:
- Staffing of developers familiar with the language and related tools
- Chances that the language will be sufficiently supported 10 or so years from now
- Available libraries/frameworks/API's (for GUI's, typically)
- Language features: syntax, TypeSafety, name-spaces, etc.
- The fourth one (language features) still has to compete with the other 3 factors in a decision-maker's mind. If something like Dart gets a good "score" on #4, it may not be enough to compensate for its poor weighting on the first three. Unless it's extremely better at #4, it will need "help" in at least one other category to get a score higher than entrenchment typically gives JS with decision-makers.
- [Modulo TypeScriptInconveniences, TypeScript? already has "available libraries/frameworks/APIs" for absolutely everything JavaScript does. It's slightly more difficult to access vanilla JavaScript libraries from Dart, but as noted Dart's standard library includes its own expressive interface to the DOM. That's your one-other-category. Since both are relatively new languages, familiarity with these languages specifically isn't particularly widespread yet---however, Dart's similarity to most imperative languages is a major selling point. Future support may be a concern for TypeScript?, which is only really supported by Microsoft, but Dart is an ECMA standard. -DavidMcLean?]
- Dart is relatively new. Maybe it or something like it will catch on. We'll just have to wait and see...
As far as general "love" of JS, the "community commentators" at
SlashDot don't seem to show a general love of JS. There are
far more "haters" than "lovers" there, as I informally survey the comments:
http://developers.slashdot.org/story/14/02/01/1618226/the-javascript-juggernaut-rolls-on
In general, for non-trivial browser-side GUI programming, most seem to want a stronger TypeSystem and better name-space management.
[Those wanting "better name-space management" are uninformed. Any non-trivial browser-side GUI programming will make use of the CommonJS or AMD module specifications, through http://browserify.org/ or http://requirejs.org/ respectively, and both module systems are extremely expressive in terms of namespacing. (Adding a stronger type system is a suggestion that has merit and is one of the major motivations behind GWT, Dart, and TypeScript?. Barring a few quirks, however, such as the [3, 10, 5].sort() example presented in the aforementioned comments section, the JavaScript type system really is no worse than any other dynamically-typed language's -- and on the flipside, I can confirm the stronger static type system offered by TypeScript? makes a lot of common patterns really inconvenient!) -DavidMcLean?]
Many either don't want a dynamic language for heavy GUI usage, or want something that at least "encourages" explicit types, such as requiring typed parameters. ("Variant" or "object" may still be allowed, but not easier to code than an explicit type.)
[My experience is that TypeScript? in particular is awful for heavy GUI usage (specifically, for a Knockout-based application -- it's a custom business app, so I'll provide specific examples if desired). But of course experiences differ, and it's entirely possible other statically-typed languages do a much better job. -DavidMcLean?]
Why is it awful at GUI's? Perhaps the DOM itself is the problem?
[No, all my problems were specifically with TypeScript?. I've started writing up TypeScriptInconveniences to illustrate a few. -DavidMcLean?]
FebruaryFourteen
Popularity Of Java Script