JS will eat TypeScript just like it ate CoffeeScript. A bigger bite maybe but still very delicious. Thanks for doing all that hard work for JS, Microsoft.
Goodbye TypeScript, hello native typing for JavaScript
21–30 of 31 posts
Re: Goodbye TypeScript, hello native typing for JavaScript
#22Earlier quoted context omitted.
I'd also add that Typescript would be a very bad language choice anyway. If we're going to have a backward-incompatible change, we should do things the right way (after all, we're stuck with it forever). Don't make a type system work around the really bad parts of JS. Instead, don't allow them in typed modules. Don't settle for an intentionally unsound (aka broken ) type system. Add an actually sound (probably hindle…
> If we're going to have a backward-incompatible change, we should do things the right way It makes much more sense to use a good language (Kotlin, Rust, Java) and transpile to JavaScript. There's already great tooling for it.
Welcome to Nim.
Re: Goodbye TypeScript, hello native typing for JavaScript
#23[dead]
Re: Goodbye TypeScript, hello native typing for JavaScript
#24So they're really going to add the syntax that looks like, but isn't actually, type annotations for the convenience of people using a third party tool, which is useless in the language itself. It isn't native typing for javascript, which would be nice, but will never happen. Ah well, Javascript was a nice simple language for a while, but I guess it was inevitable that enterprise would ruin it.
"Javascript was a nice simple language for a while", wait, what? JS from its inception was a mix of LISP and C and what's not: strange OO inheritance (prototyping), only floating points for numbers (causes a lot of confusion), undefined and == vs === stuff, crazy var keyword behaviour, global scope etc. Maybe you are referring to a subset of the language codified in the book "JavaScript: The good parts"? What happene…
I find this particular comment bizzare.
To which I would ask - why not use Rust or Java instead?
JS is good enough and simple enough to learn as a first language to play around with webpages and maybe later on deliver amazing UI interactivity.
Using it for enterprise projects with massive teams is like attempting to empty a river with a straw - then proceeding to innovate on small pumps to increase straw throughput. Technically fine but why not use tools actually made to draw water in large quantities?
Re: Goodbye TypeScript, hello native typing for JavaScript
#25Earlier quoted context omitted.
I actually am on the no-uglification bandwagon with you! With compression, I think there's more harm & pain caused by obscuring the source-code to users than there is gain in the very small reduction in size. But this stance gets quite a reaction, from what I've seen, and I wanted to give a lot more rope to the person I was replying to, rather than try to argue this (fairly nor popular) point too. Which is to say, I…
I worked on a project once and had to prove to several team members that their very slow minification tool in the build process might be reducing the uncompressed size by seemingly quite a bit, but was kind of inflating the compressed size and making the site slower for everyone in reality than the unminified files shipped directly to the user. Performance work is generally underappreciated anyway, but that was parti…
Minification isn’t just about reducing size of the output, it also has the very important side effect of obfuscating the output to make it difficult if not practically impossible for reverse engineering and compromising of IP. That is a critical aspect that businesses will always opt for. And business use cases drive things like Typescript into existence.
Re: Goodbye TypeScript, hello native typing for JavaScript
#26[dead]
Re: Goodbye TypeScript, hello native typing for JavaScript
#27So they're really going to add the syntax that looks like, but isn't actually, type annotations for the convenience of people using a third party tool, which is useless in the language itself. It isn't native typing for javascript, which would be nice, but will never happen. Ah well, Javascript was a nice simple language for a while, but I guess it was inevitable that enterprise would ruin it.
"Javascript was a nice simple language for a while", wait, what? JS from its inception was a mix of LISP and C and what's not: strange OO inheritance (prototyping), only floating points for numbers (causes a lot of confusion), undefined and == vs === stuff, crazy var keyword behaviour, global scope etc. Maybe you are referring to a subset of the language codified in the book "JavaScript: The good parts"? What happene…
When you're only using Javascript to mess with the DOM and do AJAX requests, instead of actual math, just having floats is perfectly fine. None of the things you're complaining about actually matter in the context Javascript was intended to be used for, which yes made it nice and simple.
For instance, no classes - all you need are objects, which can serve as maps, arrays and contain functions. Constructor? Loading the webpage. Destructor? Unloading the webpage. JQuery modules got a lot of flexibility and power out of a few simple features. One general syntax for function calls. Prototypes and all-global state made it simpler as well, even though modern enterprise programming eschews them because they make testing more difficult. All you needed to test javascript back in the day was f5 and the debug console. All you needed to handle dependencies was to upload a file and write a script tag, or maybe point to a CDN.
I agree with you completely about Typescript, but that's inevitable when the world insists one small, toy scripting language replace all existing languages and all domains - it has to do everything and please everyone and be as flexible as possible while still being bound to javascript's limitations at the end. But most people's complaints about javascript come from the (also inevitable) pain from trying to force it to be something it was never meant to be.
>If we add strong typing to JS that _is enforced by the runtime_ we may skip this compatibility ballast and have something more simple.
Then every runtime has to support two essentially incompatible languages and call them both "Javascript," and only one will work on the web for backwards compatibility reasons. That isn't going to happen. Just compile the language you actually want to use to WASM or native and leave JS alone.
Re: Goodbye TypeScript, hello native typing for JavaScript
#28Earlier quoted context omitted.
I'd also add that Typescript would be a very bad language choice anyway. If we're going to have a backward-incompatible change, we should do things the right way (after all, we're stuck with it forever). Don't make a type system work around the really bad parts of JS. Instead, don't allow them in typed modules. Don't settle for an intentionally unsound (aka broken ) type system. Add an actually sound (probably hindle…
> If we're going to have a backward-incompatible change, we should do things the right way It makes much more sense to use a good language (Kotlin, Rust, Java) and transpile to JavaScript. There's already great tooling for it.
JavaScript seems an unlikely compiler target, forced on us out of the odd historical success of JS on the browser. I'd think that a better target would be to make a VM like WASM.
Re: Goodbye TypeScript, hello native typing for JavaScript
#29Earlier quoted context omitted.
I worked on a project once and had to prove to several team members that their very slow minification tool in the build process might be reducing the uncompressed size by seemingly quite a bit, but was kind of inflating the compressed size and making the site slower for everyone in reality than the unminified files shipped directly to the user. Performance work is generally underappreciated anyway, but that was parti…
Minification isn’t just about reducing size of the output, it also has the very important side effect of obfuscating the output to make it difficult if not practically impossible for reverse engineering and compromising of IP. That is a critical aspect that businesses will always opt for. And business use cases drive things like Typescript into existence.
Anyone who believes minification counts as "proper" obfuscation misunderstands both. Minification is not obfuscation. They have different goals. Most "good" obfuscators are the exact opposite of minification: to obscure business logic they expand the code into sub-parts more akin to assembly language than the original logic. "Good" obfuscation is much more than just using shorter variable names everywhere.
Minification is especially not sufficient for obfuscation in a world with pretty printers embedded into every Dev Tools in every browser.
Minification is just about reducing the size of the output. Any business that truly cares about the safety of their IP should look into "proper" obfuscators.
(Personally, I don't think obfuscators are generally worth the build time and their output worth the extra bandwidth either, but yes there I understand that security theater generally beats performance concerns.)
Re: Goodbye TypeScript, hello native typing for JavaScript
#30Earlier quoted context omitted.
I worked on a project once and had to prove to several team members that their very slow minification tool in the build process might be reducing the uncompressed size by seemingly quite a bit, but was kind of inflating the compressed size and making the site slower for everyone in reality than the unminified files shipped directly to the user. Performance work is generally underappreciated anyway, but that was parti…
Minification isn’t just about reducing size of the output, it also has the very important side effect of obfuscating the output to make it difficult if not practically impossible for reverse engineering and compromising of IP. That is a critical aspect that businesses will always opt for. And business use cases drive things like Typescript into existence.
It offers no real protection against anyone who cares.
And it obstructs people who are going out of their way to improve their usage of your site. It's a pity we only see the risk in that, that the miserly antagonistic corporate dominion attitude rules, that is afraid, that quakes at users doing things not on the l blessed path.
This attitude you've very well spoken for bespeaks a great rot & sadness in the world, one that developers should actively try to work against as much as they can.