Hacker News Reader

Comment by simula67 | Hacker News Reader

> It turns out it’s useful to have a lingua franca for the web.

No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference.

> Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding

Lots of languages have a wide array of freely available code tooling and frameworks.

Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?

I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers.

JavaScript is obviously a flawed language[1] that inspires absolutely bad programming that the rest of us has to deal with. The ecosystem is terrible[2] and the community is full of self-righteous assholes[3] who has the collective attention span of a 2 year old [4].

Let's just call this experiment a failure, cut our losses and just.move.on.

[1] https://www.destroyallsoftware.com/talks/wat

[2] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

[3] http://atom-morgan.github.io/in-defense-of-douglas-crockford

[4] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

View on HN

I can't believe this is the top comment. Let's go point by point:

1) JavaScript has its warts and its gotchas like anything else (okay, maybe a few more). So what? Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Same goes for just about any other language. Focusing on the weird edge cases might make for a nice blog post, but it's not relevant to people actually building things day to day.

2) Growing pains in a very active community? Unheard of! Okay, so this was embarrassing and disappointing, but at least it's been dealt with. You can keep pointing to it if it helps your argument, but that doesn't make it valid.

3) I don't really understand what point you're trying to make here.

4) Again, very active community. Lots of churn. Plenty of reinventing / rediscovering the wheel. If that _really_ bothers you and you're struggling to separate the signal from the noise, I at least understand and respect that criticism. I don't think that's a reason for anyone to stoop to the level you have, though.

>> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on...

I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.

> I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.

You should look into typescript, it has helped us quite a lot with that particular matter.

> Tracking down things in JS is a timesuck of epic proportions.

I think you mean your codebase rather than JS. There are plenty of industrial JS codebases where this is not a problem.

I'll be the first to confess I'm not a JS wizard. That being said, it'd be nice for the following to be easier:

* figuring out which events are listening to a given DOM element at any given time

* sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company

* no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")

* keeping CSS out of JS, and JS out of HTML

* dealing with features tightly coupled to an ancient jQuery plug-in

I could go on forever... JS isn't necessarily that bad, but the way people use it is often suboptimal.

Not to be too pedantic, but most of those things have nothing to do with JS.

> figuring out which events are listening to a given DOM element at any given time

This is part of the DOM Specification, not JS. You may be using JS to manipulate and listen to the DOM, but the reason that browsers don't support doing thing X natively is because the DOM Specification does not specify it.

> * sane debugging for things Facebook Coonnect, which had a really confusing implementation at my last company

Again, this is about a Facebook client library, not Javascript.

