[HN Gopher] ECMAScript Proposal: Types as Comments
___________________________________________________________________
ECMAScript Proposal: Types as Comments
Author : 0xedb
Score : 41 points
Date : 2022-03-12 18:31 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| montroser wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=30626458
| sergiomattei wrote:
| Dumb question incoming... Why not formalize TypeScript into the
| ECMAScript spec?
| nick_ wrote:
| If only the ECMAScript/JavaScript community were this sensible.
| dham wrote:
| Why does Javascript have to have all of Typescript brought into
| it? The browser has supported multiple scripting languages
| before. Not unprecedented.
|
| <script language="typescript" />
| ByteJockey wrote:
| Google controls JS to the point of being able to ignore the
| spec (e.g. that time they left TCO behind an experimental flag
| and it just went away despite being in the spec).
|
| As long as node and chrome are so dominant, we're probably not
| going to see big shake-ups in JS that aren't driven by Google
| themselves.
|
| JS is flexible, you can cover up a lot with polyfills, but not
| completely different syntax. Doing that without Google's buy in
| would create a rift in the internet that would either end with
| browser specific web pages, or with the complete loss of power
| for the committee that sets the ECMAScript spec as JS
| officially goes from being a language that is defined by a spec
| to a language defined by a canonical implementation (in this
| case V8).
| LudwigNagasena wrote:
| Yeah, isn't TypeScript without enums and decorators already
| kind of "types as comments"?
| hombre_fatal wrote:
| Some FAQ items address this:
|
| https://github.com/giltayar/proposal-types-as-comments#why-n...
|
| Various good reasons, like how it would hinder TS evolution and
| you'd end up having to compile TS to whatever older version of
| TS the slowest implementors support anyways.
|
| But one interesting point is that type analysis is for the
| developer's benefit. What is the imagined benefit and behavior
| of pushing type analysis over the wire with the code to be run
| on the end-user's machine?
| TazeTSchnitzel wrote:
| Ignoring the type declarations gives some freedom to type
| checkers to decide what meaning they have, but it also makes them
| useless to the runtime. I think that's a shame. Could JavaScript
| engines not benefit from the type information? PHP does.
| orangepanda wrote:
| This proposal doesnt support the full typescript syntax, you'll
| need a build step anyway. What problem does it solve?
| w3news wrote:
| No, you don't need a build system, but most developers cannot
| work anymore without a build system. And what about node.js,
| it's a lot better to skip a build step.
|
| I think typescript is a temp hype just like jQuery, useful for
| many, but a few people can just do the vanilla JavaScript way.
| mattlondon wrote:
| Why go to the effort of doing all of this, but not use
| typescript? I don't see the point - they mention ignoring the
| build step, but it's not like that is particularly annoying at
| the moment, at least not in the largish-projects I've worked on
| (enterprise angular apps staffed by approx 50-60 frontend
| engineers, so fairly chunky codebase)
| dlbucci wrote:
| This topic came up earlier this week, and I just don't see what
| the big win is. I guess people want to be able to skip setting up
| a build system for TypeScript, but if you do that, you'll be
| sending a bunch of extra junk to browsers that will just be
| ignored. So you'll need to setup a minifier to strip it all out,
| which means you have to setup a build system anyway.
|
| Is there some other advantage? Easier debugging on the client, I
| guess, but proper source maps do that pretty well already. I
| dunno, this just seems to be making a complex language more
| complex for not much gain.
|
| That said, if the runtime actually used the types for safety or
| performance, I could maybe see some value added there.
| niedzielski wrote:
| I wondered about this as well but speculated that basic
| compression, either gzip or Brotli, would account for it and,
| in the case that someone doesn't care about bundling their
| code, they probably don't care if it has comments (types) in
| it. If they do care about bundling, even if that is just `cat`,
| then I think the code is "built" to some extent already.
|
| I would enjoy the flexibility to ship types but personally
| don't have any need for it. Seems like "boiling the frog" for
| type-checking in the browsers to me but I personally like the
| idea of encouraging more typing in native JavaScript.
| vbezhenar wrote:
| Browser could build optional type support (for example with
| warnings), so you can leverage it and skip all packaging stuff.
|
| And sending few percent of JavaScript is not an issue. It's
| gzipped well and it's not what will slow down the website.
|
| For example I really love that I can just write modern
| JavaScript and just send it to the browser and it works.
|
| Serious websites of course will use minifiers and stuff, but
| for some small sites it's unnecessary burden.
___________________________________________________________________
(page generated 2022-03-12 23:01 UTC)