[HN Gopher] First look: adding type annotations to JavaScript
___________________________________________________________________
First look: adding type annotations to JavaScript
Author : mariuz
Score : 162 points
Date : 2022-03-10 13:06 UTC (9 hours ago)
(HTM) web link (2ality.com)
(TXT) w3m dump (2ality.com)
| azangru wrote:
| Typescript, by the virtue of not being javascript, has evolved
| pretty rapidly, and has come pretty far. Would the addition of
| types to javascript and typescript's conformity to those type
| annotations slow down typescript's development? There's still
| some hope, at least on typescript's roadmap[0], for nominal types
| in addition to structural types. Will the standardisation of type
| annotations impose further constraints on typescript?
|
| [0] - https://github.com/microsoft/TypeScript/wiki/Roadmap#future
| Vinnl wrote:
| It's not the addition of types to JS, it's telling interpreters
| to ignore parts of JS source files that can then be used to
| insert type annotations into much like comments, e.g. for
| nominal types.
| IceHegel wrote:
| Here's why I support this:
|
| I want to write, run, and debug a js file in node without
| intermediate files. Repl speed would increase a lot.
| superfamicom wrote:
| It seems odd to go out of the way to not break older libraries
| like mootools by renaming built in functions only to now break
| all older parsers for hints that don't convert to any performance
| improvement. I love the idea, and use JSDoc comments for that
| exact reason, but it feels inconsistent.
| darepublic wrote:
| Of all the new fangled crap to emerge in js ecosystem over past
| decade, typescript stands out to me as perhaps the best and least
| BS of them. I would love for typing to be supported by ecmascript
| but unless it arrives full featured I'm concerned it will then be
| typescript vs ecmascript types and landscape will simply be more
| cluttered with competing options. Just like how new browsers have
| half assed support for es6 modules. Free me from the toolchain
| hell of js, please, I'm waiting eagerly
| Vinnl wrote:
| The original proposal has lots of caveats, justifications, and
| pre-empts many comments and questions that people seem to be
| asking here, so I'd recommend people to take a look at that
| instead: https://github.com/giltayar/proposal-types-as-comments/
|
| Also the announcement:
| https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
|
| And HN discussion: https://news.ycombinator.com/item?id=30618681
| ok123456 wrote:
| You still need some way to make typed javascript run on older
| javascript engines. This would become yet another babel preset
| you have to juggle.
|
| Why not just use typescript directly in the browser?
| esperent wrote:
| You don't have to manage every feature in babel individually,
| just target browsers with babel-preset-env. Then there's not
| anything you have to do when new features get added.
| ok123456 wrote:
| It's still a compilation target that needs to be managed by a
| build system. It doesn't address the complexity of the
| ecosystem, and just adds to it.
| TheAceOfHearts wrote:
| During development it would be helpful to have type checking
| enabled at runtime behind some flag or configuration. I want code
| to fail fast and early in my development environment. In
| production the code will be stripped and minified.
|
| I read the FAQ in the proposal but don't understand the
| challenges in adding type introspection at runtime. It seems
| weird to add all this syntax and not have any way to leverage it
| during runtime. Although maybe it wouldn't be that useful? Still
| making up my mind about this.
|
| Glad to see that these questions are at least being considered
| and explored as part of the proposal.
|
| Great job from everyone involved, this proposal shows a lot of
| promise and it makes me excited for the future of JS.
| Kerrick wrote:
| Maybe a special string flag like "use strict" -- "use types"?
| jakelazaroff wrote:
| I personally do not want to give developers the option to
| make type errors a user problem.
| themikesanto wrote:
| Type errors are a user problem already, if they make their
| way into production.
| jakelazaroff wrote:
| Not necessarily -- maybe the error is an incorrect
| argument to a function that's never used, for example.
|
| The issue is, what should the browser do if it encounters
| a type error? Should it just refuse to interpret the
| entire script? That's super heavy-handed when it's
| possible that the error doesn't even matter in practice.
| Aldo_MX wrote:
| > It seems weird to add all this syntax and not have any way to
| leverage it during runtime.
|
| Just because they're not leveraging them today, it doesn't mean
| that they won't do it tomorrow. If a proposal requires a big
| effort to implement it, it will probably never become adopted.
| mpawelski wrote:
| I think it means exactly that. If JS will get type hints that
| are not checked at runtime then we will never get runtime
| validation for these type hints since it will break a lot of
| existing code that has would have "wrong" type hints.
| [deleted]
| masswerk wrote:
| Back then, type hints for ECMAScript worked out quite well with
| AS3 (ActionScript3). Maybe worth revisiting?
|
| (It was also used for optimization.)
| synergy20 wrote:
| Even better, make sure browsers typescript ready or fully
| compatible over time. In my opinion Typescript and Javascript
| should merge into one and gradually shift towards Typescript. I
| used to feel TS is just extra effort unneeded, after using it for
| a while, I found it so great I no longer want to code in JS, not
| at all.
| madeofpalk wrote:
| The MS blog post, and actual proposal covers this fairly well
| imho:
|
| Typescript's type checking is slow and doesn't need to happen
| at runtime. Additionally, it moves failures to users rather
| than developers and makes it incredibly difficult to change
| type semantics later on.
|
| https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
|
| https://github.com/giltayar/proposal-types-as-comments/
| chess_buster wrote:
| Me, too.
| tacotacotaco wrote:
| You know you can already write doc comments in Javascript code.
| It doesn't require changing the language. IntelliJ parses these
| comments when providing code insight.
|
| Yet in my entire career I have found that I am the only dev that
| writes these comments. I use to think this was just JS devs but I
| have found C#, Java, and indeed Typescript projects that I work
| on to be sorely lacking in comments of any kind. So, how does
| this adding complexity to the language standard change this?
| xmorse wrote:
| It would be cool to have this, but i think that adding so many
| features at once to the language isn't going to happen, and
| adding one piece at a time doesn't make sense.
|
| Also, the parser performance will probably take a hit.
| KaoruAoiShiho wrote:
| Don't think this should affect performance, so it's a win for
| devs at no cost to the execution. Should just be a good thing no?
| pavlov wrote:
| A lot of what's happened in JavaScript is just retracing Adobe's
| circa 2005 proposal that nobody wanted at the time: types, JSX...
| nyxtom wrote:
| This feels like added complexity to the runtime where the long
| term goal appears to make Javascript into a sort of opt-in
| Typescript runtime. Not sure if that's a good thing or a bad
| thing - but it certainly means added complexity. That being said,
| npm is a mix of both so it's not like you can be exclusively
| javascript only anyway these days (you have to be able to read
| and understand typescript as they are dependencies)
| cphoover wrote:
| Stop trying to make JavaScript into something it's not...
|
| If you want a type system Typescript works great, and it's very
| easy to set up. You even get debugging to the original uncompiled
| source with sourcemaps.
|
| If you want a strongly-typed static language, compile to a wasm
| target... That's what it is for.
|
| Stop trying to change JavaScript into a language it is not.
|
| JMHO
| CraigJPerry wrote:
| It does feel like we have a problem saying no to language
| features, and it's not just in the JS world.
| franciscop wrote:
| Definitely, ES6 was great and it seems we've ramped up to add
| as many features as possible, which has produced a lot of
| churn and unused/hated features. A committee was formed to
| add new features when needed, and now they... just keep
| adding and adding even when not needed.
| nine_k wrote:
| Do you remember Javascript from 1996? (I do.) Do yo think that
| all the improvements of ES5 (reflection, strict mode, JSON)
| changed it into what it was not? Did ES6 (classes, imports)
| change JS into something it was not, or should not be? Did
| ES2016 (async) do that?
| dangerbird2 wrote:
| Did you read the article? All the proposal does is allow the
| javascript engine to accept typescript-style syntax, while
| erasing all the annotations at runtime. From the browser's
| point of view, it would essentially treat the type annotations
| and type declarations as comments. This combined with native
| Ecmascript modules means you could theoretically develop a
| typescript application with no bundler or other build tools.
| You'd be able able to use typescript autocomplete and linting
| in your editor, and just serve the files to your browser with a
| static http server. Some newer bundlers like Vite and esbuild
| greatly reduce the amount of configuration required to set up a
| typescript project, but being about to develop a project with
| nothing but an editor and a browser would be a huge win for
| small projects.
|
| Since the proposal doesn't care about the semantics of the type
| annotations, it doesn't even necessitate typescript. It would
| work just as well with Flow typing or even a completely new
| type checker.
| nobleach wrote:
| I get that this is a humble opinion. And I respect that. But
| for a language that draws so much ire from the programming
| community, and yet demonstrates such an ability to change and
| morph over the years. Are you saying you do NOT WANT it to get
| better? (and I realize "better" is subjective).
|
| The same is true of PHP. People hate it. People complain. PHP
| takes the criticism and makes updates. People complain more.
| cphoover wrote:
| Of course I want it to get better. I just don't necessarily
| agree that a type-system = better, particularly in the way in
| which it's been suggested. Especially when you aren't talking
| about changing the internals regarding how JS is executed or
| how data is represented, you are only talking about adding
| "comments".
|
| JavaScript has evolved as an untyped language, it has type-
| coercion and a single way to represent (most) objects in
| memory. So regardless of what kind of syntax you add on
| top... it will still be a untyped dynamic language
| internally. Are we talking about changing this truth? Or just
| adding additional syntax for developers?
| balefrost wrote:
| Out of curiosity, where do you stand on ES6 classes?
| cphoover wrote:
| Certainly cleaner than using the old prototypal inheritance
| syntax. // Dog Class function
| Dog(_name){ // call the parent constructor
| Animal.apply(this,arguments); } //
| extends the Animal prototype chain Dog.prototype =
| new Animal();
|
| Although the new class syntax may obfuscate from what's
| actually happening in an effort to look more like traditional
| class-based languages like Java.
|
| However I'm the type of person that will only use React
| function components in my codebase. I don't think the object-
| oriented style has added much too my programming, except the
| temptation to reach for an unnecessary abstraction.
| datavirtue wrote:
| That ship already sailed. If we were just twiddling the DOM I
| wouldn't even be reading this thread right now but people are
| writing production back-end code for financial services
| companies in JS. Bring on the type system.
| kall wrote:
| I think this proposal is trying to keep in that spirit while
| making everyone happy, by only adding what is effectively
| another comment syntax to JS, instead of defining a type system
| for it.
| halfmatthalfcat wrote:
| I mean, with all due respect, who are you to decide what
| Javascript is and is not? There's obviously a huge demand for
| type safety in Javascript, hence the existence and adoption of
| Typescript.
| Turing_Machine wrote:
| Compare the lines of code (on Github, say) written in
| straight Javascript and the lines of code written in
| Typescript.
|
| I do not think the demand is quite as huge as you think it
| is.
| rattlesnakedave wrote:
| I'm not sure that's a useful metric.
| Aldo_MX wrote:
| This is like saying compare the lines using generators or
| proxies vs the lines using type annotations.
|
| Just because a feature is not widely adopted it doesn't
| mean that is not useful to the people using it, especially
| when the feature is used to mitigate the entire "cannot
| find property of undefined" type of errors.
| Turing_Machine wrote:
| > Just because a feature is not widely adopted it doesn't
| mean that is not useful to the people using it
|
| But it does mean there likely isn't a "huge demand",
| which was the original claim.
|
| You're attempting to move the goalposts here.
| latortuga wrote:
| In the linked article, the author spends 1 sentence
| dealing with objections:
|
| > I can understand if JavaScript developers are afraid of
| TypeScript taking over their language. However, this
| proposal will be as far as things will go w.r.t. adding
| TypeScript features to JavaScript
|
| And in the next few sections it includes someone who
| wants to build on the proposal including using type hints
| to optimize code. I just think there's literally no way
| to guarantee that "this will be as far as things will
| go". Yes languages evolve and add new things all the
| time. But GP's point is that the language seems to be
| going toward what people want it to be coming from other
| languages.
|
| I agree, stop trying to make JS something it's not.
| neurotrace wrote:
| > And in the next few sections it includes someone who
| wants to build on the proposal including using type hints
| to optimize code.
|
| This changes literally nothing about the JS language. JS
| engines already attempt to determine the types of things
| to optimize the code they generate. Type annotations
| would just allow them to make more aggressive
| optimizations.
| moron4hire wrote:
| Every TypeScript project is going to have at least an
| equivalent amount of JavaScript code sitting in the repo
| from the output of the TypeScript compiler.
| cphoover wrote:
| most people don't version control the output of their
| compiled build though.
| cphoover wrote:
| I don't know but I've been using JavaScript for a while now.
| It seems like a lot of the people that want JavaScript to
| look similar to other languages are coming from different
| programming fields, and want JavaScript to look more like
| their language of choice.
|
| Most of the changes to JS in the last 20 years, have been
| serious improvements, but they did not change the fundamental
| characteristics of the language.
|
| Believe it or not there are a lot of people that like
| JavaScript!
| zachrip wrote:
| I would like to say that I have written js for a long time
| as well and I love it; but the thing that keeps me around
| nowadays is typescript. I would need to be paid much more
| to work on a non-ts js codebase nowadays.
| danielvaughn wrote:
| I'm on the fence about this one. On the one hand I would
| love strong typing in JS.
|
| But the reason I never adopted TS is because one time I
| spent _months_ converting Coffeescript back into JS once it
| fell out of favor. This was back when a bunch of Ruby
| developers decided that JS should look like Ruby.
|
| If I'm writing Javascript, I'm writing Javascript, not
| something that pretends to be something else.
| Bilal_io wrote:
| The good news is that you can take your time with it,
| only start using typescript in new files while converting
| older ones slowly. And even if you never do that,
| typescript tooling provides hints and autocompletion to
| vanilla J's files as well.
| neurotrace wrote:
| One of the benefits of TypeScript is that it literally is
| just JavaScript plus some. You can literally run `tsc`
| and it will spit out JavaScript written the same way as
| you wrote it but without any of the types. The only
| things that might look out of place is things like enums
| or decorators but you can choose not to use them.
| recursive wrote:
| You can generally migrate out of TS very easily if it was
| the wrong choice. You can mostly use the compiler output
| as a drop-in replacement for your source code. Depending
| on compiler options, it's quite readable.
| vosper wrote:
| You can convert TS to JS at the drop of a hat. This is
| part of what's required to get it to run a browser, which
| doesn't understand native TS. It's different to
| Coffeescript which was different syntax for JS. TS is
| additional, type-specific syntax but you are still
| writing JS.
|
| I ran a team that had to maintain a large Coffee
| codebase, that we could never get the resources to move
| off. So I know that pain. TS is different, both in how it
| works and the level of adoption. Coffeescript was always
| niche, and some benefits were there but they weren't
| game-changing for (eg) writing correct code or
| maintaining large codebases.
| Aldo_MX wrote:
| > but I've been using JavaScript for close to 20 years now
|
| How dare you use JavaScript for anything else than
| validating forms!!! What is that jQuery thing??? Stop
| trying to make JavaScript into something it's not!!!
| cphoover wrote:
| What about the aspect of JavaScript having weak type
| system relegates it's use to only be used for forms?
|
| Is C only used for forms?
| Aldo_MX wrote:
| I thought you were there literally 20 years ago when
| people were complaining about adding DHTML to the
| browser.
| [deleted]
| halfmatthalfcat wrote:
| And most of the developments in Java, since 1.8, have been
| taking ideas from other languages (primarily Scala) to make
| the language better. Why is it ok for other languages to
| evolve but not Javascript?
| cphoover wrote:
| Scala is a perfect example of an overly complex bloated
| mess with so many foot-guns I can't even begin to count
| them.
|
| EDIT: I never said JS shouldn't evolve! JavaScript has
| evolved a ton! From better handling of asynchronous
| control-flow with promises and then async/await, to
| destructing, spreads, constant assignments, Map/Set
| objects, a number of other improvements I can't even
| begin to list. But none of these changes fundamentally
| changed JavaScript from being a dynamic weakly typed
| language.
| halfmatthalfcat wrote:
| I actually write a lot of Scala and beg to differ. The
| chances for bad developers to write bad code in Scala are
| higher than most other languages but what you might call
| foot-guns are actually elegant ways at solving complex
| problems.
|
| A lot of these "problems" (implicits, enums, etc) were
| solved with Scala 3 too. Another example of a language
| evolving and becoming better based on community feedback
| and thoughtful iteration.
| madeofpalk wrote:
| > but they did not change the fundamental characteristics
| of the language.
|
| FWIW, this proposal does not change the fundamental
| characteristics of javascript. It just adds a new comment
| syntax.
| kyberias wrote:
| But didn't he merely express his opinion about this?
| halfmatthalfcat wrote:
| I'm questioning their opinion, as we do on this site.
| riskable wrote:
| The only constant is change! The "don't make JavaScript into
| something it's not" ship sailed decades ago when AJAX was
| thrust upon the world.
|
| Besides, adding even _more_ complexity to the JS ecosystem at
| this point is like pouring a cup of water into the sea.
| Salgat wrote:
| This argument could be used for literally any improvement to
| JavaScript.
| [deleted]
| msie wrote:
| All this hand-wringing about types in JavaScript. If Chrome just
| put Dart into Chrome this question would have been settled years
| ago. Or at least provide some mechanism where any browser can be
| extended with a language processor that compiles the script into
| webasm. The ship for extending JS has sailed! Also as I
| understand it webasm is still crippled in the browser with
| respect to accessing the DOM. Fix it somebody!
| earthboundkid wrote:
| > If Chrome just put Dart into Chrome this question would have
| been settled years ago.
|
| Yes, but if you compare Dart to ES6, ES6 is a much nicer
| language, so we got lucky that they failed.
| kyle-rb wrote:
| Having used both a lot, I disagree that JS/ES6 is a nicer
| language. ES6 has a couple unique cool features, but also a
| decent amount of baggage from older JS.
|
| What major features does JS/ES6 have that Dart lacks?
| jupp0r wrote:
| You can totally compile Emscripten to wasm and do all of this
| as part of your application. No further browser support needed.
| ape4 wrote:
| Is there a way to say a variable can hold any type - eg for a log
| or print function.
| kevingadd wrote:
| That's the default
| Ndymium wrote:
| TypeScript itself has two types for this purpose: "any" and
| "unknown".
|
| "any" is the escape hatch and allows you to do anything with
| the variable. In essence it stops type checking entirely for
| that variable.
|
| "unknown" takes the opposite approach and doesn't let you do
| anything with the variable value (other than pass it along to
| other "unknown" accepting variables/functions) until you have
| asserted its actual type with type guards.
| montroser wrote:
| I would welcome this making its way into ECMAScript not because I
| like TypeScript, but because it's a drag to see TypeScript
| enthusiasts litter the JavaScript ecosystem with all of the piles
| of bolt-on TypeScript baggage.
|
| Forking projects just to add type definitions, or else mega repos
| like DefinitelyTyped madness; bringing all of the terrible
| complexity that we love to hate in Webpack/ESBuild/Rollup/etc
| back over to Node.js with server-side tsc; drive-by PRs to all my
| open source projects from inspired people trying to add types and
| me having to disappoint...
|
| I would gladly do without all of that. To me, I see the
| TypeScript tradeoff as coming with only marginal upside, in
| return for a large downside as described above. But, others
| _passionately_ disagree and see a huge upside, and that 's cool.
|
| In the end, I want us all to be happy, and I think this proposal
| would have hope getting us there. For this to be really spec'd
| and standardized would be a green light even for skeptics to
| invest in deeply learning and internalizing. To get to avoid yet
| another build-time compilation step would be bliss. To have us
| all back in on the same team would be glorious.
| dlojudice wrote:
| > To me, I see the TypeScript tradeoff as coming with only
| marginal upside, in return for a large downside as described
| above.
|
| I've coded using static and dynamic types. C#, Java, Ruby, JS,
| etc. 20 something years doing it, mainly for business
| applications (opposed to system or embedded). My personal
| opinion is that types bring an elusive value of control and
| maintainability. Confronted with legacy / spaghetti code,
| developers with less experience will bring lint, code style,
| some layers and ... types, as a way to solve the problem of
| long term maintainability.
|
| But unfortunately it does not bring that much value. Actually
| it brings costs to readability and unnecessary abstraction
| (interfaces, generics, etc) aka "fighting the compiler".
|
| A better test suite can have exponential more value on
| maintainability than types.
|
| > Static Typing was the most requested language feature in the
| State of JS survey in both 2020 and 2021. [1]
|
| So when I see static types been the most requested feature I
| wonder how many of them know how to create a good test suit or
| a good architecture. If its behind this feature request is a
| different pain to be solved.
|
| [1] https://github.com/giltayar/proposal-types-as-
| comments/#comm...
| eyelidlessness wrote:
| > Confronted with legacy / spaghetti code, developers with
| less experience will bring lint, code style, some layers and
| ... types, as a way to solve the problem of long term
| maintainability.
|
| > But unfortunately it does not bring that much value.
|
| If you mean _adding_ these things post-hoc, yes the value is
| limited. If you _start_ with types, and you embrace them as a
| design and testing tool, they can literally change the kind
| of code you write in the first place.
|
| People talk about how convoluted TS types are, but the
| reality is that's because they're describing convoluted JS.
| TS-first code tends to be a great deal more straightforward,
| because you define the interface before implementing it.
|
| In other words, if you start out with static types and think
| about them first, you've likely already got a good
| architecture and test suite.
| [deleted]
| azangru wrote:
| > A better test suite can have exponential more value on
| maintainability than types.
|
| A lot of ink has been spilled over this question. The
| conclusion is: no, tests do not and cannot replace types.
| Types, in themselves, provide a layer of tests that nobody,
| typically, would think of writing (what if a function is
| called with fewer arguments? what if it receives a different
| type of argument from what it was expecting?) and eliminate a
| whole class of superfluous tests that are checking for things
| that are better checked with types.
|
| The self-documenting property of types is remarkable. Jsdocs
| do not hold a candle to a typed codebase.
|
| Plus, refactoring. Even with tests I would be scared of large
| refactorings if I didn't have a type checker to also hold my
| hand. Of course, maybe I just don't know how to write code
| properly.
| kemiller2002 wrote:
| I always say that Types are not there for the truly expert
| programmer. They are there for the rest of us. It's a lot
| easier to pick up code and understand it when you at least
| have an inkling as to what a variable or parameters needs
| to have to function.
|
| Can interfaces be confusing, and generics become difficult
| to read? Yeah of course, but that's not really the problem
| of static type system, that's a problem with the code. I've
| generally found if you're doing something where you're
| thinking "this is just getting the way", you probably need
| to rethink your approach. Clear is always better than
| clever.
| chousuke wrote:
| _no-one_ is a truly expert programmer 100% of the time.
|
| Types catch a lot of stupid errors that anyone can make,
| regardless of skill level.
|
| They also localize guarantees. If your data has a type,
| you don't need to understand the full path it took to
| arrive in your function to be able to work with it. With
| dynamic types, you can only _hope_ that a value has the
| type you need unless you explicitly check every time.
| brimble wrote:
| > I always say that Types are not there for the truly
| expert programmer.
|
| Machine-verifiable documentation about the intended I/O
| of functions and shapes of structs and objects is _hugely
| fucking valuable_ to _everyone_. Your documentation isn
| 't good enough if it doesn't include that, so it may as
| well be in a format that a machine can read, validate,
| and use to help out _every single person_ who ever has to
| read or touch that code.
| vlovich123 wrote:
| I think "truly expert programmer" is hypothetical. I
| don't think I encounter many programmers that prefer to
| eschew typing unless it's a quick one-off script. Typing
| your code takes maybe 1-10% of the time it takes to right
| (if that). It provides far more value than tests. Just
| like Rust's ownership model in the type system provides
| much better results than C++'s implicit ownership model +
| tests.
| kemiller2002 wrote:
| That's exactly my point. There are very few people that
| are real experts, people that can see code and reason
| everything in their heads with little or no help. There
| really aren't any. Everyone thinks they are, but they
| aren't. Having types helps the rest of us understand what
| is going.
| danbruc wrote:
| _I always say that Types are not there for the truly
| expert programmer. They are there for the rest of us._
|
| I would say exactly the opposite - beginners pick
| languages without [much] typing because it is or at least
| it seems easier to get started. When you step out of toy
| program territory you will start to appreciate the value
| of types.
| azangru wrote:
| > beginners pick languages without [much] typing because
| it is or at least it seems easier to get started
|
| It's hard to tell whether the reason beginners pick
| languages is because they are not typed or because they
| are immediately practical (such as javascript, php or
| python). Christopher Allen's and Julie Moronuki's Haskell
| Programming from First Principles is targeted at complete
| beginners. Harvard's CS50, which starts with C (well,
| Scratch, technically; then C), also targets beginners.
|
| You don't see much lisp among beginners, despite the
| absence of type notation.
| b6dybuyv wrote:
| I guess there are differences between how static typing is
| implemented.
|
| I've been using Elm for the last 2 years and it's not that I
| don't fight the compiler, but I constantly use it to guide me
| while refactoring. Elm code is extremely readable and types
| (including Maybe, Result, etc.) just give so much confidence
| and control to the programmer. While working with an Elm code
| base, refactoring is a constant, joyful, safe act.
|
| It is true that in many cases good tests help. However often
| when I work with Python (using type hints), I need to write a
| unit test just to ensure a contract that I could explicity
| state using types in Elm. It doesn't feel right.
| zarzavat wrote:
| Unit tests aren't a replacement for static types. Tests
| aren't machine readable so you lose all those nice IDE
| refactoring features and have to manually keep them up to
| date. Also running a test suite takes time, it takes a lot
| longer to run a test suite than it does to get live
| typecheck, which means you cannot use tests while you are
| editing. And you probably don't want to clog up your test
| suite with endless "x is a Y" tests.
|
| In general dynamic types incentivize the status quo and
| promote codebase ossification, and somewhat ironically make
| rapid prototyping harder.
| yboris wrote:
| You should try _Vite_ - https://vitejs.dev/ - start a
| _TypeScript_ project in under a minute - no annoying Webpack
| configuration needed.
| seniorsassycat wrote:
| Would you use type comments in your projects? Would you like
| pull requests adding them, or fixing them? What if the
| typescript checker and another checker have different semantics
| and you have fans fighting between `number` and `u8`?
| keawade wrote:
| I disagree that TypeScript comes with only a marginal upside.
| In my experience TypeScript projects are much more approachable
| for contributors.
|
| For example, I once was debugging an issue in a JS framework
| and while I knew what was wrong and where I could fix it I
| didn't have any idea what existing tools I had available in
| that context to fix it. Having type definitions would have made
| that work much simpler by increasing the accessibility of the
| code base.
|
| It's experiences like this that have convinced me that if I'm
| writing code that any one will possibly read or need to modify
| later (including if it is just me) then I should be writing
| TypeScript instead of JavaScript. Or, more generally, that it
| should be typed.
| lostcolony wrote:
| Your basic disagreement here feels like it would be obviated
| by the parents "I hope this makes its way into the ECMAscript
| spec"? I.e., you would get typing without any of the tooling
| Typescript requires; the parent's point was JS + typing would
| be a pure benefit compared to Typescript, and you've said
| nothing to disagree with that.
|
| So while you technically are disagreeing with the parent,
| it's on the smallest of points, and completely disregarding
| the main one the parent offered (which, fair enough, but
| wanted to point that out)
| datavirtue wrote:
| Raw JavaScript in any production app is an abomination.
| Constant issues because one of the variables had a errant
| character. Countless bugs because of the same or it not being
| defined. On top of all that how in the hell am I supposed to
| know what a parameter or return value is supposed to look
| like? I have other things to worry about. I think these type
| annotations would make everyone happy. The IDE can navigate
| and inform but the objects will still need to be defined
| somewhere. I assume we can define a custom type with these
| annotations?
| NoWizards wrote:
| I couldn't disagree more with you... All i see when working
| with different levels of experienced contributors is
| param:any any[]. Even more when you want to interact directly
| with DOM instead of using an opinionated framework.
| EMM_386 wrote:
| This is why "no-explicit-any" should be enforced in every
| project.
|
| https://github.com/typescript-eslint/typescript-
| eslint/blob/...
| david422 wrote:
| This is either just code that is too complicated or devs
| that aren't doing a good job of type hinting.
|
| Everytime there is an any, it means that each developer
| reading or modifying this code has to find it out for
| themselves - _every single time_. Why not just type hint it
| correctly in the first place.
| danielvaughn wrote:
| I'm one of those `any` developers, and can attest to the
| first scenario. Had a client ask me to fix a bug in a
| repo that I wasn't familiar with. I spin it up, start
| looking through the code, and it's this massively over-
| engineered beast. 27K lines of Angular code to support a
| 2 page SPA that's basically just a note taking app.
|
| Anyways, it's TS, and I don't know TS but I know how
| typing works so I can make my way around. I need to alter
| an interface to fix the bug, but with all the code it's
| very difficult to tell whether the change will break
| something either in the compiler or at runtime. To add on
| top of all that, the client needed the change to go out
| that day.
|
| So guess what's going to happen? I'm using fucking `any`
| and I don't care.
|
| Ultimately, this is why I don't like TS. I think it's a
| great idea, but if you look at all the energy that has
| been spent moving code over to TS from JS, and all the
| type definitions that were written into existing NPM
| packages, I have to ask myself why we don't just pursue
| making types native to JS? I don't want to write a
| secondary language that compiles to JS.
| Chyzwar wrote:
| > Anyways, it's TS, and I don't know TS but I know how
| typing works so I can make my way around. I need to alter
| an interface to fix the bug, but with all the code it's
| very difficult to tell whether the change will break
| something either in the compiler or at runtime. To add on
| top of all that, the client needed the change to go out
| that day.
|
| It is massively easier to make change to large TS
| codebase. Just because you never bothered to learn TS and
| you rush feature at cost to maintenance, do not mean it
| is TS fault.
|
| > Ultimately, this is why I don't like TS. I think it's a
| great idea, but if you look at all the energy that has
| been spent moving code over to TS from JS, and all the
| type definitions that were written into existing NPM
| packages, I have to ask myself why we don't just pursue
| making types native to JS? I don't want to write a
| secondary language that compiles to JS.
|
| Because native types would create even more fragmentation
| while being less powerful than TS. JS was never intended
| for application development, we either embrace compilers
| or move away from language that have pathetic standard
| library, dynamic and complex type coercion rules, no
| stable module system, lack of strong leadership and
| legacy of supporting IE.
| j-krieger wrote:
| You're blaming the active misuse of a tool on the tool
| itself.
| pwdisswordfish9 wrote:
| What does "while I knew what was wrong and where I could fix
| it I didn't have any idea what existing tools I had available
| in that context to fix it" mean?
| shadowgovt wrote:
| You and OP are both right, because it really depends on what
| you're doing.
|
| At the scale I operate, it would be corporate suicide to try
| and write this code in straight JavaScript without type
| support. But for smaller teams, more focused teams, and teams
| that use a heavy testing discipline or enforced naming
| conventions that supplement the lack of static typing, it's
| not a problem.
| spion wrote:
| This isn't going to fix those issues.
|
| Those issues aren't due to tsc. They're due to an ecosystem
| which refuses to recognize the realities of compilation and add
| first class support for it. Its also due to an ecosystem
| willing to break compatibility (and not just backward
| compatibility but compatibility to other tools) at the drop of
| a hat.
|
| For example, the main reason I've seen why people began using
| bundlers for node recently is the fact that a lot of modules
| transitioned to pure ES6 without CommonJS support. In most
| projects, this means you have to use a bundler to be able to
| import those modules, or switch your entire codebase to ES6
| (which is non-trivial due to changes in import path semantics).
|
| If it weren't for the above, you could just run `tsc` to get a
| `.js` file in `dist` for every `.ts.` file in `src` and run
| node on those.
| afavour wrote:
| > They're due to an ecosystem which refuses to recoginze the
| realities of compilation and add first class support for it.
|
| IMO this is the correct path. Compilation should result in
| WebAssembly and it seems like the tooling is finally getting
| there.
| jeremyjh wrote:
| I do not think that is a goal of either project; I'm not
| even aware of a POC JavaScript to WASM compiler.
| AssemblyScript couldn't work without strong typing
| semantics and doesn't support many typescript features.
| dmitriid wrote:
| > Compilation should result in WebAssembly
|
| It... It really shouldn't. Especially not if the target is
| the browser as the bridge between WebAssembly and the rest
| of the browser is still "just pass these arrays of integers
| around".
| spion wrote:
| Of course, using a bundler means you'll face several other
| unpleasant realities. Like - what about
| tests, how do they run - source maps support in node
| being 3rd party and unbearably slow for any medium sized
| project - edit: this has been fixed somewhat
| recently https://nodejs.medium.com/source-maps-in-node-
| js-482872b56116 - only the 3rd party bit, not the
| slowness bit https://github.com/nodejs/node/issues/41541
| - also applicable when not bundling, albiet fewer reprcutions
| to turning off source maps - poor native (C++) modules
| support in bundlers - modules with really dynamic
| `require` statements being supported at varying levels by
| varying bundlers
| afavour wrote:
| For what it's worth I agree with you: after spending years
| battling with Babel and all that nonsense it's been amazing to
| be able to just write ESM JS and have it run both on Node and
| in the browser.
|
| The real lightbulb moment for me was using JSDoc annotations
| with TypeScript types in JS files. It definitely isn't as
| graceful as JS itself but it's not _that_ big of a deal, plus
| it encourages you to add comments. And any TypeScript editor
| will parse the code as if it's TS, provide autocomplete, type
| checking etc etc as required.
| ht85 wrote:
| Do you write a lot of library code? I'm genuinely wondering in
| what kind of environment you would get "marginal upside" from
| having a good type system.
| riskable wrote:
| I've been coding JavaScript for many, many years. I've
| _never_ encountered a situation where the lack of typing bit
| me in the ass. Not even once!
|
| Having said that, it might be because when I'm writing
| JavaScript _it 's just me_. Normally I'm the sole developer.
| So _of course_ I know my own stuff! I 'm not going to
| experience an error passing the wrong type to a function
| because I _literally_ wrote all the functions myself. I even
| have enormous libraries of JS code that I use in my personal
| and work projects where I wrote everything.
|
| This developer is probably in the same sort of situation.
| Type errors are the kind of thing you run into when you're
| working with large codebases that were written by lots of
| different people. It's not the type of thing you experience
| with your own code.
|
| I've also written loads of Python and never experienced an
| error where the wrong type gets passed to a function (even
| working in a team). For years I couldn't even fathom how
| static typing would be a benefit other than maybe it can
| speed things up by giving a compiler/interpreter the ability
| to optimize things. Then at work--after nearly 20 years of
| Python--we finally had an issue where the wrong type was
| passed (float was inadvertently rounded because the function
| was made for integers and it wasn't obvious). It was caught
| before the code was sent to production (and it wouldn't have
| been a huge deal anyway) and I finally had a real-world
| situation where type annotations would've prevented an error.
|
| It's just not something that happens very often. It's the
| type of thing that creeps up on you for sure but it's not a
| common, every day occurrence. Type-related bugs are really
| super obscure. They're far, far rarer than type-obsessed
| developers make them out to be.
| [deleted]
| TN1ck wrote:
| > I've never encountered a situation where the lack of
| typing bit me in the ass
|
| Quite the claim! For me the moment I never want to look
| back to is to refactor a substantial part of the
| architecture of a JS app with more than 20k lines of code
| (And I did write most of it myself). If you don't do large
| scale refactorings or work mostly on smaller apps, then
| indeed, types won't be much of an issue.
|
| But you should become aware about how often you see
| "undefined is not an object" and similar, that's a type
| error that is almost gone when using TypeScript.
| Aldo_MX wrote:
| > I've never encountered a situation where the lack of
| typing bit me in the ass. Not even once!
|
| Maybe you just see the "cannot find property of undefined"
| type of errors as usual business, but this is the #1 kind
| of error I see in the logs of big applications, and
| TypeScript really helps to mitigate them.
| slewis wrote:
| Refactoring is much easier in a well typed codebase.
|
| When refactoring is easier, it happens more often, which
| means code quality and readability are higher, which
| reduces the likelihood of every other kind of error.
| pwdisswordfish9 wrote:
| > I've been coding JavaScript for many, many years. I've
| never encountered a situation where the lack of typing bit
| me in the ass. Not even once!
|
| Okay, well, here's an example of it leading to a CVE:
| https://www.mozilla.org/en-
| US/security/advisories/mfsa2012-7...
|
| The way-and-how of it is that the then-new devtools team
| working on the then-new JS console lost track of what
| objects they were passing into a polymorphic function,
| which resulted in untrusted, content-supplied objects being
| treated the same as DOM nodes that were supposed to
| originate from within the JS console implementation itself
| (for its UI), which resulted in browser-level privileges
| being given to content authors of ordinary web pages.
| danny_taco wrote:
| > Having said that, it might be because when I'm writing
| JavaScript it's just me.
|
| Well, you don't need types because you only look at your
| own code. The advantage of having my IDE tell me what to
| expect when I'm refactoring a piece of code someone else
| wrote is a few orders of magnitude more useful and
| informative than having to jump through various functions
| and files to understand what's happening.
|
| Years of writing code do not equate to proficiency and
| expertise. You may have been writing code for many years
| but I would go so far as to assume that you experience is
| actually very limited.
| matthewmacleod wrote:
| _I 've never encountered a situation where the lack of
| typing bit me in the ass. Not even once!_
|
| You absolutely have. At some point in your career, you've
| accidentally got the arguments to a function in the wrong
| order and had to debug what was happening. Or ended up with
| a `null` where you didn't expect it. Or used an invalid
| value for a string enumeration, made an inobvious typo in a
| field name of an options object, accidentally added
| brackets and called a function when you meant to pass a
| reference to it, failed to deal with the return type of a
| promise, or any number of other examples of mistakes that
| everybody makes all of the time.
|
| These are all examples of common errors that can be caught
| by a type checker. It's totally valid to debate whether the
| cost of a type system is worth paying in the context of
| different environments, but if you're starting from the
| not-really-credible position of "I have never made a type
| error, ever", then it suggests that you're working with a
| set of faulty assumptions about what they offer.
|
| (For my own part, as a Javascript user of some 20+ years
| now, picking up TypeScript has been the best boost to
| productivity and code quality I've had in my career. It's
| got to the point that I'd just point-blank refuse to work
| with a Javascript codebase now, because it's not worth it.)
| sanitycheck wrote:
| I've got (too many) years of JS experience too, and I
| started a project in TS last November to see what the fuss
| is all about.
|
| I have to say I'm a convert. Not so much because it's
| catching a ton of errors for me, more that it brings such a
| massive improvement in IDE autocomplete behaviour.
| TypeScript in VS Code starts to feel almost like C# in
| 'real' visual studio. (The errors it does catch in my code
| are usually potential null references which would
| _probably_ have been fine, but I 'm sure it's avoided a few
| bugs.)
|
| The most interesting thing for me is that it allows me to
| feel safe doing things I would avoid in plain JS, like
| using literal union types (which would be magic
| numbers/strings without the typing).
|
| I still write JS for small stuff, but when you're next
| starting a new project that'll go over a few thousand lines
| of code I definitely recommend giving it a try.
| claytongulick wrote:
| Have you tried type annotations in jsdoc?
|
| Inline /* @type */ statements and jsdoc type declarations
| coupled with .d.ts files for complex types achieves the
| same thing for me without the extra compilation step.
| LAC-Tech wrote:
| Yeah that's what I do as well. I actually find TS uglier
| now. It ends up being full of really long lines like:
| const myFunction(a: Long<TypeName>, b:
| Another<LongType>): FooBar
| discreteevent wrote:
| Agreed on both counts. For me types are not very useful for
| catching errors. What they are extremely useful for is
| documentation and navigation of code. Primarily other
| people's code of course but also for my own code once a
| certain amount of time has passed.
| pier25 wrote:
| This reflects my experience when working alone, but when
| working on a team the experience is drastically different.
| jakelazaroff wrote:
| It's never "just you", though: it's present you and past
| you. When I come back to code I wrote months or years ago,
| static types are super helpful as I try to remember what
| the heck I was doing. They're at least as valuable for
| documentation as they are for catching errors.
| Turing_Machine wrote:
| I've often speculated that strong typing only seems like a
| win to the kind of developer who makes a lot of type
| errors, and a waste of time to those who don't (which
| doesn't mean they don't make other errors, of course).
| Aldo_MX wrote:
| Or to the kind of developer that works in a big team for
| a big project.
| balefrost wrote:
| Alternatively, perhaps advocates of static typing simply
| see a larger variety of errors as type errors. In JS, if
| I typo a key of an object (e.g. `foo.excute()` instead of
| `foo.execute()`), I would call that a type error... or at
| least an error that could be caught by a static type
| system.
| david422 wrote:
| > like a win to the kind of developer who makes a lot of
| type errors
|
| Or just to the developer that likes to offload that
| cognitive load to their tools.
|
| Why hold that in my head when the IDE can keep track of
| it for me? Why memorize every single attribute name when
| the IDE can autocomplete it for me? etc.
| jeremyjh wrote:
| I've speculated that a lot of developers don't recognize
| type errors for what they are.
| markstos wrote:
| Even developers who "don't make type errors" have to deal
| with bad and unexpected data, which may be in a different
| type.
|
| If you don't validate that all untrusted data is off the
| appropriate type, security vulns or "garbage in - garbage
| out" bugs can result.
|
| Then if you do manually validate the types of untrusted
| data, then you have to wonder of having built-in type
| support might be faster.
|
| "Bad data" doesn't just come from the outside world. As
| teams start to use shared libraries written by other
| people, it's also valuable adds guards to ensure that
| shared functions are being called with the expected
| types.
|
| My own experience is that it doesn't feel like type-
| related bugs come up often on my team, but when they do
| the problems they cause can be bad enough to make us wish
| more of our code had been ported to TypeScript.
|
| Classic example: a CSV parser parsed numbers as strings
| because a particular spreadsheet quoted the number
| column. Result: "2"+"2" = "22"
| rattlesnakedave wrote:
| bringing in tooling to eliminate an entire class of
| potential errors sounds sounds like an easy decision to
| me.
| Turing_Machine wrote:
| Not if the errors are rare and the "tooling" slows down
| development.
| moron4hire wrote:
| Huh? Rebundling my 150kloc project takes about 2 seconds
| after I save a file and has already reloaded by the time
| I get to my browser window.
| frosted-flakes wrote:
| Why do you think it would slow down development? Serious
| question.
| Turing_Machine wrote:
| Those type annotations don't just magically appear. You
| have to write them.
|
| Yeah, they're optional, but if you don't write them,
| there's no point in using TypeScript in the first place.
| jeremyjh wrote:
| Types are inferred even when you don't specify them; if
| you are using a library that has type specifications a
| lot of your code is going to be well-typed just as a
| consequence of using that library.
| scns wrote:
| I was shocked how slow tsc is. Got spoiled by using
| ReasonML before.
| IshKebab wrote:
| You're wrong - the benefits of Typescript are huge, and the
| size of the hoops people are willing to jump through to get
| those benefits should indicate how big they are.
|
| I do agree it would be nice to simplify some of the tooling
| though.
| kingdomcome50 wrote:
| Found the guy who hasn't used Typescript beyond tinkering!
|
| I kid... mostly. But in all honesty I have found very few
| instances of developers who have worked significantly with both
| languages and have come to the conclusion that TS has a
| marginal upside (though maybe they will come out in defense
| here!).
| claytongulick wrote:
| <raises hand>
|
| I've worked extensively with both.
|
| I find that ts normally brings a downside, actually. In one
| project I maintain, a solid 30% of the code is nothing but ts
| stuff.
|
| It makes maintaining the code base excruciating.
|
| Small changes between versions of ts or .d.ts files have
| caused hundreds of errors. A concrete example of this is the
| change in mongo driver that forced "new ObjectId()" instead
| of "ObjectId()" though functionally there was no difference.
|
| I see massive bizarre and difficult to grok type declarations
| that grow in excruciatingly byzantine complexity just to
| satisfy the compiler for non-trivial flexible function
| definitions.
|
| I see painful compilation times, a beefy laptop's CPU getting
| pegged and the fan whining while trying to do even minor
| updates.
|
| Try to do a build while on a video conference? I see two to
| three minute build times.
|
| I see a series of nonsense stories in sprints that are
| nothing more than activity over achievement. They don't drive
| product functionality, they are a bunch of make-work to
| satisfy the developer asthetic and the compiler.
|
| The nightmare of "compiled" NodeJS production support is a
| dystopian hellscape that I'm forced to endure every day
| because of NestJS and typescript. And nothing in that has
| done _anything_ to increase code quality or reduce bugs from
| the crappy offshore team that wrote it.
|
| Clearly, I'm not a fan.
|
| That being said, I think type comments in jsdoc are a honking
| good idea.
|
| I use inline /* @type */ declarations and .d.ts files
| liberally.
|
| If we could add to jsdoc the ability to document types and
| purpose of arbitrary js objects inline, at definition time,
| instead of an external .d.ts file, I'd be a happy guy.
|
| An example of this would be sequelize schema defs, or
| mongoose schema defs, where I can have all my jsdoc code
| comments and type definitions in the same place as the code.
|
| All that being said, I like the idea of this proposal.
| Especially if it could solve the schema definition issue
| above.
|
| I think optional typing is a good idea to bake directly into
| the language. I thought AS3 did a great job of this.
|
| I even think it would be great to have an equivalent of
| "strict" that would enforce typing at the module level to
| enable straightforward AOT / wasm interop (I know it doesn't
| solve the GC issue).
|
| My beef is mostly with the extra compilation step and
| needless complexity of ts.
|
| If we had simple (no generics) opt-in typing that was
| natively supported by the engine, I think it would enhance
| the language overall, like type hints have done for python.
| forrest2 wrote:
| > find that ts normally brings a downside, actually. In one
| project I maintain, a solid 30% of the code is nothing but
| ts stuff.
|
| That 30% number is almost certainly why. The experience
| with codebases with 100% type coverage / tight types have
| been glorious, and the ones with partial coverage / plain
| js files / lots of "as any" / lack of strict compiler flags
| https://www.typescriptlang.org/docs/handbook/compiler-
| option... have been miserable and a waste of time. Can't
| stress the strict flags enough.
|
| One of the "pros" of typescript is its gradual typing, but
| I think it's a trap and forces poor impressions on people.
|
| One of those reasons is how `any` works. In gradual
| adoption, lots of stuff turns into `any`. `any` is a
| contagious/viral construct where anything it touches could
| become `any`. And then you spiral out of control and the
| whole codebase gets nothing from typescript but gets all
| the operational overhead.
|
| If your browser doesn't support text fragments, can
| cmd/ctrl+f for "contagious" and/or "gradual"
| https://www.typescriptlang.org/docs/handbook/typescript-
| in-5...
| kingdomcome50 wrote:
| > I see massive bizarre and difficult to grok type
| declarations that grow in excruciatingly byzantine
| complexity just to satisfy the compiler for non-trivial
| flexible function definitions.
|
| Is this better or worse than no type definition? Whether or
| not a type is _defined_ it is still _consumed_. I can
| totally understand that sometimes types can get a bit
| unwieldy, but those are the _exact_ scenarios that save
| future-you from introducing a bug because you didn 't know
| what a variable is (and is not). At the very least it may
| be an indicator of poor design/code smell when the above
| occurs.
|
| I hear you on compilation/build process woes. That's the
| fairest criticism against TypeScript IMO (though it's a
| fairly weak argument as well).
|
| Most of your other critiques aren't really levied against
| TypeScript, rather, your work environment (not that it
| makes working with TS any less painful!).
| fifticon wrote:
| I abandoned my attempts to make larger projects in pure
| javascript. I happily write larger projects in typescript.
| Typescript makes javascript feasible, usable for me.
| Waterluvian wrote:
| I used to feel the same way about TypeScript until I really
| gave it a try one season.
|
| I feel like I was crippling myself for years, being an inferior
| developer wasting so much time with the things that TS guards
| against, documents, and autocompletes for.
|
| I support any formalization of TypeScript that further tidies
| up the "add-on" nature of it. But to be honest, it's really
| quite fine already.
| edgyquant wrote:
| I work at a place that is full stack typescript with a legacy
| app that is Js/react (the kind of stuff I was writing in
| 2017-2018.) After using typescript and going back to fix
| issues on the legacy codebase I now understand why the
| industry adopted Ts
| simion314 wrote:
| Just finished debugging one of those ugly issues where it works
| fine for the developer but for some other person things are
| broken. it was a piece of code that assigned an Number to a
| property that should have been an object(the dev confused the
| property name). Because the project is complex and there is a
| lot of network requests and stuff running in different order
| depending on the user internet the bug did not happened to
| everybody. You could work aroudn this using setters and doing
| runtime checks but I have a feeling people that don't like
| types also don't like getter and setter.
| markstos wrote:
| Are you saying that if there had been type checking, this
| issue would have been much easier to detect and prevent?
| simion314 wrote:
| Yes a line like
|
| stuff.anAccountTypeField = obj.aNumberValue;
|
| Would cause an error in a typed language , something like
| incompatible type Number and type Account.
|
| Maybe you were confused by my commnet about the network
| requests and different order of running code, this caused
| the error not to happen most of the time so it never
| crashed on developer machine.
| jaywalk wrote:
| How could it not be? With type checking, you wouldn't be
| able to set a variable to a number when it's supposed to be
| an object.
| mbf wrote:
| Erasable types are good enough with source mapping. TypeScript
| workflows are fine. ECMAScript really doesn't need to absorb a
| TypeScript syntax. It's not necessary to keep bloating the
| runtime with a feature only useful to the developer.
| eminence32 wrote:
| If the runtime is going to be fully ignoring these type
| annotations, what type of "bloat" are you worried about?
| windows2020 wrote:
| New syntax and concepts.
| xigoi wrote:
| Larger file sizes.
| cphoover wrote:
| larger downloads, larger syntax
| Aldo_MX wrote:
| type annotations would get removed during minification,
| downloads would be the same
| ravenstine wrote:
| I'd be more optimistic about official type annotations for
| JavaScript if said typing was less like the particularly unique
| syntax of TypeScript and more like that which already exists in
| C-family languages. For instance, in Typescript, we can do this:
|
| ---
|
| const user: User = { ...
|
| };
|
| ---
|
| Why couldn't this be more like C rather than this weird
| conflation with the existing colon token?
|
| ---
|
| const User user = { ...
|
| };
|
| ---
|
| That might seem not as pleasing to those familiar with
| Typescript, but it's much closer to other existing syntaxes
| (meaning less of a learning curve coming from Java or C).
|
| Same with function definitions:
|
| ---
|
| function foo (bar: string, baz: boolean): Qux {
| ...
|
| }
|
| ---
|
| Versus:
|
| ---
|
| Qux function foo (string bar, bool baz) { ...
|
| }
|
| ---
|
| I find the latter much more familiar than Typescript and less
| confusing. It's also slightly less verbose.
| danielvaughn wrote:
| Yes exactly. There must be some good reason why TS chose the
| syntax they did, because a lot of it feels very old-school-
| java.
| stasm wrote:
| Type inference is one good reason. Similar syntax exists in a
| few modern languages, too: e.g. Rust and Swift. In languages
| with type inference it can be convenient that type
| annotations are in the postfix position relative to variable
| names: let user = new User(); let
| user: User = new User();
| Etheryte wrote:
| My completely subjective guess is that it might be to avoid
| ambiguity around reserved keywords. For example, the `void`
| keyword [0]: void function () { return 42; }();
| // returns undefined
|
| It's not something you would usually use in your code, but many
| Javascript minimizers make heavy use of it, and Typescript must
| know how to handle any valid Javascript without ambiguity.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| S1ngleM4lt wrote:
| That seems to be mostly just a matter of taste, but is
| definitely off putting when coming from other languages.
| Interestingly other recent languages like rust, zig, and go
| follow a similar convention to type script. Go has a brief
| explanation of why they went with this approach [0] so I'd be
| curious if other langs have documented their decisions.
|
| [0] https://go.dev/doc/faq#declarations_backwards
| [deleted]
| orif wrote:
| Actually, I would prefer a C/C++ dialect in TypeScript's type
| notation. Parsing time/complexity would reduce drastically, and
| would allow type inference.
| seniorsassycat wrote:
| : type syntax will be more familiar to rust, kotlin, and
| typescript devs. Why is c relevant?
|
| The name is usually more important than the type so I like that
| typescript puts it first.
| kderbyma wrote:
| then we would have another type system....no just stick with
| typescript or none at all...
| ravenstine wrote:
| Well... yeah, I don't actually advocate for another type
| system, but more that if we have any type system at all for
| JavaScript then asking why we're going with one that
| overloads the colon token when it's already been sufficiently
| overloaded in the first place. Typescript already is what it
| is, and I think we should just stick with it, but if we are
| going to get yet another type annotation system then perhaps
| it might as well not be as novel as Typescript if there's a
| benefit.
| chrismorgan wrote:
| > _Do you_ write _minified code today? Definitely not._
|
| False. I greatly enjoy writing minified code; not only is such
| golfing fun, you can regularly achieve _drastically_ smaller
| results.
|
| Automated JavaScript minifiers are a useful tool, but they all
| miss significant opportunities in even simple things like code
| reordering, because JavaScript's semantics just don't support
| that sort of thing.
|
| It puzzles me, given how much effort has gone into making a slow
| language run faster than it has any right to, how little effort
| has gone into making any kind of optimising compiler, for both
| runtime performance and bundle size. GCC and LLVM put _insane_
| amounts of effort into optimising things, which work best when
| paired with something like Rust's ownership model (... so long as
| rustc isn't currently being conservative after having uncovered
| yet another bug in LLVM's noalias!).
|
| Meanwhile in JavaScript land, the main tool used is Terser, which
| is both simple and simplistic. It does very little in the way of
| optimisation, because it basically doesn't seek to understand the
| code, and so can't apply perform any operations that could change
| the semantics in such-and-such a situation that (if you tried
| harder) provably cannot occur. Long ago, Google made Closure
| Compiler, and it's a good deal better, so long as you're willing
| to humour the idiosyncrasies it requires in advanced
| optimisations mode, but it's still far, _far_ short of what GCC
| /LLVM can do. A few years ago, Facebook toyed with symbolic
| execution in Prepack, an approach with potential for building
| good tooling, but they gave up on it before it reached the point
| of being useful.
|
| Then consider other popular tools in the ecosystem: Babel is
| stupid (by which I mean that it doesn't attempt to _understand_
| the code) and generates significantly bloated code because it's
| seeking to match semantics as perfectly as possible without
| questioning whether it _needs_ to. Buble demonstrated a different
| approach, where you say "eh, who cares about exact semantics,
| let's just note down the caveats and generate simpler, smaller
| and faster code". (For both of these tools, I'm talking about the
| old ES6+ - ES5 compilations, which are obsolete now; I'm actually
| not sure what people use Babel for now, and how much this
| judgement applies.) And for bundling, webpack, which... ugh, the
| code it generates is just wilfully inefficient. Rollup
| demonstrated a different approach, where you actually care about
| minimising code because it makes it smaller and faster.
|
| So returning to the original point: I certainly write minified
| code sometimes. I have a few <script> blocks on my site (one on
| all pages, others on pages that use them), and those are hand-
| written, sometimes with an automated minifier's help to rename
| variables for slightly better compression, but other than that,
| all manual. I've got a project I've been working on for doing DOM
| stuff off-thread with a tiny VM on the main thread to execute
| byte code, and in that I'm working the same way: I know I have to
| have a little main-thread JavaScript, but when automated
| minification can reduce my 5KB of nicely-factored code to 1934
| bytes (~1185 gzipped), but manual minification can reduce it to
| 928 bytes (~417 gzipped) that will also run faster due to
| eliminating abstractions, well, I know which approach I'm going
| with. My way of working in these sorts of projects is that I
| maintain expanded and minified source codes simultaneously, and
| apply any changes to both.
|
| You might say "why not work in semi-minified code, applying
| whatever minifying transformations you have _except_ for variable
| naming and whitespace, then use an automated tool for that part?"
| and you would have a bit of a point, except that then I'd need to
| worry about naming things, which can be complicated by reusing
| variables. Eh. I enjoy it. It's mostly fun.
|
| A byte here, a byte there... ah, fond memories of my Casio
| CFX-9850GB Plus Color calculator too on which I spent hundreds of
| hours in my school days, often golfing my programs to save one or
| two bytes here or there, since I normally had at most a few
| kilobytes of storage space spare. I discovered at one point that
| they kind of had two instruction-ending characters, a line break,
| which was _two_ bytes, and a sort of a character, which was
| _one_. Thereafter, all my source code was on one line. Those
| things were quite astonishing in their battery life, too; I would
| have racked up over 1,000 hours on it, but only went through four
| sets of four AA batteries. Meanwhile the newer model almost
| everyone else used, while about 4-10 times as fast depending on
| the operation, lacked colour and chewed through batteries around
| 40 times as fast. Then came CAS calculators, probably using 40
| times as much power again...
|
| I'm rambling, aren't I?
| cletus wrote:
| So this is one area where I think TypeScript made a mistake: it
| added syntax that wasn't compatible with Javascript. This means
| you couldn't seamlessly support JS and TS with the same repo.
|
| Wouldn't comments be a better solution to this given the legacy?
|
| Here's what I think the type system should allow at a minimum:
|
| 1. Scalar types (number, string)
|
| 2. Common union types (eg something that could be a number or a
| string)
|
| 3. This is a big one: nullability should be part of the type
| system;
|
| 4. Object typing that includes mandatory and optional keys and
| their legal types;
|
| 5. Array types (generics);
|
| 6. Dictionary types (generics); and
|
| 7. An unknown type (like "mixed" in Hack).
|
| Part of this is you need the option of preserving types at
| runtime and doing runtime type enforcement. This should be
| optional to generate a "debug" build and can be stripped out. You
| should be able to assert types as well as turn on automatic type
| checking on entry and exit to function calls as a method of
| finding bugs.
|
| These errors should also be available as a warning (ie print to
| console.log) or an error (fatal).
|
| Lastly, you should be able to easily write a type error handler
| to capture such violations.
| tomjen3 wrote:
| You can easily work with both. Disable strict in the options
| (that is why it is there), then replace .js with .ts and it
| still works. Except now maybe you get some errors because of
| type inference that detects things like calling .toFixed on a
| string.
| azangru wrote:
| > you couldn't seamlessly support JS and TS with the same repo
|
| You could ... use a bundler, which would handle both js and ts
| files quite seamlessly.
| overgard wrote:
| I don't understand what this solves... source maps make debugging
| the compiled typescript easy in a web browser, and on the server
| you can use things like ts-node to run the typescript without
| compiling. Having type "comments" seems like way less utility
| compared to what typescript offers
| spiffytech wrote:
| > I don't understand what this solves... source maps make
| debugging the compiled typescript easy in a web browser, and on
| the server you can use things like ts-node to run the
| typescript without compiling.
|
| As much as I love TS, integrating it into build or dev
| pipelines has repeatedly caused big headaches. Multi-stage
| source maps don't always get wired up correctly. Tools may
| understand TS or ESM, but not both.
|
| I would very much like this proposal to get ratified, so that
| my pipelines can become simpler and more robust, and so I don't
| need TS flavors of normal JS tools.
|
| > Having type "comments" seems like way less utility compared
| to what typescript offers
|
| The proposal isn't taking away anything that TypeScript offers.
| It lets TypeScript layer its value (types enforcement) on top
| of plain .js files, without getting in between the source code
| and tools / runtimes.
| hajile wrote:
| You still aren't going to ship all those unnecessary types in
| your production app, so you'll be creating a complicated
| pipeline anyway. The big difference here would be that your
| pipelines will be radically different, so you wouldn't know
| about random breakages in the development pipeline until you
| deployed to production.
|
| More importantly, this doesn't add all of TS, so you'd still
| have to run those tools and nothing changes except that JS is
| now locked in to a syntax that may or may not be the best for
| an actual type system in the future.
| webspaceadam wrote:
| when i understood it correct it will enable you to use
| typescript-ish language features in standard node projects
| without a compilation step. which is pretty cool for small to
| medium size projects
| [deleted]
| seniorsassycat wrote:
| Microsoft should add script/typescript support to edge with a
| checkTypes flag /s
| l30n4da5 wrote:
| Im curious what a proposal like this means for other compile-to-
| js languages. I'm assuming it really won't make any difference to
| those, but languages like ReScript, PureScript, or Elm, for
| example, all are statically typed and compile to js in the end.
| madeofpalk wrote:
| > _What about compatibility with ReasonML, PureScript, and
| other statically typed languages that compile to JavaScript?_
|
| > While these languages compile to JavaScript, and have static
| typing, they are not supersets of JavaScript, and thus are not
| relevant to this proposal.
|
| https://github.com/giltayar/proposal-types-as-comments/#what...
| jakelazaroff wrote:
| I don't think it means anything, since the JS parser will just
| ignore the type annotations.
| l30n4da5 wrote:
| that was my thought, as well.
|
| curious to see, though, if popularity of other statically-
| typed compile-to-js languages will suffer if TypeScript
| syntax is adopted into the js spec (presumably causing
| TypeScript to gobble up more market-share).
| phil294 wrote:
| CoffeeScript, for one, is already at least talking about
| emitting TS [1]. These kinds of changes are vigorously debated
| though, e.g. [2]. Once ECMA type comments get to stage 4, CS
| would probably also adapt the new syntax. Other compile-to-js
| languages that _already_ ship with their own type system like
| Dart will probably be indifferent to the debated proposal.
|
| [1] https://github.com/jashkenas/coffeescript/issues/5307 [2]
| https://github.com/jashkenas/coffeescript/issues/5394
| suydyswjuddyy wrote:
| suydyswjuddyy wrote:
| rd_police wrote:
| wolfadex wrote:
| Everyone keeps saying variations of "It would become possible to
| program (e.g.) TypeScript without compiling the source code." but
| that's not true. This proposal is only a subset of TypeScript,
| meaning that all of the existing TS infrastructure would remain
| and still be used. All this does is further bloat the ECAMScript
| for no gain.
| ARandumGuy wrote:
| This was my first thought as well, but I do think it could
| still be useful, even if not all TypeScript can be run as pure
| JavaScript. There's a lot of use cases where some type hinting
| would be useful, but the full feature set of TypeScript is not
| necessary. Long term, I could see a world where these features
| effectively replace TypeScript, which could help simplify dev
| pipelines.
| wolfadex wrote:
| How would these features replace TypeScript? TypeScript is
| more than just a syntax as it also requires a compiler,
| config, IDE tooling, and typically additional plugins to make
| it compatible with testing tools and bundlers.
| cphoover wrote:
| I agree. The TC39 committee process has had a lot of advantages
| in modernizing the language, but in the last 3-5 years we've
| seen the pace of merging new language features grow in an
| unprecedented fashion. There are advantages to evolving the
| language but there is also a risk that the syntax becomes
| bloated if there is not enough deliberation within the
| standards process.
| endemic wrote:
| I like the idea of TypeScript, and am learning it, but am
| disappointed that we're still using build systems for
| JavaScript. I thought modules, HTTP2, and evergreen browsers
| would allow us to write just plain JS (like the olden times!),
| and not have to worry about bundling, but I guess not.
| Vinnl wrote:
| You'll still want to compile (or more specifically, type-check
| and minimise), but you'll probably be able to _run_ your TS
| code without compiling, if you stick to that subset - but that
| 'll likely be pretty easy. I'm imagining lint rules like the
| ones we're using to restrict ourselves to const and let instead
| of var, and things we'll quickly internalise like avoiding
| enums, and things we're no longer using anyway, like
| namespaces. Yes, it's a subset, but includes enough that you
| don't _need_ the infra to run it.
| eyelidlessness wrote:
| I agree that there are problems with limiting this to a subset.
| But for the most part it's a very good subset that _mostly_
| only removes features which would be rejected if proposed
| today, because they have runtime semantics. This would
| effectively deprecate those features in the real world. I'm in
| the minority who likes enums, but I can live without them. The
| real, big gap here is JSX. But that rightly should be a
| separate proposal. I just want them to consider it a
| prerequisite, to avoid fracturing that aspect of TS.
| kyberias wrote:
| Imagine all the time and energy wasted having all these popular
| programming languages re-inventing and -implementing the same
| features over and over again and people discussing and arguing
| about them.
| Cthulhu_ wrote:
| I'm more and more thinking that JS is heading in the wrong
| direction. I'd opt for splitting up JS into two; one is a low
| level compilation target, something like... I forgot the name
| now, it was a subset of JS with hints in comments that allowed
| the interpreter to forego certain checks (mostly around the
| dynamic nature of e.g. objects) for speed, I believe this
| predated WASM and co.
|
| Anyway, a simple version of JS or more like bytecode. Then
| developers can pick whichever language they want. Because these
| type annotations do not benefit execution, only development.
| nerdponx wrote:
| > Because these type annotations do not benefit execution, only
| development.
|
| Well this is why TypeScript was invented in the first place.
| Not to mention that "static-only" type annotations are being
| adopted in Python and Ruby as well. Clearly a lot of developers
| see a lot of value in them.
| isaacimagine wrote:
| You're thinking of asm.js: http://asmjs.org/faq.html
| tekkk wrote:
| No, it's the right way. TS is the future of the language.
| Besides JS is not sane enough to be a low level language. WASM
| is precisely that.
| cphoover wrote:
| Then use TS if you prefer. There are plenty of people who
| prefer languages like that are type-less, and are plenty
| proficient in it.
|
| If you want a strongly-typed static language, compile to a
| wasm target with typescript, or another language... That's
| what it there for.
| Spivak wrote:
| Would you make the same argument if Chrome decided to flip
| the script and make TS the default browser language and if
| you wanted something untyped you had to use a compiler?
| cphoover wrote:
| I'm not sure how you would go from a static untyped
| language to a dynamic typed language. Pretty sure only
| the opposite is possible. You could have type-
| inference... but this is different from having a weak
| type system.
| tekkk wrote:
| Sure there is but I suppose majority are moving towards
| typed languages. Perhaps it's sad for some, but it's no fun
| having to guess types or console.log them because it's just
| not obvious. Good riddance I say.
|
| I'd rather have a proper type-less functional language and
| it's impossible to create that from JS with its legacy
| baggage.
| cphoover wrote:
| Thought experiment If you could go back in time and
| replace Brandon Eich when he first created JS what would
| you propose?
| mlajtos wrote:
| > I forgot the name now, it was a subset of JS with hints in
| comments that allowed the interpreter to forego certain checks
| (mostly around the dynamic nature of e.g. objects) for speed, I
| believe this predated WASM and co.
|
| You probably mean asm.js
| assbuttbuttass wrote:
| Isn't WASM basically this low level compilation target you're
| talking about?
| xmorse wrote:
| Before wasm there was asm.js [0]
|
| [0] https://en.wikipedia.org/wiki/Asm.js
| leodriesch wrote:
| I'd say WASM is the low level compilation target for JavaScript
| runtimes.
|
| There is also a proposal for directly shipping ASTs instead of
| JavaScript source files for performance improvements [0].
|
| [0]: https://github.com/tc39/proposal-binary-ast
| shadowgovt wrote:
| But if the types don't impact the runtime, then putting them
| directly in the source code that would be transmitted to the
| client adds cost to bandwidth without benefit.
|
| Or you pass the code through a preprocessor to strip out the
| types and squash it before sending it to the client. At which
| point you have a pre-processor in your tool chain, and it might
| as well be a compiler from your favorite language (such as
| TypeScript).
|
| I think this might be reinventing the wheel to insufficient
| benefit.
| jakelazaroff wrote:
| Services like Netlify and Cloudflare already give you the
| option to minify your code when serving it. Removing the types
| as well is a pretty small step from there.
| kevingadd wrote:
| How is it reinventing the wheel if there are already millions
| of LOC out there that use it? This is a debugging/development
| feature. The pre-processor already exists, but if you can
| iterate rapidly without having to run it and without having to
| hassle with stuff like source maps, that's a huge workflow
| improvement. Even without these type annotations any production
| javascript of moderate size is already getting minified and
| compressed before deployment regardless of whether type hints
| are used.
|
| Right now when I'm authoring typescript in vscode, I get live
| error feedback from tsc and eslint in the editor, so in
| practice I only need to run tsc to "build" because I need to
| strip out all the typescript syntax. If that syntax became
| usable in a modern browser I could skip that build step during
| development and only run it for deploys to CI, staging and
| production.
| 015a wrote:
| To be frank, I hate to be the typical HN luddite, but this
| proposal [1] feels like it will add too much parsing complexity
| to runtime JS.
|
| The counter-argument to that is: everyone minifies code anyway,
| but this feels like a very poor argument. "Adding cruft is OK
| because most people have complicated build chains to get rid of
| it" is very different from "we've opted into a build chain (tsc)
| and now have access to adding cruft"; there's a default situation
| here, which is the many people who write JS (FE or BE) and aren't
| minifying it.
|
| Additionally, their pipe dream of allowing TS to become standard
| JS "if they stick within a certain reasonably large subset of the
| language" (an actual quote from the TC) is... wild. Wild. No
| thoughts, just vibes. Typescript is an extremely mature, fast-
| moving, complex project. Their list of TS features not supported
| under this TC is only three items long (with enums and namespaces
| among the list, lol), but I guarantee there are TONS of very
| complex type-level assertions typescript is capable of which JS
| is years, maybe decades, from reaching considering the glacial
| speed ECMA moves at.
|
| Typescript will always be a superset, which they admit. The
| problem is: I hold extreme doubt that JS/ECMA is even capable of
| communicating what that differential is to average users. Will JS
| support control flow analysis for dependent parameters, aliased
| conditions, and discriminants? Const assertions? Middle rest
| elements in tuples?
|
| Typescript adds all these assertions, and more, every couple
| months, because it turns out that type systems are something of a
| pandora's box. Few language-level type systems remain at the
| simplicity of, say, Go; most become TS, or Rust, or Java. That's
| not a bad thing, but not everything should be that.
|
| If this gets traction and built, JS will in-effect, though not
| in-requirement, turn from an interpreted language to a compiled
| language, whose compiler isn't even maintained by the core
| development teams. That's a major, major shift; and I'm not sure
| the proposers have even considered the ramifications of it.
|
| [1] https://github.com/giltayar/proposal-types-as-comments/
| btown wrote:
| This is essentially what Python did with its type annotations:
| add flexible syntax support and a standard library for e.g.
| Optional[dict], and let external tools like Mypy iterate on the
| actual type checking work.
|
| https://peps.python.org/pep-0484/
|
| It's a fair compromise, though now there are two invariants: all
| untyped JS must be a subset of typed JS, which in turn must be a
| subset of Typescript. And if a JS builtin like Python's "typing"
| module is added to make type definitions easier and standardized,
| there's now two ways to define types in Typescript. Which is far
| from the end of the world... but still will be somewhat
| controversial.
| Spivak wrote:
| And it works pretty well except for some minor annoyances about
| typing things which only exist in the mind of mypy having
| runtime costs.
| rvieira wrote:
| As someone who doesn't really work with neither JS or TS, the
| proposed JS type system looks superficially very similar to TS.
|
| Is this "backporting" TS to JS or is there something else I'm
| missing?
| Aldo_MX wrote:
| It is proposing a subset of TS (type annotations) to become a
| part of JS.
| jayrhynas wrote:
| As far as I understand it, this is allowing TS types to be
| valid JS syntax that are just ignored by vanilla JS engines. So
| it is intentionally identical to TS, it just won't have any
| affect on the execution of your code.
| Ndymium wrote:
| It's not identical as features that have a difference on the
| runtime behaviour / code generation such as enums are
| deliberately omitted. It's intended to be a large subset of
| TS at first. [0]
|
| [0] https://devblogs.microsoft.com/typescript/a-proposal-for-
| typ...
| nerdponx wrote:
| For perspective, this is more or less what Python did.
|
| Originally Mypy was supposed to be a Python superset, like
| TypeScript, but instead its variable annotation syntax was
| adopted as Python syntax. It has been an interesting journey
| for Python, with a lot of ups and downs. Type hints, for all
| their productivity and bug-safety benefits in _most_ cases,
| still feel like a bolt-on feature that requires developers to
| change how they write code, and in many cases favors less-
| performant idioms and /or extra boilerplate compared to un-
| hinted Python. Whereas TypeScript has a lot more freedom to
| mess with how things work, because it's a superset that
| compiles to JavaScript and not actual JavaScript.
|
| So it's somewhat surprising to see this proposal for
| JavaScript, because the TypeScript model always seemed
| _better_ in hindsight than the Python model! But maybe it 's
| just a "grass is greener" situation.
| IshKebab wrote:
| Yeah that's deliberate. They're proposing that Typescript
| should be valid JavaScript, just with the type hints ignored by
| JS engines.
|
| Seems like a very reasonable proposal to me.
|
| It is quite similar to Python's type hint system. Python's is
| kind of rubbish because there are multiple competing type
| checkers with different semantics and most people use the crap
| one (Mypy). I can't see that being a problem here - essentially
| everyone uses Typescript and it's very good.
| hexane360 wrote:
| >most people use the crap one (Mypy)
|
| idk, I wouldn't go this far. Mypy is slow, but it's probably
| the most correct, and it allows for configurations pyright
| refuses to. For instance, the maintainers won't add an option
| to allow variable redefinition/shadowing, seemingly because
| they don't understand the difference between a variable and a
| binding
| (https://github.com/microsoft/pyright/discussions/2441). As
| for Pyre, last I checked it had a lot of false positives that
| Mypy doesn't.
|
| Besides all that, some people want to use a checker that
| isn't exclusively developed by a huge company (Microsoft,
| Google or Facebook).
| IshKebab wrote:
| I dunno I've run into very basic bugs in Mypy and I even
| went as far as trying to fix them myself. If you had read
| the code you wouldn't have such a high opinion of it!
|
| In contrast Pyright seems to get pretty much everything
| right, even really subtle things, and if it is really a bug
| then the guy that maintains it is _insanely_ good at fixing
| them. Seriously check out how many open /closed issues
| there are.
|
| As for variable redefinition, Python stupidly doesn't
| prescribe semantics so it's perfectly valid for it to
| behave like that. Definitely arguable which way it should
| go and I think for clarity it's much better to use
| different names anyway. It's not because they don't
| understand anything.
|
| Mypy has way crazier behaviours anyway, e.g. implicit
| making types optional. Different behaviour depending on the
| syntax used to add types, etc.
| icholy wrote:
| It's the TS team making the proposal.
| idontknowifican wrote:
| this is common in ECMAScript. see coffeescript and arrow
| functions
| hajile wrote:
| This adds risk with no reward.
|
| People won't use it in production because it is too big. In
| development, map files work fine and people will still use them
| because this isn't feature complete with TS.
|
| At most, it locks JS into an unchangeable type syntax that may or
| may not work out.
|
| Instead, we need a `use type` mode that fixes more of JS. I want
| type coercion gone and the super-dynamic parts of the language
| restricted (this both makes types more simple and makes the
| language more optimizable). I'd also like to see Option and
| Either types baked in and have `null` removed or severely
| restricted.
| moron4hire wrote:
| >> .d.ts files often won't be needed either.
|
| .d.ts files contain a lot of things other than types for the
| _emitted_ code. Interface types disappear completely when
| compiling TypeScript, but they are an important part of many
| .d.ts files, especially anything describing existing web APIs.
___________________________________________________________________
(page generated 2022-03-10 23:01 UTC)