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

Flow vs. Typescript

djcordhose.github.io

Post reply on HN
Print view View original

141–150 of 158 posts

Re: Flow vs. Typescript

#141

Post by cbreeden »

jeswin wrote: post #68
knocte wrote: post #33

Earlier quoted context omitted.

Right, that check-list is actually useful in any dynamically-VS-statically typed decision scenario.

IMO, that list is specific to JS because JS now gives you the ability to optionally add types. Otherwise, there are good arguments to be made for dynamically typed languages and statically typed languages. That is, I have seen a proportionally similar number of maintainable Python projects as Java.

Python added type hints in version 3.5. It's a good checklist for dynamically typed languages with optional static typing I'd say.

Re: Flow vs. Typescript

#142

Post by livus »

Joeri wrote: post #130
Aldo_MX wrote: post #122

Earlier quoted context omitted.

> Node works fantastically on Windows. I beg to differ 1. npm install gulp 2. try to delete the node_modules folder 3. waste time fighting windows' legacy stuff (260 max path length in almost everything: explorer, cmd, git bash, etc.) 4. come across rimraf eventually I wouldn't describe that flow as "fantastically" unless you mean "fantastically broken".

Not that it helps today, but the upcoming w10 anniversary update is going to get rid of the 260 char path length limit. Microsoft is waking up to the fact that developers mostly aren't using microsoft dev tools anymore. Hence, docker on windows, ubuntu on windows, redesigned env vars dialog, no more path length limit, nicer command prompt, etc...

Finally. But I wish microsoft would've done it sooner. Now a UNIX convert. Forever a convert. I'm no longer fighting my system to get shit done.

Re: Flow vs. Typescript

#143

Post by chris_st »

RussianCow wrote: post #116
chris_st wrote: post #113

Earlier quoted context omitted.

You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it. 1: https://github.com/bbatsov/rubocop

Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.

Ah, you're right. It's "just" a linter... but a pretty good one.

Re: Flow vs. Typescript

#144

Post by shados »

smt88 wrote: post #104
shados wrote: post #94

Earlier quoted context omitted.

You mean like how it breaks ES6 classes semantics by making members enumberables? Whoops (I know, if you look at my comment history I used that example all the time...but it's just such an easy one). When comes the time to pick between shinier output and correctness, TypeScript is perfectly happy to diverge from JavaScript, until it really has no choice (eg: when it moved to ES6 modules)

Can you provide a link or a non-foobar code example? I tried to Google it, but Google is terrible. Edit: This is seriously driving me nuts that I can't find anything about it. I hope you see this and respond because I'm incredibly curious!

Just try it.

Look at what is the output for the following code:

class Cat { talk() { console.log('meow'); } }

It's something along the lines of:

var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }());

The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE (try the same thing on babel's "Try it out" page), thus why Babel provides loose mode. Still, it's the kind of very subtle things that can bite you in the rear big time.

Then again, if you have good unit tests and move those over too, it won't be a problem I guess :) Also most likely not a problem if you use ES6 as the compile target.

Re: Flow vs. Typescript

#145

Post by smt88 »

shados wrote: post #144
smt88 wrote: post #104

Earlier quoted context omitted.

Can you provide a link or a non-foobar code example? I tried to Google it, but Google is terrible. Edit: This is seriously driving me nuts that I can't find anything about it. I hope you see this and respond because I'm incredibly curious!

Just try it. Look at what is the output for the following code: class Cat { talk() { console.log('meow'); } } It's something along the lines of: var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }()); The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE…

Wait... are you saying that TypeScript's ES5 output doesn't conform to the ES6 standard??? Why would that matter? There's no standard for it! I thought you were saying that TS -> ES6 was not valid ES6.

Also, properties set on the prototype will fail propertyIsEnumerable() and also hasOwnProperty(). for..in loops should always be filtered by hasOwnProperty() in any sane code base anyway.

(I tested the TS output for that class in Node 5 and my own browser, and the property did not come up in the loop, so I just don't think this is an issue in reality.)

Re: Flow vs. Typescript

#146

Post by cageface »

chris_st wrote: post #113
cageface wrote: post #48

Earlier quoted context omitted.

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.

You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it. 1: https://github.com/bbatsov/rubocop

I started using rubocop earlier this year and I've become a huge fan. It's done a lot to improve the quality of my code and the consistency of code on projects with multiple developers.

Re: Flow vs. Typescript

#147

Post by shados »

smt88 wrote: post #145
shados wrote: post #144

Earlier quoted context omitted.

Just try it. Look at what is the output for the following code: class Cat { talk() { console.log('meow'); } } It's something along the lines of: var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }()); The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE…

Wait... are you saying that TypeScript's ES5 output doesn't conform to the ES6 standard??? Why would that matter? There's no standard for it! I thought you were saying that TS -> ES6 was not valid ES6. Also, properties set on the prototype will fail propertyIsEnumerable() and also hasOwnProperty(). for..in loops should always be filtered by hasOwnProperty() in any sane code base anyway. (I tested the TS output for th…

The difference is actually somewhat subtle, but is shown here under class/enumerable. Same deal about classes requiring new (a lot of libs actually have bugs for only testing against compiled classes with older Babel and using .apply on classes): https://kangax.github.io/compat-table/es6/

And all I was saying is that the spouting of "TS is a superset of ES6!" is not that simple, since most usage will be (for now) with the ES5 output, where it isn't compliant in subtle ways that do cause problems/bugs. Nothing more :)

Obviously there's even cases here TS is compliant and Babel is not. Babel will call those bugs instead of spouting their compiler has no compromises like a lot of the comments here try to imply to convince people.

Re: Flow vs. Typescript

#148

Post by iofj »

greenspot wrote: post #29

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…

These are the sort of things you could argue in favor of using GWT.

Re: Flow vs. Typescript

#149

Post by DJCordhose »

iofj wrote: post #148
greenspot wrote: post #29

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…

These are the sort of things you could argue in favor of using GWT.

GWT compiles Java to JavaScript. The issue with it is that the semantics of Java and JavaScript are fairly different. Makes debugging and integrating native JavaScript libs harder.

Re: Flow vs. Typescript

#150

Post by cabalamat »

untog wrote: post #124
cabalamat wrote: post #118

This would be a good deal less irritating if it was written as an essay and not a slideshow.

You could always rewrite it yourself. Not every submission to HN was created as or intended for a Hacker News audience. The author wasn't under any obligation to publish their slides, personally I'm glad they did.

> Not every submission to HN was created as or intended for a Hacker News audience

That's a good point.

Post reply on HN