Static? I use my own type-checking/enforcing lib as a base for everything I write in JS or CS (https://github.com/phazelift/types.js). It's only 1.8kb, dynamic and never fails on me.
Facebook Launches Flow, Static Type Checker for JavaScript
231–240 of 282 posts
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#232There's some tremendous effort being poured into making a crippled language like javascript usable, but when talking about solutions for maintainable frontend code, I'm more excited about compile-to-js languages like haxe [0], purescript [1] or ceylon [2]. The caveats I heard about transpilers often boil down to difficulty of debugging and lack of libraries. But with the amazing browser dev tools we have, debugging p…
Last time I said this I was caught but I'll say it again. Nobody really wants to even touch Javascript without a 5 foot stick.
People will tell me that it is a good language if you know how to use it, comparing javascript mastery to C mastery in a sense. I think there lies the problem.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#233Re: Facebook Launches Flow, Static Type Checker for JavaScript
#234Re: Facebook Launches Flow, Static Type Checker for JavaScript
#235Earlier quoted context omitted.
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…
I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal. Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection. I can't remember one example of typ…
But JS does not have compile-time - you edit it, and you run it, no steps in between. If set up right you've got your unit tests running automatically whenever something changes.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#236Earlier quoted context omitted.
"better step in the right direction than the types of tools MS and Google have been putting out" The Google Closure Compiler ( https://developers.google.com/closure/compiler/ ) has been around for years and years. It does everything you mentioned (100% optional type annotations, type inference), plus more (dead code removal, inlining, compiler-time constants).
Google Closure: function hello(a){alert("Hello, "+a)}hello(3); Compilation was a success! No warnings No errors + it's not incremental hence unusably slow, requires Java. No, Closure is not the same as Flow even from a brief look at both.
That's because it's all valid Javascript - concatenating a string with a number is normal practice even in strongly typed languages (implicit type conversion). So, I don't see your point. If the argument 'a' had an annotation saying it should be a string, then I could understand an error from some checker tool, but then it wouldn't be vanilla JS anymore.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#237Earlier 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…
That's an outrageously overwrought type, though. Let's say a promise is a thing which can either succeed or fail eventually. If it fails, it gives a type e, if it succeeds a type a Promise e a Now, `then` operates on the successful result, transforming it into a new promise of a different kind. The result is a total promise of the new kind then :: Promise e a -> (a -> Promise e b) -> Promise e b I'll contest now that…
Couldn't agree more. I see this as just another example of how ordinary function composition usually wins out over OOP.
Additionally, AFAICT Promise-like things aren't actually used very much in Haskell in practice; at least not in the code I tend to see/write. MVar is probably the nearest direct equivalent, modulo error handling (which would probably just be handled using an Either in an MVar). Given that the runtime is M:N threaded, there doesn't seem to be much need for Promise and its ilk, since you can just do ordinary function composition and HoFs (with channels for communication). If you want something fancy you just use the marvellous "async" library.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#238Earlier quoted context omitted.
Surprise answer: It's not. When people sat down and decided how workers are to act in browsers - Actors are what they had in mind. This is why Web Workers don't have access to the window scope, use explicit message passing etc.
So to reply to both of you: Correct me please, but from what I understand web workers are not a part of the JavaScript language. The same way AJAX isn't a part of the JavaScript language. I would consider those (AJAX/WebWorkers) more like "system calls" to the browser. And like any system call, it has privileges the application doesn't.
To be precise:
- The JavaScript language is specified under the ECMAScript specification.
- Web workers are indeed not a part of the ECMAScript specification which considers them "host objects".
- WebWorkers and other browser APIs (timers, ajax etc) are called the DOM API. The DOM (document object model) is how JS interacts with the web page and what capabilities it exposes. (document.getElementById isn't any more JavaScript than web workers).
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#239Earlier quoted context omitted.
Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…
A lot of what you say is purely subjective. I would consider C++ to be way more verbose than Javascript. Especially with ES6 coming (and things like Flow / Typescript allowing you to use ES6 today). Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird. When you understand how it works, it's not a problem. Use it to your advantage. Not nice to optimize for?…
> I would consider C++ to be way more verbose than Javascript.
Rather damning with faint praise there.
> Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird.
Yes it does. In the '80s this was an open research area, but a consensus was reached in favour of lexical scoping for a reason.
> I get that Javascript has its quirks. But so do most languages.
False equivalence. Python (to pick an example I'm familiar with) has some quirks, sure, but it's a million times nicer to program in than Javascript, and it has all the other advantages you list (it's easy to get started with, suitable for complex apps, cross-platform and so on). I'm sure the same could be said for Ruby or OCaml or hundreds of other languages. If it were as easy to run these in the browser, I don't think we'd see anyone choosing Javascript - it really is a worse language than so many alternatives.
(I mean, by the standards of a single-application scripting language that was written in three days, Javascript is very good - we wouldn't expect such a language to be the equal of a carefully designed general-purpose programming language)
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#240Earlier quoted context omitted.
Read the Good Parts of Javascript and get a JS linter. Javascript is a fine language if you do this.
> Javascript is a fine language if you do this. No,it's not fine, it's a horrible language,with a few good features that saves it from being a catastrophy.hence "Good Parts". Or we wouldnt be here talking about Flow,Typescript or others if the language was "fine". JS was clearly not designed for what we are making out of it today. But since there is no way around Javascript in webdev,good or bad,it doesnt even matter…
You're criticizing the raw JS language, but that's not what most people in the industry are using. Fine, the original language design was horrible, but if you consider the typical stack used for web development (which could be any combination of transpilers like CoffeeScript/TypeScript, Flow, Promises, module systems, etc) it's not that bad.
Also we already have Strict mode; I imagine in the future it will get more and more uncompromising, so the JS subset we'll be actually using will be just fine.