I love JavaScript. I program in it everyday. This is a great list of useful tools.<p>That being said, I disagree with the main premise. The tooling is getting there but it's just not as good as old-school IDE's for typed languages. Specifically, the code insight tools don't really compare. For example: Intellisense, refactoring, go to definition of a symbol, and find symbol references.<p>I programmed in typed languages for many years and when I find myself back in an old-school IDE for a typed language like Eclipse or Visual Studio a cognitive load is lifted off my shoulders.
No love for react-devtools [0]? I'm amazed it wasn't even an honorable mention, considering he mentioned react and redux (which is probably generally used with react).<p>I'm also surprised he didn't mention flowtype [1], which is by Facebook and is supported by Babel! If you're writing React, you're probably already using Babel, so using flow is very low friction.<p>Furthermore, if you're interested in runtime assertions, you can use babel-plugin-typecheck [2], which will convert your flowtype annotations into assertions. If we're looking to be pragmatic, IMO, this is the optimal path to take. The library that Elliot is working on looks interesting, but even he recognizes in its page that it's still a work-in-progress.<p>If you're writing a modern JS app and you wanna take advantage of all the ES6 goodies, you'll pick up babel. And if you're using babel, you can get jsx and flowtype for free. It's ridiculous to try and build a JS app without some sort of bundler, whether it's browserify or webpack. And if you're gonna use a bundler, pulling in a transpiler like babel is really easy and it lets you write much saner code.<p>Oh, and if you're already drinking the Facebook kool-aid with react, jsx, and flowtype, you'll wanna give nuclide a shot. As I understand it, it has nice flow support, with stuff like "click-to-define" and inline linting [3].<p>I'm using flowtype annotations with the babel plugin I mentioned above, but due to my usage of non-standard features, I can't successfully run flow itself over my codebase. I'll also note that my experience with nuclide when I last tried it was underwhelming.<p>[0] <a href="https://github.com/facebook/react-devtools/" rel="nofollow">https://github.com/facebook/react-devtools/</a><p>[1] <a href="http://flowtype.org/" rel="nofollow">http://flowtype.org/</a><p>[2] <a href="https://github.com/codemix/babel-plugin-typecheck" rel="nofollow">https://github.com/codemix/babel-plugin-typecheck</a><p>[3] <a href="http://nuclide.io/docs/flow/" rel="nofollow">http://nuclide.io/docs/flow/</a>
> “JavaScript sucks for large apps because it can’t even identify the type of a variable, and it sucks for refactoring.” ~ lots of very confused people<p>The article then goes on to not use the word "refactor" again. So tell me, why am I confused? Because I have some pretty expensive JS tooling and refactoring JS absolutely, 100% still sucks compared to a statically typed language with a good IDE.
Was this written only to promote <a href="https://github.com/ericelliott/rtype" rel="nofollow">https://github.com/ericelliott/rtype</a> and <a href="https://github.com/ericelliott/rfx" rel="nofollow">https://github.com/ericelliott/rfx</a>?<p>They seem great. Are there any other good gradual type hinting platforms for Javascript anywhere?
Honest question and a bit of a side-note, is javascript actually fast? Because in my experience it's still pretty slow, it's just relatively faster than it was.<p>For example I remember doing a Mandelbrot set generator in js about 3 years ago and it was a lot slower than C#. I'm talking orders of magnitude, methods that took 10 ms in C# would take 1000 ms in js.<p>But worse than that it hit incredible performance problems when I had an array of more than 10,000 items and tried to use push/unshift or a shift/pop.<p>I'm no language expert, and I never really dug into why as it was just for fun. Be interested to hear other people's perspective or a more technical explanation. I'm not really interested in those 'we tested these simple method speed' comparisions, I'm more interested in practical experiences.<p>EDIT: Regarding tooling, I'm presently optimizing js in a client's site and the profiling in dev tools is still basic compared to professional tools in C# for example, so this guy needs to expand his experience if he thinks DevTools is 'good'.
> “JavaScript sucks for large apps because it can’t even identify the type of a variable, and it sucks for refactoring.”<p>So where are the toolings for refactoring then? Article doesn't mention a single one.
Seems weird to not see Google's closure compiler on a list about JS dev tools that includes a linter.<p>I haven't gotten around to playing with Babel or ES6, and I want to. I haven't bothered to Google it yet, but anybody have experience with Babel + Closure compiler? Is it easy, or difficult and inconvenient, or not possible?
Atom tern-js is a keeper! I also use mancy, which is a javascript repl with really good code completion: <a href="http://www.mancy-re.pl" rel="nofollow">http://www.mancy-re.pl</a>
A lot of what he says about hot reloading has actually been spearheaded out of the ClojureScript community. Look at figwheel, for example. I'm glad that those concepts are coming to plain js.
It's hard to argue that the all-round experience JavaScript development is better than say Java/C#. The former language has to deal with at least 2 different ecosystems: NodeJS and Browser and the latter usually try its best to give consistent experience everywhere. One would argue that optimizing for specific environment is better but in the case of JavaScript, I don't feel that way.<p>The library/tools churn in JavaScript is another issue that a few people have raised as a concern. I used to think that companies are crazy (or wasteful) to create their own collection/mvc/widget/utility libraries or tools but I suppose it's better than to migrate from one used-to-be-popular library to another current-du-jour library by the time your infrastructure (build, test, packaging pipeline) is already set in stone and you're focusing on building products.<p>JavaScript for large app/large team, does it work? yes it does. But you have to be _very_ discipline and skilled. Apprenticeship might work for C#/C++/Java/Rails (yes, Rails specifically) but it's definitely harder in JavaScript. Some people might not like to hear this but for a large team/large app, you have to impose structure, convention, rules, etc which may be at odds with the liberty/freedom that JavaScript can offer.<p>Those DO's items for JavaScript such as to build small contained function/libraries may not applied as-is given certain complex requirements (say Single Page App). Eventually your controller/presenter code evolve (sure, we still try our best to break down the complexity but it won't be as cute as underscore library).<p>Disclaimer: I use JavaScript every day and am part of the team that builds large products (SAP Lumira, SAP Cloud for Analytics) using JavaScript (90-95% of the code base, front-end and back-end. Yes, that's right ;) SAP+JavaScript).
One of the reasons that static tooling with JS (intellisense, static analysis, go to definition) lags behind those for other languages is the lack of consistent class syntax. Some explicitly create prototypes, some simply attach closures to `this`, and yet many others create their own utility routines to create and extend classes. This makes it incredibly hard to analyze the code structure and infer the methods and properties a certain instance may hold.<p>ES6 may help with this, but it will be a long time before ES6 are natively supported and ES6 class syntax are adopted among devs.
Thanks for sharing such great list. My everyday coding somehow relates JavaScript. Visual Studio is the best IDE i have ever used, though it has some intellisense issue only for javascript, specially when your project consumed many libraries and some of the library used same method name. As a debugging tool Chrome Dev tool is awesome.