Live data from Hacker News

JavaScript at 20

brendaneich.github.io

251–260 of 327 posts

Re: JavaScript at 20

#251

Earlier quoted context omitted.

> Works on OSes. We have a choice. No, it doesn't work on OSes. OSes only handle one language: the native machine code of that platform. Everything else must be compiled to it. This is exactly the same as browsers. Edit: At least two people disagree with me (-1 points) - would you mind elaborating why?

Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.

> Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.

Uh, what? You do have a choice in the browser. I don't understand.

Re: JavaScript at 20

#252

Earlier quoted context omitted.

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 y…

> 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? Because we don't write assembly ourselves. Unless we are doing micro optimi…

> Because we don't write assembly ourselves.

Well, you don't write assembly because it's not pleasant to write in. JavaScript is actually quite high-level by comparison, so you can write in it, and many people do.

> Unless we are doing micro optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.

You don't need to look at generated JS either. If the tooling sucks then you do, but that is only because we live in early days, and the tooling isn't quite there yet.

> JS is not the "assembly of the web". It's a high level language. Your comparison is idiotic.

It is a high-level language! But it is also a good compiler target, and contains a low-level language (asm.js) which is also a good compiler target.

It's not a poor comparison.

Re: JavaScript at 20

#253

Earlier quoted context omitted.

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…

Man, python on the server and in the browser. What a world that would be.

Ta.....da? http://pyjs.org/

Re: JavaScript at 20

#254

Earlier quoted context omitted.

> And giving a real choice of language would been even better. You have a real choice of language! You can use any language you like, and compile to JS. Or are you going to complain that x86 CPUs provide no "real choice of language", offering only x86 assembly?

Unless you have all of the optimizations available to the lowest level you are restricted which is why people complain about "only JS". There are no optimizations missing from x86 so complaining about it is pointless. Especially given the improvements in sandboxing having a more powerful underlying language could improve things (note that this doesn't mean it needs access to the API of the underlying OS, which is whe…

> Unless you have all of the optimizations available to the lowest level you are restricted which is why people complain about "only JS".

> There are no optimizations missing from x86 so complaining about it is pointless.

Not true. x86 is a high-level language and modern x86 CPUs do a lot of fancy stuff behind-the-scenes to try and make code run better.

Re: JavaScript at 20

#255
This page caused my iPad to hard reset. Twice.

That's pretty impressive actually, but I don't currently have access to any other computers to read it on, so it's also quite bothersome.

Does anyone have an alternative URL with the content, but without the slideshow or whatever it is? I'm presuming it's some JavaScript that is causing the crash.

Yes, I appreciate the irony and no, I'm not trolling. I really want to read this!

Re: JavaScript at 20

#256

"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 someth…

https://wiki.haskell.org/The_JavaScript_Problem

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.

Re: JavaScript at 20

#257

"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 someth…

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

Re: JavaScript at 20

#259
post #240

Earlier quoted context omitted.

As I understand it, yes, 'var' is now obsolete. 'let' does the same thing with less confusing semantics.

I disagree, function scope is not going away. So I still have to understand that. If I mix in lexical scope, I now have to think about 2 scopes, which makes my life worse.

I think one could argue that function scoping is no longer necessary - there's nothing you would do with function scoping that you couldn't do with lexical-block scoping, since with lexical scoping, you can still declare variables at a function block scope.

The only real benefit I can think of from function scoping is hoisting, reliance upon which strikes me as an antipattern.

Re: JavaScript at 20

#260
post #15
post #14

Earlier quoted context omitted.

JavaScript is further from an ideal language than many out there.

It isn't, because there is no ideal language. Seriously. Even if there was the goalposts would keep moving anyway as things like functional programming get more popular. My ideal language is one that I can use as often as possible in as many different contexts as possible. JavaScript is alright for that.

Do you think people will be using JavaScript 10,000 years from now? What you're saying implies they might as well.
Post reply on HN