121–130 of 158 posts
Earlier quoted context omitted.
I develop on Windows and deploy to Linux regularly, zero problems. Most of the projects are purely js with no dependencies on binaries.
Last time I tried to do something with Node on Windows I ran into the maximum path length issue, but I guess npm 3 is supposed to help with that?
Earlier quoted context omitted.
Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?
> but the ecosystem around Node is so much tailored around Linux I really don't understand why people keep saying this, it's simply not true. Node works fantastically on Windows. I've yet to come across a library that won't work on my Windows box (barring obviously platform specific stuff). Node-gyp works fine too, and many libraries with native code offer Windows versions. Especially when comparing to e.g. Ruby or P…
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".
This would be a good deal less irritating if it was written as an essay and not a slideshow.
This would be a good deal less irritating if it was written as an essay and not a slideshow.
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.
The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax. This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. It's inferred types are a much stronger system imo too - gets out of a developers way more. Typescript is great, but I really do pr…
Give that a shot if you're looking into that sort of workflow.
Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20
I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don…
To be fair, it's one line in a config file / tsc commandline.
>Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java)
Flow also uses structural typing, except for ES6 classes which it considers nominally typed.
>I don't remember the ramifications of this, but I think one was it makes Flow easier to work with/require less boilerplate
I can't imagine how that's related.
>I think the nullable operator was one case, where the operator Microsoft chose could be ambiguous with JavaScript code in Flow, so Facebook chose a different one.
I think you're talking about the type assertion operator which used to be angle brackets in TS. Yes it would cause syntax ambiguities with JSX. Since Flow had JSX support from the start for React, they chose a different operator (?:). When TS added support for JSX, they added another type assertion operator (as).
Earlier quoted context omitted.
No. With flow you can do both: var x /*: string*/ = "" var x : string = "" With TS you can only do the latter. The first one has the advantage that it's legal Javascript, thus not requiring a compiler. Since typescript is set-up purely as a compiler anyway I'm not sure it would be a useful feature for them. A disadvantage could be that it's easier to make silent errors by making syntax errors in the comments. I don't…
That's not entirely accurate. TypeScript 1.8 added the ability to use type information from JSDoc-style comments. For example: /** * @param {string} a * @param {number} b * @returns {string} */ function foo(a, b){ return a + b; } Is functionally identical to: function foo(a: string, b: number): string { return a + b; } See: https://github.com/Microsoft/TypeScript/issues/4790
Earlier quoted context omitted.
> but the ecosystem around Node is so much tailored around Linux I really don't understand why people keep saying this, it's simply not true. Node works fantastically on Windows. I've yet to come across a library that won't work on my Windows box (barring obviously platform specific stuff). Node-gyp works fine too, and many libraries with native code offer Windows versions. Especially when comparing to e.g. Ruby or P…
> 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".
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...