101–110 of 123 posts
That being said, the only way forward is to learn! But there seems to be total lack of solid learning resources with plentiful of examples and most importantly "best practices" that explain why the new construct is better and when to use it over the old way.
I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
I'm not sure this answers your question, but: I've been working with TS for the past couple of years but now I'm working on a Flow project. Flow doesn't even compare. It falls short on many things TS would immediately flag, and just feels less thought-out (subjective I know). Tooling support is terrible and while not the language's fault, it means it just doesn't help you as much as it could. Using Flow basically bec…
".... at least if they use flow, they are bagging up their shite which is better than a open field of the stuff".
I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
1. it often fails to find the type for an imported piece of code 2. more often than not refers to the type definition being a problem rather than whoever's calling a function with an incorrect type 3. it seems to have an issue with cache busting(?) (I `killall flow` multiple times per day to make sure it's not complaining about old code)
All in all I feel very sad for choosing Flow over TypeScript two weeks ago. We felt TS would be more invasive to our Webpack pipeline but I think I might just take a weekend to migrate over to TS...
TS seems to have a lot more type definitions available as well, a more active community perhaps?
Looking at the issue list of Flow I'm starting to suspect they're not very active in maintenance / issue handling. TS seems much more active.
I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?
Earlier quoted context omitted.
Talking about flow, I was wondering: couldn't something like that be implemented just with comments, leaving us with actually 100% valid javascript? Eg: // @param somestring [String] yadda yadda // @return [Boolean] function somefunction(somestring) { // @type [Boolean] var ret; ... return ret; } This would remove any type of "lock in" if you want to use it...
I'd prefer that approach too, as I can also document things at the same time as providing type annotations; flow-jsdoc looks interesting, but I don't know how easy it would be to plug into a Babel/Webpack+Babel workflow: https://github.com/Kegsay/flow-jsdoc
It can also build really nice HTML documentation to.
Earlier quoted context omitted.
Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.
Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.
Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking).
Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny.
I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).
Earlier quoted context omitted.
IntelliJ Ultimate user here, writing and refactoring TS works quite well. There are some minor issues (e.g. sometimes it doesn't show the usual "this method is overridden in a child class" indicator), and refactoring likes to randomly modify somearray['foo'] when renaming a someclass.foo property, but I can live with that.
How is Flow looking in webstorm? As good as their typescript support?
I did have to turn off code completion based on flow, because it slowed down the IDE noticeable (they do warn of this next to the setting...), but I hope that support will improve in the next versions, as flow gets more mature.
Earlier quoted context omitted.
I also avoid VS, but VSCode is nothing at all like its big brother. It's actually very quick and lean. If you're interested in TypeScript at all, the two were made for each other. I'd suggest giving it a try. Just note it's closer to a text editor with IDE functionality, rather than a full-blown IDE itself.
I can pretty much get that and more with Notepad++ or Sublime, though. I've moved back to vim for simple text editing, N++ for casual writing and organizing my thoughts. Is there any specific feature that makes it better than other editors in your book?
Honestly if I could get TFS integration on the level of GIT (for work, although ideally we would migrate to GIT) I would dump VS - it's bloated, when stuff fails you have no clue why or hope of fixing it, VSCode mostly wraps CLI tools so if the default integration fails you can work your way through it, unlike fucking TFS magic VS integrated tracking failing or whatever.
VS is still the only choice for .NET proper, but for .NET Core VSCode is usable enough and improving.
TS integration is the best I've seen, they are the first to support new TS features
Earlier quoted context omitted.
Picking and choosing language features via babel plugins (many of which will never become part of JavaScript) is an anti-feature. You essentially are creating your own language that only you understand.
We don't support custom syntax that isn't already a proposal (meaning it has potential to be in JS), and we also encourage using presets like https://github.com/babel/babel-preset-env instead of providing your own configuration of plugins unless you are more of a power user. It's our intention as a tool to align with TC39 and transition users to using native JS when it's supported
Earlier quoted context omitted.
I can pretty much get that and more with Notepad++ or Sublime, though. I've moved back to vim for simple text editing, N++ for casual writing and organizing my thoughts. Is there any specific feature that makes it better than other editors in your book?
Apart from Intellisense completion, a full featured integrated debugger, version control integration wich supports line wise staging, a diff viewer, a fast integrated terminal that even gets link detection in the next release, proper variable renaming and a working "Go to Definition" that is even implemented in most of the third party language plugins? No. Pretty much the same as Notepad++.