4 ms·

Yep, and that's why JS is moving and everyone else is biting the dust lol. Progress needs to be made and those who can't follow don't have the right to complai

Yep, and that's why JS is moving and everyone else is biting the dust lol. Progress needs to be made and those who can't follow don't have the right to complain really. Old tools are always available because language compatibility is preserved (which, imo should also be dropped, we would have much better language as a result). We also stick to LTS (in my case node LTS)

no_wizard 8y ago
Not to pick a fight but even with all the recent improvements I am of the opinion that it has a long way to go. There’s no explicit Abstract Base Classes, there are base objects you can’t transparently inherit from (Thinkging of promises here in particular. Why can’t I transparently override built in promises for customization? I know you can inherit from it but you can’t modify a parents constructor) and it lacks lazy class invocation (looking at you `new` keyword) Honestly I wish the ECMAScript board would have just went he other way and doubled down in making JS a function language instead of trying to push more OOP approaches would have been a lot better. It’s always been a little wonky as a Prototype based OO language anyway.
- gear54rus 8y ago
  That's a bit dangerous. There's good in both functional approach and type systems but I'd rather see them where they are - in TypeScript and lodash and have vanilla be as vanilla as possible. Time will tell, there's already been a case where things from framework were pulled into ES (coffeescript).
  - no_wizard 8y ago
    I’m curious what you mean by dangerous? I’m having trouble discerning what you mean. If you mean going into a functional paradigm I’d say it’s definitely a matter if taste. However my biggest gripe is that the ECMAScript board seems intent on being all things to all people. So they half implemented classes. And they added some neat data types. But god for bid you want to override their constructors yet if I make a class I can override my constructors as one would expect in a class based language. Though forcing the new keyword onto classes wasn’t a great paradigm to keep imo. Nor do I like how static methods and properties are treated. Also decorators are only for classes? Why does that make any sense? It’s really screwy. At least going the opposite direction would’ve forced correctness on a baseline. If they want to be an OOP langsuge with classes the Standards need to embrace it more fully and I see little evidence of that
    - Fellshard 8y ago
      ECMAScript has no strong opinion on what paradigm it wants to be in. Originally, it could have looked like a more Algol-y Self. But so many kludges and 'pragmatic' additions were made early on to make working with the DOM 'easier' that the object-orientation aspect never really took shape in any of the core APIs. The reason that's critically concerning for the language and its ecosystem is that since 'vanilla JS' has no opinion, all the libraries created for it tend to have to form their own opinion. This then means that when binding to many ES libraries, you're torn between a hundred flavors of functional, half-baked OO, procedural, or just bit buckets of inconsistency. If the language can't make up its mind, you're guaranteed to see fragmentation by its users.
    - shados 8y ago
      > Also decorators are only for classes? Why does that make any sense? The generally thought is that you technically only need them for classes (and really, only for class members and properties). For anything else you can just use a higher order function. Not as pretty, but JS decorator arent about syntax sugar, they're about filling one of the bazillion gaps in the language that opens when you introduce a class keyword. Of course, the spec for decorator has been thrown away and started over once already (so basically no one using typescript/angular/mobx/whatever with decorators are actually spec compliant these days), and the new spec has been in limbo for years. Decorators aren't part of JS at all right now.
sjellis 8y ago
> language compatibility is preserved I think that Go and ECMAScript has shown that language compatibility is critical. The language changes that really improve quality of life change the way that you write code in that language, which mean you have to rewrite your existing code to opt-in to them. Small languages changes may not actually be worth the cost of adoption.
matheusmoreira 8y ago
> which, imo should also be dropped, we would have much better language as a result This just creates two different languages. The older language only dies when everyone stops using it. The Ruby community managed to do that with 1.9 but Python 2 still exists alongside Python 3.
jcden 8y ago
JavaScript is slow as hell

no_wizard 8y ago

Not to pick a fight but even with all the recent improvements I am of the opinion that it has a long way to go. There’s no explicit Abstract Base Classes, there are base objects you can’t transparently inherit from (Thinkging of promises here in particular. Why can’t I transparently override built in promises for customization? I know you can inherit from it but you can’t modify a parents constructor) and it lacks lazy class invocation (looking at you `new` keyword) Honestly I wish the ECMAScript board would have just went he other way and doubled down in making JS a function language instead of trying to push more OOP approaches would have been a lot better. It’s always been a little wonky as a Prototype based OO language anyway.

gear54rus 8y ago
That's a bit dangerous. There's good in both functional approach and type systems but I'd rather see them where they are - in TypeScript and lodash and have vanilla be as vanilla as possible. Time will tell, there's already been a case where things from framework were pulled into ES (coffeescript).
- no_wizard 8y ago
  I’m curious what you mean by dangerous? I’m having trouble discerning what you mean. If you mean going into a functional paradigm I’d say it’s definitely a matter if taste. However my biggest gripe is that the ECMAScript board seems intent on being all things to all people. So they half implemented classes. And they added some neat data types. But god for bid you want to override their constructors yet if I make a class I can override my constructors as one would expect in a class based language. Though forcing the new keyword onto classes wasn’t a great paradigm to keep imo. Nor do I like how static methods and properties are treated. Also decorators are only for classes? Why does that make any sense? It’s really screwy. At least going the opposite direction would’ve forced correctness on a baseline. If they want to be an OOP langsuge with classes the Standards need to embrace it more fully and I see little evidence of that
  - Fellshard 8y ago
    ECMAScript has no strong opinion on what paradigm it wants to be in. Originally, it could have looked like a more Algol-y Self. But so many kludges and 'pragmatic' additions were made early on to make working with the DOM 'easier' that the object-orientation aspect never really took shape in any of the core APIs. The reason that's critically concerning for the language and its ecosystem is that since 'vanilla JS' has no opinion, all the libraries created for it tend to have to form their own opinion. This then means that when binding to many ES libraries, you're torn between a hundred flavors of functional, half-baked OO, procedural, or just bit buckets of inconsistency. If the language can't make up its mind, you're guaranteed to see fragmentation by its users.
  - shados 8y ago
    > Also decorators are only for classes? Why does that make any sense? The generally thought is that you technically only need them for classes (and really, only for class members and properties). For anything else you can just use a higher order function. Not as pretty, but JS decorator arent about syntax sugar, they're about filling one of the bazillion gaps in the language that opens when you introduce a class keyword. Of course, the spec for decorator has been thrown away and started over once already (so basically no one using typescript/angular/mobx/whatever with decorators are actually spec compliant these days), and the new spec has been in limbo for years. Decorators aren't part of JS at all right now.

sjellis 8y ago

> language compatibility is preserved I think that Go and ECMAScript has shown that language compatibility is critical. The language changes that really improve quality of life change the way that you write code in that language, which mean you have to rewrite your existing code to opt-in to them. Small languages changes may not actually be worth the cost of adoption.

matheusmoreira 8y ago

> which, imo should also be dropped, we would have much better language as a result This just creates two different languages. The older language only dies when everyone stops using it. The Ruby community managed to do that with 1.9 but Python 2 still exists alongside Python 3.

jcden 8y ago

JavaScript is slow as hell