The majority of news, social media, video, media sites, message boards, online games and web apps fit this description. I'd wager that 95%+ of websites produced by a paid professional today are in this category. Unfortunately no, I don't have data to back this up, only my perception as a web developer.
[1] due to relying on a module system, es6 transpiler, etc
I also don't consider a website serving machine-generated javascript to be a "compiled application" analagous to a C, Flash or Java binary (whereas WASM would be,) but almost every time I try to go down the "javascript is not machine code or bytecode" rabbithole, I get downvoted to oblivion.
First off I must be careful and acknowledge that a language which changes at a pace faster than the body of programmers using it can safely absorb could be considered an anti-pattern. As it stands I'm not sure if JS fits this.
Look at how Java has changed over the years. Back when it was created the syntax was appreciated by many as resembling C++ enough and being OO enough to be "good". Obviously there were many nits to pick by purists but programmers adopted the language and many people touted it. Java did not become popular because non-technical people were pushing it. Programmers liked it well enough.
I was a religious zealot when it came to OO. Now I find myself loathing large OO systems and trying to write procedural functional code as often as possible and only using classes when necessary. The Java language has evolved to add lambdas, streams, etc.. Should Java have added lambdas or should it have stayed the way it was, "good enough"? Even if one is a programming paradigm zealot of any persuasion one must acknowledge that a great deal of production code was written just fine using only the early Java language features. Should we have stopped there?
If code should be written first and foremost for programmers to understand and only incidentally for compilers to then it should stand to reason: as our collective understanding of how to express the behavior of a computer program evolves, so should the language(s).
Why would WASM mean slowing down JS changes?
It seems very improbable to me that this will occur in the next five years.
As for the pace of changes, it's hard to tell. All the same, if TIOBE is to be believed, JS is getting more popular, not less.
Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level.
If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)
But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades.
And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.
All other things being equal, a decade is preferable because time/attention is valuable. Frequent and in particularly non-careful updates can put individuals and in the grip of a form of the red queen problem rather than being able to spend time/attention on new levels of capability.
I don't particularly mind some obsolescing of browsers where JS is concerned, and browsers in general have done a remarkable job of retaining backward compatibility.
More problematic, though, is the attitude that's more or less every website should be a JS-powered (or, in the future, web-assembly) SPA without any kind of back-end fallback for user agents that don't support it, thus making JS capability the bar for any UA. That's short-sighted, doesn't consider user conditions outside of a narrow range of experience, doesn't consider that there might be user agents other than browsers as commonly understood. If that's all you have the resources to do and how you choose to spend them, that can still be reasonable engineering (though my experience is the benefits of figuring out how to make it work w/o JS first -- if it's possible -- often pays engineering dividends), but I think it's weird it's the default now.
> Try downloading Firefox 1-10 and see if they work today ;)
Firefox 1-10 would be broken because they're embedded in a set of assumptions about specific non-web platforms, not because many (if not most) websites couldn't reasonably support them as clients. I don't see any reason to import the shortcomings of non-web platforms into the web.
Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.
So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.
1. The language design is flawed. That is, the desired functionality requires changes to the core language, because it can't be made from existing building blocks. The fundamental language constructs are not universal enough, so new functionality will always require "just one more" special case in the language itself.
or
2. People are shoving things into the core language, that should rather be implemented as a library/framework.
What things going into core do you think should be a separate framework?
But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics.
>What things going into core do you think should be a separate framework?
An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.
Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint).
Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.
That is surprising to me. I work with code that is more than a couple years old all the time and I would guess most people do to.
Just 2? More like 9:
* function expression
* function declaration
* arrow function (single line, single param)
* arrow function (single line, multiparam)
* arrow function (multiline, single param)
* arrow function (multiline, multiparam)
* object shorthand
* class declaration
* class expression
async/await could be implemented with just generators, and were so implemented in ES6; async/await was added to the language because it was convenient. A language without full coroutines is fine.
Keep adding rules and break the compatibility of strict code, or forget about it and live with current problems forever?
I think JavaScript’s core foundation is changing because its use cases have rapidly changed. Like C++ or PHP though, it likely has a lot of legacy cruft.
Are any Ruby experts able to chime in if its language/runtime changed much after Rails hit the scene?
> Why stop adding new useful features?
No actively used languages that I know of have stopped adding features.