Who writes JS these days? Will it go with Angular/jQuery?
You got downvoted by people with broken sarcasm detectors...
Poe's law doesn't make it very easy.
Facebook Launches Flow, Static Type Checker for JavaScript
241–250 of 282 posts
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#242Earlier quoted context omitted.
TS bolts on a straightforward nominative type system without type unions (or non-nullable types), so it can't handle a variable typed as `number | string`, it'll immediately drop down to `any`. That is, flow aims to remain useful in the face of more JS idioms. It won't make a difference between nullable and non-nullable either, so AFAIK function length(x) { return x.length; } length(null); can never be a compile-time…
Union types are present in the master branch of the TS compiler. The compiler also uses instanceof and typeof === ... to reduce the range of types inside a branch, similar to Flow.
Due to ship with TypeScript 1.4 - see recent blog post: http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s...
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#243Another comment that just occurred to me: JavaScript becoming gradually typed is an interesting reflection of the recent history of the optimization of JavaScript interpreters, which consist of deducing where semantically dynamic objects behave like static class instances, then inlining the accessors and where beneficial, the "class methods", and specializing && JITing the semantically dynamic functions that almost a…
That's the basic principle Dart is founded on. (hardly surprising when the Dart authors are the same people who did V8)
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#244Can someone explain in simple words what is the problem that this would fix? I've never felt the need for this, why should I care?
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#245This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language. That said, I am curious what solutions this solves that isn't already solved by enforcing good code…
> This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language.
Typescript (from MS) sounds a lot like what you describe - it doesn't change Javascript, it just adds types to it (and makes some ES6 features available), and it puts a lot of work into playing nice with the wider JS ecosystem (e.g. via the definitelytyped project, which integrates type definitions for most popular "third-party" javascript libraries).
> That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. Full disclaimer, the largest js projects I've worked on were in the tens of thousands of lines, not hundreds of thousands, but type checking just seemed completely unnecessary provided a good coding guide and test coverage were maintained and enforced.
Perfect testing can do everything a type system can. But a type system can do it with less programmer effort, much lower maintenance overhead, and in a standard form that makes it easier to maintain. So you can do the same thing but cheaper - or, more realistically for how software is developed in most companies, you can get better reliability for the same engineering budget.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#246Earlier quoted context omitted.
Well, here are some things that it does that other tools don't: - It type checks JSX - It supports some ES6 features others don't (like destructuring) as the build step - It has union types (TS will get those soon, already in master) - It does a lot more inference and a lot more assumptions. It assumes you won't multiply a string by a number for example (although technically '10' * 5 is legal in JS). So it's opiniona…
I digress but... you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibi…
All the time, in my case.
Today I got the order of parameters to a callback wrong ("error" was the last rather than the first parameter). The documentation didn't say anything about parameters, it only said that the callback would be called with a result. I had to look into the source code to discover the details. I am not sure if Flow would be able to catch this kind of bug but if so, it would certainly save me a lot of time.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#247Earlier quoted context omitted.
Strongly typed JS is actually pretty hard - probably not by Haskell and Scala standards - but if you take promises for example the signature of `then` is: Promise -> ((A -> (Promise | B)),(E -> (Promise | C))) -> Promise That is - a promise's then - takes the promise (as this) and executes either a `.then` fulfillment handler or a catch handler. If the `fulfill` handler executes the value is unwrapped and either a ne…
I don't want to say what I'm about to say, but... I don't care about the type signature of promises. I actually don't care about the type of anything which has a complicated type; I think it's just incredibly winning that I will now be able to describe the shape of the raw data circulating in my code. I've always found really annoying, in Haskell, to see incredibly complex type idioms emerging to allow stuff that doe…
There's certainly a hierarchy; if you don't have typed data then you won't benefit from generics. If you don't have typed containers then forget about monads. If you don't have simple monads then no point worrying about how to compose them.
And yet, as someone who's been working in Scala for nearly 5 years now, more and more of these abstractions are starting to seem "worth it". My first Scala code was quite imperative, mixing random effects left and right. But eventually I started handling async calls explicitly - or perhaps I should say, I became fluent enough in the language that I could make an explicit distinction between sync and async calls without in being too cumbersome - and then I reaped the rewards, with more reliable, more performant, more maintainable code. And then I did the same thing with error handling, replacing surprise exceptions with an explicit Either (stacking this inside the Futures), and again I found my code became clearer, easier to reason about.
I've just finished factoring out database access into a Free monad based construct, and for the first time in my life I can test database access in a smarter way than just creating a (possibly in-memory) testing database and hoping it does the same things a real database would do. The monad tools are good enough to make it easy - as easy as "magic" Spring AOP, but explicit and ordinary. I've written a library for dealing with monad stacks that I'm sure would have horrified myself of three years ago (https://github.com/m50d/scalaz-transfigure), but I've come here through small incremental steps that have made sense at every stage (it helps that I'm a big believer in Agile). If I'd been dropped in it with a language like Haskell where everything has to be monadic from day 1, I think I'd've given up. I still wouldn't use monads for I/O (at least, not yet) - the advantages don't seem worth the overhead. But I'm glad I'm working in a language where these things are possible, and where I can gradually adopt them in my own time.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#248Whatever people's thoughts on the language itself, JavaScript has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast.
It helps that companies like Google and Facebook have invested a significant amount of research power into designing frameworks and tooling around it. Just from there two companies alone, we have tools like React, Angular, Karma, JSX, Jest, and now Flow. Tooling that involves the browser more include Polymer and Traceur (ES6 to ES5 transpiler).
To contrast this, I have been doing development with Cordova the past week & writing Cordova plugins to fill in missing functionality - the plugin ecosystem with Cordova is horrid, and the documentation is often awful. To compound it, Android developers don't seem to believe in documenting their libraries well.
I will take the JS ecosystem any day when confronted with a choice like that.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#249Earlier quoted context omitted.
> But type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. You know where else none of that exists? In the machine code on which the JVM rests and to which Java code can be JIT compiled by the JVM before execution. So, if you can't have it compiling to JS, you never could have it on the JVM, either.
It's not the same thing at all. Javascript isn't machine code, and it isn't bytecode. It's its own completely separate high-level language, that executes in an unsafe, unpredictable and highly mutable environment.
You should tell that to google adwords, inbox, and AWS console, then. All of them are developed with GWT, and haven't functioned in any unsafe, unpredictable, or highly mutable way.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#250Earlier quoted context omitted.
I'm not sure if what you are describing is that realistic. A function that is used in some weird incorrect way that it won't get caught in development, QA or unit testing? Perhaps that can happen, but it's not been my experience. I use assertions liberally; they are especially helpful when refactoring and trying to figure out all of the dependent code that needs to be updated. Sure it's less certain than what you get…
The point is that you substitute the extra testing and QA with types. The assertion doesn't guarantee type correctness, so you test that function and downstream functions. That's extra code burden. Instead, you could have type checking.
I disagree, tests and QA happens regardless. Adding a compile step to development is a big downside to the type approach.