> * no magically defined functions or variables (i.e. foo["bar"+ someId] = eval("function () {...}")

If you mean the use of eval to change the runtime environment, pretty much every dynamic language supports some form of eval. It would also be impossible to write certain types of code without eval.

> * keeping CSS out of JS, and JS out of HTML

Not sure how this is a criticism of JS.

> * dealing with features tightly coupled to an ancient jQuery plug-in

Again, this is a common software engineering problem, and has nothing to do with Javascript.

I think you've illustrated some of the reasons that Javascript is so apparently unpopular -- often (but not always) people reference some aspect of the DOM, or jQuery, or whatever vendor-hacked snippets from the late 90s that they remember, without considering that the "bad" parts of the language are by now well known, and there exist extremely efficient and standards-compliant, double-JIT'ed runtimes for JS.

If only web developers would unite and put an end to JS once and for all.

This is really sad, a whole industry that was once inspired by Unix philosophy and was supposed to be beautiful and fun, is now conquered by languages like JS, php, and Java: so ugly and so not fun.

I always thought programming should be something you do cause you like it, not because you're forced to do it. If you use JS cause "everybody else uses it" and "it pays more", then I'm sorry, you're screwed. I thought CS industry belongs to developers, not tech giants (Oracle, Microsoft, ...) who force Java and JS on everybody.

Someday, some body will stand up and say "Enough is Enough".

Edit: If you want to downvote, at least please tell me why I'm wrong...

> (Oracle, Microsoft, ...) who force Java and JS on everybody.

Why call out Microsoft? They aren't forcing Java or JS. They came up with C# and Typescript instead.

I can't speak to Typescript, but C# is way more fun to write than Java. It's not particularly interesting or glamorous, but it is nicer to write.

I meant in general. Microsoft did force their flawed Windows on everybody anyway.

Microsoft forced Windows on everyone, therefore by the transitive property of online griping, Microsoft also forced JS and Java on everyone? But in general, so it makes sense.

This is like saying Coca-Cola is responsible for the high sugar content in Hershey's chocolate. In general.

Disclosure: Microsoft employee.

We've converted all our JS to TS, huge timesaver.

You are forgetting that even Eich didn't want to do JS; he wanted to embed Scheme but was overruled by suits at Netscape who wanted to ride the Java hype. That's why the semicolons and curly braces. It really is indefensible on technical grounds.

I think they also told him to make it forgiving, like html, so that beginners could use it. Thus the implicit conversion rules, optional semicolons, being able to leave new off a function constructor, not having to use var, and so forth.

These laundry lists of js warts get dragged out continually, so I really have to ask: How are you people actually developing in javascript and haven't yet discovered linters?

Linters have been around for over a decade and solve all of these issues (as they do in other languages as well). They're also easily integrated in every text editor and build system I've ever seen.

And why shouldn't the interpreter support these rules? Because a linter can do this almost as easily, and not break backward compatibility.

The same can be said for C's flaws. Just use a linter.

That didn't stop people from wanting to come up with or use different languages in place of C, where possible.

It's too bad nobody pumped the brakes after it was a little successful, and said "Okay guys, let's stop dicking around and do this right now, before we have to deal with it for the next 30 years". Alas...

What state was guile in at the time? Could we have ended up with that instead of javascript?

> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours.

Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell.

JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its superficial design flaws.

It's a really bad, tasteless language.

> I don't think that's a reason for anyone to stoop to the level you have, though.

I really don't think he 'stooped' to anything.

In case Eich reads your comment: given that it had to be done in ten days and "look like Java", JavaScript is a fine langauge.

(But yeah, compared to languages that were designed over years obviously it's incredibly bad.)

To quote Eich (from here[1]):

" Ten days to implement the lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per our over-optimistic agreement, cloned java.util.Date -- Y2K bugs and all! Gosling...).

Sorry, not enough time for me to analyze tail position (using an attribute grammar approach: http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_...). Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self).

I'll do better in the next life. "

[1] Edit: jwz.org intercepts HN links. See mjgoeke's comment.

I'd recommend copy+pasting the link to www.jwz.org if you want to open it...

  https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1048

> The ecosystem is terrible and the community is full of self-righteous assholes who has the collective attention span of a 2 year old

> I don't think he 'stooped' to anything

Really? This is supposed to be a place for civil, mature discussion. There are plenty of valid arguments against javascript as a language and as a community, there's no need for childish comments like that.

I don't understand why people say javascript is such an awful language. The "Wat" video previously posted features of a few javascript idiosyncrasies, but I think most people would consider such obscure syntax combinations to be ill mannered, and most people understand to be very careful around type conversions.

At a higher level of organization, the language begins to matter less and less, and what matters more are that subcomponents within a larger system obey their contracts, and that there's some concurrency strategy if you have distributed state.

I don't understand why people say javascript is such an awful language.

Frankly, because from a language design perspective, it is - or at least used to be: Bad scoping rules (implicit global declarations by default, function instead of lexical block scope if var is present), weird implicit conversions, no good story for code reuse/object extension so everyone doing anything complex had to cook up their own version, ...

Nevertheless, I actually enjoy programming in Javascript ;)

> It's a really bad, tasteless language.

It's really not that bad. It's actually a good language, and getting better all the time. See? We can go back and forth, without any substance.

But seriously, modern JS is not that bad.

> Let's just call this experiment a failure

The problem with "just calling this experiment a failure"—why that won't work in practice—is that JavaScript is not a failure. It's extremely successful.

Browsers are successful and Javascript was lucky to be the common base of browser languages.

Pretty much this, although arguably JS's flexibility aided in allowing developers to get around various limitations. That can be seen as a good or bad thing, depending.

And it is extremely successful because it's not a bad language. Sure, there's lots of "wat", but a non-professional programmer is going to say "wat" about every strange error they get from another programming language that js would have just passed silently with a weird result. Then they will replace whatever construct isn't working with one that does, and get on with their life, unlike people who seem to have a lot of energy to waste on complaining.

