20 ms·

"Haters gonna hate." Anyone claiming that JS is the "worst thing to happen to the web" and/or that some other language would miraculously solve all of the prob

"Haters gonna hate." Anyone claiming that JS is the "worst thing to happen to the web" and/or that some other language would miraculously solve all of the problems present in JS should do the following, "Go create it." Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere." There are plenty of people already trying to solve this problem by actively doing something. I've worked with enough engineers that love to criticize every design choice made but when it comes to asking them what the better alternative is they have nothing to say. They just "know" there's a better way. Well, stop using your intuition based rationalizing that there's a problem and start using your creative and logical faculties to actually solve the "perceived" problem before presenting a criticism. Or at a minimum present a well thought out and actionable direction towards the solution.

deezenuts 11y ago
ok
- knightofmars 11y ago
  I would +1 your username if that were a feature of YC.
teacup50 11y ago
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.
- pcwalton 11y ago
  > Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine, and try and write the browser in JS. You mean like Firefox?
  - mattmanser 11y ago
    Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
    - pcwalton 11y ago
      > Works on OSes. We have a choice. The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude. Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js. > Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable? That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static. Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
      - ForHackernews 11y ago
        Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
        nostrademons 11y ago
        Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there. The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
- TazeTSchnitzel 11y ago
  > Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
  - 14paninta 11y ago
    What does that even mean? It's nonsensical. Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. Microsoft can ship the CLR for ARM, x86, PowerPC. You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Microsoft can't ship a fully functioning CLR for JS.
  - TazeTSchnitzel 11y ago
    14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it. > What does that even mean? It's nonsensical. What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain? >Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either. >You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. >You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. You can also retarget stuff compiling to JS to compile to something else, like Lua. >Microsoft can ship the CLR for ARM, x86, PowerPC. > You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you. > Microsoft can't ship a fully functioning CLR for JS. This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.
- ender7 11y ago
  Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.
  - TazeTSchnitzel 11y ago
    ...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
    - 14paninta 11y ago
      asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
    - cwyers 11y ago
      I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
      - TazeTSchnitzel 11y ago
        Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
        tosh 11y ago
- rjsw 11y ago
  Internet Explorer had a pretty clean API for adding extra scripting languages.
  - TazeTSchnitzel 11y ago
    Yes, the Windows Script Host. But I don't believe two languages could very effectively talk to eachother, right? Couldn't they only really interact with the native code stuff (DOM etc.), i.e. the easy part?
    - rjsw 11y ago
      It wasn't too difficult to add an interface to COM from a new language, that seemed the easiest way to call "out" to something else.
  - tracker1 11y ago
    And in practice, that separation layer lead to objects tied together across COM boundaries, and severe memory leaks for any significant applications.
- sqren 11y ago
  > Or, they could take their own medicine, and try and write the browser in JS. Like Blink-in-JavaScript[0] ? ;) [0] https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js
arbsn 11y ago
I don't believe that someone needs to have a solution in order to observe that there is a problem. The resources available to an individual for creating and reasoning are finite, and as long as one is able to give good reasons why they know that there is a better way, "there is a problem" may still be valuable information.
- swsieber 11y ago
  If it wasn't widely know that Javascript is a problem, then merely observing that it's a problem instead of trying to provide a solution would be useful. But it's a widely known problem and so complaining does nothing useful. Essentially, at this point in the game, complaining is useless rehashing of a beaten horse.
  - mozumder 11y ago
    There's a whole world of problems to fix before you even get to the problem of Javascript. Right now, the world only has 3.5 base browser engines. Those browser developers have no interest in adding a new standard language like Python, even though more people prefer that to Javascript. So, if you were to develop a new browser language, you need to build a new browser from scratch, and then move a billion people to it.
    - cmdrfred 11y ago
      Man, python on the server and in the browser. What a world that would be.
      - Ygg2 11y ago
        Filled with version problems :P Oh, you got Python 6, well we have Python 8 which breaks your code in subtle ways.
      - coderzach 11y ago
        2.7 or 3?
