
Must-See JavaScript Dev Tools - ericelliott
https://medium.com/javascript-scene/must-see-javascript-dev-tools-that-put-other-dev-tools-to-shame-aca6d3e3d925
======
ryanackley
I love JavaScript. I program in it everyday. This is a great list of useful
tools.

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.

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.

~~~
stephenr
I don't really write much JS these days, but JetBrains IDE's (IDEA, PHPStorm,
WebStorm) are able to provide pretty good code intel (and do refactoring) for
e.g. PHP using DocBlocks (or of course language type hints/return types now) -
I'd imagine the same is true of JS using JSDoc DocBlocks, no?

I know for front-end, and also a reasonable number of back-end web developers
in scripting languages lightweight editors like Sublime, Atom etc are popular
these days.. maybe that's driven the idea that "scripting/untyped/loose typed
languages can't have good Code Intelligence"?

~~~
mateuszf
Yes, JetBrains IDE's for dynamically typed languages are pretty nice, but what
they allow is still nothing compared what Intellij IDEA does for Java. And I'm
saying this as a fan of Clojure which is not statically typed.

~~~
stephenr
Can you give an example of an IDE feature in eg Java that isn't incorporated
for a language like say PHP?

~~~
mateuszf
100% right code completion, call hierarchy, navigations, accurate safe
refactorings. True, it is possible to use reflection (kind of metaprogramming)
to call a method in Java too, but it's done sporadically because of various
reasons. It's not just a matter of additional features, but rather a matter of
being sure that they will just work without thinking about edge cases.

~~~
stephenr
I don't know how the IDEA/etc code completion for Java/etc works, but for PHP
it works from stub files (i.e. they have an engine that can build completion
info from actual PHP files, and then they create stubs of the builtin
classes/functions) so it works well (and you get the exact same level of
support for included libraries or project src) except for one repeating issue:

There is apparently less effort spent making sure those stubs are really
accurate.

Does anyone (do JetBrains staff read HN?) know what process they use to
generate the stubs?

------
TheAceOfHearts
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).

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.

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.

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.

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].

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.