Sure, but there are better alternatives, and now that JS isn't just confined to the web, where it had no real competition, people are complaining because they see it being used instead of better tools that have been available for a long time.

ES6 is better.

[edit] ES6 is definitely better than a swift kick in the groin. It is certainly better than the original version of javascript. And it is also better than a lobotomy.

Better than....? A swift kick to the groin? Original Javascript? Lobotomies?

"Better" doesn't necessarily imply "Good".

ES6 is definitely a better Javascript. But whether it's better than other languages on the server (or desktop) side is the question. But maybe by ES10 it will be.

I don't think there is universal agreement on what the better alternatives are. If there were, comments like these would list them. There are however worse examples for desktop development never the less used on the desktop like VBA, java, adobe air, scala.

As with so many choices, there is a trade off. If it were possible to point to some system that is unambiguously better on all axes than javascript and its ecosystem, then you'd have a point, but since there isn't, we're back to arguing trade offs, and really, getting upset about the tools other people choose to make things is a pretty fruitless use of time and energy. If people really want to encourage others to move, they'd be better evangelising the solutions they love than berating people for choosing what they choose.

> And it is extremely successful because it's not a bad language.

Perhaps not a bad language, but I do think it falls into the same category as PHP - just good enough.

It's just good enough to do what we want it to do, and given the lack of choice, we're willing and ready to pile abstraction upon abstraction upon it to try and reduce the pain involved with getting work done.

And like masochists, we look at the results and go "Well, that didn't hurt too bad this time, so I'm willing to go do it again."

I don't think you know what you're talking about. PHP, up to version 4 at least, was hardly even a language. More like a collection of macros.

Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.

> hardly even a language. More like a collection of macros.

You just described Forth, and a good portion of Lisp. Both of which are great, groundbreaking, and productive languages.

> an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility

Very eloquently said. However, compared to other dynamic languages like Lisp, Perl, Ruby, and Python, it doesn't strike me as particularly free or flexible. The ability to create and use DSLs directly within those languages really displays true flexibility and freedom, IMO.

Of course, you don't always want unlimited flexibility and freedom in a language; it's why a particular type-safe languages with a very restrictive borrow checker is so popular.

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation.

Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

Operator overloading in Python made the Pandas library possible where you can treat a DataFrame syntactically like you can in R, which is really nice for data science.

"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.

It's not just arithmetic, it's also being able to use comparison operators to filter, which is really convenient. What languages like R do at the syntactic level is make the programming language closer to math, where you can do things like add vectors or multiply matrices using simple operators.

Also, it adds up (no pun intended). You're right that add() vs. + for a simple case when you only do it a few times is no big deal. But it is a bigger deal when you do it a lot, and the arithmetic can be a little more complicated.

We could by analogy apply this argument to adding integers and floats together. It's more convenient to use the + operator for that, but someone could argue that an add() function is just a minor inconvenience, so why bother overloading the + operator?

That is until you have to use it hundreds of times.

We apparently have a very different definition of DSLs. Both jQuery and Lodash are, to me, libraries with lots of functions. A DSL, to me, would be a change in the underlying language being interpreted.

i.e.

    describe file("foo") do
      it { should exist }
      it { should be_owned_by "root" }
    end

vs.

    _.map(["a"], function(s) {alert(s)})

  describe("something", () => {
    it(should(exist))
    it(should(be_owned_by, "root"))
  });

Also

  _.map(["a"], s => alert(s))

Or just

  _.map(["a"], alert)

Except your rspec example isn't a change to the underlying language is it? Also, Check out mocha for the JavaScript equivalent.

Also, when you use only one function of lodash, you can't call it a language, but there are chains and flows for creating powerful pipelines for collection processing.

Compared to what? PHP is/was far, far worse than JS has ever been, and I remember when you couldn't declare a function in a function (IE3 iirc). There are a few, well defined quirks, and some other behaviors that are arguable, but JS is one of the most expressive languages around, and with the ES2017+ enhancements really nice.

JS is my favorite language, hands down... C# is a close second, and that's as much for the tooling as the language, though the p/invoke and native interfaces are pretty awesome. After that, there's some functional languages I like, and have been looking for a reason to use Rust or Go for something... beyond that, most languages have a lot of their own warts.

