14 ms·

Must-See JavaScript Dev Tools

177 points by ericelliott 11y ago

gamesbrainiac 11y ago
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
dgellow 11y ago
I didn't know about iron-node, it's an awesome tool! Great stuff, thanks for sharing.
TheAceOfHearts 11y ago
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/
- makepanic 11y ago
  The Ember Inspector [0] is another great devtools addon for developing Ember applications. [0] http://guides.emberjs.com/v2.2.0/ember-inspector/installation/ http://guides.emberjs.com/v2.2.0/ember-inspector/installatio...
- ericelliott 11y ago
  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 11y ago
    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).
fiatjaf 11y ago
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?
- gcanti 11y ago
  Shameless plug: https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb. Used in development/production in several places, included the new MapBox Studio
- Touche 11y ago
  > 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.
  - deleted 11y ago
    [deleted]
- ericelliott 11y ago
  No, that's not why, but thanks for the complement. =) I gave a talk at the O'Reilly Fluent conference a while back discussing lots of the developer tooling that was available for JS a couple years ago. I wanted to gauge general awareness of the tools, so I conducted some informal audience hand-raise surveys. I was shocked at the number of people at a JavaScript conference that weren't aware of the great JavaScript tools that I took for granted. That's why I wrote the article. I think there's a lot of value in a general ecosystem overview. What kinds of tools are there, what are the tools like? Are there interesting future trends to make note of? I think raising awareness of the overall ecosystem is valuable. The only reason I even mentioned rtype and rfx is because I'm not satisfied with the type tooling available for JavaScript right now. Flow and TypeScript are supersets of JS, so to really embrace those, you have to step away from the standard - something I'm not willing to do at that level. JSDoc is not live code at all, and it easily falls out of sync with your source. It's also awkwardly verbose, and only loosely JavaScript based (essentially copied from Javadoc). React users have React.PropTypes, which is pretty cool, but too React-specific and also awkwardly verbose. I am working on rtype/rfx to fill a void in this department. If there was anything I believe to be better, I'd happily link to that, instead. =)
ryanackley 11y ago
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 11y ago
  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"?
  - inglor 11y ago
    This. I love the look of awe sublime people have when I open webstorm - perform a "go to definition" and it just works. It's amazing how many capabilities people miss on.
    - Lio 11y ago
      I guess it depends on the code base you're working on. My main experience of using webstorm was on a client's legacy code base. Their policy was that webstorm had to used over any other tool. None of the clever feature like go to definition worked properly and it ended up just dropping back to grepping for symbols project wide. Personally I couldn't see any features you couldn't get from using TernJS and ctags with a quality editor. I found it a bit slow and the keyboard navigation to be about limited. (Not in the main editor so much but in little things like navigating window splits, manipulating pairs, etc)
voltagex_ 11y ago
http://vorlonjs.com/ http://vorlonjs.com/ is pretty amazing.
luisrudge 11y ago
Visual Studio Code is not an IDE. It's just a bad named Editor
- Klathmon 11y ago
  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 11y ago
    atom + plugins, not just atom. Same with vs code. If we count plugins, emacs and vim are both ide's as well.
    - Klathmon 11y ago
      But the main selling point of Atom is it's plugins. If you don't count the plugins, it's barely even an editor (even syntax highlighting is a plugin). And I agree with the last part as well. Properly configured Emacs and vim can be used as IDEs, however they can also be used as editors.
    - coldtea 11y ago
      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.
- coldtea 11y ago
  It has an integrated debugger and build options -- which is the minimal to NOT be an editor and be an IDE. It also has some refactorings and even a console and plugins. What do you think it lacks to be an IDE? Note that it's also also in early stages atm.
mattmanser 11y ago
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'.
- lojack 11y ago
  It's fast for IO bound applications because of its natural asynchronousity. For CPU bound applications, it's moderately competitive with other interpreted languages, not particularly fast, but acceptable for a lot of things.
- xiaoma 11y ago
  It's fast compared to Ruby or Python, but slow compared to Java or C#. You really wouldn't want to do number crunching in it anyway, since it only has one type of Number—floats.
- coldtea 11y ago
  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.
johnjelinek 11y ago
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 11y ago
  Much credit is due to Elm and Figwheel, which both served as inspiration for the JavaScript time travel debuggers such as Cerebral and Redux.
markmywords 11y ago
Oh dear, these splash images are getting out of hand :)))
niix 11y ago
This author reminds me of the BuzzFeed for JavaScript.
edwinnathaniel 11y ago
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).
netheril96 11y ago
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.
peeters 11y ago
> “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 11y ago
  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!
tasnimreza 11y ago
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.
romanovcode 11y ago
> “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 11y ago
  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. =)
  - peeters 11y ago
    So to answer the OP's question, we're not confused, and JS still sucks for refactoring? (as I have to maintain a big monolothic client-side JS app, and good tools for refactoring would be most welcome)
  - romanovcode 11y ago
    >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 11y ago
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 11y ago
  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#october-15-2015-v20151015 https://github.com/google/closure-compiler/wiki/Releases#oct... [2]: https://github.com/google/closure-compiler/wiki/ECMAScript6#transpilation https://github.com/google/closure-compiler/wiki/ECMAScript6#... (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 11y ago
    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?
- ericelliott 11y ago
  IMO, the main benefit of Closure Compiler are the type checking errors. However, it's a pretty heavy handed solution for that compared to existing tools like JSDoc + TernJS, or DefinitelyTyped TS annotations. It relies heavily on JSDoc, and I believe JSDoc has had its time, and is on its way out (being replaced by tools like Flow, TypeScript, rtype/rfx).

