I'm disagreeing with the tone, but there's a lot of truth to this unfortunately:
1. ECMA has set themselves up for yearly ECMAScript updates. How that's considered helpful (to browser adoption that is, rather than job safety) remains a mystery to me. Right now we're in the habit of using javascript-to-javascript (babel) translation even for the most trivial of things; for example, Bootstrap 4's complimentary (now compulsory?) JS source requires it. Basically, we're suffering the worst of JavaScript (for webpack etc. alone, because browsers won't handle ES6 imports), without being able to enjoy JavaScript's strength (being able to run directly in the browser with a simple page reload).
2. Most newer ECMAScript features are refinements over earlier ones (eg. async/await, Promises). There's of course nothing wrong with that. But many idioms of modern JavaScript can only be understood if seen in context, and in the discourse of earlier idioms they're replacing. But this kind of iterative improvement will get us into a foobar'd web stack and just sets the stage for the next generation of web developers to reinvent the wheel.
I'm also questioning the way so-called "web standards" come into existence. There's no real community drive behind it; the standard bodies of old, such as W3C, are struggling apparently and leaving a void behind, and it's just Google et. al. dictating things. As a result, your new shiny React app runs only on Chrome. Now if you just want a portable app framework, there are much better options available; there was no need to pollute the web with it.
Edit: typescript, or any other compile-to-javascript language, isn't the answer
I usually find myself somewhere on your side of the argument, but I don't get it.
Re: 1. Do you mean to say that browser adoption of new language features is slower now that the language spec is moving faster? If anything, ECMA is putting the pressure on browser vendors to release features faster. There's always going to be some kind of lag between the spec being out and browsers implementations. Doesn't mean the spec can't continue making forward progress.
Re: 2. This point is over my head I think. Can you elaborate?
Re: React. My shiny new React app works in whatever browser I build it for. You know that Facebook itself is built in React right? You don't have to use async/await, or Promises if you don't want to. And if you have to, that's what shims are for.
Re: Google dictating things. I can't say I know who employs the people sitting on ECMA meetings. Would it be such a bad thing if some of them worked for Google? I for one, would welcome our new Google overlords. You know .. the people sitting at these boards are people who have a vested interest in the future of JS. They have an incentive to keep pushing the envelope. It's just how things work. And it's good for us too.
Re: compile-tojs language not being the answer: What?? It sounds like your problem is precisely with JS! Both as a language and an organization. Why wouldn't the answer be some other language that relieves you of those worries?
What I meant is that a JavaScript release cadence shouldn't be set ahead of time, but rather adapted to the state of actual implementations in browsers.
> Re: 2
Try training a beginner on JavaScript. I have (kids on simple games), and the language and environment is so idiosyncratic already that piling new abstractions, OOP, syntax sugar and grand aspirations onto it isn't a net win for me. My bad experience with teaching JavaScript was because of strange/heisenbug-like rAF async races and general quirkiness I could figure out as someone with compiler development experience, but had a hard time explaining to novices.
> Re: Google dictating things
The problem with Google is the dominance of Chrome/WebKit browsers, or rather the out-of-control complexity of "web standards". Creating a browser from scratch is considered economically impossible at this stage. Given that a good part of our daily communication and information is on the web, at a certain point you need to weigh how complex you want the web stack to become, when the price to pay is a dependency on a single party or single piece of software. Note I'm not saying this is an evil plan or something, it's just how things are developing on the web. From that point, it's not far for the web to become AOL 2.
> Re: compile-tojs language
But I like the practical and unassuming side of JavaScript, and would rather see JavaScript being used and improved for things it was designed to do. Basically, manipulating DOM items with direct namespace bindings into the language in response to user activity. I also like JavaScript's ubiquity and portability (the "Script" in JavaScript).
I see, thanks for explaining. I totally get the frustration with the complexity of the web platform. I don't like running into heisenbugs either, and explaining rAFs to someone who is still trying to grasp the fundamentals of coding sounds like a special type of hell to me. That's why I don't use those APIs. They are there for experts who know they need them, and are best ignored by everyone else. It's with this mindset that I say, "let them build the runtime the web deserves". It will be complex, but not needlessly. The complexity will be inconvenient to many until we abstract it away, and we will. Lots of progress already in terms of libraries (React and others) and languages (CLJS comes to mind).
Building a browser should be hard. It's really an OS. You don't hear complaints that Linux or Mac provides too many types of system calls or low level features. Unless you're a subject matter expert, but if you're teaching kids how to code simple games, you start with Python or something, not C or machine code. It's needlessly complex to build something useful using those languages. So if your point is that it's becoming needlessly complex to use JS on the web platform (whether your beef is with the syntax, or the APIs of the platform), why not use a language that removes all that complexity? There are beautiful solutions to precisely these issues. Speaking for ClojureScript here .. (but of course many more langs compile to JS). Moving to this lang will remove OOP, all the es6/7 syntactic madness, and any and all issues related to object instance equality. There is no such concept of an instance of an object in that language due to it's immutable, persistent data structures. Add the ground breaking core.async into the mix, and you have relieved yourself of all heisenbugs related to async stuff. You don't have to worry about what a Promise is, etc .. it's nice.
I get your sentiments toward the practical, scripty side of JS. But I think it's reasonable to say, either practice restraint and _only_ use those good parts, or if that proves to be difficult, it's time to move on to a better, higher level, more safe and fool-proof language. And you can still interop if you want. Either way, core language and platform innovation must go on.
1. ECMA has set themselves up for yearly ECMAScript updates. How that's considered helpful (to browser adoption that is, rather than job safety) remains a mystery to me. Right now we're in the habit of using javascript-to-javascript (babel) translation even for the most trivial of things; for example, Bootstrap 4's complimentary (now compulsory?) JS source requires it. Basically, we're suffering the worst of JavaScript (for webpack etc. alone, because browsers won't handle ES6 imports), without being able to enjoy JavaScript's strength (being able to run directly in the browser with a simple page reload).
2. Most newer ECMAScript features are refinements over earlier ones (eg. async/await, Promises). There's of course nothing wrong with that. But many idioms of modern JavaScript can only be understood if seen in context, and in the discourse of earlier idioms they're replacing. But this kind of iterative improvement will get us into a foobar'd web stack and just sets the stage for the next generation of web developers to reinvent the wheel.
I'm also questioning the way so-called "web standards" come into existence. There's no real community drive behind it; the standard bodies of old, such as W3C, are struggling apparently and leaving a void behind, and it's just Google et. al. dictating things. As a result, your new shiny React app runs only on Chrome. Now if you just want a portable app framework, there are much better options available; there was no need to pollute the web with it.
Edit: typescript, or any other compile-to-javascript language, isn't the answer