Improving JavaScript: Google throws AtScript into the mix

While not exactly best friends it is rather a shame that Google couldn't just work with Microsoft to enhance Typescript in a compatible way rather than introducing their own flavour.

Most (if not all of this) this was available in JS2 2006 or so.

Certain companies didn’t want it even though they could have had it more or less for free - they didn’t join the committee to allow the language to do things easily.

If people could see what you could do in a browser with JS2 and some SVG with attitude...

Typescript is licenced under the Apache 2 licence and is a standard. So there's no non-technical reason why they couldn't use it.

As to the technical reasons why you would use it... The annotations perhaps...? I'm struggling to see much if any need for Runtime Introspection in a language designed to run in the browser. I've seen some sophisticated client-side applications these days so... maybe? But I can't think of any real reason why you'd want it and I can see it mainly being used by some far too clever programmers to write code that everyone who inherits their project stares at and backs away from.

So chiefly I see its use being impregnable job security. No doubt and Objective C programmer will appear to tell me why it's actually useful here. ;)

Isn't that exactly what Typescript does?

Re: Ooops

This is all true. What the author meant to says is "the absence of language features and classes make JavaScript projects hard to maintain for large teams of barely competent (but cheap) programmers who need protecting against themselves." We rockstar coders can continue writing framework-free uber-code using ed.

-A.

Re: Ooops

Two different quotes I reference:

The difference between prose and poetry is not that different languages are used, but that the same language is used, differently.

Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language.

Re: Ooops

It can help if the language has one clear way of doing something. Perl, for example, has three ways of doing everything so every programmer does it differently or every team has a massive document saying thou shalt program this way which new programmers have to master. And there is a retraining cost if the approach a language uses to solve a problem is different to the standard one.

That said, I love programming with closures. And find I rarely need to stray into prototypes.

Re: Ooops

Nope, its not absurd - have you heard of assembly? Why do you think we have compiled high level languages in the first place?

Rather than retype common sense, check out: http://stackoverflow.com/questions/2684364/why-arent-programs-written-in-assembly-more-often

Perl can be a dog to maintain and thats due to its features.

The practicality of code is that its hardly ever documented and pretty much the documentation is wrong (usually APIs are well documented but the code behind isnt).

And yes you can write poor code in any language - but pound for pund, I'd still rather not have to deal with well written js.

Re: Wrong on so many levels

I disagree with point 3. javascript catching on was a historical anomaly and had nothing to do with whether or not it had classes.

Re: Wrong on so many levels

> Adding C++-style objects to the language will spoil the system for those who like it and fail to satisfy you because the old stuff will still be there. AND you'll have to produce a detailed specification for how the two systems relate. (Oh joy!)

Not really - Typescript manages this with dynamic typing and the Any type.

Re: Wrong on so many levels

Re Point two? Bollocks- It wont spoil things - bad project management would. Types and classes would make thing a lot easier for a lot of people.

Re: JS is shote

Yes, we *should*. But, of course, it's not going to happen, at least, not for many, many years to come.

Whether we like it or not, JS is the lingua franca of the web. It is essentially the 'assembler' language of the browser. Everything we develop has to eventually execute as JS.

This may change in another 20 or 30 years. Maybe. But in the meantime, we have to use *something* to write our browser-based applications with.

I am not convinced the intent is to deliberately proprietise the web, more wanting to deliver a useful and usable solution quickly without becoming bogged-down in delays while trying to agree a new standard and arguing how it should be.

"If you don't like it; fork it", has both advantages and disadvantages.