I mean, the whole "{} + [] == 0" thing is cute and all, but isn't that just tip-of-the-iceberg hilarity? Isn't the real problem with javascript that it's slow and messy?

I was under the impression modern JS interpreters JIT to machine code and are fast. Kind of like how Java was slow in 1995 but today is kind of amazingly fast. Which I guess implies that there are two ways a language can become fast: one is by being designed for speed, and another is by becoming extremely popular/useful and having tons of millions of hours of thought and work put into making it faster.

JS engines have improved by about 2 orders of magnitude in speed for actual use over the last 10 or so years. They've outpaced Moores law.

Probably because the head guy working on V8 had lots of experience with virtual machines going back to Self in the 80s. But it's kind of silly to say that JS VMs have outpaced Moore's law, given that interpreted JS was very slow to begin with. It's not the same as a compiled languge improving by that much in the same time.

Basically, JS wasn't leveraging much of the computer's power until V8 came along.

It seems that you're complaining about some perceived meaning in my comment, but I'm not sure what it was.

Having written significant pieces of code in javascript over the last 13 years, I've benefitted massively from those speed increases, and while I'm aware of a number of reasons that they have occurred (including but not limited to the v8 engine - I remember reading excitedly about tamarin, tracemonkey and the like), I don't think it's silly to point out the sheer magnitude of the improvement.

I'm not trying to say that JS is going to save us from Wirth's law or anything, I'm just trying to give people context on what a huge jump it has been.

Okay, but we can always replace "slow" by "slower than" and in a desktop environment (which the article is about), we could still compile C++ code to run natively and outperform JavaScript any day. The whole brouhaha about JavaScript being fast stemmed from it suddenly not being 10 times slower than native code in benchmarks. But it's still slower.

By using JavaScript you are, out of the box, sacrificing about 20% of your performance for the comfort of using it. In some cases, maybe only 10%. In others 50%.

I can totally understand how that's a trade-off one is willing to make in many cases. But for desktop apps, I kinda want them to run at full speed. Like, a 0.2 second delay can get annoying if it comes at the wrong time or stacks with something else. And somehow, you can feel that in many hyper-modern apps that are so many layers removed from the hardware, the devs probably don't even know where it touches it.

When I first started learning JavaScript, I wondered how people became proficient at the langue with all these weird quirks[0] that don't raise errors. Turns out that there are a bevy of things to help combat these quirks. Two of them are strict mode[1] (which can be scoped[2] in instances were libraries/frameworks would fail running in strict mode) and linters.

Strict mode and linters do not fix everything. This is doubly so if your developers ignore the warnings and errors that the linter throws. The language isn't inherently bad, but plain old JavaScript is not beginner friendly for new developers. It requires the discipline to not just throw things together.

[0]: https://dorey.github.io/JavaScript-Equality-Table/unified/ [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> I wondered how people became proficient at the langue with all these weird quirks[0] (links the usual loose equality table)

Why don't you all just use === instead of ==?

Tell me, how long does it take to learn it?

There are plenty of times where you want ==, or for that matter, any falsy/truthy expression in JS... about the only points where I have issues with some of the defaults for falsy/truthy come down to the number 0... Outside that, I find that there are times where I'm dealing with inputs that can be a string or number, and the coercion can be handy.

I would never suggest people start learning programming with JS first... although, there is the huge benefit of not needing more than a text editor and browser (already on their machine) to get started with it. One area of JS that I HATE is Date... it sucks, it's woefully incomplete and moment-timezone is huge to download in a browser.

The primitives, coercion and a lot of other bits of JS I really appreciate... but === vs == is pretty low on my list... that said, I tend to prefer the airbnb eslint preset, so it makes me use it anyway.

> There are plenty of times where you want ==

FWIW, I've never used ==

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

> I'm used to javascript enough to think in advance

I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:

1) debugging someone else's code is a lot more time consuming than debugging your own

2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code

3) the docs are simpler to write and easier to read.

It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:

  function doStuff(a, b, c) {

      if (!c && b instanceof Function) {
          c = b;
      }
      c()
  }

"`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it."

I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.

Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.

True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.

It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error.

That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.

> so be it.. it didn't crash/error.

That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".

> If someone calls me with invalid input, and it's coerced and you get invalid output

But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.

