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?

> Re: 1

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.

Don't worry, Web Assembly (or something similar) will soon be ubiquitous and having one, thoughtlessly tossed together, horribly "designed" language which constantly receives updates that are wholly ignored where it really counts will no longer be the reality of web targeted development. If there is one good thing about web dev today it's that adoption of new tech in the client space is really fast.

Of course, personally, I solve this problem by refusing any job that requires me to use JavaScript more than twice per complete solar eclipse. That's worked quite well now for over a decade.

> ...refusing any job that requires me to use JavaScript...

I'm getting jealous. Most job offers I see conflate software development with web development and even jobs earmarked “backend” come with JavaScript baggage.

Native mobile app development is the exception here if you can weed out the "we need an iOS developer with a strong understanding of Angular.js and HTML5" jobs or the React Native jobs that some consulting company talked a hiring manager into thinking they need.

I get to write our internal web apps in seaside (Smalltalk framework. It's awesome in ways most people can't even imagine) and let colleagues that actually like web development fix any serious UI issues.

Web development can be a bliss.

Every time I try to get into Seaside, I can't get past the mangling of URLs that takes place. Have they come up with some way around that?

I don't think so. To survive web development I have just accepted that I am standing on one toe on a ship of abstractions upon abstractions trying my best not to fall off.

Safe plan for sure. The whole damn thing is patched together with popsicle sticks and rubber cement.

What do you do? I was a Windows application and back-end developer for a long time, with only occasional forays into web. Took a job at a consultancy about 8 years ago, and it's been all web-dev ever since.

That's a more interesting question to me right now because I was actually wondering exactly what the answer was myself. I've been thinking of looking for a new job since my current employer grows ever more ... shall we say, unstable, over time. Really it's the market, and at least they are trying to adapt... But, anyway, I've been here a long time though, and it's mainly because I've had the pleasure of moving across many projects with enough variety and newness to keep me interested. Oh and they are extremely flexible with my work schedule and situation (WFH, set my timeframes 99% of the time.)

So I made a list. In 15 years as a working pro, across 3 corps, I've worked on 18 substantial projects.

There has been something of a theme with almost every project I've spent my time on. It's pretty generic sounding, but, data integration is probably the best term for it. The one project I spent the most time on and dug my hands into the deepest was a home grown message queue/pubsub middleware system, with some business specific semantics built in at the protocol level. I've worked on large scale vertical integrations for state compliance (basically, getting a bunch of data out of an extremely semantically burdened personnel db transformed and delivered to a state entity for compliance with reporting laws. Constantly, streaming style.) And also some cool small scale apps purely for doing research, which is where I fell in love with Spring Boot. I was so shocked at how fast we could have a serious Java app platform up and running with everything required for the whole stack using that tool, and that was like 4 years ago.

Anyway, all my projects kinda look like this. It's easy to call most of them ETL implementations, I guess, but they always have some particular complexity that keeps them from being solved with off-the-shelf tools, or at least, not completely solved.

The only time I have had to do web development in the last, say, 8 years, has been propping up dead simple UIs to some of the unfinished systems just to drive some user flows, UIs that are inevitably replaced by something "good" by someone else later, or a CLI even. And to be clear, I've got no qualms implementing services to be consumed by the front end. It's the forced dependency on tools I view as ill suited to reliable software production and collaboration (mainly JavaScript, in all its forms) that bug me. And while it's admirable that so many people keep trying to "solve" this, the real solution is for browsers to stop demanding we target JavaScript, and instead, target a language agnostic platform how we developers best see fit. Frankly, I think we'd be far better off if browsers exposed the friggin .NET CLR as their lingua franca. Could always use Mono or hell, Roslyn now, I guess. That's why I'm hopeful for WebAssembly.

You know, 48 hours ago I had never used Scala or Spark (directly) before, and now I've got a brand new 1.0 code-baby (Scala spark app running on AWS JavaScript, and instead, actually represent a real platform to be targeted EMR via Data Pipeline) transforming a few 100 gigs of internal analytics data dumped into S3 on a daily basis so it can be accessed efficiently with Athena for my tiny internal data analysis prototyping team. So it's certainly not about fear or inability of learning new tools.

It's just that at this point in my life and career, I have a much clearer understanding of the sort of languages, tools and libraries that make my job smoother, easier, and more successful. Things that reduce risk in the shipped products, improve the experience of working with others both new and experienced with the code base, and of course, things I personally like. To me, it's worth being adamant about not wasting my time with garbage, and sadly the entire web environment is built on a trash foundation. One that's bled into the server space, wasting a ton of time and power.

Luckily out of everything you can find jobs for, there are PLENTY of options that fit my criteria. It's not like strongly typed languages with good static analysis potential are rare. On the current TIOBE top 20, I'd take 7 or 8 without too much concern.

And some of the hot areas right now, the parts I'd be involved with, are implemented with good tools. Like Spark that I mentioned, heavily favored in "Data Engineering" tasks, is built with Scala, which is fine. More importantly, the true platform for it and nearly every single one of all the alternative tools in the space, is Hadoop, which is Java, which the place I have the most experience. So I think I'll probably be looking to expand my time in this part of the industry for my next job. Besides, it feels kinda cool to talk casually about how a terabyte of ram might not be enough for your next analysis task.

They had one job: Add type annotations. 99.99% of all issues I have with javascript would be solved with that, but I guess it just wasn't in the stars.

> While there's still time, escape to TypeScript (though it will be flooded by crap from TC39 soon enough), ClojureScript, Kotlin, Scala.js, Elm, Purescript

And dartlang