[0] [https://github.com/facebook/react-
devtools/](https://github.com/facebook/react-devtools/)

[1] [http://flowtype.org/](http://flowtype.org/)

[2] [https://github.com/codemix/babel-plugin-
typecheck](https://github.com/codemix/babel-plugin-typecheck)

[3] [http://nuclide.io/docs/flow/](http://nuclide.io/docs/flow/)

~~~
ericelliott
Flow's type inferrence features are great, but I'm not a fan of the inline
type annotations, which is one of the major reasons I didn't just use it
instead of working on rtype/rfx.

I believe that both Flow and TypeScript are competing solutions that are
precursors to what may eventually become standard in JavaScript. At that
point, all the annotations written for Flow and TypeScript will become
obsolete overnight.

This is essentially the same thing that happened to AMD, and one of the
reasons that I advocated for users to chose Node-style modules and Browserify
(and now Webpack) instead of AMD.

I consulted on several projects and gave exactly that advice. They didn't
listen. Now they're stuck supporting a huge AMD legacy & Bower ecosystem and
the authors of Bower are no longer supporting it.

That is the future that awaits those who build TypeScript + Flow-annotated
applications. Fine if it's just a few modules here and there, but for large
enterprise apps, you're building a mountain of technical debt what will
eventually need to be paid.

Don't get me wrong, I am really excited that Flow and TypeScript are paving
the way, and I blatantly stole some good ideas from them for rtype/rfx, but
I'm also very wary about leading people down a road that I am pretty confident
will dead-end within a few years.

Both projects still have great value though. We learned a lot from AMD, and it
has influenced the new standards. I am confident that TypeScript and Flow with
both influence whatever we get in the JS standard. I know the TypeScript team
is already experimenting with additions to the runtime reflection
specifications coming in future iterations of ECMAScript.

~~~
WorldMaker
With regards to AMD: SystemJS is a polyfill for the ES2015 module loader
designed to remain a set of plugins to said module loader should a browser
actually start to implement it. The plugins include the ability for the ES2015
module loader to directly load AMD and CommonJS modules, thus none of the
legacy AMD is technically lost and you also don't necessarily need something
like Browserify/Webpack in a build process or Node-style modules (CommonJS).
JSPM is a package manager for SystemJS and for the most part it can be fairly
straightforward to move from Bower to JSPM.

With regards to Typescript: I don't think it is a "dead end" and I definitely
think you are wrong about the future of it. Typescript has been relatively
careful at keeping "an eye to the horizon" and having some idea of the
"forward compatibility" of its features. For instance, the module format in
Typescript was built before the ES2015 standard finalized, but the final
standard was surprisingly close to what Typescript used and nothing
necessarily required being rewritten and it was very easy to clean up the old
style incrementally if you did feel like being particular about using the
final ES2015 syntax. I feel like the same can be said about Typescript's type
annotations. They are definitely informed by ES4 ("the lost version", what
forked into ActionScript, sort of) and in turn, yes, the Typescript team is
certainly influencing the standards to possibly add type annotations to the
EcmaScript standards ("this time for real"), or at least a Python 3-like
approach where type annotations are safely ignored by browsers when left in
the code.

At the very least, if ES standardized type annotations are suitably different
from Typescript there will presumably be a Typescript transpiled output to it
(just as the old Typescript module imports get output correctly when targeting
ES2015), and you can even use that output to bootstrap your conversion to the
new syntax (thanks to Typescripts attempt to remain a pure superset of ES).

------
peeters
> “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

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.

~~~
Roboprog
This seems less of an issue when your JS codebase is more "FP" and less "OOP".
Or, using more composition and less inheritance. (it's funny that even Go-lang
manages just fine w/out inheritance)

Thankfully, I've been doing more JS, and less Java, in the last year. Despite
the curly braces, it feels like going back to the golden age of the 80s
sometimes, before the original sin of C/++/Java. I remember using dynamic
languages and (in very small part at school) Lisp (as well as better static
languages) before C and its spawn were shoved down our throats for the better
part of 20 years.

(Unix is a great OS, but C is just a portable assembler, not a good high level
language model)

It's a shame JS had to be dressed up to even look like Java/C++. We got
functions, we got dynamic size arrays/lists, we got property lists with atoms,
lists and functions as values. Hoo-boy!

------
fiatjaf
Was this written only to promote
[https://github.com/ericelliott/rtype](https://github.com/ericelliott/rtype)
and [https://github.com/ericelliott/rfx](https://github.com/ericelliott/rfx)?

They seem great. Are there any other good gradual type hinting platforms for
Javascript anywhere?

~~~
Touche
> Was this written only to promote ...

Yes. Notice this is a list of only the trendiest of tooling and excludes many
great and popular tools that aren't used by the cutting-edge react-webpack-
flux-babel developer this post is directed towards.

The goal is the same as commercials with attractive people, associative
advertising.

------
mattmanser
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.

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.

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.

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.

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'.

~~~
coldtea
It's much faster than Python, Ruby, PHP scripting languages in microbenchmarks
testing just the language's features (no C libs). It can get to 1.5x / 2x
slower than C.

You can get whole games like Quake to compile and run in real time in JS and
in high resolution, so the Mandelbrot set should pose no issue at all.

You need to take care to work with the JIT though, not sabotage it. Perhaps
the code went in an non-optimal way?

For Mandelbrot, eg. instead of an array of tons of objects you could allocate
memory in a buffer and have JS manage it.

~~~
mattmanser
Quake was released in 1996, so what's so amazing about that? Because of
Moore's law a 20 year old game running in IE6's javascript engine would
probably be fast enough.

The equivalent Ruby, Python or PHP could easily run Quake on today's hardware.

Also, what do you mean by 'much'. Like orders of magnitude or 30%?
Microbenchmarks are fairly useless.

~~~
coldtea
> _Quake was released in 1996, so what 's so amazing about that?_

I didn't say Quake 1. Actually all of Quake 1-4 has been ported to run under
JS/WebGL. Besides, it's still amazing given that the rendering happens in high
resolutions and gets good refresh rates.

Moore's law or not, Python and Ruby can't pull this off with the same speed.

> _Also, what do you mean by 'much'. Like orders of magnitude or 30%?_

For things that test the raw language (e.g. its interpreter and
implementation, instead of directly calling to some C helper that does
everything like e.g. Math.cos would do) it's usually an order of magnitude.

------
romanovcode
> “JavaScript sucks for large apps because it can’t even identify the type of
> a variable, and it sucks for refactoring.”

So where are the toolings for refactoring then? Article doesn't mention a
single one.

~~~
ericelliott
The JS ecosystem has largely embraced small modules and microarchitectures
over monolithic code, which pretty well sidesteps the need for cross-project
refactoring tools that are popular with Java and C++.

If you have a refactoring problem, I suspect it's a symptom of a monolithic
architecture problem. Solve that, instead. =)

~~~
romanovcode
>monolithic architecture problem.

Having monolith is not a problem. In many cases having it makes perfect sense.
Making everything micro-services because it's hot nowadays - that's a problem
though.

------
dahart
Seems weird to not see Google's closure compiler on a list about JS dev tools
that includes a linter.

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?

~~~
timothya
The Closure Compiler supports compiling ES6 code already, and can also do
transpilation down to ES3/ES5. [1][2]

Google also has the Traceur Compiler which does transpilation of new JS
features (ES6, ES7 proposals, and a couple of features that aren't in either)
into older versions. [3]

[1]: [https://github.com/google/closure-
compiler/wiki/Releases#oct...](https://github.com/google/closure-
compiler/wiki/Releases#october-15-2015-v20151015)

[2]: [https://github.com/google/closure-
compiler/wiki/ECMAScript6#...](https://github.com/google/closure-
compiler/wiki/ECMAScript6#transpilation) (might be a bit out of date, since
there have been releases since that document was last edited)

[3]: [https://github.com/google/traceur-
compiler](https://github.com/google/traceur-compiler)

~~~
dahart
Holy crap, I wasn't paying attention and missed that annoucement... awesome!
Thanks, I have no excuse not to try it now.

Poking around, Traceur looks like something to play with and get acquainted,
but not for production code just yet?

------
gamesbrainiac
Atom tern-js is a keeper! I also use mancy, which is a javascript repl with
really good code completion: [http://www.mancy-re.pl](http://www.mancy-re.pl)

------
johnjelinek
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.

~~~
ericelliott
Much credit is due to Elm and Figwheel, which both served as inspiration for
the JavaScript time travel debuggers such as Cerebral and Redux.

------
edwinnathaniel
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.

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.

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.

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).

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).

------
niix
This author reminds me of the BuzzFeed for JavaScript.

------
markmywords
Oh dear, these splash images are getting out of hand :)))

------
netheril96
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.

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.

------
dgellow
I didn't know about iron-node, it's an awesome tool!

Great stuff, thanks for sharing.

------
luisrudge
Visual Studio Code is not an IDE. It's just a bad named Editor

~~~
Klathmon
I disagree with this sentement.

I haven't used Visual Studio Code enough to be able to speak to it
specifically, but editors like Atom and Sublime can be outfitted to basically
be IDEs.

I can actually do more with Atom now than i could with Webstorm just a year
ago.

~~~
luisrudge
atom + plugins, not just atom. Same with vs code. If we count plugins, emacs
and vim are both ide's as well.

~~~
coldtea
Well, in VS Code case, just VS Code is enough.

Plus, IntelliJ and Eclipse BOTH implement ALL of their functionality as
plugins. It's just that they come with a default set of plugins pre-installed.

------
tasnimreza
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.

------
voltagex_
[http://vorlonjs.com/](http://vorlonjs.com/) is pretty amazing.