I think I have used weak equality once, because I needed truthy/falsy. I've always used strong equality. I always tell people that unless there is an absolute need for weak equality and you can thoroughly explain why weak equality works better than another solution, refactor for strong equality.

The all these weird quirks thing was really a naive me talking back then. JS was my second language after Java. Anonymous functions, async execution, implicit typing, weak typing - it requires a different way of thinking when you move from Java to JS and you're just starting. Most everything is explicitly defined, and everything executes in the order that is listed in Java. JS is whole different beast.

>about every strange error they get from another programming language that js would have just passed silently with a weird result

Wait, do you mean to imply that "passing silently with a weird result" is somehow better than throwing a verbose, descriptive error?

Are there bad languages? Can you give an example of a such language? I'm also wondering why JS changed so much lately if it was a great language already.

> Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser.

You're not contradicting what you are replying to. People are using Javascript because it's the only option, but it is useful to have a lingua franca.

I just wish that lingua franca wasn't Javascript.

I agree with the first part.

The issues of: "utility of lingua franca" and "ubiquity of Javascript" are orthogonal issues.

It seems everyone agrees that Javascript would not have been the first choice of language. There is no short argument there, you have to go out and try at least one other language and compare them.

However, on the second question, I don't see why it is useful to have a lingua franca.

Multiple languages arise out of multiple needs. You want a superfast language for your OS, you want a quick high level language for quickly examining data, you want a language that describes visuals and so forth.

What are the benefits of a lingua franca for the internet, or any other domain? They still get to exchange data in an agreed upon format.

Because all of the languages supported by the browser have to interact with the DOM. DOM memory management is incredibly tricky: it will not do to just have "an agreed upon format" to exchange data between such languages. You need all the languages to participate in a single garbage collection regime and to have semantics for interoperability at the object level between all of them, which is a very difficult problem.

Even getting interoperability between JS and C++—what the browsers do to implement the DOM—has been exceptionally difficult, with innumerable security vulnerabilities resulting from this.

When I said "agreed upon format" I was thinking of something like JSON to talking to the server. I didn't think of various tabs on a browser having to interact.

You probably know more about how the browser works than I do, but I think I see what you're saying.

Suppose we implemented a browser that can allows front ends coded in RUST. In my mind, the browser just gives the RUST app its own tab, with its own memory and so forth.

I am not proposing mixing up languages for the a given front end, or for components within an application or anything. Not because I think that would be wrong, but because I haven't thought it through.

Also, when it comes to languages. I rather have one language to be agreed upon, and to have small, gradual improvements to that language while keeping the world standard and simple. In case of JavaScript the improvement is strong typing.

If you want strong(er) typing, just create with TypeScript or flow... I don't see nearly the value in it that you seem to.

> I just wish that lingua franca wasn't Javascript.

Why?

Just because undefined is not a function [0]?

[0] https://twitter.com/vikasgorur/status/744204277745254400

It's very far from the only option server-side (node), but a lot of people are using it there... and on the desktop (various native tooling options, electron, etc), and in mobile apps (react native, nativescript, cordova).

I know someone who's wished for "one language to rule them all" for a long time and wants/wanted that to be Visual Basic... It's a matter of perspective as much as anything else.

JS can be a very beautiful/expressive language... and mocking some of the corner cases of coercion doesn't really help the argument. JS started as a language for input validation first... it works in a way that input validation passes/fails very cleanly. It makes it a great transport/middle-man language actually.

> Learn something else.

No. I've never understood the anti-[language] viewpoint. Wouldn't it be great to have every language available in every ecosystem? Why bother with web assembly when we could just replace JS with python because that's what _I_ want.

[1] Let's be honest, This is every language. There are some stupid, stupid, STUPID parts of JS that everyone enjoys pointing out. And... since everyone points them out, nobody actually uses them.

[2] It happened and they changed the root cause within a week. I would view that as a pretty good ecosystem. Now take a look at python 2 vs 3. Almost 8 years later, and we still need: http://py3readiness.org/

[3] Every language.

[4] Just because people talk loudly about something, doesn't mean most people use it. 90% of the internet still runs on jQuery: http://trends.builtwith.com/javascript/javascript-library

I've spend a decade in c and c++, another in Java. I've now moved to Javascript and I love everything about it. Well not everything, I don't really like the whole NPM and millions of dependencies. I also don't like react and angular. But JS is so big, there's enough other stuff I do like.

