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

71–80 of 89 posts

Re: Announcing TypeScript 2.7

#71

Post by rk06 »

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…

>But with JS you don't need to wait for your code to compile so you can test it much quicker.

This is no loner a valid criticism as any decent IDE (or a mature Code Editor) can run static analysis as you type and warn you abut issue, before you even compile.

Source: VsCode does static analysis on TypeScript.

Re: Announcing TypeScript 2.7

#72

Post by AriaMinaei »

mpawelski wrote: post #67
AriaMinaei wrote: post #58

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 wha…

Just curious, what are the problems/bugs with `$Call ` that you are talking about? note: I only used TypeScript, not Flow)

I think this demonstrates some of the bugs: https://flow.org/try/#0PTAEAEDMBsHsHcBQiCWA7ALgUwE6QIYDGWoAS...

Re: Announcing TypeScript 2.7

#73

Post by mpawelski »

lhnz wrote: post #38

Personally I've moved away from the TypeScript compiler and towards the betas of `babel@7` and `@babel/preset-typescript` ( https://www.npmjs.com/package/@babel/preset-typescript ). It seems to be faster and there is better integration with `jest`, `rollup`, various css-in-js libraries and (maybe in future?) `create-react-app`. (I still run `tslint` and `typescript` in the background for type-checking and linting. An…

I'm not sure if I understand fully this babel typescript integration. Can you help me understand this?

What's the point?

So in future babel would be able to parse TS file and output JS file with all the transformations it supports? So it's useful if you want to use some new EsNext feature currently not supported by TS compiler?

Is this the main advantage? Because for me it looks like a pretty weak reason (TS has improved a lot when it comes to supporting new ESNext features). Anyway, from what I understand TS provide API that for example webpack loaders use (like https://github.com/TypeStrong/ts-loader and https://github.com/s-panferov/awesome-typescript-loader) and it looks that those can be integrated with babel.

Or is it mainly to support tools that depends on babel for parsing AST? And microsoft is willing to maintain this babel integration for next versions of TS? So non-microsoft community developed tools can easily add support for TS (instead of only supporting JS), like Prettier did (https://github.com/prettier/prettier/issues/13)?

But are everyone using babel for JS parsing? I'm not that into JS tools community, and am a bit confused by all this ESTree, Esprima, recast, jscodeshift projects and relationship between them. You mentioned `recast` TS support and it looks they want to use babel for this too. So it's microsoft bet that all future JS tools that need to parse JavaScript AST will use babel for that, and hence they will add TypeScript support because it would be easy?

Re: Announcing TypeScript 2.7

#74

Post by Raphmedia »

ComputerGuru wrote: post #52
Raphmedia wrote: post #34

Earlier quoted context omitted.

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.

Don't be act like an idiot simply to make a point. You simply come across as some elitist programmer who can't be bothered to learn frontend tooling.

All of those technologies are simply Javascript running serverside (or developer clientside during the development).

I sent you a gulp example because gulp it's very easy to use and you can quickly build customized build processes with it.

"gulp-typescript-babel" is simply a wrapper for "gulp-babel" and "gulp-typescript" which are both simply Javascript libraries. Read their source, there's nothing complicated going on in there.

"gulp-typescript" simply wraps around "Microsoft/TypeScript" and make it easy to pipe into gulp.

"gulp-babel" simply wraps around babeljs and make it easy to pipe into gulp.

"babel" is simply a lib that polyfills and rewrite your next generation JavaScript into code that older browsers can understand.

You originally said "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.". I sent you this snippet to show how simply it is to build TypeScript.

Oh look, I explained to you a "month worth of research" in a simple HN comment... ! You could have googled it and read a blogpost about it instead.

Sorry for being harsh but if you need a month to figure out how to run Javascript on your computer you need to consider a new career.

Re: Announcing TypeScript 2.7

#75

Post by Raphmedia »

paulddraper wrote: post #69
Raphmedia wrote: post #34

Earlier quoted context omitted.

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.

> instead of blindly mashing things together ...immediately mashes a massive number of things together

Since when is using two libraries (typescript and babel) considered mashing a massive number of things together?

If you don't want to leverage Gulp to easily automate your build process then don't.

If you don't want to use NPM to download packages then simply download the .zip archive on Github,

Re: Announcing TypeScript 2.7

#76

Post by alexozer »

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…

I do very little webdev, but `parcel index.html` seems to be able to do just about anything.

Re: Announcing TypeScript 2.7

#77

Post by paulddraper »

Raphmedia wrote: post #75
paulddraper wrote: post #69

Earlier quoted context omitted.

> instead of blindly mashing things together ...immediately mashes a massive number of things together

Since when is using two libraries (typescript and babel) considered mashing a massive number of things together? If you don't want to leverage Gulp to easily automate your build process then don't. If you don't want to use NPM to download packages then simply download the .zip archive on Github,

(1) It's three: gulb, typescript, and babel.

(2) It's hundreds more

    $ npm install
    $ jq '.dependencies | length'
IDK what "blind mashing" would be if not this.

Re: Announcing TypeScript 2.7

#78

Post by spiralx »

ComputerGuru wrote: post #56
jsheard wrote: post #43

Earlier quoted context omitted.

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.

I think you're getting Babel and SystemJS confused - the latter allows you to use TypeScript files as the source attribute in script tags and have it transpiled within the browser, which is sometimes used in examples and tutorials because it avoids any need to use the command line or configure a new TS project.

Re: Announcing TypeScript 2.7

#79

Post by Raphmedia »

paulddraper wrote: post #77
Raphmedia wrote: post #75

Earlier quoted context omitted.

Since when is using two libraries (typescript and babel) considered mashing a massive number of things together? If you don't want to leverage Gulp to easily automate your build process then don't. If you don't want to use NPM to download packages then simply download the .zip archive on Github,

(1) It's three: gulb, typescript, and babel. (2) It's hundreds more $ npm install $ jq '.dependencies | length' IDK what "blind mashing" would be if not this.

Do you count the number of vendor DLLs when you develop .NET applications using third party libraries? Of course libraries will have dependencies.

You are only "blindy mashing" three libraries here. Gulp to manage your workflows, Typescript (because that's the goal of your workflow) and Babel to allow older browsers to read modern Javascript. You can cut Babel out of it if you develop something for a modern browser (internal apps, mostly).

That's three widely used dependencies. There is nothing obscure about them at all. The only questionable choice in that tooling chain is Gulp. The reason I used gulp here is that it's very easy to use it to output simple Typescript. Something such as Webpack and Browserify would be for bundling modules and that's an advanced topic.

Re: Announcing TypeScript 2.7

#80

Post by [deleted] »

nateroling wrote: post #45
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…

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.

[deleted]
Post reply on HN