olau 11y ago
I sometimes wish Javascript would take more hints from Python in getting some of the details right. For instance, it would be nice if == would work so that ["foo"] == ["foo"] and { foo: 1 } == { foo: 1}. But I suppose fixing that would be a too bold move. I like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python.
- nilliams 11y ago
  > like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python. I'm a Python fan but I can't disagree more on that point. Python has terrible lambdas, and poor idioms when working with collections (list iteration over chainable/fluid interfaces). Underscore.js, which at this point stands for 'idiomatic JS for collections', and the ES5 methods on arrays (filter/map) which are largely supported now provide a better way to handle arrays & hashes than idiomatic Python. With ES6 fat-arrow functions it's even better. It's one of Python's biggest weaknesses when compared to other dynamic languages IMO -- that the idiomatic way to deal with 'collections' is not a chainable/fluid pattern, but instead to do multiple list comprehensions, or use the ugly filter-plus-lambda patterns which compose badly. Double evens in a list: ES6: [1, 2, 3] .filter(x => x % 2 == 0) .map(x => x * 2) ES5: [1, 2, 3] .filter(function(x) { return x % 2 == 0 }) .map(function(x) { return x * 2 }) Python: map(lambda x: x * 2, filter(lambda x: x % 2 == 0, [1, 2, 3])) # or evens = [x for x in [1, 2, 3] if x % 2 == 0] [x*2 for x in evens] The ES6 & ES5 JS examples are both clearly superior syntax IMO. More readable and the anonymous functions support multi-line so extend to more use-cases. EDIT: Removed the word 'objective' because I'm talking syntax.
  - dragonwriter 11y ago
    > ES6 & ES5 JS are both objectively better IMO. This sentence reveals a deep misunderstand of either what "objectively" means. (FWIW, I prefer the ES5/ES6 syntax to Python here, as well; I just don't mistake that preference for something other than subjective.)
copsarebastards 11y ago
I'm one of the people who says JavaScript is the worst thing to happen to the web, and I don't need an alternative to say that, because my issue is with what JavaScript does, not how it does it. An alternative that does the same thing wouldn't solve my complaint. I don't want a web where all my software and data is owned by other people who don't have my best interests in mind. JavaScript allows "free" websites to replace programs running on my machine which is fundamentally opposed to my goals. I don't want all the power that computers have brought to humanity to be concentrated in the hands of corporations, I want it to be free for anyone to use. I'm glad JavaScript is shitty and I wish it were shittier, because that would slow the growth of corporate control over our capabilities and data.
- aeze 11y ago
  You're misplacing the blame.
  - copsarebastards 11y ago
    I'm not placing blame at all. I don't think anyone could have foreseen what effect JavaScript would have on the internet.
- palmer 11y ago
  Lots of corporations that don't have your best interest at heart write software that doesn't live on the web, in any number of languages. Conversely, I can write open-source javascript that does something useful for you, that does not mine your data or do anything of that sort. I don't see how this relates to javascript.
  - copsarebastards 11y ago
    The most pervasive and harmful companies all use JavaScript and couldn't do the harm they do without it (or, I suppose, an equivalent technology). I would venture that I could solve all the problems you would solve with open source JavaScript with another programming language, because almost no program actually needs to be a web application.
cookiecaper 11y ago
The correct solution is to write a DOM interface for Python and start distributing browsers with Python VMs. Python's not a perfect language but it's much better than JavaScript. There are acceptable alternatives besides Python too, but that would be my favorite. I don't see why we need to invent a whole new scripting language for client-side execution on the web, the problems really aren't that special. I know the history of JavaScript and I'm not saying it didn't serve a purpose for a time, but that time has passed; it's time to move on and put in a big boy programming language.
rnhmjoj 11y ago
https://wiki.haskell.org/The_JavaScript_Problem https://wiki.haskell.org/The_JavaScript_Problem
- nilliams 11y ago
  Would just like to point out that though Haskell may be an interesting language this url and title itself is still needless, passive-aggressive douchebaggery from the author responsible, and a turnoff to many JS devs like myself who aren't fools and may want to consider Haskell one day. 'The depths to which JavaScript sucks are well-documented and well-understood.' Same applies to Haskell. As with any language, humility please.
brandonmenc 11y ago
> Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere." That's a legitimate complaint. There's so much inertia that without the backing of the major browser manufacturers, any effort to introduce a change is doomed to obscurity. People are allowed to complain, even while not being able or willing to work on a solution. We used to do that with DOS all the time.
lorddoig 11y ago
Although your suggestion may be popular, it is, in fact, suboptimal. If one believes that "JS is the worst thing to happen to the web" and that "some other language would miraculously solve all of the problems" then going off into the wilderness to "create" is almost certainly a dead-end endeavour. A language is only one component of what's needed to replace JS - there's also winning over 4 major browser vendors who've dumped no trivial quantities of money, time, and PhDs into polishing this particular turd.[0] Then there's the standardisation peeps and so on. It's not so much a technical challenge - many existing languages could add support for DOM APIs and become an in-browser candidate relatively trivially - but a political one. And when was the last time you heard of someone solving a political problem by saying "hey guys, I've got a great idea here"? Some not-absurd propositions: 1. "The finance system is shit" 2. "Modern government is shit" 3. "JS is shit" All 3 of these have many potential non-shit replacements - but things never change. Why? Because barriers are very, very real. These things could only ever fall to the most expertly executed, well resourced, and lucky of targeted attacks. The only viable strategy for the average "hater" (whose "hate", incidentally, is emphatically not invalidated by his lack of perfect solution) is to try to affect top-down change. Now, no one person is likely to achieve this - even exceptional people have a fearsome challenge when faced with groupthink (Galileo, anyone?) So what is in the "haters" toolbox? Well, seeing as web standards authorities are run like district councils in the 1980's (go try to find out how to make your view officially known on an ECMAScript draft), us in the peasantry have little but our ability to create and maintain a murmur - and occasional scream - of discontent which hopefully, one day, might have some psychological effect on those who do hold the power, because lord knows it's not us users. You may recognise this particular strategy from historical great hits such as "representative" "democracy" and friends where it has been, on the whole, a slow, inefficient, wasteful, but occasionally effective way of going about things. So my well thought-out and actionable strategy is to ignore this advice and continue to grumble - and, if you can manage it, try to be just a little bit louder than last time: shit adds up at scale. [0]: Mr Eich told me himself that they're too invested in JS, see https://news.ycombinator.com/item?id=9264531
- knightofmars 11y ago
  There's a difference between spouting negative emotion filled complaints into the ether (or claiming things are "shit" or a "turd" on random hacker news comment boards) and positively engaging in a community to effect change. All of the statements you've made are just a more articulate re-hashing of the same facts that everyone knows. You're engaging in the same cycle of "Problem here! Barriers!" If everyone took the viewpoint you've described and extrapolated it into the rest of life nothing would ever be accomplished. Yet somehow, here we are flying around the world in a day and walking around with futuristic computer phones in our pockets. Just because you think the barriers are too large for you doesn't mean they're too large for everyone (and resources are something you accumulate, you don't wake up one morning with them at your beck and call). "...but things never change." I think you're wrong. Things do change. They just don't change at a pace that is fast enough and obvious enough for someone who feels passionate about an issue (Gay rights, Women's rights, Black's rights, all civil rights crusades, anyone?) And it often takes a long time for people to realize they need to be actively engaged instead of complaining from the sidelines before any change occurs. By all means, continue to grumble on comment boards, just don't act surprised or upset when the direction of the thing you were grumbling about doesn't go the way you want it to.
SilasX 11y ago
"You haven't single-handedly brought about the adoption of a superior client-side language in browsers. Therefore, the double/triple-equals thing was a great idea."
modarts 11y ago
"Don't talk about it: be about it" -Bob Burns
peterashford 11y ago
The simplest solution would be to specify a VM for the web - that way people could use whatever language they like. Using JS for this purpose is suboptimal. This would require people like Eich to entertain alternatives to his diseased progeny.
- BrendanEich 11y ago
  Hi Peter, I hope you can see (or will soon see) that a specified polyglot VM for the Web is what I've been working on all along.

deezenuts 11y ago

knightofmars 11y ago
I would +1 your username if that were a feature of YC.

teacup50 11y ago

There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.

pcwalton 11y ago
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine, and try and write the browser in JS. You mean like Firefox?
- mattmanser 11y ago
  Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
  - pcwalton 11y ago
    > Works on OSes. We have a choice. The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude. Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js. > Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable? That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static. Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
    - ForHackernews 11y ago
      Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
      - nostrademons 11y ago
        Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there. The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
TazeTSchnitzel 11y ago
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
- 14paninta 11y ago
  What does that even mean? It's nonsensical. Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. Microsoft can ship the CLR for ARM, x86, PowerPC. You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Microsoft can't ship a fully functioning CLR for JS.
- TazeTSchnitzel 11y ago
  14paninta replied to this, but their comment's dead (shadowban?) - anyway, I'll repost it here and respond to it. > What does that even mean? It's nonsensical. What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain? >Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined. Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either. >You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture. >You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations. You can also retarget stuff compiling to JS to compile to something else, like Lua. >Microsoft can ship the CLR for ARM, x86, PowerPC. > You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you. Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you. > Microsoft can't ship a fully functioning CLR for JS. This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.
ender7 11y ago
Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.
- TazeTSchnitzel 11y ago
  ...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
  - 14paninta 11y ago
    asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
  - cwyers 11y ago
    I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
    - TazeTSchnitzel 11y ago
      Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
      - tosh 11y ago
rjsw 11y ago
Internet Explorer had a pretty clean API for adding extra scripting languages.
- TazeTSchnitzel 11y ago
  Yes, the Windows Script Host. But I don't believe two languages could very effectively talk to eachother, right? Couldn't they only really interact with the native code stuff (DOM etc.), i.e. the easy part?
  - rjsw 11y ago
    It wasn't too difficult to add an interface to COM from a new language, that seemed the easiest way to call "out" to something else.
- tracker1 11y ago
  And in practice, that separation layer lead to objects tied together across COM boundaries, and severe memory leaks for any significant applications.
sqren 11y ago
> Or, they could take their own medicine, and try and write the browser in JS. Like Blink-in-JavaScript[0] ? ;) [0] https://www.chromium.org/blink/blink-in-js https://www.chromium.org/blink/blink-in-js

arbsn 11y ago

I don't believe that someone needs to have a solution in order to observe that there is a problem. The resources available to an individual for creating and reasoning are finite, and as long as one is able to give good reasons why they know that there is a better way, "there is a problem" may still be valuable information.

swsieber 11y ago
If it wasn't widely know that Javascript is a problem, then merely observing that it's a problem instead of trying to provide a solution would be useful. But it's a widely known problem and so complaining does nothing useful. Essentially, at this point in the game, complaining is useless rehashing of a beaten horse.
- mozumder 11y ago
  There's a whole world of problems to fix before you even get to the problem of Javascript. Right now, the world only has 3.5 base browser engines. Those browser developers have no interest in adding a new standard language like Python, even though more people prefer that to Javascript. So, if you were to develop a new browser language, you need to build a new browser from scratch, and then move a billion people to it.
  - cmdrfred 11y ago
    Man, python on the server and in the browser. What a world that would be.
    - Ygg2 11y ago
      Filled with version problems :P Oh, you got Python 6, well we have Python 8 which breaks your code in subtle ways.
    - coderzach 11y ago
      2.7 or 3?

olau 11y ago

I sometimes wish Javascript would take more hints from Python in getting some of the details right. For instance, it would be nice if == would work so that ["foo"] == ["foo"] and { foo: 1 } == { foo: 1}. But I suppose fixing that would be a too bold move. I like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python.

nilliams 11y ago
> like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python. I'm a Python fan but I can't disagree more on that point. Python has terrible lambdas, and poor idioms when working with collections (list iteration over chainable/fluid interfaces). Underscore.js, which at this point stands for 'idiomatic JS for collections', and the ES5 methods on arrays (filter/map) which are largely supported now provide a better way to handle arrays & hashes than idiomatic Python. With ES6 fat-arrow functions it's even better. It's one of Python's biggest weaknesses when compared to other dynamic languages IMO -- that the idiomatic way to deal with 'collections' is not a chainable/fluid pattern, but instead to do multiple list comprehensions, or use the ugly filter-plus-lambda patterns which compose badly. Double evens in a list: ES6: [1, 2, 3] .filter(x => x % 2 == 0) .map(x => x * 2) ES5: [1, 2, 3] .filter(function(x) { return x % 2 == 0 }) .map(function(x) { return x * 2 }) Python: map(lambda x: x * 2, filter(lambda x: x % 2 == 0, [1, 2, 3])) # or evens = [x for x in [1, 2, 3] if x % 2 == 0] [x*2 for x in evens] The ES6 & ES5 JS examples are both clearly superior syntax IMO. More readable and the anonymous functions support multi-line so extend to more use-cases. EDIT: Removed the word 'objective' because I'm talking syntax.
- dragonwriter 11y ago
  > ES6 & ES5 JS are both objectively better IMO. This sentence reveals a deep misunderstand of either what "objectively" means. (FWIW, I prefer the ES5/ES6 syntax to Python here, as well; I just don't mistake that preference for something other than subjective.)

copsarebastards 11y ago

I'm one of the people who says JavaScript is the worst thing to happen to the web, and I don't need an alternative to say that, because my issue is with what JavaScript does, not how it does it. An alternative that does the same thing wouldn't solve my complaint. I don't want a web where all my software and data is owned by other people who don't have my best interests in mind. JavaScript allows "free" websites to replace programs running on my machine which is fundamentally opposed to my goals. I don't want all the power that computers have brought to humanity to be concentrated in the hands of corporations, I want it to be free for anyone to use. I'm glad JavaScript is shitty and I wish it were shittier, because that would slow the growth of corporate control over our capabilities and data.

aeze 11y ago
You're misplacing the blame.
- copsarebastards 11y ago
  I'm not placing blame at all. I don't think anyone could have foreseen what effect JavaScript would have on the internet.
palmer 11y ago
Lots of corporations that don't have your best interest at heart write software that doesn't live on the web, in any number of languages. Conversely, I can write open-source javascript that does something useful for you, that does not mine your data or do anything of that sort. I don't see how this relates to javascript.
- copsarebastards 11y ago
  The most pervasive and harmful companies all use JavaScript and couldn't do the harm they do without it (or, I suppose, an equivalent technology). I would venture that I could solve all the problems you would solve with open source JavaScript with another programming language, because almost no program actually needs to be a web application.

cookiecaper 11y ago

The correct solution is to write a DOM interface for Python and start distributing browsers with Python VMs. Python's not a perfect language but it's much better than JavaScript. There are acceptable alternatives besides Python too, but that would be my favorite. I don't see why we need to invent a whole new scripting language for client-side execution on the web, the problems really aren't that special. I know the history of JavaScript and I'm not saying it didn't serve a purpose for a time, but that time has passed; it's time to move on and put in a big boy programming language.

rnhmjoj 11y ago

https://wiki.haskell.org/The_JavaScript_Problem https://wiki.haskell.org/The_JavaScript_Problem

nilliams 11y ago
Would just like to point out that though Haskell may be an interesting language this url and title itself is still needless, passive-aggressive douchebaggery from the author responsible, and a turnoff to many JS devs like myself who aren't fools and may want to consider Haskell one day. 'The depths to which JavaScript sucks are well-documented and well-understood.' Same applies to Haskell. As with any language, humility please.

brandonmenc 11y ago

> Don't whine about the barriers and how a new language would never be adopted because "JS is already everywhere." That's a legitimate complaint. There's so much inertia that without the backing of the major browser manufacturers, any effort to introduce a change is doomed to obscurity. People are allowed to complain, even while not being able or willing to work on a solution. We used to do that with DOS all the time.

lorddoig 11y ago

Although your suggestion may be popular, it is, in fact, suboptimal. If one believes that "JS is the worst thing to happen to the web" and that "some other language would miraculously solve all of the problems" then going off into the wilderness to "create" is almost certainly a dead-end endeavour. A language is only one component of what's needed to replace JS - there's also winning over 4 major browser vendors who've dumped no trivial quantities of money, time, and PhDs into polishing this particular turd.[0] Then there's the standardisation peeps and so on. It's not so much a technical challenge - many existing languages could add support for DOM APIs and become an in-browser candidate relatively trivially - but a political one. And when was the last time you heard of someone solving a political problem by saying "hey guys, I've got a great idea here"? Some not-absurd propositions: 1. "The finance system is shit" 2. "Modern government is shit" 3. "JS is shit" All 3 of these have many potential non-shit replacements - but things never change. Why? Because barriers are very, very real. These things could only ever fall to the most expertly executed, well resourced, and lucky of targeted attacks. The only viable strategy for the average "hater" (whose "hate", incidentally, is emphatically not invalidated by his lack of perfect solution) is to try to affect top-down change. Now, no one person is likely to achieve this - even exceptional people have a fearsome challenge when faced with groupthink (Galileo, anyone?) So what is in the "haters" toolbox? Well, seeing as web standards authorities are run like district councils in the 1980's (go try to find out how to make your view officially known on an ECMAScript draft), us in the peasantry have little but our ability to create and maintain a murmur - and occasional scream - of discontent which hopefully, one day, might have some psychological effect on those who do hold the power, because lord knows it's not us users. You may recognise this particular strategy from historical great hits such as "representative" "democracy" and friends where it has been, on the whole, a slow, inefficient, wasteful, but occasionally effective way of going about things. So my well thought-out and actionable strategy is to ignore this advice and continue to grumble - and, if you can manage it, try to be just a little bit louder than last time: shit adds up at scale. [0]: Mr Eich told me himself that they're too invested in JS, see https://news.ycombinator.com/item?id=9264531

knightofmars 11y ago
There's a difference between spouting negative emotion filled complaints into the ether (or claiming things are "shit" or a "turd" on random hacker news comment boards) and positively engaging in a community to effect change. All of the statements you've made are just a more articulate re-hashing of the same facts that everyone knows. You're engaging in the same cycle of "Problem here! Barriers!" If everyone took the viewpoint you've described and extrapolated it into the rest of life nothing would ever be accomplished. Yet somehow, here we are flying around the world in a day and walking around with futuristic computer phones in our pockets. Just because you think the barriers are too large for you doesn't mean they're too large for everyone (and resources are something you accumulate, you don't wake up one morning with them at your beck and call). "...but things never change." I think you're wrong. Things do change. They just don't change at a pace that is fast enough and obvious enough for someone who feels passionate about an issue (Gay rights, Women's rights, Black's rights, all civil rights crusades, anyone?) And it often takes a long time for people to realize they need to be actively engaged instead of complaining from the sidelines before any change occurs. By all means, continue to grumble on comment boards, just don't act surprised or upset when the direction of the thing you were grumbling about doesn't go the way you want it to.

SilasX 11y ago

"You haven't single-handedly brought about the adoption of a superior client-side language in browsers. Therefore, the double/triple-equals thing was a great idea."

modarts 11y ago

"Don't talk about it: be about it" -Bob Burns

peterashford 11y ago

The simplest solution would be to specify a VM for the web - that way people could use whatever language they like. Using JS for this purpose is suboptimal. This would require people like Eich to entertain alternatives to his diseased progeny.

BrendanEich 11y ago
Hi Peter, I hope you can see (or will soon see) that a specified polyglot VM for the Web is what I've been working on all along.