7 ms·

I understand JS was an experiment and that there was much to add to make it a proper language, but isn't it good enough now? Can we expect the pace of changes t

I understand JS was an experiment and that there was much to add to make it a proper language, but isn't it good enough now? Can we expect the pace of changes to slow down (specially in light of WebAssembly)? I'm not a JS developer and/or language developer, honestly just curious.

chatmasta 9y ago
If it’s not breaking backwards compatibility then what’s the problem with improvements?
- akvadrako 9y ago
  It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.
  - Digit-Al 9y ago
    If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
  - tcd 9y ago
    Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. 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 ;)
    - akvadrako 9y ago
      I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... 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.
    - wwweston 9y ago
      > Software can work from anywhere between a few hours to a decade before an update is required 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.
  - orf 9y ago
    That 4 year old browser is full of security holes though. Why would anyone want to encourage that?
  - jsheard 9y ago
    New syntax can obsolete older browsers, but it doesn't necessarily have to in the age of Babel and Typescript. Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.
    - akvadrako 9y ago
      If you are using babel there is no need for the new browsers to support the new syntax at all.
      - always_good 9y ago
        Sure there are. For example, your bundle size shrinks when targeting newer browsers because more features exist, fewer need to be polyfilled.
        akvadrako 9y ago
        Then you must prepare two bundles, one for new browsers and one for old. I suppose that's possible, but doesn't seem worth it.
        TomMarius 9y ago
        It is worth it most of the time.
        styfle 9y ago
        You can use <script type=module> to target newer browsers. It’s definitely worth having two bundles because the ES6 and newer is much smaller. And one day, you stop shipping the old ES5 bundle.
  - irrational 9y ago
    My view is, if everyone was on an evergreen browser (and didn't do something like turn off the auto updates) then there would be no such thing as a 4-year old (or even 1-year old browser). If I could wave a magic wand I'd have 100% of websites all using cutting edge HTML, CSS, JS features tomorrow so the WWW absolutely breaks for anyone not using an up to date evergreen browser (the lone exceptions being the download pages for Firefox, Chrome, etc.). The sooner businesses, Luddites and grandpas upgrade the better. But that's just my view as a developer who is so sick and tired of supporting browsers that have been out of support for years.
    - Yetanfou 9y ago
      Your view excludes all platforms made before "evergreen browsers" became a thing and will exclude all platforms which the makers of "evergreen browsers" deem too small or unprofitable to support. So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.
- Yaggo 9y ago
  The more there's featues, the harder it will be to create new independent implementations, which is not good for openness/competition. The bar is already too high.
- tzahola 9y ago
  Because these constant "improvements" usually mean two things: 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.
  - castis 9y ago
    The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?
    - tzahola 9y ago
      >The language design is absolutely flawed, hence the push to make that less so. 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.
      - alangpierce 9y ago
        > But a flawed language cannot be made non-flawed while keeping backwards compatibility 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.
TheAceOfHearts 9y ago
No. There's still lots of ongoing work. There's a repo [0] with proposals and the different stages they're in. Why would WASM mean slowing down JS changes? [0] https://github.com/tc39/proposals https://github.com/tc39/proposals
- gtirloni 9y ago
  Because people would start developing in other languages that target WebAssembly and demand less of JS today.
  - yayana 9y ago
    Competing options lowering demands? I think that only makes sense if something has lost market share to the point that it is not in use.
    - chrismorgan 9y ago
      Most people that write JavaScript don’t care about any of these new features. They are developed by those on the cutting edge, for those on the cutting edge. Eventually, some of them become more widely used, occasionally even going mainstream. (We’ve seen a rash of that in the past few years.) If the technology leaders all switched to WebAssembly and no longer cared about JavaScript, JavaScript development would stall, and people that still wrote JavaScript would probably breathe a sigh of relief as their target stopped moving. (It could still regain momentum after such an event.) It seems very improbable to me that this will occur in the next five years.
paol 9y ago
WebAssembly doesn't really have anything to do with Javascript. As for being good enough now: not yet. It's getting closer, another iteration or two and I think it could settle down for a while. Also it's worth noting the rapid pace of change in the JS specs is a recent phenomenon. It was stagnated for years before that.
- ricardobeat 9y ago
  WASM-compiled code might completely replace javascript, being faster at all stages: loading, parsing and execution. That's probably the point he was making.
  - krapp 9y ago
    WASM compiled code doesn't improve upon the use of javascript as a scripting language, only javascript as 'bytecode.' I don't think WASM would replace javascript in those cases, unless you could drop another language into a script tag and have it work as easily for basic DOM manipulation, which people still do.
    - ricardobeat 9y ago
      That’s true, but the vast majority of web sites today are already compiled applications.
      - phpnode 9y ago
        Majority of top 1000 websites perhaps, most websites aren't compiled at all, they just link to jQuery on a CDN somewhere.
        ricardobeat 9y ago
        WordPress powers almost 30% of the others, and could also switch to WASM whenever they feel like it.
      - irrational 9y ago
mattbierner 9y ago
I don’t see JavaScript ever reaching a point where everyone involved agrees that is good enough. There are still too many conflicting opinions of what the language should be. The ecosystem’s constantly evolving libraries and frameworks also drive the language design, and new language needs are always emerging from these
_pdp_ 9y ago
JS is the language of the Web. The web is in constant flux. It is no surprise that the JS language will involve too.
endless1234 9y ago
Why stop adding new useful features? What actively used high level language has done that?
- gtirloni 9y ago
  >> Can we expect the pace of changes to slow down? > Why stop adding new useful features? No actively used languages that I know of have stopped adding features.
  - endless1234 9y ago
    Compared to ES5->ES6, I think these yearly bite-sized updates have indeed made it slow down and be much more manageable
- tzahola 9y ago
  LISP
  - ZenoArrow 9y ago
    Lisp is a family of languages, there hasn't been a single Lisp language since the 1960s. The different dialects of Lisp add new features.
    - kazinator 9y ago
      However, the major ANSI dialect hasn't changed since 1994, so OP has a fair point.
      - ZenoArrow 9y ago
        Common Lisp is a standard, but the various implementations of that standard have added non-standard features. For example, I believe Unicode support was added to SBCL around 2004.
partoa 9y ago
My two cents, JS has come a long way and should qualify as a "proper language" if it wasn't one before. Is it good enough? Is any language ever good enough? 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.
rpedela 9y ago
JS still lacks support for 64-bit integers and BigDecimal support would be extremely nice. Otherwise I think the language is good enough.
- johnsonjo 9y ago
  Just in case anyone is not aware there is a stage 3 proposal [1] for 64 bit integers right now called BigInt [2]. [1]: https://github.com/tc39/proposals https://github.com/tc39/proposals [2]: https://github.com/tc39/proposal-bigint https://github.com/tc39/proposal-bigint
ryanmarsh 9y ago
I don't like the idea of considering a language "good enough" and here's why. 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).
- gtirloni 9y ago
  That makes a lot of sense, thanks for your thoughtful comment.

