Live data from Hacker News

JavaScript at 20

brendaneich.github.io

151–160 of 327 posts

Re: JavaScript at 20

#151

Cool presentation, but holy shit, taking ~2 minutes to load on FF and freezing the browser is not.

Anecdote, but I've got 30 tabs open in Chrome and I'm using a Macbook Pro that's over 7 years old and it loads in less than 3 seconds. Also, I can open it in Lynx. The un-alt'd images mean there's a bit of inaccessible content, but it's actually more or less coherent, which might be useful to those whose machines are struggling with the content or even (potentially) to those rendering opinions on whether the web just…

Anecdote, IE11 "Edge"-mode still doesn't support 3D CSS transformations. It's also end of life in Win8. The presentation worked fine in Chrome and Firefox.

It only consumes a few MB RAM. But the favicon of his website is missing - that's why it looks like it loads several seconds.

Re: JavaScript at 20

#152
> "Always bet on JS"

Yeah, that's why it took you so long to get basic things in the language. The JS crowd is finally excited that they have these nice shiny things. Quite a few of those have been a standard part of numerous languages for so long.

"Always bet on JS" basically means this: "JS is too big, so all the fuck ups I and others made will eventually be fixed. Because nobody is going to try to bet on anything other than JS now."

It's circular, Eich.

Re: JavaScript at 20

#153
WRT async/await, don't lazily prefer serial await, when parallel await is possible:

Serial example:

    async function someAsync(list) {
      let ret = [];
      try {
        for (let item of list) {
          let res = await asyncFn(item)
          ret.push(res)
        }
      } catch(e) { /* ignore */ }
      return ret;
    }

Parallel example:

    async function someAsync(list) {
      let promises = [];
      try {
        for (let item of list) {
          let promise = asyncFn(item)
          promises.push(promise)
        }
        return await Promise.all(promises)
      } catch(e) { /* ignore */ }
      return [];
    }

Re: JavaScript at 20

#154
post #14
post #11

Earlier quoted context omitted.

But there is no "best language", that's the problem. Compiling down to JS/asm.js is about as good as we'll get, realistically.

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

Self was bad because prototype based languages are not intuitive. This is why we get the endless years of people trying to explain why it's good or how to use it and endless "discoveries" and "frameworks" to leverage "new" tricks. JS is a mess because it's prototype based, to start. Same reason Pony is more progressive than Erlang (Prolog syntax?).

Re: JavaScript at 20

#155
post #131

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

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.

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.

Re: JavaScript at 20

#156
post #69

JavaScript is like English. It incorporates the best parts of other languages. Starting from Java, you can now see the clear influence of Python in ES6/7 with generators and string templates. I think this is JS's greatest asset.

> Python in ES6/7 with generators and string templates.

When I think of generators and string templates, Python is not one of the first three languages I think of.

Re: JavaScript at 20

#157

Earlier quoted context omitted.

> 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 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 optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.

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

Re: JavaScript at 20

#158

Earlier quoted context omitted.

I'm not a JS programmer so I was confused with using "let" and the arrow function to create a function versus using "function funcname {}".

Naming functions with 'var' or 'let' is possible in JavaScript because functions are first-class in JS unlike some common languages that don't have a functional paradigm (say Java). I think the function foo() {} syntax is mostly to make programmers coming from languages like Java feel comfortable but it does get confusing to have multiple syntax/semantics for declaring functions. The fat arrow '=>' in ES6 adds yet an…

I wonder if it wouldn't have been better to just declare "javascript 2", and write a compiler from "javascript 1/legacy" to "javascript 2" in "javasript 2" -- and suggest browsers/implementers used that.

I mean, do we really need both let and var; function * , function and => (I suppose having to mark a function as re-entrant at least one can understand, though)?

In the presentation, it's not clear (granted without commentary) why one would ever, for new code, write:

    // Interpolate expressions into a template string
    var name = "Bob",
        time = "today";
    
    console.log(`Hello ${name}, how are you ${time}?`);

    function dedent(strings, ...values) {
      let result = '';
      for (let i = 0; i 
And not:

    let name = "Bob",
        time = "today";
    
    console.log(`Hello ${name}, how are you ${time}?`);

    let dedent = (strings, ...values) => { // is this valid?
      let result = '';
      for (let i = 0; i 
I understand backwards comparability, but for at least Firefox, let won't work without marking the code in question as v1.7 anyway. It might as well have been Self, Ruby or R6RS.

While having as compact syntax as Smalltalk or Lisp might be going a bit far in the other direction -- I do wish they'd taken the time to simplify the language.

Re: JavaScript at 20

#159
post #122

Edit2: When do you switch off your transpiler and serve native ES6? In 2020? Original: What do you do in 2017? What if you already code in ES6 and transpile it to JS5 at the moment. Do you simply switch from serving JS5 to JS6? Older browsers (todays current browser) don't support "class", "let" and other new syntax constructs. The just fail with JS errors. Can one browse the web with IE11 and iOS 8 Safari in 2017? (…

The web is a lot more broken if you browse in IE6 than you appear to think. Some major sites work OK only because they had a financial interest (single digits of IE6 marketshare) until the last few years to maintain IE6 compatibility. This will degrade rapidly, but go off the very-well beaten path today and you'll find the web basically unusable. Backwards compatibility on the web has long been backwards compatibilit…

IE11 (Win8) and various devices that won't receive an update like many Android 4 and older iOS devices will be around for a few years!

Sure, you can use a transpiler and serve JS5 the next ten years (2025). What do you plant to do? It seems most simply haven't thought about the problems lying ahead.

Many were against the ES4/E4X changes that e.g. Firefox supported for some time, as they would have broken backwards compatibility. ES6 breaks backwards compatibility with the new syntax keywords and there is no fallback afaik. If there is a fallback, well then everything would be fine.

Wouldn't it be better if such vendors would ship an security & ES6 syntax support update to their old browser software?

Re: JavaScript at 20

#160

Earlier quoted context omitted.

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

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

I think the web is getting better in this regard. Since the introduction of emscripten and asm.js there have been some improvements to the tooling and runtime to make it so you can just write your app in C or C++ without really thinking about JavaScript.

It's only a matter of time before other languages can have the same level of support.

Post reply on HN