4 ms·

There is a lengthy debate surrounding private field syntax [1][2]. As a TypeScript user, I prefer regular-JS drop this proposal altogether, rather than use the

There is a lengthy debate surrounding private field syntax [1][2]. As a TypeScript user, I prefer regular-JS drop this proposal altogether, rather than use the current syntax. Refactoring and index-access notation become awkward with it. Anecdotally, the vast majority of serious developers I know transpile to JS. [1]: https://github.com/tc39/proposal-class-fields/issues/177 [2]: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md

aasasd 8y ago
I'm pretty sure transpilation is supposed to gradually adopt something more modern than es5.
- wakeywakeywakey 8y ago
  I agree overall, but some language/env enhancements (e.g. BigInt) transpile more naturally than syntax-dependent ones like #private.
jkrems 8y ago
The discussion seems to be mostly driven by people who are used to a very specific syntax and can't understand why it wouldn't work for a real implementation for private. Nothing will stop these people from keeping their use of "private as documentation only" while others will get their proper implementation of private state that isn't as fragile as the one offered by TypeScript. That last part isn't a dig at TypeScript - it's just that at the time it was the best TS could possibly offer. I expect that TypeScript will adopt this proposal given that some of the people working on and defending the proposal seem to be part of the TypeScript team. > Refactoring and index-access notation become awkward with it. Given that other languages have similar solutions and this actually has more information in the source file, I assume that refactoring will become quicker and index-access will just move to private maps. Adding arbitrary fields at runtime and dynamic access to private fields are both tools with limited value compared to the potential for introducing subtle bugs.
TACIXAT 8y ago
>Anecdotally, the vast majority of serious developers I know transpile to JS. TIL I'm not a serious developer. I actually think compiling Javascript is a huge barrier to entry to would be devs. I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt.
- btown 8y ago
  It truly, truly depends on the conceptual size of the application you're writing. Small components with simple interactions? Use something like Vue without compilation, and you'll have a low barrier to entry. But if you're writing complex business logic, trying to build pipelines of client-side data whose derivations are fed into a myriad of components, and you'll want things like type constraints, module hierarchies, compiler support for things like JSX to simplify the cognitive load of understanding what a thing-that-outputs-HTML-like-stuff does. At the end of the day, compiler setup is O(1), and code complexity is at least Ω(N) in how difficult it becomes to understand a codebase. It's worth doing anything you can with the compiler to reduce complexity in large codebases.
- gwillz 8y ago
  Vast majority != you. Unless you're obscenely overweight or some sort of hive mind, I can't imagine OP was suggesting that you're not a serious developer. I also think you right. Compilers don't always go well with programming inductees. This is why Python and Ruby are so popular as introductory courses. But this is why I think Javascript has done so well because it doesn't _need_ compiling, which is great for new-comers. When things level up and get complicated, enter JS compilers. It's a 'best of both worlds' sort of thing.
- aphextron 8y ago
  >I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt. The problem is that this breaks down immediately for a million different reasons at any kind of scale with multiple developers, complex dependency graphs, and the need for automated testing. The tooling exists to solve real problems whether you've experienced them or not.
aphextron 8y ago
I have to agree with this. The syntactic sugar that has been slowly amassing around JS has been mostly useless in the face of things like TypeScript and Babel reaching ubiquitous usage. It's better off just left to a transpilation target at this point, as everything will be WASM based once that's ready anyways.
- paulddraper 8y ago
  Serious question: Why would you use WASM for a dynamically typed, GC'ed language?
  - aphextron 8y ago
    >Serious question: Why would you use WASM for a dynamically typed, GC'ed language? The point is using it as universal bytecode for deploying anything you want. Ideally we could do front end web development with any language/framework combo and just compile to WASM. It seems like that's the future, with things like Blazor getting major support, and that JS will probably mostly die out over the next 5 years. https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor
    - bfrydl 8y ago
      WASM always seems like the future until you find out how big the binary is relative to even a meaty JS app when it includes all the code needed to support things like GC or dynamic typing.

aasasd 8y ago

I'm pretty sure transpilation is supposed to gradually adopt something more modern than es5.

wakeywakeywakey 8y ago
I agree overall, but some language/env enhancements (e.g. BigInt) transpile more naturally than syntax-dependent ones like #private.

jkrems 8y ago

The discussion seems to be mostly driven by people who are used to a very specific syntax and can't understand why it wouldn't work for a real implementation for private. Nothing will stop these people from keeping their use of "private as documentation only" while others will get their proper implementation of private state that isn't as fragile as the one offered by TypeScript. That last part isn't a dig at TypeScript - it's just that at the time it was the best TS could possibly offer. I expect that TypeScript will adopt this proposal given that some of the people working on and defending the proposal seem to be part of the TypeScript team. > Refactoring and index-access notation become awkward with it. Given that other languages have similar solutions and this actually has more information in the source file, I assume that refactoring will become quicker and index-access will just move to private maps. Adding arbitrary fields at runtime and dynamic access to private fields are both tools with limited value compared to the potential for introducing subtle bugs.

TACIXAT 8y ago

>Anecdotally, the vast majority of serious developers I know transpile to JS. TIL I'm not a serious developer. I actually think compiling Javascript is a huge barrier to entry to would be devs. I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt.

btown 8y ago
It truly, truly depends on the conceptual size of the application you're writing. Small components with simple interactions? Use something like Vue without compilation, and you'll have a low barrier to entry. But if you're writing complex business logic, trying to build pipelines of client-side data whose derivations are fed into a myriad of components, and you'll want things like type constraints, module hierarchies, compiler support for things like JSX to simplify the cognitive load of understanding what a thing-that-outputs-HTML-like-stuff does. At the end of the day, compiler setup is O(1), and code complexity is at least Ω(N) in how difficult it becomes to understand a codebase. It's worth doing anything you can with the compiler to reduce complexity in large codebases.
gwillz 8y ago
Vast majority != you. Unless you're obscenely overweight or some sort of hive mind, I can't imagine OP was suggesting that you're not a serious developer. I also think you right. Compilers don't always go well with programming inductees. This is why Python and Ruby are so popular as introductory courses. But this is why I think Javascript has done so well because it doesn't _need_ compiling, which is great for new-comers. When things level up and get complicated, enter JS compilers. It's a 'best of both worlds' sort of thing.
aphextron 8y ago
>I think a development experience of put the code on the page and it runs is a lot better than configuring npm/gulp/grunt. The problem is that this breaks down immediately for a million different reasons at any kind of scale with multiple developers, complex dependency graphs, and the need for automated testing. The tooling exists to solve real problems whether you've experienced them or not.

aphextron 8y ago

I have to agree with this. The syntactic sugar that has been slowly amassing around JS has been mostly useless in the face of things like TypeScript and Babel reaching ubiquitous usage. It's better off just left to a transpilation target at this point, as everything will be WASM based once that's ready anyways.

paulddraper 8y ago
Serious question: Why would you use WASM for a dynamically typed, GC'ed language?
- aphextron 8y ago
  >Serious question: Why would you use WASM for a dynamically typed, GC'ed language? The point is using it as universal bytecode for deploying anything you want. Ideally we could do front end web development with any language/framework combo and just compile to WASM. It seems like that's the future, with things like Blazor getting major support, and that JS will probably mostly die out over the next 5 years. https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor
  - bfrydl 8y ago
    WASM always seems like the future until you find out how big the binary is relative to even a meaty JS app when it includes all the code needed to support things like GC or dynamic typing.