[HN Gopher] TC39 Proposal: Type Annotations
___________________________________________________________________
TC39 Proposal: Type Annotations
Author : rglover
Score : 92 points
Date : 2022-06-08 19:29 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| E2EEd wrote:
| This article is on the hn front page but disappears for this
| account "E2EEd".
| pvg wrote:
| You might have hit 'hide' on it, take a look at
|
| https://news.ycombinator.com/hidden
|
| when logged in
| E2EEd wrote:
| Yes, that is it, thanks.
| [deleted]
| padjo wrote:
| Immediate reaction is that this is a bad idea. Seems like it
| would result in a weird Frankenstein language that is neither
| fish nor fowl. The lack of prior art for this type of approach is
| particularly concerning.
| cphoover wrote:
| Nahhhh lets get the immutable data structures (record + tuples)
| proposal to land, this one is of much more value IMO
|
| https://github.com/tc39/proposal-record-tuple
| [deleted]
| andreineculau wrote:
| This 100!
| Matheus28 wrote:
| Sounds like a bad idea. I get it that not specifying type syntax
| makes it the most flexible, but also prevents any actual checks
| and optimizations from being performed by the browser. So it's
| just inflating bundle sizes for no reason. Might as well run them
| through something that checks then removes type annotations...
| which is what we already have
| hardwaregeek wrote:
| By that same logic, comments are inflating the bundle size.
| Both can be stripped out using a minifier or bundler.
| cookiengineer wrote:
| I don't understand what effect it would have on bundle sizes?
|
| If you are going to transpile/bundle your assets, you're
| probably using webasm at some point...or not!?
|
| And nobody forces you to have typed minified JS in your
| bundles?
| lagrange77 wrote:
| > So it's just inflating bundle sizes for no reason.
|
| When using a bundler, it will be trivial to remove the
| annotations in the build process.
|
| Using a TypeScript transpiler in that process is also trivial
| you might say. But static typing syntax and tooling as part of
| the language itself is the way to go imo.
| Matheus28 wrote:
| >But static typing syntax and tooling as part of the language
| itself is the way to go imo.
|
| But if the typing syntax is essentially just comments in very
| specific places... what advantage does it bring? Sure one can
| use tools to interpret those comments and check types... but
| at that point, isn't just using typescript tooling much
| superior (interface declaration, type declarations, etc. not
| just a type between : and =)?
|
| I will confess that I am guilty of having used JSDoc comments
| for quick and dirty .js scripts that I didn't want to grab
| the tsc compiler for, but still wanted vscode to check my
| types. But even being one of the likely users of this
| proposal, I feel that it's needlessly bloating the language.
| rektide wrote:
| > _But if the typing syntax is essentially just comments in
| very specific places... what advantage does it bring?_
|
| It means the supplemental information needed to run either
| static or dynamic type-checking is there & so that either
| browsers or toolchains can use it.
|
| And it means that the code would just run on existing
| systems. For production we'd probably want to strip out
| comments, but for production we already often do strip out
| comments (which I wish could be "undone" on most sites by
| users wanting to know! View source!!).
|
| Let's turn your question around: what advantage does
| existing typescript language have, over a backwards-
| compatible & type-carrying enhancement to JS?
| Matheus28 wrote:
| >It means the supplemental information needed to run
| either static or dynamic type-checking is there & so that
| either browsers or toolchains can use it.
|
| The format isn't specified, it's just a comment. Browsers
| can't take advantage of it. Toolchains already do cross-
| compiling when they're bundling anyway, so it's not
| required on that front.
|
| >what advantage does existing typescript language have,
| over a backwards-compatible & type-carrying enhancement
| to JS?
|
| Typescript is on a much faster release schedule than the
| standards. Just think of how slowly its (amazing) type
| system would've evolved if designed by committee.
|
| I'd be all for a type system in javascript a couple of
| years ago. But seeing how fast typescript evolved when
| it's not limited by a committee, I think that keeping
| that separate of the main language is completely
| acceptable.
| rektide wrote:
| > _The format isn 't specified, it's just a comment_
|
| The authors intend to support a variety of type systems,
| such as TypeScript & Flow. That TypeScript would need to
| define it's own grammar doesn't seem harmful, & would
| surely be standardized quickly, exterior to this more
| general spec.
|
| Latter you say: _" Typescript is on a much faster release
| schedule than the standards."_ Well, since the format
| isn't specified, TypeScript is free to release at their
| leisure. Not bundling orthogonal concerns together,
| providing low-level extensible capabilities is a win.
|
| > _Browsers can 't take advantage of it._
|
| Why not? They could.
|
| > _Toolchains already do cross-compiling when they 're
| bundling anyway, so it's not required on that front._
|
| Ok, but you're ignoring the goal of this proposal: _" The
| aim of this proposal is to enable developers to run
| programs written in TypeScript, Flow, and other static
| typing supersets of JavaScript without any need for
| transpilation"_
| lagrange77 wrote:
| > what advantage does it bring?
|
| The advantage would be, that static typing is part of the
| language. Don't you find it odd to use another language
| just for a missing _language feature_? For me it feels
| somewhat hacky and '// temp. solution!!! fix
| soon!'-worthy.
| Matheus28 wrote:
| But with this proposal, static typing wouldn't be part of
| the language. It's just a fancy looking comment. No
| different than using JSDoc with a nicer syntax
| lagrange77 wrote:
| Ok agreed, i would also like to have the type checker
| build into the language as well. But in the end, this is
| a scripting language. Maybe it's not too bad to not
| enforce it being typed, but provide a baseline to have it
| being typed optionally, in form of an 'official'
| annotation syntax.
|
| But i'm thinking out loud now.
| yakshaving_jgt wrote:
| > Don't you find it odd to use another language just for
| a missing language feature?
|
| No. Why do you?
|
| For a language to _not_ try and have all the features it
| possibly can _is_ a feature.
| lagrange77 wrote:
| > No. Why do you?
|
| I mean, i like TypeScript a lot. I think i do find it
| odd, because i'm used to using languages, that are
| constructed with a certain feature set. Obviously
| Java/ECMA Script evolved a lot more chaotic than most
| other languages.
|
| Transpiling a superset of a language to its subset
| introduces indirection, which makes it feel hacky imo.
|
| I feel like, if there is another language feature we want
| to add in the future, how should that be injected? In
| form of a superset of TypeScript?
|
| I would be cool with TypeScript as the target language,
| though.
| asddubs wrote:
| it should also be enforced by the language. and then you can
| still check and remove it using a transpiler, if you want
| (for smaller sizes + speedup due to lack of type checks). but
| if you're gonna add type annotations, they should _do
| something_
| lagrange77 wrote:
| > it should also be enforced by the language.
|
| yes maybe with a 'use typestrict' directive or something.
| jupp0r wrote:
| It would be great to be able to have access to types at runtime
| in order to change behavior based on types. That would make
| TypeScript so much more useful but it does require javascript
| support.
| Matheus28 wrote:
| You should try decorators for that. They're pretty decent
| jupp0r wrote:
| Yeah it's a workaround, but not really ergonomical for the
| library author (for example they can't modify the type
| being decorated).
| mixedCase wrote:
| You can use a runtime type system like io-ts or something
| like reflect-metadata. Let's not pay the cost when we don't
| need it.
| jupp0r wrote:
| The compiler knows when this is used and can only insert
| type metadata when needed. io-ts and reflect-metadata are
| unwieldy crutches compared to a type system that's designed
| to influence runtime behavior (ie Rust, C++, etc).
| olliej wrote:
| Oh, we're finally talking about reinstating the syntax that gave
| us `for(of)`
| spion wrote:
| I'm not sure this will help solve any of our problems.
|
| Theoretically, there would be no more need for compilation tools
| after this change is implemented.
|
| In practice, lambdas need to be bundled, frontends still need to
| be bundled and running typescript in node efficiently nowadays
| should be as easy as `node -r @swc-node/register path/to/file.ts`
|
| So this will actually not ease the JavaScript tooling nightmare.
| laurencerowe wrote:
| Not requiring bundling to be setup during development is a huge
| win for developer ergonomics. Though I prefer to write
| TypeScript I've avoided it in some small projects where I
| didn't want the hassle of setting up the transpiler / watcher /
| etc.
|
| Production bundling can then be as simple as running `deno
| bundle index.js` or similar.
| brundolf wrote:
| Transpiling and bundling are two separate things. Removing the
| need for one of those would have benefits even if the other
| were still there
|
| That said, I'm not convinced this would actually remove one of
| them:
|
| - It would mean shipping more code which is a no-no
|
| - It probably won't ever cover the whole of typescript's
| features, so many people will continue to use that, and will
| still have to transpile
|
| I'm sure this will help... somebody, but it's going to be a
| very narrow set of workflows that benefit
| klodolph wrote:
| This makes both irrelevant, since you can already run code
| without bundling.
|
| Obviously it's not something you'd do in a normal production
| environment. It's nice to be able to run code without any
| compilation steps if you're working on something small (e.g.
| some demo on my personal website) or something in a
| development environment.
|
| I've done this. Served up JS with "import" statements
| everywhere. The devserver just served JS straight from the
| filesystem without modification. When I change the JS, the
| browser just needs to reload--there's no build process, no
| waiting. The production environment ran it all through
| Closure. Closure also ran in the dev environment, but it ran
| asynchronously, in the background, telling you what the
| errors are.
|
| No source maps to deal with. No delays. The browser gets
| exactly what I write.
| brundolf wrote:
| Sure, it's just that very few companies are probably going
| to be doing this outside of very early prototypes/toy
| examples. Load time is just too important
| rektide wrote:
| Trying to ease development burdens & generate more
| intercompatible ways of doing things, with less lift required to
| get going, while retaining the same benefits of types for those
| who want them, is 100% a superb & worthy idea.
|
| It's great to see such developer-friendly compatibility &
| adaptability.
|
| Top level comments so far (I have skipped two top level
| comments):
|
| _" I don't want this." "I'm not sure this will help solve any of
| our problems." "Sounds like a bad idea" "Nahhhh lets get the
| [non-type related foobar] proposal to land" "This is a wrong
| assumption." "Just merge with Typescript already" "there will be
| a flame war"_
|
| Mercy! Be happy!
| codeflo wrote:
| I'm fully with you. This greatly simplifies tooling by making
| transpilers entirely optional, meaning you don't need a
| complicated setup just to get going. Developers get
| convenience, users aren't affected, that's a win all around.
|
| People may not fully realize this, but the problem with the
| "just standardize TypeScript" suggestions is that TypeScript is
| a fast moving target. This is actually well argued in the
| proposal: lots of meaningful innovation is still happening in
| that space with more precise checks, which also means that
| small incompatibilities happen from version to version. That's
| okay if we're talking about dev tooling that a team can choose
| to upgrade at their own pace. It would be really bad to have
| browser upgrades affect the functionality of existing websites.
| asddubs wrote:
| browsers are very conservative about breaking changes.
| javascript features that allow for loose and questionable usage
| is the thing that got us into this mess in the first place.
| once this is out there, there will be code using it in the most
| incorrect way it can get away with, and no one will want to
| break that code later on.
|
| that's why it's not just important that we get "something", but
| we get it right.
| rektide wrote:
| > _javascript features that allow for loose and questionable
| usage is the thing that got us into this mess in the first
| place._
|
| And what "mess" is this? Again I think my previous advice is
| pretty on point: "Be happy!" Everything has only gotten
| better, from my perspective. That TypeScript exists & has
| grown up is yet more proof that incremental, ongoing,
| progressive advancement is amazing. I think if we'd tried to
| make everything all at once, it would have been a disaster.
|
| > _once this is out there, there will be code using it in the
| most incorrect way it can get away with, and no one will want
| to break that code later on._
|
| This is a spec to let various typechecks be applied, but
| doesn't specify any specific type-system. I have a hard time
| visualizing whatever scary situation it is you are imagining.
| This seems low risk.
| yakshaving_jgt wrote:
| > Everything has only gotten better, from my perspective.
|
| Would you accept the idea that the language has actually
| gotten worse? What would it take to convince you?
| rektide wrote:
| > _What would it take to convince you?_
|
| arguments.
|
| i've been doing this for over two decades, & the ability
| to sling async functions, w3c streams, abortcontrollers,
| modules, optional chaining,... everything is so kick ass
| better. my resistance to being convinced is going to be
| high, but heavens yes i'd love to entertain something
| higher & more illuminating than the general retrogressive
| cassally slanderous backhanding this language endlessly
| endures.
| [deleted]
| pvg wrote:
| You could just, you know, vote on or reply to those comments.
| rektide wrote:
| I have. But there's a pervading forrest of negativity,
| especially on js subjects, and trying to argue about each
| tree is only so helpful. The meta-attending to whats
| happening is direly needed.
| pvg wrote:
| Pasting bits of other people's comments out of context to
| sneer at them is plainly less helpful than not doing that,
| whatever you choose to meta-call it.
| rektide wrote:
| I think I've done a moderate & mild job of holding up a
| very reasonable mirror to what happens, broadly, in a lot
| of threads. This isnt at all unrepresentative of what's
| happening. In most cases it's people's first words.
|
| This is long long overdue. Silence about this cavalcade
| cannot go on imdefinitely. This reaction you are having
| seems way way out of line for some pretty basic
| reflection.
|
| How else might we try to meta-attend to our social
| problems?
| polskibus wrote:
| Just merge with Typescript already and reduce the complexity of
| the ecosystem. If someone does not want types they can just 'any'
| everything.
| frou_dh wrote:
| TypeScript doesn't have a language specification so there's
| nothing to merge. If you tell browser vendor X that they need
| to start supporting TypeScript, what does that mean?
| Existenceblinks wrote:
| I can't come up with reason why you got downvote. This is a
| fundamental and basic thing on designing type. I'm afraid to
| comment "merge what?" (genuine question)
| neysofu wrote:
| I wouldn't hold the lack of a natural language specification
| against Typescript. Canonical open-source implementations
| work just as well in practice and tend to become de-facto
| standards: Microsoft's compiler is effectively a human- and
| computer-readable specification.
| dymk wrote:
| Adding (even a simplified version of) the Typescript typesystem
| to the Javascript spec is probably a bad idea. It's all the
| weird little complexities of Typescript that make it flexible
| enough to add types to most JS code.
|
| Javascript as an untyped build target is fine. I'm opposed to
| adding (ignored) type hints to Javascript because they'd just
| end up rebuilding Typescript, but done poorly.
| cyral wrote:
| Or enable implicit any which makes it just like JS with
| optional types.
| codedokode wrote:
| > The sunsetting of IE11 and the rise of evergreen browsers that
| implement the latest JavaScript standard means that developers
| can once again run standard JavaScript code without
| transpilation.
|
| This is a wrong assumption. There are lot of smartphones that do
| not get updates and have browsers that can be several years old.
|
| Therefore transpiling and polyfills are not going away anywhere
| soon.
|
| Of course, supporting different browsers can insignificantly
| increase development costs. It might be impractical to try to
| support Internet Explorer 7. A safe and reasonable choice would
| be to make sure that site looks and works perfectly in any
| browser released 5 years ago and is usable in a 10-year old
| browsers.
|
| Obviously there are cases when this rule can be amended, for
| example, if you are making a game requiring a fast GPU and a
| mouse, then you can ignore smartphones and old browsers. But for
| a general website, like a corporate website, an online store, a
| social network, this seems like a sane default choice. You can
| extend support to 12-15 years old browsers if you feel confident
| in your skills.
| asddubs wrote:
| I think it doesn't really matter one way or the other, anyway.
| Even if it takes 10 years to proliferate, at some point in the
| future, it'll be 10 years from now, and we'll be able to use
| it. depending on your usecase, maybe sooner.
| laurencerowe wrote:
| I still expect most people would bundle and minify the code
| shipped in production but removing the requirement to setup a
| transpiler for development would be a huge win for developer
| ergonomics.
|
| For many smaller projects that bundling step may then simply be
| `deno bundle index.js` or similar.
| klodolph wrote:
| I love this.
|
| Maybe it means that I don't have to preprocess / compile
| TypeScript before running it. This is a genuine win for me. The
| TypeScript compiler can continue doing what it does best--type
| checking--and then I can just run the code. Running the
| TypeScript compiler from a cold start takes a surprisingly long
| amount of time.
|
| Currently, I have to figure out how to get a build system that
| compiles TypeScript once for bundling to the browser and once for
| running in Node, and the user experience around setting this up
| is just incredibly bad. It sucks. I make some change to how I
| build for browser and it turns out to be incompatible with
| whatever system I am using for Node. This solves part of that
| problem, and reduces friction. Type annotations can be just part
| of the JS and stripped out by minification.
| bavell wrote:
| This is the reason I don't use the typescript compiler and
| instead use babel to strip the types out completely on
| compilation. I use vs-code's built-in type checking when coding
| in dev and then throw out types in prod. Fast dev builds and
| still get all the type checking I want. Optionally you can run
| the full blown typescript compiler as part of CI/CD if you want
| to ensure no errors or warnings hit prod.
| redox99 wrote:
| I don't see what the issue is.
|
| For backend node, you simply edit a couple of lines in the
| package.json to use ts-node during dev, and run tsc for
| shipping builds (a bit more performant than ts-node).
|
| For frontend usually you literally don't configure anything,
| Next.JS, CRA, or whatever already comes with typescript
| preconfigured if you select it. And if you do everything
| manually, considering you still need to setup babel, webpack
| etc, it makes almost no difference.
|
| It seems quite extreme modifying javascript for this
| considering you still would want to remove types in order to
| reduce bundle size, and you would still need the actual
| compiler because you have things such as enums, annotations and
| more that JS doesn't support either.
| rektide wrote:
| How many years have you been doing this? How many hours have
| teams you've worked on spent configuring build pipelines? How
| many people have you seen to go other mentors or helpers in
| your org when they are setting up a new project? How many
| many times have you seen someone start from from nothing & be
| done in <1 hour?
|
| This post reads like a facetious trivialization of how
| complicated everything is, how complexly interlinked build
| systems are.
|
| Most harmfully, it trivializes what a pain in the ass it is
| when the source/libraries you are consuming have already been
| downcompiled into lesser JS via someone elses perhaps-poorly
| configured build pipeline. I'd guess that >80% of TypeScript
| modules don't export ESM right now. TypeScript 4.7 is about
| two weeks old & it's the first time TypeScript and Node's ESM
| play well[1]. Because it all involves complex transpilation.
|
| You know what would be great? If we could just write code. If
| we didn't _have_ to worry about build pipelines. If my
| toolchain could make what it would of other code, be it JS or
| JS+TypeScript Type Annotations or JS+Flow Type Annotations.
|
| > _" For frontend usually you literally don't configure
| anything, Next.JS, CRA, or whatever" "For backend node, you
| simply edit a couple of lines in the package.json"_
|
| The amount of dissympathy for the real complexity here, for
| how hard a couple specific projects have worked to make
| things "just go" is staggering. The amount of ink spread to
| support, the amount of stack overflow questions struggling
| through, is probably enough to reprint the Apollo Missions
| guidance software a couple times over.
|
| This is hard stuff. It's complex & interlinked. There are not
| singular solutions; there's many many interlinked &
| complected tools & systems & options.
|
| Easing the path back towards- it will work. Towards just
| being able to ship code, without necessarily needing to
| typecheck it, transpile it, downcompile it: it helps a huge
| range of people who are really really in need of help. Who
| don't have teams, companies, support. Who just want to start
| to learn, want to start to get going. This change may or may
| not (I'd argue more that it may but...) have huge impact on
| your life as a highly-late industrial supercorp developer,
| but it has huge impacts on the ecosystem, it's
| approachability, it's friendliness. Writing all that off,
| just pretending we have some magic wands we can wave & these
| dilemnas, these pitfalls, are not really here: woe be un to
| us if we are not willing to assess the real cost of this all.
| I can't see your post as taking for real the costs.
|
| [1] https://devblogs.microsoft.com/typescript/announcing-
| typescr...
| 88913527 wrote:
| I can't do much without some degree of pre-processing. The
| browser can't resolve NodeJS-style require's, so I'll need a
| bundler to serve my app in a manner the browser can understand.
| I imagine most use cases today face this dilemma. It wasn't the
| type annotations holding me back for requiring pre-processing,
| it was the ecosystem around how JavaScript is written that is
| the primary factor.
| runarberg wrote:
| I haven't used NodeJS type requires in new projects since
| Node 12 (which EOL-ed last april). Most code I write now uses
| standard imports. There is off course some issues around
| resolving from npm but there are mitigations, and going
| forward import maps (already supported by Chrome) will solve
| most of these.
|
| Really the only reason to do pre-processing is if you want to
| do some optimization beyond what the browser can do, or if
| you want to write a syntax which is not supported by your
| target runtimes. And for many developers (including most
| library authors) this is not the case.
| runarberg wrote:
| I've been writing Vanilla JavaScript with JSDoc annotations and
| using TypeScript as a type checker (as opposed to a compiler)
| for some of my hobby-projects, and it is amazing breath of
| fresh air from the bundler tool chains of the past.
|
| As pointed out by this proposal the JSDoc annotations are--to
| put it mildly--a bit cumbersome. The more complicated types are
| close to impossible to figure out how to write, if they are
| possible to write at all. And on Q&A forums I constantly have
| to translate between the two syntaxes in my head, since most of
| the audience will probably not understand the JSDoc syntax.
|
| Having a unified type annotation syntax which the runtime
| ignores will definitely make my life easier.
| yakshaving_jgt wrote:
| Looks like programmers wish their favourite language would adopt
| their new favourite feature right after they've just learned how
| to use it. Sure, it makes the language you use more
| sophisticated, but at the cost of raising the bar for everyone
| else to learn that language.
|
| To continuously add features and complexity to JavaScript makes
| getting started with web development that much more cruel and
| arduous for our more junior colleagues.
|
| If you like types (and personally -- as someone who for the past
| several years has almost exclusively written Haskell and Elm
| professionally -- I do), why not just pick a different language
| that has the features you want and compile it down to JavaScript?
|
| I have a perception (and I'm sure some would argue it's
| inaccurate) of the web development community that likes to pat
| itself on the back for being smart enough to use JavaScript's
| [relatively] new spread operator, but at the same time whinging
| about Elm because its syntax looks weird.
| frou_dh wrote:
| > the web development community that likes to pat itself on the
| back for being smart enough to use JavaScript's [relatively]
| new spread operator, but at the same time whinging about Elm
| because its syntax looks weird.
|
| It's probably more like that meme image from some TV show:
|
| Elm user: I feel bad for you.
|
| Enthusiastic JS/TS user: I don't think about you at all.
| j3schmidt wrote:
| pplongway wrote:
| alexfromapex wrote:
| Calling it now, there will be a flame war over type systems
| Existenceblinks wrote:
| I think the first thing in design to have sane (sound) type is to
| separate effects from pure stuff. Browser engine is complex but
| API shouldn't be, right? It would be great if those compile-to-js
| lang authors folks also get involved. (those ML based and some
| others)
| golergka wrote:
| This proposal doesn't include any actual type-checking. It
| would make various type checking annotations valid no-ops in
| JS, nothing more.
| Existenceblinks wrote:
| Yeah I also have another comment
| https://news.ycombinator.com/item?id=31673288 about chance to
| do something different.
| rubyfan wrote:
| Am I the only one that thinks annotations are a code smell?
| codedokode wrote:
| Isn't reverse engineering a code with annotations much easier
| than without them? And reverse engineering the code often takes
| significant time in large projects.
| asddubs wrote:
| I don't want this. I want real types, that are checked and throw
| errors, or are at least coerced on being passed into/out of
| methods (preferably the former)
|
| If you don't want to take the performance hit of type checks, you
| can still check and then remove type annotations during bundling.
| Having this would just mean that we will never ever ever get
| actual static typing in javascript, so it's actually worse than
| doing nothing.
| h1fra wrote:
| Well a lot of other people want this. And both ideas are not
| incompatible.
|
| If you don't want to this, you can still build your own real
| types, that's the beauty of JS.
| [deleted]
| shadowgovt wrote:
| I'm not sure I understand the concern. Static types _are_
| checked and emit errors, but they do so statically (i.e. at
| compilation time).
|
| There's nothing I see in this proposal to prevent a user-agent
| from running a static analysis on JavaScript input into the
| console or DOM editor before trying to interpret it. If what
| you're saying you want is for the typechecking to be done by
| the user-agent for every piece of downloaded JavaScript... Why?
| I mean, a user-agent could be constructed to do that, but it'd
| be inefficient over just trusting the vended code (which, in a
| sense, we should probably just default to doing, because
| nothing stops the developer from type-asserting or omitting
| types so in the grand scheme of things, the code is exactly as
| provably sound if we typecheck it before running as if we
| don't).
|
| What would "actual static typing in JavaScript" look like that
| this proposal isn't?
| asddubs wrote:
| the proposal is for type annotations, which are to be treated
| as comments. i want type checking to be done in the browser,
| whether it's before the javascript is run or at runtime isn't
| important, the point is that i want the browser to explicitly
| be forced to do it. and then if I'm sure my types are correct
| and I want to speed things up, I can strip out the type
| annotations. but this means that for smaller scripts, or in
| general during development, you don't need an extra
| compilation step at all.
|
| I want the browser to reject feeding a string into a number
| parameter of a function, at which point it does this isn't
| important to me as much as that it should be more than just a
| comment that is ignored completely.
| shadowgovt wrote:
| If it's static analysis, then the browser can always
| execute it and throw it out after execution, that's the
| nature of static analysis.
|
| There would absolutely have to be an escape hatch, or
| configuring one's browser in this way would make most of
| the web fail to work (and unfortunately, the golden rule
| for features in browsers is "if it breaks most existing
| sites, you can't add it because most users aren't savvy
| enough to understand what is happening and will uninstall
| your browser in response"). But I can't actually see
| anything stopping a given user agent from choosing to offer
| that as a development feature for a specific domain, which
| would be pretty swell.
| danuker wrote:
| > Having this would just mean that we will never ever ever get
| actual static typing in javascript
|
| I think we will never have enforced static typing in
| Javascript, because of legacy code.
|
| The solution is to use something higher level. Maybe Elm.
|
| https://elm-lang.org/
| asddubs wrote:
| well, if you don't have type annotations, nothing is
| enforced, obviously. but you can pretty easily make it
| legacy-code compatible by just having type annotations be
| optional, but enforced if present
| rektide wrote:
| You're free to go develop a transpiler that adds the
| guards/checks you desire to your code. Nothing stops you from
| building on this starting place. The data would be there.
|
| JS engines could do the same!
|
| Let's start with the first steps: getting the information.
| asddubs wrote:
| the moment they add this to javascript, there will be people
| out there feeding strings to number-annotated parameters of
| functions (and so on). and then of course no one is going to
| want to break existing code. that's why doing this in a way
| that is not enforced is corrosive to having types in the
| language in the future.
| rektide wrote:
| as others have stated, the answer seems to be to opt in:
| "use typechecks"
|
| or only warn.
|
| i don't think anyone would consider turning it on by
| default everywhere. this seems like an extreme non-issue.
| [deleted]
| jmisavage wrote:
| We almost had it with JavaScript 2/ECMAScript 4, but Microsoft
| and Google killed it. One because they didn't want to update
| their JS engine and the other had just released v8. Adobe
| implemented it as ActionScript 3 and Firefox had most of it
| done too. Everything since then has been about incrementally
| add similar features into the existing code base without fixing
| the foundation.
| lstamour wrote:
| Okay, but also at the same time we had XHTML with strict
| errors that would crash the webpage. As a result, nobody used
| it or wanted it in practical, messy, real world code.
|
| Since that backtrack, the Internet has always been about
| displaying _something_ at all times.
|
| Adding types to JavaScript and hard failing when they're
| incorrect is not a JavaScript anyone wants to publish. We'd
| rather have the forgiving but messy JavaScript than the one
| that stops a webpage from working when it gets a different
| data shape from a JSON endpoint due to runtime checks.
|
| Nobody actually wants runtime checks on the web unless you've
| a way to opt in to them. And guess what? You could. There's
| nothing stopping you from writing a compiler that adds
| runtime checks to your code. In fact, that's pretty much what
| code generators do for typescript when they create validation
| functions to make writing or working with APIs a bit easier.
| asddubs wrote:
| adding type annotations to your code _is_ opting in. if you
| don 't want it, you can leave them out, or have them be
| removed during bundling. what's the point of having
| annotations that do nothing?
| lstamour wrote:
| So we can run unmodified TypeScript code without needing
| to bundle inside Node.JS and other implementations of
| JavaScript such as JS Core.
|
| By allowing but ignoring types, you get the best of both
| worlds - optional type checking and runtime compatibility
| - without further compilation.
|
| Frankly I think of this feature as a Node.JS feature and
| a reduce-duplication feature. You can store and run the
| same TS syntax in a file with a .JS extension.
|
| Today, I often find TypeScript samples that I copy into
| JS projects and then have to painfully remove the
| TypeScript bits to get it to run. This fixes that. Your
| IDE can benefit from reading the types and tell you about
| errors - that's where you can fix them anyway.
|
| If you want <script lang="TypeScript" ... /> to work,
| with compile type checks and everything, that's a
| different feature?
| klodolph wrote:
| Wouldn't we remove comments from the language by that
| reasoning? Comments also do nothing.
| klodolph wrote:
| > One because they didn't want to update their JS engine and
| the other had just released v8.
|
| ECMAScript 4 was canceled for a whole host of reasons. Trying
| to blame browser vendors is just bonkers. The standard made
| too many changes all at once and existing work on
| implementations had progressed too far.
|
| https://auth0.com/blog/the-real-story-behind-es4/
| Existenceblinks wrote:
| Same. This proposal could be a chance to gradually move away
| from insane javascript typing. I think the first thing is to
| make effect manager and separate DOM API from anything else,
| and introduce sound typing language on pure side. This way is
| not messing with any underline engine but API. Webassembly text
| is a whole new language that can be compiled and interact with
| javascript. Why can't we have to new sound type language, it
| doesn't have to have many features since DOM API is still
| there.
| ash_gti wrote:
| https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
|
| Has additional context on this proposal and has previously been
| linked here.
| syspec wrote:
| > _One can explicitly specify the type arguments of a generic
| function invocation or generic class instantiation in
| TypeScript._ // TypeScript add<number>(4,
| 5) new Point<bigint>(4n, 5n)
|
| > _The above syntax is already valid JavaScript that users may
| rely on, so we cannot use this syntax as-is. We expect some form
| of new syntax that could be used to resolve this ambiguity. No
| specific solution is proposed at this point of time, but one
| example option is to use a syntactic prefix such as :_
| // Types Annotations - example syntax solution
| add::<number>(4, 5) new Point::<bigint>(4n, 5n)
|
| > _These type arguments (:: <type>) would be ignored by the
| JavaScript runtime. It would be reasonable for this non-ambiguous
| syntax to be adopted in TypeScript as well._
|
| ----
|
| Hmm I didn't know this, so I tried it myself in Chrome's
| console... sure enough it works... new
| DOMPoint<Number>(4,5)
|
| Given that the above works in the browser, what exactly is it
| doing? I've never seen angle brackets used that way in vanilla JS
| code
| Matheus28 wrote:
| ((new DOMPoint) < Number) > (4,5)
|
| Comma operator makes (4,5) = 5
| evan_ wrote:
| It's just less than/greater than:
|
| https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9...
| methyl wrote:
| It just evaluates to false, as this is just two comparison
| operations. It's easier to comprehend if add a parentheses
| around first operation as such: (new DOMPoint
| < Number) > (4, 5)
|
| (new DOMPoint < Number) evaluates to true and it becomes (true)
| > (4, 5). Because (foo, bar, baz) syntax always evaluates the
| last item, we can finally simplify it into (true > 5), which
| surely enough in Javascript evaluates to false.
| epidemian wrote:
| > Given that the above works in the browser, what exactly is it
| doing?
|
| Oh, buckle up! new DOMPoint<Number>(4,5)
|
| Let's first clean things up a bit: DOMPoint an Number are just
| identifiers. So, let's replace those with a and b:
| new a<b>(4,5)
|
| Let's also add some spacing around these tokens to distinguish
| them better: new a < b > (4, 5)
|
| Yep, those < and > are comparison operators.
|
| And let's also add some parentheses to make clear the order of
| operations in these comparisons. The above expression is
| equivalent to: (new a < b) > (4, 5)
|
| Now, let's remember that a is DOMPoint, so `new a` is just
| instantiating a new DOMPoint object. Yep, the parentheses at
| the end of the `new Something` calls are optional if no
| parameters are passed. > new DOMPoint
| DOMPoint { x: 0, y: 0, z: 0, w: 1 }
|
| (That's the result of trying that out on a JS console. The
| initial > on the first line is the REPL prompt, not part of the
| JS syntax. And the second line is what the REPL prints.)
|
| So the < operator is comparing a DOMPoint object to b, which is
| Number, which is just a constructor function. IIRC, what JS
| does is these kind of situations is to convert both operands to
| strings and then compare those. > (new
| DOMPoint).toString() "[object DOMPoint]" >
| Number.toString() "function Number() { [native
| code] }"
|
| So the first < comparison is going to compare these two
| strings, and since '[' is less than 'f' (of course... ASCII),
| the < result will be `true`. The whole expression can then be
| reduced to: true > (4, 5)
|
| The right-hand side of this > operation, `(4, 5)`, is curious.
| The parentheses are just normal parentheses for grouping
| expressions, but what's inside of them are two expression
| joined together by the comma operator[1]! Basically, both
| expressions, 4 and 5, are evaluated, one after the other, and
| the result of the whole is the result of the last one:
| > 4, 5 5
|
| So, we're almost there! The whole thing can now be reduced to:
| true > 5
|
| Since one of the operands is a number, JS tries to convert the
| other one to a number too. `true` converted to a number yields
| 1, which is not bigger than 5 -- finally, something that makes
| sense!
|
| So now we know why the whole thing that looks like TypeScript
| but isn't, is valid JavaScript and evaluates to false :)
| > new DOMPoint<Number>(4,5) false
|
| 1: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| JadeNB wrote:
| true > 5
|
| > Since one of the operands is a number, JS tries to convert
| the other one to a number too. `false` converted to a number
| yields 0, which is not bigger than 5 -- finally, something
| that makes sense!
|
| You meant that `true`, not `false` which doesn't appear in
| this partially evaluated version, is numified, right?
| epidemian wrote:
| Oh, yes. Silly mistake. I've fixed my comment. Thanks for
| the catch!
| colejohnson66 wrote:
| IMHO, the "turbofish" syntax (popularized by Rust) is ugly and
| should not be used. The reasoning of syntax ambiguity is also a
| lame one because C# manages just fine without it. But to then
| say that:
|
| > The above syntax is already valid JavaScript that users may
| rely on, so we cannot use this syntax as-is.
|
| What users would be using said syntax? Why would one compare a
| function to a type? If we're making a backwards incompatible
| change, just say that `func < type` is a syntax error unless
| immediately followed by the rest of a call. IMO, in any spec
| committee, if a naysayer says that "someone may be using that
| syntax", they should be required to prove it. _Prove_ that
| someone is comparing a function to be less than a type, and why
| they 'd do such a thing.
|
| Honestly, I don't see how this can be done in a backwards
| compatible way short of type annotations in _comments._ Just
| rip the bandaid off and have WHATWG say that TypeScript is a
| valid runtime and allow ` <script src="..."
| type="typescript">`. Deno manages to have a TypeScript runtime
| just fine.
| crooked-v wrote:
| > Why would one compare a function to a type?
|
| Aggressively minified and optimized JS code results in all
| sorts of weird things.
| colejohnson66 wrote:
| Sure, but if a minifier/optimizer wants a "truthy" value,
| they can just use "1". It'd be a pretty bad minifier if it
| turned something needing a truthy value into anything more
| than that.
|
| Unless one can find some minifier producing said example,
| it's a bad argument.
| jffry wrote:
| It's essentially unknowable if anybody has produced code
| out there that is like this, but the point still stands
| that it is valid code.
|
| If you want to uphold a commitment to backwards
| compatibility, you simply cannot extend your language in
| a way that might possibly change the behavior of valid-
| but-nonsensical code in the wild.
| steen_hansen wrote:
| Hey I got an idea, let's ignore a better solution like
| Closure.spec's runtime type checking.
|
| Its even like "functional", you can turn it on or off at will, it
| can even do regular expression tests to validate string
| parameters.
|
| I partially copied it for Javascript,
| https://www.npmjs.com/package/type-czech, it even runs in
| JsFiddle https://jsfiddle.net/steen_hansen/1Lshcept/?Example-
| Contents
| Existenceblinks wrote:
| Or make Webassembly text extensible then we could have
| something like https://github.com/carp-
| lang/Carp/blob/master/docs/LanguageG...
| Matheus28 wrote:
| That sounds awfully inefficient
___________________________________________________________________
(page generated 2022-06-08 23:00 UTC)