You see, you don't have to like everything about it to enjoy working with it. I pick the stuff I care about and put my positive energy towards it, instead of my negative energy towards the other. You should try it. You're free to make whatever tools you use right now as easy to use and as quick to learn. Maybe if you try hard enough, us Javascripters might come join your side.

People just hate all old and we'll used languages. You hear javascript, java, and c++ getting hated on all the time. I feel like as languages age people just find all the stuff they hate about it. That being said javascript was a uniquely poorly designed language that only gained popularity by people being forced to use it. At least the modern versions of it seem to be have fixed many problems.

For [1] many languages have "wat"'s. Also, the leap from "wat"'s to "absolutely bad programming" is a jump in reasoning. You can be a poor hacker in any language.

For [2] and [4], they are issues with the ecosystem, which I suppose it related but isn't strictly js, ie., you don't have to use React (shock). For npm, at least that issue has been addressed.

[3] is a social issue...it happens in many places. Can you claim that the university system is flawed due to similar attitudes of students who attend university?

I'm a fan of "You can write COBOL code in just about every language." I saw a pretty large VB5/6 app that was entirely styled like a COBOL app.. it was hideous to debug/use/follow, but it can be done... After that, I decided a lot of the time, it isn't the language that's the problem most of the time.

[2], [3] and [4] I would argue are not problems specific to JS, but are problems with "lingua francas" in general. Ubiquity, massive massive general popularity and low barriers of entry for a language will lead to an ecosystem dominated by the NIH and overengineering of eager & inexperienced programmers, and by egos. This would occur were any language put in JS' position.

The challenge is navigating such ecosystems in a selective and informed way, which is a programming skill in itself.

> Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?

Humans that "really wanted to" landed on the Moon, brought hundreds of millions of people out of poverty, cured polio and brought down Communism.

The real problem is that you'll never get that many people to agree on something like killing Javascript and creating something radically superior (whatever that is). The web ecosystem is proof of the highest level of agreement possible on a wide scale.

And to be honest, what's the alternative? If Javascript dies, we won't get a great new common programming language. We'll get 10 mostly walled gardens with barely any compatibility. Unix vendor wars, post-web edition.

Here's the thing -- we didn't need to get the moon's participation. A moon shot is an application of physics, with some concern for weight tradeoffs and fuel energy density and the like. It's not a coordination problem.

>Most people do not use JavaScript since it is useful. They >use it since it is the only option available on the browser.

Maybe it's the only option available on the browser because it is useful to have a lingua franca for the web.

simula67, are you aware that the website (http://jojiantony.xyz) in your profile goes to an Apple phishing website?

For a long time, there was no political will to kill Javascript; there was barely enough political will to reform it -- see the Eich vs. Wilson debate [1].

Now that JS has seen 2 new versions in 2 years, momentum has picked up and it's keeping up with the times much more so than in the late 2000s when its flaws were glaring and apparent. One of the interesting side-effects of the extra effort going into the web platform is the 'wasm' effort [2] which could replace Javascript at some point -- yes, the usual caveats about GC and DOM apply, but they're coming [3][4].

Though the political line is that wasm isn't intended to replace Javascript, once it attains feature parity (like it's headed towards), it'll be trivial to do so, regardless of what the designers intend. When that time comes, JS will probably still be used as a written language, but wasm will become the new compilation target.

[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban...

[2] https://webassembly.github.io/

[3] https://github.com/WebAssembly/design/issues/219

[4] https://github.com/WebAssembly/design/blob/master/GC.md

> I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers.

Where I live JS jobs are some of the highest paying actually. If anything people are moving to it.

> "Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ?"

Kill maybe too string a word (languages that reach the level of usage of JavaScript tend to stick around regardless of what's currently popular), but for me the main promise of WebAssembly is to allow web browsers to branch out from JavaScript as the only native programming language of the web (as well as improving performance).

> > It turns out it’s useful to have a lingua franca for the web.

> No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser.

Are you not contradicting yourself here? If people use JS only because it's what's on the browser, then it's only because people see value in ... having a lingua franca for the web.

I smell an agenda in the comment from the person with the username "simula67"... (this is a joke, by the way)...

Reply on news.ycombinator.com