177 points by ericelliott 11y ago

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

dgellow 11y ago

I didn't know about iron-node, it's an awesome tool! Great stuff, thanks for sharing.

TheAceOfHearts 11y ago

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/

makepanic 11y ago
The Ember Inspector [0] is another great devtools addon for developing Ember applications. [0] http://guides.emberjs.com/v2.2.0/ember-inspector/installation/ http://guides.emberjs.com/v2.2.0/ember-inspector/installatio...
ericelliott 11y ago
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 11y ago
  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).

fiatjaf 11y ago

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?

gcanti 11y ago
Shameless plug: https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb. Used in development/production in several places, included the new MapBox Studio
Touche 11y ago
> 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.
- deleted 11y ago
  [deleted]
ericelliott 11y ago
No, that's not why, but thanks for the complement. =) I gave a talk at the O'Reilly Fluent conference a while back discussing lots of the developer tooling that was available for JS a couple years ago. I wanted to gauge general awareness of the tools, so I conducted some informal audience hand-raise surveys. I was shocked at the number of people at a JavaScript conference that weren't aware of the great JavaScript tools that I took for granted. That's why I wrote the article. I think there's a lot of value in a general ecosystem overview. What kinds of tools are there, what are the tools like? Are there interesting future trends to make note of? I think raising awareness of the overall ecosystem is valuable. The only reason I even mentioned rtype and rfx is because I'm not satisfied with the type tooling available for JavaScript right now. Flow and TypeScript are supersets of JS, so to really embrace those, you have to step away from the standard - something I'm not willing to do at that level. JSDoc is not live code at all, and it easily falls out of sync with your source. It's also awkwardly verbose, and only loosely JavaScript based (essentially copied from Javadoc). React users have React.PropTypes, which is pretty cool, but too React-specific and also awkwardly verbose. I am working on rtype/rfx to fill a void in this department. If there was anything I believe to be better, I'd happily link to that, instead. =)

ryanackley 11y ago

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 11y ago
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"?
- inglor 11y ago
  This. I love the look of awe sublime people have when I open webstorm - perform a "go to definition" and it just works. It's amazing how many capabilities people miss on.
  - Lio 11y ago
    I guess it depends on the code base you're working on. My main experience of using webstorm was on a client's legacy code base. Their policy was that webstorm had to used over any other tool. None of the clever feature like go to definition worked properly and it ended up just dropping back to grepping for symbols project wide. Personally I couldn't see any features you couldn't get from using TernJS and ctags with a quality editor. I found it a bit slow and the keyboard navigation to be about limited. (Not in the main editor so much but in little things like navigating window splits, manipulating pairs, etc)

voltagex_ 11y ago

http://vorlonjs.com/ http://vorlonjs.com/ is pretty amazing.

luisrudge 11y ago

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

Klathmon 11y ago
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 11y ago
  atom + plugins, not just atom. Same with vs code. If we count plugins, emacs and vim are both ide's as well.
  - Klathmon 11y ago
    But the main selling point of Atom is it's plugins. If you don't count the plugins, it's barely even an editor (even syntax highlighting is a plugin). And I agree with the last part as well. Properly configured Emacs and vim can be used as IDEs, however they can also be used as editors.
  - coldtea 11y ago
    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.
coldtea 11y ago
It has an integrated debugger and build options -- which is the minimal to NOT be an editor and be an IDE. It also has some refactorings and even a console and plugins. What do you think it lacks to be an IDE? Note that it's also also in early stages atm.

mattmanser 11y ago

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

lojack 11y ago
It's fast for IO bound applications because of its natural asynchronousity. For CPU bound applications, it's moderately competitive with other interpreted languages, not particularly fast, but acceptable for a lot of things.
xiaoma 11y ago
It's fast compared to Ruby or Python, but slow compared to Java or C#. You really wouldn't want to do number crunching in it anyway, since it only has one type of Number—floats.
coldtea 11y ago
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.

johnjelinek 11y ago

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 11y ago
Much credit is due to Elm and Figwheel, which both served as inspiration for the JavaScript time travel debuggers such as Cerebral and Redux.

markmywords 11y ago

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

niix 11y ago

This author reminds me of the BuzzFeed for JavaScript.

edwinnathaniel 11y ago

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

netheril96 11y ago

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.

peeters 11y ago

> “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 11y ago
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!

tasnimreza 11y ago

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.

romanovcode 11y ago

> “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 11y ago
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. =)
- peeters 11y ago
  So to answer the OP's question, we're not confused, and JS still sucks for refactoring? (as I have to maintain a big monolothic client-side JS app, and good tools for refactoring would be most welcome)
- romanovcode 11y ago
  >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 11y ago

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 11y ago
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#october-15-2015-v20151015 https://github.com/google/closure-compiler/wiki/Releases#oct... [2]: https://github.com/google/closure-compiler/wiki/ECMAScript6#transpilation https://github.com/google/closure-compiler/wiki/ECMAScript6#... (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 11y ago
  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?
ericelliott 11y ago
IMO, the main benefit of Closure Compiler are the type checking errors. However, it's a pretty heavy handed solution for that compared to existing tools like JSDoc + TernJS, or DefinitelyTyped TS annotations. It relies heavily on JSDoc, and I believe JSDoc has had its time, and is on its way out (being replaced by tools like Flow, TypeScript, rtype/rfx).