Hacker News Reader

Comment by olingern | Hacker News Reader

JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next. JS/TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.

View on HN

The negative is that some issues are really hard to fix, because you don’t want to break the backwards compatibility guarantee.

For example, there is a bug in go’s built-in HTML templating, that it misrepresent javascript backticks.

If you do

in HTML template, it will interpret // as a comment and return

This is now really hard to fix; it means either rewriting the JS parser from scratch, but that is a giant change (currently the JS parser is really simple, backticks are hard to do properly without reimplementing all from scratch); the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat.

So there is basically an unfixable bug sitting in go html templates.

https://github.com/golang/go/issues/9200

If it’s bad enough, why not release a v2 of the library?

The standard library seems to only be versioned with the language. An external v2 could work, but I’m not sure there’s any precedent for a v2 of a standard library package.

> I’m not sure there’s any precedent for a v2 of a standard library package.

urllib/urllib2 in Python is one example. There are others; it's not really unprecedented.

There is no precedent in Go. It's been discussed a few times here and there, but real plans AFAIK.

Why can't they just make a new version of the library for fixes?

Can't they add an option or something that specifies how backticks are handled with the default setting to be the current (so nothing breaks) and any new code or existing code that knows about the issue can set it to a better value?

> the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat.

Given script tags are allowed, this seems like the least reasonable choice. What other arbitrary JS features should be disallowed because the parser isn’t spec compliant?

> JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next.

Only if you want it to change. Our codebase is plain JS/TS, we don't use many recent features, and it's fine.

Are we just ceding Javascript to Microsoft at this point due to the ubiquity of Typescript?

It’s already mainstream to minify your JS anyway as part of a long build process. JS transparency is used by very few people.

TypeScript does not output obfuscated JS. The output is completely human-readable, even if certain things don't match the source exactly. TS explicitly tries to stay in line with JS, syntax-wise.

If anything, TypeScript is quite deferential to TC-39. Microsoft is part of the standardization process, but certainly not the main/only driver. I don’t know where you got the impression that this is a MS issue, but TS changes because JS changes not the other way around.

No. Typescript is really strict about being only type annotations for JavaScript (except `enum`), so I'm not sure why you'd think that makes them control JavaScript.

It wouldn't be a loss if browsers could natively understand Typescript annotations, and even take advantage of them for the JIT.

Looking forward to the day, actually.

Reply on news.ycombinator.com