chatmasta 9y ago

If it’s not breaking backwards compatibility then what’s the problem with improvements?

akvadrako 9y ago
It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.
- Digit-Al 9y ago
  If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
- tcd 9y ago
  Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. 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 ;)
  - akvadrako 9y ago
    I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... 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.
  - wwweston 9y ago
    > Software can work from anywhere between a few hours to a decade before an update is required 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.
- orf 9y ago
  That 4 year old browser is full of security holes though. Why would anyone want to encourage that?
- jsheard 9y ago
  New syntax can obsolete older browsers, but it doesn't necessarily have to in the age of Babel and Typescript. Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.
  - akvadrako 9y ago
    If you are using babel there is no need for the new browsers to support the new syntax at all.
    - always_good 9y ago
      Sure there are. For example, your bundle size shrinks when targeting newer browsers because more features exist, fewer need to be polyfilled.
      - akvadrako 9y ago
        Then you must prepare two bundles, one for new browsers and one for old. I suppose that's possible, but doesn't seem worth it.
        TomMarius 9y ago
        It is worth it most of the time.
        styfle 9y ago
        You can use <script type=module> to target newer browsers. It’s definitely worth having two bundles because the ES6 and newer is much smaller. And one day, you stop shipping the old ES5 bundle.
- irrational 9y ago
  My view is, if everyone was on an evergreen browser (and didn't do something like turn off the auto updates) then there would be no such thing as a 4-year old (or even 1-year old browser). If I could wave a magic wand I'd have 100% of websites all using cutting edge HTML, CSS, JS features tomorrow so the WWW absolutely breaks for anyone not using an up to date evergreen browser (the lone exceptions being the download pages for Firefox, Chrome, etc.). The sooner businesses, Luddites and grandpas upgrade the better. But that's just my view as a developer who is so sick and tired of supporting browsers that have been out of support for years.
  - Yetanfou 9y ago
    Your view excludes all platforms made before "evergreen browsers" became a thing and will exclude all platforms which the makers of "evergreen browsers" deem too small or unprofitable to support. So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.
Yaggo 9y ago
The more there's featues, the harder it will be to create new independent implementations, which is not good for openness/competition. The bar is already too high.
tzahola 9y ago
Because these constant "improvements" usually mean two things: 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.
- castis 9y ago
  The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?
  - tzahola 9y ago
    >The language design is absolutely flawed, hence the push to make that less so. 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.
    - alangpierce 9y ago
      > But a flawed language cannot be made non-flawed while keeping backwards compatibility 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.

TheAceOfHearts 9y ago

No. There's still lots of ongoing work. There's a repo [0] with proposals and the different stages they're in. Why would WASM mean slowing down JS changes? [0] https://github.com/tc39/proposals https://github.com/tc39/proposals

gtirloni 9y ago
Because people would start developing in other languages that target WebAssembly and demand less of JS today.
- yayana 9y ago
  Competing options lowering demands? I think that only makes sense if something has lost market share to the point that it is not in use.
  - chrismorgan 9y ago
    Most people that write JavaScript don’t care about any of these new features. They are developed by those on the cutting edge, for those on the cutting edge. Eventually, some of them become more widely used, occasionally even going mainstream. (We’ve seen a rash of that in the past few years.) If the technology leaders all switched to WebAssembly and no longer cared about JavaScript, JavaScript development would stall, and people that still wrote JavaScript would probably breathe a sigh of relief as their target stopped moving. (It could still regain momentum after such an event.) It seems very improbable to me that this will occur in the next five years.

paol 9y ago

WebAssembly doesn't really have anything to do with Javascript. As for being good enough now: not yet. It's getting closer, another iteration or two and I think it could settle down for a while. Also it's worth noting the rapid pace of change in the JS specs is a recent phenomenon. It was stagnated for years before that.

ricardobeat 9y ago
WASM-compiled code might completely replace javascript, being faster at all stages: loading, parsing and execution. That's probably the point he was making.
- krapp 9y ago
  WASM compiled code doesn't improve upon the use of javascript as a scripting language, only javascript as 'bytecode.' I don't think WASM would replace javascript in those cases, unless you could drop another language into a script tag and have it work as easily for basic DOM manipulation, which people still do.
  - ricardobeat 9y ago
    That’s true, but the vast majority of web sites today are already compiled applications.
    - phpnode 9y ago
      Majority of top 1000 websites perhaps, most websites aren't compiled at all, they just link to jQuery on a CDN somewhere.
      - ricardobeat 9y ago
        WordPress powers almost 30% of the others, and could also switch to WASM whenever they feel like it.
    - irrational 9y ago

mattbierner 9y ago

I don’t see JavaScript ever reaching a point where everyone involved agrees that is good enough. There are still too many conflicting opinions of what the language should be. The ecosystem’s constantly evolving libraries and frameworks also drive the language design, and new language needs are always emerging from these

_pdp_ 9y ago

JS is the language of the Web. The web is in constant flux. It is no surprise that the JS language will involve too.

endless1234 9y ago

Why stop adding new useful features? What actively used high level language has done that?

gtirloni 9y ago
>> Can we expect the pace of changes to slow down? > Why stop adding new useful features? No actively used languages that I know of have stopped adding features.
- endless1234 9y ago
  Compared to ES5->ES6, I think these yearly bite-sized updates have indeed made it slow down and be much more manageable
tzahola 9y ago
LISP
- ZenoArrow 9y ago
  Lisp is a family of languages, there hasn't been a single Lisp language since the 1960s. The different dialects of Lisp add new features.
  - kazinator 9y ago
    However, the major ANSI dialect hasn't changed since 1994, so OP has a fair point.
    - ZenoArrow 9y ago
      Common Lisp is a standard, but the various implementations of that standard have added non-standard features. For example, I believe Unicode support was added to SBCL around 2004.

partoa 9y ago

My two cents, JS has come a long way and should qualify as a "proper language" if it wasn't one before. Is it good enough? Is any language ever good enough? 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.

rpedela 9y ago

JS still lacks support for 64-bit integers and BigDecimal support would be extremely nice. Otherwise I think the language is good enough.

johnsonjo 9y ago
Just in case anyone is not aware there is a stage 3 proposal [1] for 64 bit integers right now called BigInt [2]. [1]: https://github.com/tc39/proposals https://github.com/tc39/proposals [2]: https://github.com/tc39/proposal-bigint https://github.com/tc39/proposal-bigint

ryanmarsh 9y ago

I don't like the idea of considering a language "good enough" and here's why. 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).

gtirloni 9y ago
That makes a lot of sense, thanks for your thoughtful comment.