Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.7

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Announcing TypeScript 2.7

#51

Post by the8472 »

deeg wrote: post #26

I'm a back-end developer (Java, Scala, some Rails) and when I first heard developers were using Node+JavaScript as a server stack I thought they were nuts to use a dynamic scripting language for enterprise software. TypeScript has a chance to turn that around, though, and might be the future: a mostly-typed language that also has the flexibility to be dynamic when called for. I really like TypeScript and it has usher…

The issue with typescript is that it relies a lot on external type definitions for non-typed JS modules. And those are plain wrong or outdated at times, leading to lots of compiler errors (but correct code!) which in turn means you can't let your build fail when type errors are detected and you acquire some compiler error numbness over time.

I mean it's better than no type checking at all, but it falls short of languages where it's actually baked in instead of relying on external definitions.

Re: Announcing TypeScript 2.7

#52

Post by ComputerGuru »

Raphmedia wrote: post #34
ComputerGuru wrote: post #31

TypeScript is a great improvement over JS, still held back by the horrible state of the JS module system in browsers. You write your code and it does what you want, then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else. And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear m…

Come on, take the time to learn your tools instead of blindly mashing things together. Step 1 : npm install --save-dev gulp-typescript-babel Step 2: var gtb = require('gulp-typescript-babel'); gulp.task('compile', function () { gulp.src(config.typescript) .pipe(gtb({incremental: true, configFile: 'tsconfig.json'}, {presets: ['es2015']})) .pipe(gulp.dest(config.output)) }); Step 3: Enjoy.

Right, I forgot to mention the duplication of build systems between TypeScript’s own, webpack, npm, gulp, and others.

Ironic that you speak of "blindly mashing things together" - how many different build systems did you mash together there, hidden behind a meta npm package?

The web needs CMake or meson more than C/C++ ever did.

Re: Announcing TypeScript 2.7

#53

Post by Arnavion »

_uhtu wrote: post #40
ComputerGuru wrote: post #31

TypeScript is a great improvement over JS, still held back by the horrible state of the JS module system in browsers. You write your code and it does what you want, then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else. And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear m…

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, system…

>This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable.

"amd vs esnext vs systemjs" is about module formats.

"Babel vs browserify vs requireJS vs webpack" is about transpilers and loaders.

Re: Announcing TypeScript 2.7

#54

Post by ComputerGuru »

_uhtu wrote: post #50
nateroling wrote: post #45

Earlier quoted context omitted.

I love that there are currently two replies to you, both implying you're an idiot for not knowing how to do this, and both presenting different solutions.

I never called him an idiot, I just called him out for not researching at all before posting. His understanding of Javascript has not been updated in at least 3 years based on the fact that he called ES6 ESNext, even though ES6 has been released for almost 3 yars. There's also two different compilers for C, but it's not considered complicated to get started running a C program.

I wasn’t referring specifically to ES6 when I said ESNext, I was referring to the ever-evolving “this willl be addressed in the next ES release, just add ESxxx as a flag to the zillion build systems and you’ll be good to go,” as well as simultaneously referencing the ES module system.

My post was not intended to be taken literally. It was a rant, I’m sorry for the lack of precision and effort. (Not being sarcastic.)

Re: Announcing TypeScript 2.7

#55

Post by dfgin »

Nvm. ESxx is already waaaay too bloated, and Typescript only adds to that. All those new features are only adding complexity, pain and bugs. I'm curious when we arrive at the point when it's less painful to write a web app in C, it feels we're getting quite close already!

I try to keep my codebase as simple as possible with Coffeescript, doing dynamic type checking with types.js. Honestly very rare to see a type related bug in my codebases.

For all those ESxx and Typescript proponents out there: You don't need it. It doesn't make your life easier at all. In the Javascript domain I wind down as much as possible on the endless libs and tools to keep my codebase readable and my mind healthy.

Re: Announcing TypeScript 2.7

#56

Post by ComputerGuru »

jsheard wrote: post #43
_uhtu wrote: post #40

Earlier quoted context omitted.

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, system…

Furthermore, you usually don't need Babel if you're a Typescript user because the Typescript compiler covers more or less the same ground. Use Typescript+Webpack if you like types, or Javascript+Babel+Webpack if you like surprises, and in either case use ES6 module imports.

However a lot of guides (even some officially sanctioned ones iirc) use Babel to transpile typescript in the browser, forgoing the precompilation to JavaScript entirely.

I don’t know if that’s just an artifact of days gone by, an attempt to bypass tsc before it gained on-the-fly watch-and-compile support, or for another reason entirely.

Re: Announcing TypeScript 2.7

#57

Post by [deleted] »

ComputerGuru wrote: post #54
_uhtu wrote: post #50

Earlier quoted context omitted.

I never called him an idiot, I just called him out for not researching at all before posting. His understanding of Javascript has not been updated in at least 3 years based on the fact that he called ES6 ESNext, even though ES6 has been released for almost 3 yars. There's also two different compilers for C, but it's not considered complicated to get started running a C program.

I wasn’t referring specifically to ES6 when I said ESNext, I was referring to the ever-evolving “this willl be addressed in the next ES release, just add ESxxx as a flag to the zillion build systems and you’ll be good to go,” as well as simultaneously referencing the ES module system. My post was not intended to be taken literally. It was a rant, I’m sorry for the lack of precision and effort. (Not being sarcastic.)

[deleted]

Re: Announcing TypeScript 2.7

#58

Post by AriaMinaei »

TypeScript 2.8, due next month, is shaping up to be an interesting release! It introduces a feature called "conditional types [0]" which opens up a lot of type-level programming opportunities.

Flow also has the `$Call` type (type-level function application), but unfortunately as with most of its features, it didn't go through community testing/input before release, and thus it has bugs that render it useless for what I assume to be very common use-cases.

[0] https://github.com/Microsoft/TypeScript/pull/21316

Re: Announcing TypeScript 2.7

#59

Post by maxxxxx »

jondubois wrote: post #44
maxxxxx wrote: post #39

Earlier quoted context omitted.

I think Javascript is definitely way too forgiving. I just had a situation where a property name was mistyped. The value was "undefined" which then can be compared against strings. So the code worked without warnings but the results were wrong. Took several days to track this down in a long promises chain. With a typed language this wouldn't even have compiled.

But with JS you don't need to wait for your code to compile so you can test it much quicker. If you write tests then this is almost never a problem. With typed languages, I often lose my train of thought while waiting for the compiler. When warnings come up, I'm like a robot, I don't actually think, I just follow the line numbers. Statically typed languages make me lazy. I feel like I spend all my time and mental ene…

I guess it's all a matter of taste or what you are used to. I like relying on the compiler. The stricter the compiler the better.

Re: Announcing TypeScript 2.7

#60

Post by ComputerGuru »

_uhtu wrote: post #40
ComputerGuru wrote: post #31

TypeScript is a great improvement over JS, still held back by the horrible state of the JS module system in browsers. You write your code and it does what you want, then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else. And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear m…

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, system…

Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless.

I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it.

> I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.

In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess.

I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it.

We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place.

We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself.

With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.

Post reply on HN